In the latest stable on Linux, when I enable volume rendering in one of my 16 bit scans (without using a preset), too many control points on the scalar color map is created.
This makes it too tedious to reorganize colors. Is used to be 4-5 points as I recall. Is there a reason why it has increased so much.
The change was necessary to ensure that the volume’s color map is copied to volume rendering color transfer function with acceptable accuracy. We had to find a balance between sufficient color reproduction and the ability to manually edit the color mapping, that’s why the number of control points are limited to 24. See detailed description here:
What could be improved is to change the trivial 256-entry color tables (vtkMRMLColorTableNode) to procedural color nodes (vtkMRMLProceduralColorNode), which define a color transfer function by a few control points. For example, the 256 table items of the gray color node could be replaced by a color transfer function that contains 2 control points. Control points of procedural color nodes are copied to volume rendering transfer functions and they remain easily editable there, because these color maps are typically defined by just a few control points.
The issue is there is no easy way of removing multiple control points quickly. It requires a lot of mouse clicks to remove them one by one.
For these smooth colors (e.g. gray), only the 3-4 control points would suffice (in fact right at the same control point spots at where the ramp for opacity map is.
It is really easy to delete control points: click on one and keep hitting Delete key until all unnedded control points are gone. It takes about 10 seconds to delete all the 24 control points.
Indeed, most of the color maps are “smooth” and can be described by 2 to 5 control points. As I described above, they could be replaced by color transfer functions, but someone would need to reverse-engineer them: determine what control points and color space choice reproduce the original table values.
Thats a lot of clicks, and the main problem it is not a one-time thing, you have to do it again and again for every new transfer function you are creating.
As a comprise could be possible to do a right-mouse click option that says “remove all control points”. Because it would be way faster to add 3-4 points on where you want them to be than to remove 20 one by one.
Making removing all control points easier might be an acceptable workaround for some use cases and for some color maps. However, it would be better to address the root cause of the issue: use the minimum necessary number of control points to define a color map. That would allow convenient editing without losing any information.
Are you only interested in the gray colormap?
Most often for microCT we start with gray and then adjust colors.
Aren’t the uCT… presets good enough as a starting point? If you can detect a micro-CT automatically then you can write a Subject Hierarchy plugin that sets up volume rendering using a uCT preset by default.
Those can be good enough starting points for mineralized tissue scans, but ultimately there is wide range of intensities based on voltage, filter and (if used) contrast solution.
It seems that the goal is not to copy the window-level preset but to make it easier to create good volume rendering transfer functions. To achieve this, we could add more volume rendering presets, and maybe we could also develop a new feature: applying window/level used in n the slice view to shift/scale the volume rendering transfer functions.
