[MINC-development] weird minc 2 bug

[Jonathan HARLAP]

Hi Bert,

This argument seems internally consistent, although probably 
counterintuitive to any user who doesn't feel a need to understand in 
great detail the inner workings of MINC - and, by extension, the subtle 
difference between the order of dimensions in the file and the order of 
variables.

Fixing the perl library does seem an easy and quick solution, although 
there are probably many other scripts out there that do the same thing 
and will thus break similarly...

That said, what would you suggest is the right way for someone at the 
command line to find out the dimension order of a MINC file?  (IE, what 
could I use instead of mincinfo -dimnames)

Cheers,
J


Robert VINCENT wrote:
> Hi Jonathan,
> 
> Interesting point. Because the 'mincinfo -dimnames' option does not query
> the image variable dimensions, it looks as though the dimension order was
> never intended to be correct. The reported dimensions simply reflect the
> _file_ order, which as you know, is independent of the variable ordering.
> It just happens to be the case that most netCDF files created with our
> tools will coincidentally have the same dimension ordering in the file as
> in the image variable. But nothing prevents someone from creating a valid
> netCDF MINC file with fewer image dimensions than file dimensions, or with
> a different ordering in the image variable, and the 'mincinfo -dimnames'
> option will not reflect these facts.
> 
> So I'd argue it was mistaken to use the -dimnames option assuming
> that it will return only the image variables dimensions, in the proper
> order. This contradicts both the code and the documented function of the
> option.
> 
> However, we may have to find a way to preserve this behavior to prevent
> breaking the existing perl libraries. But we should probably fix the perl
> library was well, as it has probably caused some subtle bugs from time to
> time.
> 
> 	-bert
> 
> On Wed, 7 Jun 2006, Jonathan HARLAP wrote:
> 
>> Here's a neat one:
>>
>> Take a CDF file, run it through mincconvert -2 to get the corresponding
>> HDF file.  Now open both file in register (or just use
>> mincinfo/mincheader).  You'll see that the dimension order is, as it
>> should be, identical.
>>
>> Now, the fun part.  Run mincinfo -dimnames on the two files, and observe
>> the different dimension order.
>>
>> This fun bug is great in that it's a subtle little glitch in mincinfo,
>> but affects many little programs, such as mni-perllib's
>> MNI::MincUtilities::get_dimension_order()
>>
>> Example output below.
>>
>> Cheers,
>> J
>>
>>
>> % mincinfo  m?.mnc
>> file: m1.mnc
>> image: signed__ short 0 to 4095
>> image dimensions: xspace zspace yspace
>>      dimension name         length         step        start
>>      --------------         ------         ----        -----
>>      xspace                    124          1.4        -86.8
>>      zspace                    256     -1.01562      118.492
>>      yspace                    256     -1.01562      130.992
>>
>>
>> file: m2.mnc
>> image: signed__ short 0 to 4095
>> image dimensions: xspace zspace yspace
>>      dimension name         length         step        start
>>      --------------         ------         ----        -----
>>      xspace                    124          1.4        -86.8
>>      zspace                    256     -1.01562      118.492
>>      yspace                    256     -1.01562      130.992
>>
>>
>> % mincinfo -dimnames m?.mnc
>> xspace zspace yspace
>>
>>
>> xspace yspace zspace
>>
>>
>>
>> _______________________________________________
>> MINC-development mailing list
>> MINC-development at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>>
> 
> 
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development