TransferFunction colour space
Fingolfin1196 opened this issue · comments
Due to my dissatisfaction with ParaView, I have implemented a simple volume renderer using OSPRay to visualize the results of some simulations I have run. While most aspects now work as intended, I have not been able to recreate the default transfer function of ParaView, which consists of the colours #3b4cc0, #dddddd, and #b40426 in HTML notation, using OSPRay. I have interpolated these colours in sRGB to generate 256 colours, converted those to linear RGB, and used that to set the color property of the TransferFunction that I use in my VolumetricModel. The results are rendered to a framebuffer using the OSP_FB_SRGBA format and stored directly to a PNG file using OpenImageIO (the results are equivalent to the PPM helper from OSPRay). However, using the scivis renderer and appropriate opacity values, I get the following result:
This is in contrast to ParaView using its OSPRay backend (only the strip at the centre is correct, the outer parts exhibit some interpolation issues that are not relevant for this issue):
Since the colours are off significantly and I have not been able to identify the actual colour space in which the transfer function colours need to be specified, I see no solution other than a custom lookup table to find the values that OSPRay requires to output the correct colours, which is obviously a bad approach. I would be very glad about some help resolving this issue.
Could be related to #492
The approach you describe sounds right: the color values of OSPRay's transferfunction are in linear RGB space and thus should be converted vom sRGB. However, it looks like that ParaView does not do this: https://gitlab.kitware.com/vtk/vtk/-/blob/master/Rendering/RayTracing/vtkOSPRayVolumeMapperNode.cxx#L405
Thus, to get the same result as in ParaView you may need to use the colors as is, without sRGB-to-linear conversion.
@demarle thoughts?
Dropping the conversion does not solve the issue. If I use OSP_FB_SRGBA as the format of the framebuffer, the gamma is obviously wrong (in addition to the hues being wrong):
If I use OSP_FB_RGBA8 (i.e. I pretend to use linear RGB everywhere), I get a similar result as before:
How are you interpolating between those three (Red, White and Blue) values? ParaView's default interpolation mode is "diverging". If your interpolation is different, it could explain the differences you are seeing between your and ParaView+OSPRay's colors.
See https://vtk.org/doc/nightly/html/classvtkColorTransferFunction.html#a7308a34ac7b702136fe9298946b720db and https://gitlab.kitware.com/vtk/vtk/-/blob/master/Rendering/Core/vtkColorTransferFunction.cxx#L155 for the implementation. In VTK2OSPRay the interpolation should always be close to VTK's GL backend because we populate OSPRay's LUT with whatever VTK's TF gives us (https://gitlab.kitware.com/vtk/vtk/-/blob/master/Rendering/RayTracing/vtkOSPRayVolumeMapperNode.cxx#L399).
The interpolation was indeed the difference: When using RGB interpolation in ParaView, I get a very similar result to the original OSPRay image, and if I use diverging interpolation for the transfer function in OSPRay, I get the expected output:
Thank you very much for pointing out the interpolation and providing the relevant links to VTK that helped me implement the diverging interpolation in my code. My issue is resolved.