[Insight-users] Detaching an image from the pipeline and probing a filter's state from Java.

[Luis Ibanez]

Hi Julia,

Here is how you should disconnect an image from its source filter:



       filter->Update();
       OutputImageType::ConstPointer outputImage = filter->GetOutput();
       outputImage->DisconnectPipeline();  // disconnect from the filter
       filter = NULL; // should indirectly kill the filter

       // at this point you can verify if the image is alive
       // by calling methods such as Print():
       outputImage->Print( std::cout );


Note that the image that you receive from the filter
*MUST* be stored in a SmartPointer, otherwise the
image will not be preserved once we destroy the filter.

In Java that means that you must use the type that has
the termination "_Pointer".


This sequence should work with any ITK filter.



Regards,


     Luis



====================
Julia Smith wrote:
> What's the one-true way to ensure an image is detached from the 
> pipeline? After applying a filter, I'd like to destroy it, but keep the 
> image around and use it as input to other filters. I have a problem 
> where some filters seem to work correctly (connected and 
> object-morphological filters) but binary morphological filters do not.
> 
> I've tried making a new image instance, then graft the output of the 
> doomed filter to the new image, but am still seeing some filters (binary 
> erode/dilate) failing to operate correctly. Although I am not certain 
> this is my problem in this case, I need to have a better way of figuring 
> out what a filter's status is.
> 
> Here I am assuming that I have some condition not satisfied and this is 
> the reason the binary morphological filters above GetOutput() calls 
> return a shifted left and up by one source image after an Update().
> 
> I have to say the transliteration from C++ to Java causes a lot of problems.
> 
> Example: create a filter, generate an image from that filter, 
> GetOutput() and save the reference off in a class' field (the image 
> should not be deallocated as a result -- then again the filter should 
> not be gc-ed as well), garbage collect the filter, and bingo, the image 
> was de-allocated. Next time you interact with your image from Java you 
> get a SegV. And if you have preserved the image by sticking it in a 
> wrapped smart pointer, has the filter reference on the native side 
> remained valid or has the filter instance been destroyed leaving the 
> image with a crap reference?
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users