[Insight-developers] backward compatibility issue with newstreaming support

[M.Staring at lumc.nl]

Hi Brad,
 
The patch you committed recently does not yet seem to work. I added a
note to the bug tracker where I explain better why I think it does not
yet work.
 
Thanks for the effort,
 
Marius


________________________________

	From: insight-developers-bounces at itk.org
[mailto:insight-developers-bounces at itk.org] On Behalf Of
M.Staring at lumc.nl
	Sent: vrijdag 11 december 2009 17:55
	To: blowekamp at mail.nih.gov
	Cc: insight-developers at itk.org; norman-k-williams at uiowa.edu
	Subject: Re: [Insight-developers] backward compatibility issue
with newstreaming support
	
	
	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/20091216/7b0a3599/attachment.htm>