[vtkusers] SetInputData() vs SetInputConnection()

[Maarten Beek]

I replaced my ProcessorClass by vtkImageThreshold and the strange behaviour disappeared.

I guess my ProcessorClass is wrong.... :-(
So my question now is: how to correctly write a vtkImageAlgorithm that has an internal pipeline?

I have looked at vtkImageOpenClose3D, but (apparently!) don't really understand SetSharedInputInformation(), SetSharedOutputInformation(), and ReportReferences().

Maarten

On Wednesday, April 30, 2014 11:37:23 AM, Berk Geveci <berk.geveci at kitware.com> wrote:
 
Confusing.

Can you compile VTK with VTK_DEBUG_LEAKS set to ON (it is an advanced CMake flag) and see if you get reports of any objects leaking at exit?




On Tue, Apr 29, 2014 at 4:40 PM, Maarten Beek <beekmaarten at yahoo.com> wrote:

Some additional info I found:
>
>
>When I use SetInputConnection(), I see only one object being destructed as well (like with using SetInputData w/o RemoveAllInputs()).
>However the memory usage with SetInputConnection() is 378Mb as opposed to 430Mb with SetInputData(): the difference is about 50Mb (the size of the tiff image).
>
>
>As I said in the earlier email I sent today, I am loading 2 images into 2 different ProcessorClass objects, or at least that's what I think. The images are similar and come from the same file, but the reader (which is destroyed by vtkSmartPointer when it gets out of scope?) cannot be that smart to realize it can tell the ProcessorClass objects to share the image, can it?
>
>
>Maarten
>
>On , Maarten Beek <beekmaarten at yahoo.com> wrote:
> 
>I see (only reporting lines with reference to ReferenceCount):
>
>-> activate()
>vtkImageData (00000000070808D0):UnRegistered by vtkInformation(...), ReferenceCount = 3
>
>vtkImageData (00000000070ADA70):UnRegistered by vtkInformation(...), ReferenceCount = 3
>
>->deactivate() (without RemoveAllInputs() call)
>vtkImageData (00000000070ADA70):UnRegistered by vtkTrivialProducer (...), ReferenceCount = 2
>
>vtkImageData (00000000070ADA70):UnRegistered by vtkInformation (...), ReferenceCount = 1
>
>vtkImageData (00000000070ADA70):Registered by
 vtkTrivialProducer (...), ReferenceCount = 2
>
>vtkImageData (00000000070ADA70):UnRegistered by vtkGarbageCollectorImpl (...), ReferenceCount = 0
>
>
>
>vtkObject (00000000070ADA70): Destructing!
>
>
>
>
>-> activate()
>vtkImageData (0000000006FA15D0):UnRegistered by vtkInformation(...), ReferenceCount = 3
>
>vtkImageData (0000000006FB0180):UnRegistered by vtkInformation(...), ReferenceCount = 3
>
>
>->deactivate() (with RemoveAllInputs() call)
>vtkImageData (0000000006FA15D0):UnRegistered by vtkTrivialProducer (...), ReferenceCount = 2
>
>vtkImageData (0000000006FA15D0):UnRegistered by vtkInformation (...), ReferenceCount = 1
>
>vtkImageData (0000000006FA15D0):Registered by vtkGarbageCollectorImpl (...), ReferenceCount = 2
>
>
>vtkImageData (0000000006FA15D0):UnRegistered by vtkGarbageCollectorImpl (...), ReferenceCount = 0
>
>
>vtkObject (0000000006FA15D0): Destructing!
>
>
>vtkImageData (0000000006FB0180):UnRegistered by vtkTrivialProducer (...), ReferenceCount = 2
>
>vtkImageData
 (0000000006FB0180):UnRegistered by vtkInformation (...), ReferenceCount = 1
>
>vtkImageData (0000000006FB0180):Registered by vtkGarbageCollectorImpl (...), ReferenceCount = 2
>
>
>vtkImageData (0000000006FB0180):UnRegistered by vtkGarbageCollectorImpl (...), ReferenceCount = 0
>
>
>vtkObject (0000000006FB0180): Destructing!
>
>
>
>
>It makes sense in my code that I create 2 copies of vtkImageData, loaded into different ProcessorClass objects, but I don't understand why the first copy doesn't get destructed when I am not using 
>RemoveAllInputs()
>
>
>Maarten
>
>On Tuesday, April 29, 2014 10:39:24 AM, Berk Geveci <berk.geveci at kitware.com> wrote:
> 
>Hmmm. This is fishy. I wonder if there is a leak somewhere in the new code. Can you try something for me? Add a reader->GetOutput()->DebugOn() right after SetInputData() and re-run. Do you see the object reference count go to 0 in deactivate?
>
>
>-berk
>
>
>
>On Mon, Apr 28, 2014 at 11:53 AM, Maarten Beek <beekmaarten at yahoo.com> wrote:
>
>Hi all,
>>
>>
>>I bumped into something I don't really understand:
>>
>>
>>
>>void MyClass::activate()
>>{
>>    vtkSmartPointer<vtkTIFFReader> reader = vtkSmartPointer<vtkTIFFReader>::New();
>>    <...>
>>    reader->Update();
>>
>>
>>    m_Processor->SetInputData(reader->GetOutput());
>>}
>>
>>
>>void MyClass::deactivate()
>>{
>>    if( 0 != m_Processor )
>>    {
>>        m_Processor->RemoveAllInputs();
>>        m_Processor->Delete();
>>        m_Processor = 0;
>>
>>    }
>>}
>>
>>
>>In the deactivate() function I do need the RemoveAllInputs() call to avoid a 50MB memory leak (100 slice 512x512 tiff). I don't need RemoveAllInputs() when I use SetInputConnection(reader->GetOutputPort()) in the activate() function.
>>
>>
>>Why is the difference between SetInputData() and SetInputConnection() with regards to memory management?
>>
>>
>>m_Processor is derived from vtkImageAlgorithm and has an internal pipeline inside the RequestData(), processing the image data with vtkImageConvolve, vtkImageSobel2D, vtkImageThreshold and a few more.
>>
>>
>>int ProcessorClass::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector* outputVector)
>>{
>>    vtkInformation* outInfo = outputVector->GetInformationObject(0);
>>    vtkImageData* output = vtkImageData::SafeDownCast(outInfo->Get(vtkdataObject::DATA_OBJECT()));
>>
>>
>>    if( this->GetMTime() > this->BuildTime )
>>    {
>>        this->buildPipeline();
>>    }
>>
>>
>>    if( 0 != this->GetNumberOfInputConnections(0) )
>>    {
>>        this->MergeFilter->Update();
>>        output->ShallowCopy(this->MergeFilter->GetOutput());
>>    }
>>
>>
>>    return 1;
>>}
>>
>>
>>
>>
>>
>>Maarten
>>
>>_______________________________________________
>>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
>>
>>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20140430/f2ee5c9a/attachment.html>