[vtkusers] vtkSmartVolumeMapper ignoring clipping

[David Gobbi]

Well, I never said the documentation was intelligible, I was just making
sure that you had looked at it, since you hadn't asked what the ClipDataOn
method was for.

If ClipDataOn is not set, then the data is unchanged, only the information
(meta data) is changed.  Specifically, the filter reports the WholeExtent
as whatever you tell it to report.  Because the data itself is not changed,
the result is usually that the WholeExtent is smaller than the Extent.
Downstream mappers and filters are often confused by this, since they
expect that the WholeExtent should always be equal to or greater than the
Extent.

If ClipDataOn is set, then vtkImageClip will allocate a new array of the
requested size as its output, and then copy the corresponding slab of the
input data into its output.

Yes, there is a bit of metadata called WholeExtent that is faithfully
passed down the pipeline.  But, as I said, at least some (or maybe all) of
the volume mappers call UpdateWholeExtent and then render the Extent,
because they expect that after calling UpdateWholeExtent the Extent should
be equal to the WholeExtent.  But it's not, because Update() doesn't
guarantee that you get exactly the extent that you asked for, it merely
guarantees that you get _at least_ the extent you asked for but it might
give you a larger extent than you asked for (that's just the way the
pipeline works).

I consider the bug to have originated in vtkImageClip because it uses
WholeExtent in a way that does not follow the "principle of least
astonishment".  It sets the WholeExtent to be less than the Extent, and of
course that is a condition that many other VTK filters don't check for.
They simply assume that the Extent will always be a subset of the
WholeExtent (why wouldn't they?).  If you call ClipDataOn() on
vtkImageClip, then your pipeline should work, but it will be a bit slower
due to the copy.

As for SetCroppingRegionPlanes, it was always meant to be called
explicitly, it was never meant to be called automatically.  As far as I'm
concerned, changing the code to make it be called automatically would be a
Bad Thing (and at the very least, it would result in backwards
incompatibility).  However, I'm still suggesting it as a potential way for
you to crop the volume.

  David


On Fri, Apr 11, 2014 at 12:40 PM, Richard Whitehead <
richard.whitehead at vivosight.com> wrote:

> David,
>
> Yes I did read it (several times).
>
> "Reduces the image extent of the input.
>
> vtkImageClip <http://www.vtk.org/doc/nightly/html/classvtkImageClip.html> will
> make an image smaller. The output must have an image extent which is the
> subset of the input. The filter has two modes of operation: 1: By default,
> the data is not copied in this filter. Only the whole extent is modified.
> 2: If ClipDataOn is set, then you will get no more that the clipped extent."
>
> I can't say I completely understand.  If ClipDataOn is not set, then what
> does this filter do (nothing?)?
> My understanding was that this extent metadata flowed down the pipeline;
> if it doesn't work that way then I'm still confused.
> Imagine I have a series of filters, I now have to pass this information
> into each of them (since they should each only be filtering valid data),
> keeping track of what's connected to what in a dynamic system, when I was
> just hoping to join one filter into the next.  Exactly the sort of thing
> that the information flow was supposed to achieve, I thought.  I don't
> really see why the volume viewer can't get the whole extent from its info
> object and set SetCroppingRegionPlanes on itself.  You're sayiing this is
> normal behaviour and not a bug, it's a deficiency of the clipper, but in
> this case I don't see what use the clipper is.
>
> Please can you explain, when you say that the clipper ".. simply modifies
> the WholeExtent in the image information instead of actually clipping the
> data.", what is it that it could do to clip the data?  What information
> carries the valid volume, if not the whole extent?  I'm going to be writing
> my own 3D filters soon and I need to understand this stuff.  (And yes, I am
> working my way through the two books, but I can't sit at work and read
> them!).
>
> Many thanks,
>
> Richard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20140411/1600fd25/attachment.html>