[Insight-developers] backward compatibility issue with new streaming support

[Bradley Lowekamp]

Hello Marius,

Please log this issue into the bug tracker:
http://www.cmake.org/Wiki/ITK_Procedure_for_Contributing_Bug_Fixes

I presume that you are querying GetIORegion after reading the image ( or information ). The member variable is not designed to be set during the reading process it should an option to set before reading. So it's should not effect anything if this variable remains zero.

I am not sure about the tiff reader. I see that itkTiffImageIO also uses the IORegion too, but that has been there since 2004.

This is what I am thinking will patch metaIO for you:

===================================================================
RCS file: /cvsroot/Insight/Insight/Code/IO/itkMetaImageIO.cxx,v
retrieving revision 1.103
diff -u -r1.103 itkMetaImageIO.cxx
--- itkMetaImageIO.cxx	22 Nov 2009 13:33:53 -0000	1.103
+++ itkMetaImageIO.cxx	11 Dec 2009 15:48:28 -0000
@@ -894,17 +894,26 @@
     
     delete [] indexMin;
     delete [] indexMax;
+
+    
+    m_MetaImage.ElementByteOrderFix( m_IORegion.GetNumberOfPixels() );
+    
     }
-  else if(!m_MetaImage.Read(m_FileName.c_str(), true, buffer))
+  else 
     {
-    itkExceptionMacro("File cannot be read: "
-                      << this->GetFileName() << " for reading."
-                      << std::endl
-                      << "Reason: "
-                      << itksys::SystemTools::GetLastSystemError());
+    if(!m_MetaImage.Read(m_FileName.c_str(), true, buffer))
+      {
+      itkExceptionMacro("File cannot be read: "
+                        << this->GetFileName() << " for reading."
+                        << std::endl
+                        << "Reason: "
+                        << itksys::SystemTools::GetLastSystemError());
+      }    
+
+    // since we are not streaming m_IORegion may not be set, so 
+    m_MetaImage.ElementByteOrderFix( this->GetImageSizeInPixels() );
     }
 
-  m_MetaImage.ElementByteOrderFix( m_IORegion.GetNumberOfPixels() );
 } 
 

On Dec 11, 2009, at 11:15 AM, M.Staring at lumc.nl wrote:

> We have an abstract image type that does not need to know at compile-time the image type and dimension. We can delay the decision of the specific image type till after the reading. So, the reader itself is non-templated. We are using the ITK IO to get the meta information and the pixel buffer. We do all the ReadImageInformation(), GetComponentType(), and GetNumberOfComponent(), but now we apparantly additionally need to do SetIORegion().
> 
> But anyway, the discussion is not how our reading framework is designed, but that there was a change in behaviour. I just wanted to report that.
> 
> What is important for us to know is, if we add the following lines to our code:
> 
> ---------------------------------------
> const unsigned nrOfDimensions = m_itkImageIO->GetNumberOfDimensions();
> itk::ImageIORegion ioRegion(nrOfDimensions);
> 
> for(unsigned int i=0; i < nrOfDimensions; ++i)
>  ioRegion.SetSize(i, m_itkImageIO->GetDimensions(i));
> 
> m_itkImageIO->SetIORegion(ioRegion);
> ---------------------------------------
> 
> if that is the correct use of ITK image IO ?

Yes I that this is correct. You are setting the IORegion to the largest region, that is the actual size of the image. 

While at one point IORegion was not required to be set, because ImageFileReader set it, it have become expected to be set now. Unfortunately, we only test the IO with the ImageFileReaders, so it is problematic to test for this. 

> 
> I don't mind changing our code a little bit, but I want to change it in a correct fashion.
> 
> Marius

> 

========================================================
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/20091211/3a8b1588/attachment.htm>