[Paraview] application specific questions

[Bond, Karina Paula Carvalho]

Hi Utkarsh,

Thanks for your responses. I have some follow-up questions. Please see below...

Karina,

> 1.       Will Paraview allow me to specify a differ color bar for the 
> CT data ( I'd like to use one of the presets - X-ray) and  the 
> segmented objects after the data has been loaded into Paraview? OR do 
> I have to specify a "Look UP table" in my VTK files? Currently I am 
> just using the "Default" keyword.

ParaView will allow you to pick LUTs for the CT data and the segments both of which you're reading from the vtk files. ParaView likes to share lookup tables when the scalar arrays have the same name. If you run into that situation, you can rename the scalar arrays either in the VTK files or using  the Calculator filter. (I can give you details if it comes to that). ParaView does not respect LUTs specified in the VTK files so "DEfault" is just as good as any other in this case.

<Karina> Ok great. I think for my test cases, I have the scalar name the same for the CT data and the all the segments. I can easily fix this. And then you are saying I should be able to use the "LUT Editor" in Paraview individually for each of my files(*.vtk) after loading them in manually, right?

>
> 2.       Is there a way to have one file for the CT data and all the 
> segmented objects? I will be segmenting a large number of object s 
> from the data and loading them into Paraview one at a time would not 
> be efficient. If there is such a file, will Paraview allow me to 
> view/un-view each object separately?

I am guessing the segmented objects are polygonal (vtkPolyData), in which case you can easily use the "vtm" format to group the files into a sequence of blocks in a Multi-Block dataset. This preserves the information about individual segments as well. YOu can then apply the "Extract Block" filter to select/un-select the blocks you don't want to be seen. This functionality is expected to be improved in future so that you don't have to use the "Extract Block" filter at all.

<Karina> Well, currently I was using "Unstructured Grid" for the segments. Can I use *.vtm to group a bunch of "unstructured grid" blocks of data? If yes, is there some advantage of using "Polydata" instead of "unstructured grid" for the segments? If you cannot group "unstructured grid" blocks then I guess I can use "PolyData" instead.  
Ok the *.vtm format seems like what I need though I will need some time to digest to construct them. So if load my *.vtm file into Paraview, is there a quick way to select a different LUTs for each segment? OR will I have to manually extract each block and select a LUT? I can see how this might get cumbersome as the number of segments increase. I was actually hoping I could somehow specify the LUT in the vtk file. But you said earlier this is not recognized in Paraview, right? Any thoughts?

> 3.        I am currently running Paraview on my desktop (windows 7) 
> which has a pretty good processor and 16GB of RAM. I store the CT data 
> as a structured point VTK file and the segmented objects as 
> unstructured grid VTK files. Some of the CT data sets are pretty large 
> on the order of
> 512x512x1000 points. The volume rendering is not instantaneous when I 
> rotate the object. Is this expected ? And if so , is the delay because 
> of the processor, the RAM or the graphics card?

What version of ParaView are you using? 3.14 has "smarts" in there to pick the fastest volume renderer. ParaView should switch to "cheaper"
rendering mode as you interact. Is the delay something that you see intially and goes away as you keep on moving the mouse or is it present for each movement of the mouse?

<Karina> I am using v3.14.0. For the unstructured grid data , the volume rendering displays almost like a surface rendering while I am moving the mouse. And then there is a delay one I have settled on a position ( not pressing the  left-button on the mouse") and then I see the volume rendering.

 Also, the rendering for the
> unstructured grid VTK is even slower.  I would think this is expected 
> given the delay for the structured grid - I would think Paraview has 
> to work harder because of the unstructured nature of the points. 
> Correct? Is there a more optimal way to present my data to Paraview?

Yes, unstructured will indeed be much slower. It also leads to lot of memory bloat so it's generally not  a good idea to convert a structure-data to unstructured grid unless warranted.
<Karina: OK.

Utkarsh