[vtkusers] vtkSmartVolumeMapper ignoring clipping

[David Gobbi]

Hi Richard,

Did you read the doxygen web page for vtkImageClip before posting your
question?

If your intent is simply to crop the volume rendering, then you can apply
the cropping in the mapper (using
vtkVolumeMapper::SetCroppingRegionPlanes()) instead of using a filter to
crop the data beforehand.

In general, my advice is to just try different ways of doing the cropping
until you find out which way gives the best performance.

  David



On Fri, Apr 11, 2014 at 9:21 AM, Richard Whitehead <
richard.whitehead at vivosight.com> wrote:

> David,
>
> Thanks very much for replying.  The filter is actually doing exactly what
> I want - I don't want the data to be altered or reallocated, I just want to
> mark its extent as reduced.  It sounds like it should be doing a bit more ("physically
> clipping the Extent"?) and then the upstream filters would understand, is
> that correct?
>
> Can you advise whether I should instead use another filter (such as
> vtkImageReslice or vtkExtractVOI), or would it be better to continue with
> what I have done which is to remember the clipping in my app?  Performance
> is an issue here, the extent may be updated several times a second, and the
> memory volume is reasonably large.
>
> Many thanks,
>
> Richard
>
>
>
>
> On 11 April 2014 13:49, David Gobbi <david.gobbi at gmail.com> wrote:
>
>> Hi Richard,
>>
>> The vtkImageClip filter performs what I consider to be an undesirable
>> optimization, by default it simply modifies the WholeExtent in the
>> image information instead of actually clipping the data.  See the
>> doxygen page on this filter for more info.
>>
>> The volume mappers generally ignore the WholeExtent, instead what
>> they do is ask the pipeline to update the whole image, and then they
>> render whatever data is present.  Since vtkImageClip only modifies the
>> WholeExtent info, without physically clipping the Extent, the effects
>> of vtkImageClip are ignored.
>>
>> I do not consider this to be a bug in the volume mappers.  I consider
>> it to be an unwise optimization in vtkImageClip that does something
>> that is unexpected not only to users, but also to downstream filters
>> and mappers.
>>
>>   David
>>
>> On Fri, Apr 11, 2014 at 4:28 AM, Richard Whitehead
>> <richard.whitehead at vivosight.com> wrote:
>> >
>> > This looks like a bug in VTK?
>> >
>> > I'm visualising a memory volume (vtkImageData) which is then connected
>> to a
>> > vtkImageClip so that only the valid parts of the volume are rendered.
>> >
>> > Connecting that clipper into a vtkImageViewer2 to view slices works
>> fine;
>> > the invalid part of a slice is clipped off.
>> >
>> > But connecting that same clipper into a vtkSmartVolumeMapper, which is
>> set
>> > as the mapper of a vtkVolume, the display always shows the whole extent
>> of
>> > my memory volume, ignoring the clipping.
>> > I have set CroppingOn on the mapper, no effect.
>> >
>> > If I set the mapper's clipping region with SetCroppingRegionPlanes then
>> it
>> > clips as expected, but I would have expected the mapper to take notice
>> of
>> > the "whole region" given by the clipper without me having to pass the
>> clip
>> > information around my program myself.
>> >
>> > Please can someone tell me if this is wrong, or if not for now perhaps a
>> > cheat so I can get the clipping region from the clipper and set it on
>> the
>> > mapper.
>> >
>> > Many thanks,
>> >
>> > Richard
>>
>
>
>
> --
>
> Richard Whitehead *-* Senior Imaging Engineer
>
> *Michelson Diagnostics Ltd*
>
> *M:* +44 (0)7905 955276   *T:* +44 (0)20 8308 1695
>
> *E: *richard.whitehead at vivosight.com   *W:* www.vivosight.com
>
>
> <http://www.vivosight.com/>
>
>
> Michelson Diagnostics Ltd, 1 Grays Farm Production Village, Grays Farm
> Road, Orpington, Kent  BR5 3BD, UK
>
> Registered Office: 3 Shearwater, Maidstone, ME16 0DW.     Registered in
> England No. 5732681
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20140411/05b5ab3f/attachment.html>