[Paraview] paraview plugin for vtkImageGaussianSmooth, uniform grid slice representation smoothness

Burlen Loring bloring at lbl.gov
Wed Mar 14 16:53:14 EDT 2012


i guess it has to do with the way slice representation works? I'm sure 
Utkarsh knows, and may know a way to make it do what you want.

I hadn't noticed this as our data has such a high resolution that the 
differences between slice and surface representations aren't showing up. 
but zooming in I can see what you mean.

Does the niftivolume reader let you subset the data? you could 
effectively select a slice that way, which has the added benefit of 
reducing your I/O, and use the surface representation to get the look 
you desire.

On 03/14/2012 01:40 PM, FISSELL at pitt.edu wrote:
> Hi Burlen,
>
> When I use 2nd method below, and extract a slice with slice filter, I do
> use Surface representation and that is the look I am trying to achieve.
>
> When I use 1st method below (which is what I am trying to stick with)
> if I switch to Surface representation I get the surface over the entire 3D
> volume, which is not what I want.  I am effectively using the slice
> representation
> to select a slice for viewing.
> I am reading in my 3D volume with the NiftiReader plugin (NIfTIVolumereader)
> and I think it gives me point data.
>
> thanks,
> Kate
>
>
>> Hi Kate,
>>
>> Does changing from Slice representation to Surface representation make a
>> difference? does your dataset have cell or point data?
>>
>> Burlen
>>
>> On 03/14/2012 01:27 PM, FISSELL at pitt.edu wrote:
>>> Hi Burlen,  Utkarsh,
>>>
>>> Thanks much for your detailed answers, and the caveat.
>>> A developer here just told me that vtkImageGaussianSmooth
>>> might not be what I need.  I am trying to achive a non-pixellated
>>> look in a rendering of a slice from a volume.
>>>
>>> Right now I read in the volume and choose a slice representation to
>>> look at a selected plane.  The datatype remains uniform grid.
>>> As per the image intensities in the voume, it looks a bit pixellated.
>>> Changing shading between flat/Gouraud makes no difference, I think
>>> because its not a surface.
>>>
>>> If I read in the volume and then use the slice filter to extract a
>>> slice.
>>> The output slice is polygonal mesh datatype.
>>> I choose a surface representation to look at that slice and there is
>>> a nice smoother look across the pixels.  (Changing shading between
>>> flat/Gouraud
>>> doesn't seem to make a  difference here either.)
>>>
>>> The developer here thinks that even if I pre-smooth my volume with
>>> vtkImageGaussianSmooth the uniform grid slice representation will
>>> look a little pixellated.  Is there a way to get the nice smoothness of
>>> the polygonal mesh surface look on my uniform grid slice representation
>>> ?
>>> My script will just be a little more complicated if I need to call the
>>> slice filter,
>>> so I'd rather not if this can be handled at the representation level.
>>>
>>> thanks
>>> kate
>>>
>>>
>>>> Hi Kate,
>>>>
>>>> It shouldn't be too hard for you to expose the vtkImageGaussianSmooth
>>>> in
>>>> PV.  I have one caveat for you re: using vtkImageGaussianSmooth in
>>>> parallel: when it runs it will trigger a complete re-execution of your
>>>> entire pipeline including the reader.This happens because
>>>> vtkImageGaussianSmooth increases the update extents which, unless
>>>> something has changed in the recent version of PV, would be satisfied
>>>> by
>>>> the reader re-executing. this could cause you some performance related
>>>> issues especially for large data where I/O becomes a significant
>>>> bottleneck. On the other hand, this re-execution would happen only when
>>>> running in parallel and if you have small data it might not be too bad.
>>>>
>>>> I encountered this issue a while back. with our data size the
>>>> additional
>>>> I/O was unacceptable. i wrote a parallel ghost cell generator for image
>>>> data to prevent the pipeline re-execution for operations like kernel
>>>> convolution that require ghost cells. The plugin includes a kernel
>>>> convolution filter as well. To use it you'd have to build and load our
>>>> plugin and add the "image ghosts" filter right before the "kernel
>>>> convolution" filter. Our kernel convolution filter also has a CUDA
>>>> implementation that's about 20x faster than the cpu version (note: CUDA
>>>> stuff is still being developed, still some issue when update extent is
>>>> too large to fit on the gpu). I'm attaching a link to the latest
>>>> release
>>>> of the plugin in case you could use it. It requires a parallel build of
>>>> PV. http://www.hpcvis.com/SciVisToolKit/SciVisToolKit-12.02.tar.gz
>>>>
>>>> Burlen
>>>>
>>>> On 03/14/2012 10:16 AM, FISSELL at pitt.edu wrote:
>>>>> Hi,
>>>>>
>>>>> I didn't see a paraview plugin for the  vtkImageGaussianSmooth.cxx
>>>>> filter
>>>>> in the paraview Filters menus or the filters.xml file.
>>>>> Is there some equivalent ?
>>>>>
>>>>> If not:  am I right that I will need to write a little paraview plugin
>>>>> wrapper in
>>>>> order to be able to use vtkImageGaussianSmooth in a pvpython script ?
>>>>> Any reason other than somewhat ugly parameter specification or lack
>>>>> of interest/time that there isn't a plugin ?
>>>>>
>>>>> thanks
>>>>> kate
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>
>



More information about the ParaView mailing list