[Insight-users] Image index limits

[Bradley Lowekamp]

Nice work in tracking this down! I have done some similar 1GB reading chunks in MetaImageIO as well due the Apple OSX not being able to read more then 2GB with one call.

It looks like there may be some more subtle problems with large file in the ImageIO. There looks like there are some usages of type long, which is like incorrect, and there number of pixel is type int in some places too. A close review of the file with these issues in mind is needed.

Can you please log it into the bug tracker. Follow the instruction in the "Entering a bug" in the following document:

http://www.itk.org/Wiki/ITK_Procedure_for_Contributing_Bug_Fixes

Thanks,
Brad

On Jan 13, 2010, at 8:23 AM, Robert.Atwood at diamond.ac.uk wrote:

> Hi Alex et. al:
> I developed a fix for the problem in itkAnalyzeImageIO.cxx , it seems to
> work for me both with compressed and uncompressed .img files
> 
> 
> I'm not sure if it strictly satisfies code style requirements for itk
> but if anyone could help it satisfy these then perhaps it could be
> implemented? 
> 
> The fixes:
> 1. Test the return value of gzread to ensure correct data amount is read
> and no other error has occurred. Throws exception if the return value is
> 0 or -1.
> 
> 2. Only read a chunk of size < (2^32 - 2 ) at a time (defined by a macro
> .. ) . Loop through the chunks if the file is bigger than this.
> 
> I've tested this with small (10Mb) chunk size on compressed .img.gz and
> uncompressed .img files of the 5Gb output (uncompressed) from Alex's
> ImageFill_Cube and the results appear correct. 
> 
> I hope this helps!
> 
> Robert  
> 
> 
> 
> -- 
> 
> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
> 
> Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
> 
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
> 
> Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
> 
> 
> 
> 
> 
> 
> 
> 
> 
> <itkAnalyzeImageIO.cxx><ATT00001..txt>

========================================================
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/pipermail/insight-users/attachments/20100113/c24d81ef/attachment.htm>