[ITK-users] [ITK] streaming TileImageFilter for arbitrary number of inputs

Fri Jul 22 08:49:03 EDT 2016

Hi,

Who is holding the pointer to the newly created ImageFileReader outside of the loop? For that type of operation I’ll frequently just stash smart pointers into a std::vector or list.

Regarding the example, look at the scope of the smart pointers with respect to the execution of the pipeline.

HTH,
Brad

> On Jul 22, 2016, at 6:00 AM, Grothausmann, Roman Dr. <grothausmann.roman at mh-hannover.de> wrote:
> 
> Many thanks Brad for Your detailed reply. I understand now the problems concerning streaming TileImageFilter.
> However I still wonder why my non-streaming version also does not work any more after moving the creation of reader instances into the for-loop:
> https://github.com/romangrothausmann/ITK-CLIs/blob/ebfc0aea37d28cbbf2bb22c3f56be52453cebde9/tile.cxx#L46-L50
> 
> Is this construct inappropriate for the TileImageFilter?
> Why does it work for:
> https://itk.org/Doxygen/html/SphinxExamples_2src_2Filtering_2ImageGrid_2AppendTwo3DVolumes_2Code_8cxx-example.html#_a2
> 
> On 21/07/16 15:41, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote:
>> Hello,
>> 
>> The TileImageFilter does not fully stream [1]. The filter also has some odd
>> behavior, and other older implementation details. If you are going to work on
>> a streaming pipelines it is best practice to examine the filters to determine
>> how the Requested regions behave.
>> 
>> However, there is no reason that the TileImageFilter algorithm couldn’t
>> support streaming. It is just a matter of code and a bunch of testing. A
>> contribution for this issue would be welcomed! Also this filter is in need a
>> refactoring and bring it up to several other best practices. There are
>> several issue with the current implementation that would cause it not to work
>> correctly with a streaming pipeline, and cause excessive execution.
>> 
>> You can also use the PipelieMoniotorImageFilter to record and print the
>> pipeline interaction during Update [2]. This information helps with debugging
>> and diagnosing problems, but if the pipeline is mis-behaving ( as the
>> TileImageFilter may ), the information may not be correct.
>> 
>> I have tried similar streaming with the JoinSeriesImageFilter. However I ran
>> into many problems with having hundreds of ImageIO being utilized at the same
>> time. There were problems with having too many files open at the same time
>> along with ImageIO libraries that couldn’t handle single threaded access to
>> multiple files.
>> 
>> [1]
>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/ImageGrid/include/itkTileImageFilter.hxx#L125-L136
>> 
>> 
> [2] https://itk.org/Doxygen/html/classitk_1_1PipelineMonitorImageFilter.html
>> 
>>> On Jul 21, 2016, at 6:41 AM, Grothausmann, Roman Dr.
>>> <grothausmann.roman at mh-hannover.de> wrote:
>>> 
>>> Dear mailing list members,
>>> 
>>> 
>>> Based on the examples for TileImageFilter I've created a working CLI to
>>> append an arbitrary number of inputs
>>> (https://github.com/romangrothausmann/ITK-CLIs/blob/4fdf5778022598dcf83fb38e6002df72bd67bef3/tile.cxx).
>>> 
>>> 
> As there is an example that does not apply Update and DisconnectPipeline on the readers (https://itk.org/Doxygen/html/SphinxExamples_2src_2Filtering_2ImageGrid_2AppendTwo3DVolumes_2Code_8cxx-example.html#_a2) 
>>> I changed my code such that a reader instance is created for each input in
>>> a for-loop:
>>> https://github.com/romangrothausmann/ITK-CLIs/commit/ebfc0aea37d28cbbf2bb22c3f56be52453cebde9
>>> 
>>> 
>>> 
> However, the update from the writer seems not to propagate to the readers whether streaming or not. Can the TileImageFilter not stream in such a case or are further modifications necessary?
>>> 
>>> Thanks for any help or hints Roman
>>> 
>>> 
>>> On 18/08/14 17:01, Michka Popoff wrote:
>>>> Hi
>>>> 
>>>> Going the way described in the CreateVolume example is the way to go.
>>>> 
>>>> Why did you uncomment the DisconnectPipeline() call and Update() call in
>>>> the for loop ? They need to stay there, else you will always use the last
>>>> image. That’s why you see the same image, the single update call will be
>>>> triggered at the end of the script and read only one image.
>>>> 
>>>> You don’t need to call tileFilter->Update(), you can remove this line.
>>>> The writer->Update() will take care of the pipeline update. As a bonus,
>>>> you may wrap your writer->Update() call, to fetch errors at the end of
>>>> the pipeline:
>>>> 
>>>> try { writer->Update(); } catch( itk::ExceptionObject & error ) {
>>>> std::cerr << "Error: " << error << std::endl; return EXIT_FAILURE; }
>>>> 
>>>> I made a little Python prototype, the syntax is a little bit different
>>>> than in C++ but it gives you the main idea.
>>>> 
>>>> Michka
>>>> 
>>> 
>>> -- Dr. Roman Grothausmann
>>> 
>>> Tomographie und Digitale Bildverarbeitung Tomography and Digital Image
>>> Analysis
>>> 
>>> Institut für Funktionelle und Angewandte Anatomie, OE 4120 Medizinische
>>> Hochschule Hannover Carl-Neuberg-Str. 1 D-30625 Hannover
>>> 
>>> Tel. +49 511 532-2900 _____________________________________ Powered by
>>> www.kitware.com
>>> 
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>> 
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://www.kitware.com/products/protraining.php
>>> 
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>> 
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/insight-users
>>> _______________________________________________ Community mailing list
>>> Community at itk.org http://public.kitware.com/mailman/listinfo/community
>> 
> 
> -- 
> Dr. Roman Grothausmann
> 
> Tomographie und Digitale Bildverarbeitung
> Tomography and Digital Image Analysis
> 
> Institut für Funktionelle und Angewandte Anatomie, OE 4120
> Medizinische Hochschule Hannover
> Carl-Neuberg-Str. 1
> D-30625 Hannover
> 
> Tel. +49 511 532-2900