Color maps for multiple representations in single pqRenderView in custom application remain synchronised even when "UseSeparateColorMap" property is true
I have a custom Paraview client application that is used to display astronomical data (with the data living on a standard pvserver
instance). As part of it, I display multiple 2D images in the same renderview (an instance of pqRenderView*
). The images are loaded and controlled through a container class that owns the object and redirects commands to the proxies. The images are all instantiated and loaded separately, to make sure that arbitrary numbers of images can be loaded.
Here is a snippet from the container class header to define some of the variables referred to later on:
vtkSMSessionProxyManager* serverProxyManager;
pqObjectBuilder* builder;
pqPipelineSource* imageSource;
pqDataRepresentation* imageRep;
vtkSMProxy* imageProxy;
vtkSMTransferFunctionProxy* lutProxy;
pqRenderView* viewImage;
The renderview and objectBuilder are passed through from the class that initialises the server connection, creates the view, and governs the user interaction. It keeps a vector array of the container class that controls the images.
The images are created as follows:
QString filename;
imageSource = pqLoadDataReaction::loadData({ filename });
imageRep = builder->createDataRepresentation(this->imageSource->getOutputPort(0), viewImage);
imageProxy = imageRep->getProxy();
vtkSMPropertyHelper(imageProxy, "Representation").Set("Slice");
auto separateProperty = vtkSMPVRepresentationProxy::SafeDownCast(imageProxy)->GetProperty("UseSeparateColorMap");
vtkSMPropertyHelper(separateProperty).Set(1);
vtkSMPVRepresentationProxy::SetScalarColoring(imageProxy, "FITSImage", vtkDataObject::POINT);
imageProxy->UpdateVTKObjects();
The colour map for each image is initialised by the following:
vtkNew<vtkSMTransferFunctionManager> mgr;
lutProxy = vtkSMTransferFunctionProxy::SafeDownCast(mgr->GetColorTransferFunction("FITSImage", imageProxy->GetSessionProxyManager()));
When the user changes the colour map, this is what I use to change the colour map:
if (vtkSMProperty *lutProperty = imageProxy->GetProperty("LookupTable")) {
auto presets = vtkSMTransferFunctionPresets::GetInstance();
lutProxy->ApplyPreset(presets->GetFirstPresetWithName(name.toStdString().c_str()));
vtkSMPropertyHelper(lutProperty).Set(lutProxy);
lutProxy->UpdateVTKObjects();
vtkSMPVRepresentationProxy::RescaleTransferFunctionToDataRange(imageProxy, false, false);
vtkSMPVRepresentationProxy::SetScalarBarVisibility(imageProxy, viewImage->getProxy(), true);
imageProxy->UpdateVTKObjects();
this->colourMap = name;
return 1;
}
If the user chooses to select log scale, that is changed by this snippet:
if (auto logProperty = lutProxy->GetProperty("UseLogScale"))
{
double range[2];
vtkSMTransferFunctionProxy::GetRange(lutProxy, range);
vtkSMCoreUtilities::AdjustRangeForLog(range);
this->logScale = true;
vtkSMTransferFunctionProxy::RescaleTransferFunction(lutProxy, range);
vtkSMPropertyHelper(logProperty).Set(1);
changeColorMap(this->getColourMap());
lutProxy->UpdateVTKObjects();
imageProxy->UpdateVTKObjects();
return 1;
}
For some reason, if I just change the log scaling property, the actual colour map resets to the default, which is why I change the colour map again after setting the scaling property.
Each image is initialised separately and added to the pqRenderView. However, despite setting the “UseSeparateColorMap” property to true on initialising the image, all the images in the renderview has their colour maps synchronised. If any of the images have their colour maps changed, all the others will follow suit.
I have tested the value of the "UseSeparateColourMap" property at various points in my program after first initialisation using the below code snippet, and at every point after initialisation it returns true.
int sep;
vtkSMPropertyHelper(vtkSMPVRepresentationProxy::SafeDownCast(imageProxy)->GetProperty("UseSeparateColorMap")).Get(&sep);
if (sep == 1)
std::cerr << "Setting colour map with \"UseSeparateColourMap\" set to true!" << std::endl;
This issue was initially reported on the Paraview discourse before being referred here.