[Insight-developers] AnalyzeIO large files and compression

[Hans Johnson]

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/7f721240/attachment.htm>