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

[FISSELL at pitt.edu]

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
>
>
>