[vtk-developers] Interesting imaging pipeline information bug

[Berk Geveci]

Great. I agree with this approach.

I would actually love to see this approach for all meta-data - request
pairs. It would be a lot of work to extend it to WHOLE_EXTENT() /
UPDATE_EXTENT() though.

-berk

On Thu, Jan 21, 2016 at 1:42 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Some of the imaging filters (e.g. vtkImageReslice) need the origin and
> spacing in order to compute the UpdateExtent. Without this information,
> these filters would always have to set the UpdateExtent to the whole extent.
>
> For vtkImageReslice, for example, the ResliceTransform is expressed in
> spatial units (e.g millimeters) so figuring out the relationship between
> the output extent and the input extent requires that the origin and spacing
> are known.
>
> So it seems that the solution is as follows, at least for vtkImageReslice:
> 1) if SPACING and ORIGIN are not available, then they are not passed
> downstream (pretty obvious that injecting bogus information into the
> pipeline is bad).
> 2) also, if they are not available, then the UPDATE_EXTENT required for
> proper streaming cannot be computed, so the input update extent would have
> to be set to the whole extent.
>
> Also, for some filters, the origin and spacing are used to compute the
> output extent if the caller doesn't set the output extent explicitly.
>
> Long story short: these filters can be modified so that they don't crap
> out when ORIGIN and SPACING are missing, but we cannot remove ORIGIN and
> SPACING from the pipeline completely without removing some nice features
> and seriously breaking backwards compatibility.
>
> Cheers,
>  - David
>
> On Thu, Jan 21, 2016 at 10:50 AM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>
>> Interesting. This probably sort-of worked previously because the pipeline
>> called vtkImageData::CopyInformationToPipeline() at some point. I am saying
>> sort-of because the pipeline could still have the wrong information at
>> certain stages. In theory, these keys are supposed to be available during
>> RequestInformation(). Otherwise, one can simply used origin and spacing
>> from vtkImageData. The only way for these to be there during
>> RequestInformation() is if the source/filters provided it. So if the source
>> didn't provide it, you would end up with default values during
>> RequestInformation and correct but redundant data during RequestData.
>>
>> Since the pipeline only very partially supports these, I would like to
>> get rid of them OR make them optional. Optional being that filters should
>> check for their existence and not assume they will be always available.
>>
>> Best,
>> -berk
>>
>>
>> On Thu, Jan 21, 2016 at 12:29 PM, David Gobbi <david.gobbi at gmail.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> I was looking through the bugtracker this morning (I know, I shouldn't
>>> do that :-)
>>> and found an interesting one:
>>>
>>>   http://www.vtk.org/Bug/view.php?id=15901
>>>
>>> Basic issue is that most VTK image algorithms do this:
>>>
>>>   double spacing[3], origin[3];
>>>   inputInfo->Get(vtkDataObject::ORIGIN(), origin);
>>>   inputInfo->Get(vtkDataObject::SPACING(), spacing);
>>>
>>> This seems to have worked fine in VTK 5, but in VTK 6, is there any
>>> guarantee
>>> that the pipeline will have ORIGIN and SPACING for vtkImageData?
>>>
>>>  - David
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160121/4efdc3a6/attachment-0001.html>