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

Mon Jul 25 08:07:30 EDT 2016

Many thanks Brad for the hint of the smart pointer scope and storing it in 
std::vector, at least the non-SDI version now works as expected.

On 22/07/16 14:49, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote:
> 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
>

-- 
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