[vtkusers] How to get the input to a filter as algorithm output?

Bill Lorensen bill.lorensen at gmail.com
Tue Dec 15 12:32:47 EST 2009


itk streams also....

On Tue, Dec 15, 2009 at 12:07 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> But in VTK, especially with streaming, it is definitely wrong.  For
> example, the algorithm itself might request one UpdateExtent, and then
> the when RequestData is called, the mini-pipeline might request a
> different update extent, and everything upstream will re-execute.
>
>   David
>
>
> On Tue, Dec 15, 2009 at 10:00 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> It's not the wrong way in itk. You'll see in the itk snippet I posted
>> that the first filter in the mini-pipeline does set it's input to the
>> filter's input directly.
>>
>>
>> On Tue, Dec 15, 2009 at 11:53 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> Not sure if this "Graft" is really any different from the ShallowCopy
>>> technique that Berk described.  If there's a simple way do what's
>>> needed with ShallowCopy and/or DeepCopy then no changes to VTK are
>>> required, just better documentation.
>>>
>>> The main concern that I have is that the first thing that any beginner
>>> will attempt to do is connect the filter's input directly to their
>>> internal mini-pipeline, and that is the wrong way to do it.
>>>
>>>   David
>>>
>>>
>>> On Tue, Dec 15, 2009 at 9:44 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>>> ITK has mechanisms to support minipipelines and they are used
>>>> frequently in filters. The main facility is a Graft method that each
>>>> DataObject implements. Filters implement GraftOutput() methods that
>>>> Graft() a data object to a filter's output. Here is the documentation
>>>> for an image's Graft method:
>>>>  /** Graft the data and information from one image to another. This
>>>>   * is a convenience method to setup a second image with all the meta
>>>>   * information of another image and use the same pixel
>>>>   * container. Note that this method is different than just using two
>>>>   * SmartPointers to the same image since separate DataObjects are
>>>>   * still maintained. This method is similar to
>>>>   * ImageSource::GraftOutput(). The implementation in ImageBase
>>>>   * simply calls CopyInformation() and copies the region ivars.
>>>>   * Subclasses of ImageBase are responsible for copying the pixel
>>>>   * container. */
>>>>
>>>> It may be an interesting future project to see if such a mechanism can
>>>> be added to VTK.
>>>>
>>>> Bill
>>>>
>>>>
>>>> On Tue, Dec 15, 2009 at 9:41 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>> Where to start... there are a couple important items here.
>>>>>
>>>>> First, there's nothing wrong with directly accessing data objects when
>>>>> you are writing a VTK filter.  Obviously the filter must access the
>>>>> data.  That's completely different from accessing the data objects
>>>>> outside of the filters, and whenever I said "don't mess with the data
>>>>> objects", I really meant "if you want to mess with the data, then
>>>>> write a filter".
>>>>>
>>>>> Second item: In VTK it isn't safe to write a VTK filter that executes
>>>>> other VTK filters inside of it.  Which is really unfortunate, because
>>>>> it sure is a useful thing to be able to do.  But if you look through
>>>>> all the filters in VTK (i.e. vtkAlgorithm derived objects), you will
>>>>> not find a single one that does this.
>>>>>
>>>>> Each vtkAlgorithm has an executive that deals with the vtkInformation
>>>>> and sends Requests to the vtkAlgorithm.  If, internally, you grab the
>>>>> algorithm's input and feed it into your little "internal pipeline",
>>>>> then that internal pipeline will propagate its own requests to the
>>>>> input's producer.  As a result a RequestData in the main (external)
>>>>> pipeline can cause the internal pipeline to update, which causes all
>>>>> sorts of requests to be sent up both the internal and external
>>>>> pipeline before the RequestData completes.  This is a violation of the
>>>>> usual, careful way that the pipeline is supposed to step its way
>>>>> through the various requests.  It may result in undefined behavior of
>>>>> the pipeline.
>>>>>
>>>>> It would be nice if someone devised a recipe for how to safely use a
>>>>> mini-pipeline inside a VTK filter, by using deep copies of the data
>>>>> objects or whatnot, but so far I haven't seen one.  About the closest
>>>>> thing that I've done is use ITK from inside a VTK filter.
>>>>>
>>>>>   David
>>>>>
>>>>>
>>>>> On Tue, Dec 15, 2009 at 1:18 AM, Jérôme <jerome.velut at gmail.com> wrote:
>>>>>> Hi David D.,
>>>>>>
>>>>>> If I understood well, you write VTK pipeline inside a VTK filter. If so, I
>>>>>> also do that *very* often. My way avoids to get the input data, just
>>>>>> connects the input:
>>>>>> blend->AddInputconnection( this->GetInputConnection( ) ); // 'this' being
>>>>>> your vtkAlgorithm-derived filter.
>>>>>>
>>>>>> Secondly, I read with interest the thread in which David G. taught about VTK
>>>>>> pipelining. And I don't think he would have your head for using the
>>>>>> old-fashioned SetInput method. It is just like... old-fashioned, but you
>>>>>> don't "touch" at the data. It is unfair because you add some -maybe-
>>>>>> unuseful static cast, but the integrity of the pipeline is still preserved.
>>>>>>
>>>>>> David G. can you confirm my feelings?
>>>>>>
>>>>>> Jerome
>>>>>>
>>>>>> 2009/12/15 David Doria <daviddoria+vtk at gmail.com>
>>>>>>>
>>>>>>> The first thing I typically do (and I got this by looking at existing
>>>>>>> filters) at the beginning of a RequestData() is:
>>>>>>>
>>>>>>>  vtkInformation *inInfo = inputVector[0]->GetInformationObject(0);
>>>>>>>  vtkImageData *input = vtkImageData::SafeDownCast(
>>>>>>>      inInfo->Get(vtkDataObject::DATA_OBJECT()));
>>>>>>>
>>>>>>> However, now I have an actual object, so I have to do things like the
>>>>>>> following:
>>>>>>>
>>>>>>>  vtkSmartPointer<vtkImageBlend> blend =
>>>>>>> vtkSmartPointer<vtkImageBlend>::New();
>>>>>>>  //blend->AddInputConnection(input->GetOutputPort()); //can't do this
>>>>>>> because 'input' is not an algorithm output
>>>>>>>  blend->AddInput(input);
>>>>>>>
>>>>>>> David G. would have my head for this! How should this be done instead?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> David D.
>>>>>>> _______________________________________________
>>>>>>> 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 VTK FAQ at:
>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>
>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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 VTK FAQ at:
>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> 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 VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>
>>>>
>>>
>>
>



More information about the vtkusers mailing list