[Insight-developers] AnalyzeIO large files and compression

[Bradley Lowekamp]

Ok,

I spent yesterday afternoon working on the large IO bug, so I am glad to hear that this class is not obsolete. I will be committing the patch tomorrow morning, which will include the fix for the ".img.gz" writing issue as well.

As all the current tests pass, but I don't use this format much. You may want to verify my changes didn't foobar anything tomorrow afternoon.

Thanks,
Brad

On Jan 21, 2010, at 11:58 AM, Hans Johnson wrote:

> YOU CAN NOT REMOVE AnalyzeImgeIO.  The behavior differences between AnalyzeImageIO and that of NiftiImageIO are not reconcilable in a backwards compatible way.   The .hdr/.img extension are not sufficient to distinguish between the two file formats, and you must also look at the last few bytes of the header to determine if NiftiImageIO or AnalyzeImageIO should be used (This is why NiftiImageIO processes the files first, and if the “nifti magic key” is not there, it defers to the AnalyzeImageIO).
> 
> Hans  
> -- 
> Hans J. Johnson, Ph.D.
> Hans-johnson at uiowa.edu
> 
> 278 GH
> The University of Iowa
> Iowa City, IA 52241
> (319) 353 8587
> 
> 
> From: Kent Williams <norman-k-williams at uiowa.edu>
> Date: Thu, 21 Jan 2010 08:48:59 -0600
> To: Bradley Lowekamp <blowekamp at mail.nih.gov>, ITK <insight-developers at itk.org>
> Subject: Re: [Insight-developers] AnalyzeIO large files and compression
> 
> You are right about the file extension issue. Do you want me to test and check in the fix, or do you want to do it?  I think this was a case where more than one person was working on the code — the test for ‘.gz’ I think predates adding the ‘FileExtension’ function which returns ‘.img.gz’.  When the FileExtension function was added, the test wasn’t updated.
> 
> I don’t remember why we still keep AnalyzeImageIO around.  It seems like I wanted to eliminate it at one point after the NIfTI reader was added, but there was something about the NIfTI library that caused a problem.  I would dearly love for itkAnalyzeImageIO to go away, as it was some of the first code I wrote for ITK, and it’s A) theoretically obsolete now that we have the NIfTI reader and B) isn’t particularly well written.
> 
> 
> 
> 
> 
> 
> On 1/20/10 3:54 PM, "Bradley Lowekamp" <blowekamp at mail.nih.gov> wrote:
> 
>> Hello,
>> 
>> I was testing my fix for the following bug:
>> http://www.itk.org/Bug/view.php?id=10135
>> 
>> When I noticed that I was unable to generate a compressed output file. And the coverage seems to indicate the same:
>> http://www.cdash.org/CDash/viewCoverageFile.php?buildid=519292&fileid=10945147
>> 
>> 
>> I think I see the problem in the code:
>> if(!fileExt.compare( ".gz" )) should be ".img.gz"
>> 
>> There is also the Nifti which reads and writes the img format. Is one suppose to be better then the other? My test appears to work with writing the compressed writing code enables. Is there any history or related issues to this IO that I should know about before making these changes?
>> 
>> Thanks,
>> Brad
>> 
>> 
>> ========================================================
>> 
>> Bradley Lowekamp 
>> 
>> Lockheed Martin Contractor for
>> 
>> Office of High Performance Computing and Communications
>> 
>> National Library of Medicine 
>> 
>> blowekamp at mail.nih.gov
>> 
>> 
>> 
> 
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
> 
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20100121/c193a5d7/attachment.htm>