[Insight-developers] NIfTI and Analyze 64-bit lossage

[kent williams]

Hmmm.  Theoretically NIfTI should write compliant Analyze Files, so that's a
NIfTI bug. Like I said, I will look at fixing this -- it's almost certainly
a structure alignment problem on both platforms.

We can also change the CanWriteFile/CanReadFile in itkNiftiImageIO.cxx so
that it won't claim to read/write Analyze files (.hdr, .img, .img.gz).




On 7/27/07 7:50 AM, "Blezek, Daniel J (GE, Research)" <blezek at crd.ge.com>
wrote:

> Hi Kent,
> 
>   I'm having problems with NIfTI on my 32 bit machine as well, it writes
> 352 bytes.  It seems to Analyze doesn't like the 352 byte NIfTI header.
> It was my understanding that NIfTI just used unused fields in the
> Analyze header.  I also don't like that Analyze is never used, as it's
> after Nifti in itkImageIOFactory.  Seems to break our model.
> 
> For the moment, I switched Nifti and Analyze in the IOFactory.  I'll not
> check it in, but perhaps we should think a bit about this issue of 2
> formats that share header extentions.
> 
> -dan
> 
> kent williams wrote:
>> The problem, with both NIfTI and Analyze is that the file format --
>> and the code used to read and write them, are grounded in a 1991,
>> 32-Bit-Only mindset.  The problem that Dan Blezek encountered is one
>> of structure alignment, not of integer size.
>> 
>> I can test integer size in my own abbreviated version of stdint, and
>> not wory too much about a hypothetical platform that has no 32 bit
>> integer type.  
>> Is there such an architecture? If sizeof(short int) == 16, and
>> sizeof(int) == 64, what would they call a 32-bit int? 'long short
>> int'?  
>> 
>> I have other assignments on my plate at the moment, but I know how to
>> fix things, in niftilib and itkAnalyzeImageIO, and will work on it in
>> the next week or so.
>> 
>> 1. Modify niftilib so that instead of putting sizeof(Header) in the
>> sizeof_hdr field, put in 348.
>> 
>> 2. Modify the header readers and writers so that they read the 348
>> bytes of the header, and then extract the various fields from the
>> header at their mandated offsets in the header.  On writing,
>> similarly, place each attribute at it's proper offset.
>> 
>> In any case, there's still only one read/write per header.  Even
>> explicitly reading each field one at a time wouldn't cause a
>> performance penalty, since we're only talking about 348 bytes, read
>> or written once per file.
>> 
>> 
>> 
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers