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

[M.Staring at lumc.nl]

Hi Bradley,
 
I just entered a bug: 
 
  http://www.itk.org/Bug/view.php?id=10035
 
Your proposed patch for MetaIMageIO seems like we had in mind, but then
done the right way :-)
If you add the patch to the bug we can see if it works for us.
 
Regarding tiffImageIO, we appeared to be testing the
MevislabTiffImageIO, and not the ITK one. Sorry for that. We will check
soon for the other image IO's and let you know.
 
Marius


________________________________

	From: Bradley Lowekamp [mailto:blowekamp at mail.nih.gov] 
	Sent: vrijdag 11 december 2009 17:29
	To: Staring, M. (LKEB)
	Cc: norman-k-williams at uiowa.edu; bill.lorensen at gmail.com;
insight-developers at itk.org
	Subject: Re: [Insight-developers] backward compatibility issue
with new streaming support
	
	
	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/3670d042/attachment-0001.htm>