Set desired scale in vtkColorTransferFunction

Hello everyone!

I’m currently working with vtkColorTransferFunction and in the documentation I found the following constants:

export const ColorSpace = {
   RGB: 0,
   HSV: 1,
   LAB: 2,
   DIVERGING: 3,
};

export const Scale = {
   LINEAR: 0,
   LOG10: 1,
};

vtkColorTransferFunction object has a method setColorSpace(ColorSpace.LAB) to set ColorSpace, but I couldn’t find something similar for Scale.

So my question is how to set the desired Scale, for example, if I want to change its value by clicking on a checkbox?

for some reason model.scale is being used, but no API let it access it.
You can create a PR to expose it with macro.setGet(...)

Since my level of knowledge allows me to work with the vtk.js library only as a user through trial and error, could you, as an experienced developer and part of the vtk team, correct this issue, especially since it is unlikely to take much time and, if I understand correctly, the absence of such a method came as a surprise even to you.

Thank you very much in advance!

It looks like the perfect time to make your first contribution. You gotta start somewhere :slight_smile:

I’m happy to help you though.

You might want to consider this other example that exposes the viewType enum. By exposing, I mean it creates getViewType() and setViewType() accessors.

Okay, if I understand you correctly, since everything vital already exists for scale then I just need to add 'scale' in the same row with 'colorSpace' and other strings in macro.setGet(publicAPI, model, ['useAboveRangeColor', 'useBelowRangeColor', 'colorSpace', 'discretize', 'numberOfValues']); and that’s it?

Or is there anything else that needs to be done?

Yes, that’s basically it.
Problem is, scale is an enum. There is a special setGet signature for such enums. You can see an example here: vtk-js/Sources/Widgets/Core/WidgetManager/index.js at master · Kitware/vtk-js · GitHub

Hth,
Julien.

Alright, got it. So the following should be correct:

macro.setGet(publicAPI, model, ['useAboveRangeColor', 'useBelowRangeColor', 'colorSpace', 'discretize', 'numberOfValues', { type: 'enum', name: 'scale', enum: Scale }]);

even despite the colorSpace is also enum?

That looks reasonable to me.
You might also want to “fix” the colorspace and apply the {type: 'enum' ...} signature on it as well.

Yes, I could also add a similar entry for colorSpace, however for now it works fine just with the specification as a string rather than a special object with the enum qualification. Is it worth changing the colorSpace if it works fine now?

It is just “continuous improvement”. When we spot a bug, it’s better to fix it right away. It avoids wasting time next time to fix it.

I did a PR a few days ago, but it seems like it went unnoticed. Could you tell me please if everything is correct and whether any additional actions are required from me in order for this PR to be merged?