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
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview

Reply via email to