From a.janke at gmail.com  Sun Jun  4 02:33:35 2006
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 4 Jun 2006 02:33:35 -0400
Subject: [MINC-development] default file type (HDF5 vs NetCDF)
In-Reply-To: <447DB941.6050501@bic.mni.mcgill.ca>
References: <Pine.SGI.4.44.0605311057170.2388251-100000@shadow.bic.mni.mcgill.ca>
	<447DB941.6050501@bic.mni.mcgill.ca>
Message-ID: <d747ed50606032333y441ed89fr5bf813a8301524c5@mail.gmail.com>

In this case I cast my vote in the same box as Jon's.  I have been
using an older version of minc2,0 at home now ever since shifting to
Montreal with no hassles.


a

On 5/31/06, Jonathan HARLAP <jharlap at bic.mni.mcgill.ca> wrote:
> I'd say that people who install MINC 2 probably should get MINC 2
> files...  But that's just my naive expectation that when I download,
> compile and install MINC 2 then when I run format conversions and
> processing tools they'd start using the MINC 2 format.
>
> So I'd vote to make the change.  However - if others are opposed, then I
> suggest an alternate change: add a -2 option to dcm2mnc and rawtominc.
>
> J
>
>
> Robert VINCENT wrote:
> > Hi,
> >
> > I had coded it this way specifically to avoid having programs like
> > rawtominc default to MINC 2.0 format. My intent was that a user would have
> > to make the decision to change all of their files to MINC 2.0 format, and
> > then all subsequent tools would automatically honor this decision. But I
> > didn't want a user to get a MINC 2.0 file without knowing they'd asked for
> > it.
> >
> > If the general feeling is that MINC 2.0 is working for people, then I
> > don't object to this change. I just didn't want to force the new format
> > onto the world, especially in environments where MINC 2.0 format support
> > might be incomplete.
> >
> >       -bert
> >
> > If people feel that
> > On Wed, 31 May 2006, Jonathan HARLAP wrote:
> >
> >
> >>Heylas,
> >>
> >>I know I've raised this before, but now that I understand what's going
> >>on a little better I'd like to propose a small change:
> >>
> >>In libsrc/netcdf_convenience.c the function micreatex reads:
> >>
> >>     if ((cmode & MI2_CREATE_V1) != 0) {
> >>         fd = nccreate(path, cmode);
> >>     }
> >>     else if (miget_cfg_bool(MICFG_FORCE_V2) || (cmode & MI2_CREATE_V2)
> >>!= 0) {
> >>      fd = hdf_create(path, cmode, opts_ptr);
> >>     }
> >>     else {
> >>         if (mi_nc_files == 0 && mi_h5_files != 0) {
> >>             /* Create an HDF5 file. */
> >>             fd = hdf_create(path, cmode, opts_ptr);
> >>         }
> >>         else {
> >>             /* Create a NetCDF file. */
> >>             fd = nccreate(path, cmode);
> >>         }
> >>     }
> >>
> >>
> >>I propose changing the line "if (mi_nc_files == 0 && mi_h5_files != 0)"
> >>to read " if (mi_nc_files == 0)"
> >>
> >>The reason is that currently the code will default to creating HDF5
> >>files only if a program has already opened an HDF5 file.  The change
> >>proposed would make it such that the library will only create CDF files
> >>if a program has already opened a CDF file.  This won't influence any of
> >>the minc tools normally used on a day-to-day basis, but will change the
> >>default output of file format converters that don't read any minc files
> >>before creating an output file.
> >>
> >>I didn't put this in CVS yet as I don't know what your process is for
> >>getting this kind of functionality change into the library.
> >>
> >>Cheers,
> >>J
> >>_______________________________________________
> >>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
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>


-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canada->Montreal                                   Cell: +1 (514) 924 2012

From jharlap at bic.mni.mcgill.ca  Wed Jun  7 12:48:56 2006
From: jharlap at bic.mni.mcgill.ca (Jonathan HARLAP)
Date: Wed, 07 Jun 2006 12:48:56 -0400
Subject: [MINC-development] weird minc 2 bug
Message-ID: <44870378.2080806@bic.mni.mcgill.ca>

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




From baghdadi at sickkids.ca  Wed Jun  7 13:05:07 2006
From: baghdadi at sickkids.ca (Leila Baghdadi)
Date: Wed, 07 Jun 2006 13:05:07 -0400
Subject: [MINC-development] weird minc 2 bug
In-Reply-To: <44870378.2080806@bic.mni.mcgill.ca>
References: <44870378.2080806@bic.mni.mcgill.ca>
Message-ID: <1149699907.9037.24.camel@localhost.localdomain>

Jonathan,

I am actually in the process of building a new minc distribution. 

I will see if I can fix this bug.

Thanks for reporting it.

Leila


On Wed, 2006-07-06 at 12:48 -0400, 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


From bert at bic.mni.mcgill.ca  Wed Jun  7 13:18:28 2006
From: bert at bic.mni.mcgill.ca (Robert VINCENT)
Date: Wed, 7 Jun 2006 13:18:28 -0400
Subject: [MINC-development] weird minc 2 bug
In-Reply-To: <44870378.2080806@bic.mni.mcgill.ca>
Message-ID: <Pine.SGI.4.44.0606071303440.2422336-100000@shadow.bic.mni.mcgill.ca>

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
>



From jharlap at bic.mni.mcgill.ca  Wed Jun  7 13:53:55 2006
From: jharlap at bic.mni.mcgill.ca (Jonathan HARLAP)
Date: Wed, 07 Jun 2006 13:53:55 -0400
Subject: [MINC-development] weird minc 2 bug
In-Reply-To: <Pine.SGI.4.44.0606071303440.2422336-100000@shadow.bic.mni.mcgill.ca>
References: <Pine.SGI.4.44.0606071303440.2422336-100000@shadow.bic.mni.mcgill.ca>
Message-ID: <448712B3.2090603@bic.mni.mcgill.ca>

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

From bert at bic.mni.mcgill.ca  Wed Jun  7 14:09:59 2006
From: bert at bic.mni.mcgill.ca (Robert VINCENT)
Date: Wed, 7 Jun 2006 14:09:59 -0400
Subject: [MINC-development] weird minc 2 bug
In-Reply-To: <448712B3.2090603@bic.mni.mcgill.ca>
Message-ID: <Pine.SGI.4.44.0606071355440.2422336-100000@shadow.bic.mni.mcgill.ca>

Hi Jonathan,

I agree that the behavior of 'mincinfo -dimnames' isn't especially
intuitive for people who don't know all of the inner workings of MINC.
But I think Peter implemented it intentionally as a method for listing all
of the dimensions defined in a file. He also created the "-vardims" option
to actually print the dimensions associated with a variable in the correct
order. So:

mincinfo -vardims image <filename.mnc>

should always give the right result for either netCDF or HDF5. So it is
probably the more useful option, and people have understandably failed to
appreciate the difference.

	-bert

On Wed, 7 Jun 2006, Jonathan HARLAP wrote:

> 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
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>


From cjb at pet.auh.dk  Wed Jun 21 05:18:46 2006
From: cjb at pet.auh.dk (Christopher Bailey)
Date: Wed, 21 Jun 2006 11:18:46 +0200
Subject: [MINC-development] mnc2nii with direction cosines?
Message-ID: <e041cab00606210218o5b603fc4i4d11870ad8aa9434@mail.gmail.com>

Hi guys,

I'm having some troubles with mnc2nii which seem to be related to
files with direction cosines set (i.e. not identity). The result is a
segfault:

/* snip */
  sto_xyz_matrix = '2 0 0 -96 0 2 0 -132 0 0 3 -72 0 0 0 1'
  sto_ijk matrix = '0.5 0 0 48 0 0.5 0 66 0 0 0.333333 24 0 0 0 1'
  sform_i_orientation = 'Left-to-Right'
  sform_j_orientation = 'Posterior-to-Anterior'
  sform_k_orientation = 'Inferior-to-Superior'
/>
MINC type 3 signed 1
0: 64 0 1
1: 113 1 1
2: 96 2 1
bytes per voxel 2
# of voxels 694272
Segmentation fault

I'm using:

$ mnc2nii -v
program: 1.4
libminc: 1.4
netcdf : 3.5.0 of Jul 29 2003 10:27:35 $

The fix was to do a mincresample -dircos 1 0 0 0 1 0 0 0 1 ...

I'd gladly upload a problem file to anyone interested. Or should I
just upgrade...?

Best,

Chris

-- 
Christopher Bailey <cjb at pet.auh.dk>
PET Centre and
Center of Functionally Integrative Neuroscience
Aarhus University Hospital, Denmark
http://www.cfin.au.dk/

From bert at bic.mni.mcgill.ca  Wed Jun 21 16:05:56 2006
From: bert at bic.mni.mcgill.ca (Robert VINCENT)
Date: Wed, 21 Jun 2006 16:05:56 -0400
Subject: [MINC-development] mnc2nii with direction cosines?
In-Reply-To: <e041cab00606210218o5b603fc4i4d11870ad8aa9434@mail.gmail.com>
Message-ID: <Pine.SGI.4.44.0606211605330.91020-100000@shadow.bic.mni.mcgill.ca>

Hi Christopher,

Send the file to my gmail account, rdvincent at gmail.com

I'll take a look at it.

	-bert

On Wed, 21 Jun 2006, Christopher Bailey wrote:

> Hi guys,
>
> I'm having some troubles with mnc2nii which seem to be related to
> files with direction cosines set (i.e. not identity). The result is a
> segfault:
>
> /* snip */
>   sto_xyz_matrix = '2 0 0 -96 0 2 0 -132 0 0 3 -72 0 0 0 1'
>   sto_ijk matrix = '0.5 0 0 48 0 0.5 0 66 0 0 0.333333 24 0 0 0 1'
>   sform_i_orientation = 'Left-to-Right'
>   sform_j_orientation = 'Posterior-to-Anterior'
>   sform_k_orientation = 'Inferior-to-Superior'
> />
> MINC type 3 signed 1
> 0: 64 0 1
> 1: 113 1 1
> 2: 96 2 1
> bytes per voxel 2
> # of voxels 694272
> Segmentation fault
>
> I'm using:
>
> $ mnc2nii -v
> program: 1.4
> libminc: 1.4
> netcdf : 3.5.0 of Jul 29 2003 10:27:35 $
>
> The fix was to do a mincresample -dircos 1 0 0 0 1 0 0 0 1 ...
>
> I'd gladly upload a problem file to anyone interested. Or should I
> just upgrade...?
>
> Best,
>
> Chris
>
> --
> Christopher Bailey <cjb at pet.auh.dk>
> PET Centre and
> Center of Functionally Integrative Neuroscience
> Aarhus University Hospital, Denmark
> http://www.cfin.au.dk/
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>