[Insight-developers] Pipeline's excessive GenerateOutputInformation causes unnecessary GenerateData

[Bradley Lowekamp]

Hello,

This bug I found causes the pipeline re-executed under "normal" (non-streaming, non-release data, non-inp lace, aka normal) situations. I have attached an example which shows the problem I have discovered. The output is as follows:

--------------- First Update ---------------
-------- Start ShrinkImageFilter "shrinking" ShrinkImageFilter (0x1015b3660)
Progress  | 0 | ...  0.994886 | 1
Filter took 0.000846148 seconds.
-------- End ShrinkImageFilter "shrinking" 
I0: 223
F0: 10
I1: 227
F1: 23
I2: 231
F2: 41
--------------- Second UpdateOutputInformation ( no modification should occour )---------------
I0: 223
F0: 10
I1: 235 [<- modified!]
F1: 23
I2: 231
F2: 41
--------------- Second Update ( no generation should occour )---------------
-------- Start ShrinkImageFilter "shrinking" ShrinkImageFilter (0x1015b3660)
Progress  | 0 ...  0.994886 | 1
Filter took 0.000789046 seconds.
-------- End ShrinkImageFilter "shrinking" 



This shows that the GenerateOutputInformation is executed a second time, and modifies the output of the shrink image filter. This then causes the remaining pipeline to re-execute! Because no parameters are changed, ProcessObject::GenerateOutputInformation was not expected to be executed.

Why is it executed?
The answer lies in ProcessObject::UpdateOutputInformation. This method essentially compares the modified time of the input, to the time the GenerateOutputInformation was last called. The GenerateData methods are called after the UpdateOutputInformation phase of the pipeline, which means that after an "Update" ProcessObject::m_OutputInformationMTime is always less then the input's modified time ( if the input was connected to a filter which previously execute). This means that all pipelined ImageToImage filters always call ProcessObject::GenerateOutputInformation for every pipeline Update!

Why is this not always a problem?
The default implementation of ImageToImageFilter::GenerateOutputInformation copies the input information to the output. The first time this methods is executed it sets the correct information, and modifies the time. However, the second time the smart set methods, notices the current value matches the value to be set, and does not modify the time. Therefore, filters who use the default implementation of GenerateOutputInformation do not exhibit this bug.

Which ones do?
The filters who call Superclass::GenerateOutputInformation, and then change the values. Because these filters set the output information to the input, then change the value to an internally calculated one, the output will be modified. Causing the pipeline to be re-executed! The ShrinkImageFilter is one example, many of the filters which change spacing or size will cause this issue as well.

Solutions?
I see two approaches. 1) Don't let the methods be executed excessively. This would likely require a output information time stamp in DataObjects. 2) Don't let the GenerateOutputInformation methods change the time if not needed. I could envision some type of save current output information, set new stuff, then if it didn't change set the old modified time. 


I think solution #1 is better. It does assume that the output information only depends on other output information. 



Thoughts on if this is really a bug, if you think that the GenerateOutputInformation should usually be called or other views are appreciated!


Brad



========================================================
Bradley Lowekamp  
Lockheed Martin Contractor for
Office of High Performance Computing and Communications
National Library of Medicine 
blowekamp at mail.nih.gov


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20100510/d1ec46d1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itkGenerateOutputInformationTest1.cxx
Type: application/octet-stream
Size: 2658 bytes
Desc: not available
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20100510/d1ec46d1/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20100510/d1ec46d1/attachment-0001.htm>