[Paraview] Best file format for volume rendering in ParaView?

[Berk Geveci]

Disclaimer: I am not a medical guy and I don't deal with volumes very often.

I suspect that your best bet is to use ITK (or VTK) filters to somehow
create one or more axis-aligned, non-overlapping volumes out of the
original data. This could be done as a pre-processing step or within the
reader. I don't know which filters would be best for this. I suspect that
you will need at least vtkImageReslice. You might need to go to the ITK or
VTK list for more detail. Once you have non-overlapping, axis-aligned
volumes, you can volume render them the usual way. It would be pretty easy
to write a volume representation that can handle a multi-block dataset of
non-overlapping images.

Best,
-berk

On Wed, May 23, 2012 at 3:38 AM, Christoffer Green <
christoffer.green at gmail.com> wrote:

> Hello
>
> Thank you for the suggestions.
>
> The use case is that I am currently writing an application (based on
> ParaView) that is going to be used by doctors/researchers for visualizing
> MRI data of blood flow (some more information can be found here:
> http://www.jcmr-online.com/content/14/S1/W14 ). This means that the user
> has some data files (volumes of velocity data, 2d image planes, none of the
> data is axis aligned, all of it overlapping) and they need to get this data
> in to the application and I am currently trying to figure out what the
> recommended way of doing this would be. I can not rely on the users having
> any deep knowledge of ParaView, 3d math or even above basic general
> computer skills so asking them to write macros or manually rotating the
> data might not work well :)
>
> The data->cleantogrid->volume render workflow sounds interesting. My
> current problem with it (as well as using mergeblocks instead of
> cleantogird) is that it appears to take about 8 hours to produce a result
> that way (I do not know what that result is yet since I have not seen it
> through to the end). This is off course unacceptably slow but perhaps this
> is a bug?
>
> But if I understand you correctly you are saying that unstructured grid
> is the data format that would be best for this. Is there any file format
> that when imported is an unstructured grid by default and would doing it
> that way speed things up massively?
>
> BR/ Christoffer
>
>
> On Tue, May 22, 2012 at 3:39 PM, Berk Geveci <berk.geveci at kitware.com>wrote:
>
>> What is your end goal? Volume rendering a collection of MRI volumes
>> (together? non-overlapping?) that may not be axis aligned? One way of doing
>> this in ParaView would be to convert them to unstructured grid (by using
>> clean-to-grid for example) but this comes at a large memory overhead and
>> performance overhead. The simpler and more efficient way of doing it is to
>> load each MRI volume as a separate image data and then use the
>> Transformation setting from the Display panel to position and orient them
>> as necessary. It would pretty straightforward to write a macro to do all of
>> this automatically given a particular file.
>>
>> On Mon, May 21, 2012 at 7:57 AM, Christoffer Green <
>> christoffer.green at gmail.com> wrote:
>>
>>> Hello
>>>
>>> What are your thoughts on the best file format to use when doing volume
>>> rendering in ParaView?
>>>
>>> I have been trying out the ensight format and the vtk format and find
>>> them less then ideal, is there anything better?
>>>
>>> Findings for ensight:
>>> ParaView does not appear to support volume rendering of ensight files
>>> due to it not supporting volume rendering of multi-block datasets and the
>>> ensight reader always imports things in multi block mode. There are ways to
>>> get around this (tetrahedralize together with calculator filter) but the
>>> end results appear to be extremely slow when volume rendering.
>>>
>>> Findings for vtk:
>>> Importing a volume of data as image data and volume rendering it works
>>> well but image data in the vtk format must always be aligned to the global
>>> orthogonal (x, y, z) axes so it cannot be rotated. Since we have multiple
>>> data files that all must be positioned and rotated in a scene (MRI volumes
>>> and image planes) this makes things uncomfortable. There is a transform
>>> filter in ParaView but after applying it to image data it changes the data
>>> type to curvalinear grid which ParaView cannot volume render.
>>>
>>>
>>> What are the alternatives?
>>>
>>> BR/ Christoffer
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20120524/93861db7/attachment.htm>