From gstoynev at biospective.com  Wed Aug  1 13:56:38 2012
From: gstoynev at biospective.com (George Stoynev)
Date: Wed, 1 Aug 2012 13:56:38 -0400
Subject: [MINC-users] minc-toolkit 0.3.11,
	Display 1.6 segmentation fault on 3D object
Message-ID: <CAH3fwHgZXY+W-B8fjN43tc0qX6iEekak8Z6OKg4rEjBGT9eZzQ@mail.gmail.com>

Hi all,

I ran in interesting issue today.
Following the instructions in
http://www.bic.mni.mcgill.ca/ServicesSoftware/ServicesSoftwareMincToolKit I
installed the minc-toolkit 0.3.11, the minc-toolkit-testsuite and the
bic-mni-models on 64-bit Ubuntu 10.04.
Then I ran "source /opt/minc/minc-toolkit-config.sh" and successfully
completed the test run "bash /opt/minc/run_tests.sh TEST".

Then I ran "Display file1.obj", where file1.obj is a 3D-object file and I
got Segmentation fault. But "Display file2.mnc" works correctly, if
2D. "Display
-version" reports it as 1.6.
For comparison, I ran "/usr/local/bic/bin/Display file1.obj" and the file
successfully opened. This version of Display is reported as 1.3 and comes
from display-1.5.0-1maverick_amd64.deb.

Did anybody else experienced such an issue?

Thank you,
George Stoynev

From mishkind at gmail.com  Wed Aug  1 14:01:38 2012
From: mishkind at gmail.com (Mishkin Derakhshan)
Date: Wed, 1 Aug 2012 14:01:38 -0400
Subject: [MINC-users] minc-toolkit 0.3.11,
 Display 1.6 segmentation fault on 3D object
In-Reply-To: <CAH3fwHgZXY+W-B8fjN43tc0qX6iEekak8Z6OKg4rEjBGT9eZzQ@mail.gmail.com>
References: <CAH3fwHgZXY+W-B8fjN43tc0qX6iEekak8Z6OKg4rEjBGT9eZzQ@mail.gmail.com>
Message-ID: <CAB-GmL0WPMa0cqSo=sEHTyWoK-UoOHkeUYMiD5m-KTM7taw74w@mail.gmail.com>

Hi,
I ran into this issue at some point as well.
I think DIsplay always expects the first file to be a minc file so
something like this worked for me:
Display anymincfile.mnc file1.obj

On Wed, Aug 1, 2012 at 1:56 PM, George Stoynev <gstoynev at biospective.com> wrote:
> Hi all,
>
> I ran in interesting issue today.
> Following the instructions in
> http://www.bic.mni.mcgill.ca/ServicesSoftware/ServicesSoftwareMincToolKit I
> installed the minc-toolkit 0.3.11, the minc-toolkit-testsuite and the
> bic-mni-models on 64-bit Ubuntu 10.04.
> Then I ran "source /opt/minc/minc-toolkit-config.sh" and successfully
> completed the test run "bash /opt/minc/run_tests.sh TEST".
>
> Then I ran "Display file1.obj", where file1.obj is a 3D-object file and I
> got Segmentation fault. But "Display file2.mnc" works correctly, if
> 2D. "Display
> -version" reports it as 1.6.
> For comparison, I ran "/usr/local/bic/bin/Display file1.obj" and the file
> successfully opened. This version of Display is reported as 1.3 and comes
> from display-1.5.0-1maverick_amd64.deb.
>
> Did anybody else experienced such an issue?
>
> Thank you,
> George Stoynev
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From vladimir.fonov at gmail.com  Wed Aug  1 14:21:07 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Wed, 01 Aug 2012 14:21:07 -0400
Subject: [MINC-users] minc-toolkit 0.3.11,
 Display 1.6 segmentation fault on 3D object
In-Reply-To: <CAB-GmL0WPMa0cqSo=sEHTyWoK-UoOHkeUYMiD5m-KTM7taw74w@mail.gmail.com>
References: <CAH3fwHgZXY+W-B8fjN43tc0qX6iEekak8Z6OKg4rEjBGT9eZzQ@mail.gmail.com>
	<CAB-GmL0WPMa0cqSo=sEHTyWoK-UoOHkeUYMiD5m-KTM7taw74w@mail.gmail.com>
Message-ID: <50197393.10307@gmail.com>

Hello,

actually , I think Display is supposed to work with just .obj file, but 
it looks like one of the recent changes introduced a bug which is 
triggered in this case.


On 12-08-01 02:01 PM, Mishkin Derakhshan wrote:
> Hi,
> I ran into this issue at some point as well.
> I think DIsplay always expects the first file to be a minc file so
> something like this worked for me:
> Display anymincfile.mnc file1.obj
>
> On Wed, Aug 1, 2012 at 1:56 PM, George Stoynev <gstoynev at biospective.com> wrote:
>> Hi all,
>>
>> I ran in interesting issue today.
>> Following the instructions in
>> http://www.bic.mni.mcgill.ca/ServicesSoftware/ServicesSoftwareMincToolKit I
>> installed the minc-toolkit 0.3.11, the minc-toolkit-testsuite and the
>> bic-mni-models on 64-bit Ubuntu 10.04.
>> Then I ran "source /opt/minc/minc-toolkit-config.sh" and successfully
>> completed the test run "bash /opt/minc/run_tests.sh TEST".
>>
>> Then I ran "Display file1.obj", where file1.obj is a 3D-object file and I
>> got Segmentation fault. But "Display file2.mnc" works correctly, if
>> 2D. "Display
>> -version" reports it as 1.6.
>> For comparison, I ran "/usr/local/bic/bin/Display file1.obj" and the file
>> successfully opened. This version of Display is reported as 1.3 and comes
>> from display-1.5.0-1maverick_amd64.deb.
>>
>> Did anybody else experienced such an issue?
>>
>> Thank you,
>> George Stoynev
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


-- 
Best regards,

  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com


From assemlal at cim.mcgill.ca  Wed Aug  1 14:35:23 2012
From: assemlal at cim.mcgill.ca (Haz-Edine Assemlal)
Date: Wed, 01 Aug 2012 14:35:23 -0400
Subject: [MINC-users] minc-toolkit 0.3.11,
 Display 1.6 segmentation fault on 3D object
In-Reply-To: <50197393.10307@gmail.com>
References: <CAH3fwHgZXY+W-B8fjN43tc0qX6iEekak8Z6OKg4rEjBGT9eZzQ@mail.gmail.com>
	<CAB-GmL0WPMa0cqSo=sEHTyWoK-UoOHkeUYMiD5m-KTM7taw74w@mail.gmail.com>
	<50197393.10307@gmail.com>
Message-ID: <1343846124.13634.4.camel@talos>

Hi George,
Interesting. Could you point me to an object file which produces this
error? 

Haz-Edine

On Wed, 2012-08-01 at 14:21 -0400, Vladimir S. FONOV wrote:
> Hello,
> 
> actually , I think Display is supposed to work with just .obj file, but 
> it looks like one of the recent changes introduced a bug which is 
> triggered in this case.
> 
> 
> On 12-08-01 02:01 PM, Mishkin Derakhshan wrote:
> > Hi,
> > I ran into this issue at some point as well.
> > I think DIsplay always expects the first file to be a minc file so
> > something like this worked for me:
> > Display anymincfile.mnc file1.obj
> >
> > On Wed, Aug 1, 2012 at 1:56 PM, George Stoynev <gstoynev at biospective.com> wrote:
> >> Hi all,
> >>
> >> I ran in interesting issue today.
> >> Following the instructions in
> >> http://www.bic.mni.mcgill.ca/ServicesSoftware/ServicesSoftwareMincToolKit I
> >> installed the minc-toolkit 0.3.11, the minc-toolkit-testsuite and the
> >> bic-mni-models on 64-bit Ubuntu 10.04.
> >> Then I ran "source /opt/minc/minc-toolkit-config.sh" and successfully
> >> completed the test run "bash /opt/minc/run_tests.sh TEST".
> >>
> >> Then I ran "Display file1.obj", where file1.obj is a 3D-object file and I
> >> got Segmentation fault. But "Display file2.mnc" works correctly, if
> >> 2D. "Display
> >> -version" reports it as 1.6.
> >> For comparison, I ran "/usr/local/bic/bin/Display file1.obj" and the file
> >> successfully opened. This version of Display is reported as 1.3 and comes
> >> from display-1.5.0-1maverick_amd64.deb.
> >>
> >> Did anybody else experienced such an issue?
> >>
> >> Thank you,
> >> George Stoynev
> >> _______________________________________________
> >> MINC-users at bic.mni.mcgill.ca
> >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> 
> 



From gstoynev at biospective.com  Wed Aug  1 16:54:45 2012
From: gstoynev at biospective.com (George Stoynev)
Date: Wed, 1 Aug 2012 16:54:45 -0400
Subject: [MINC-users] minc-toolkit 0.3.11,
 Display 1.6 segmentation fault on 3D object
In-Reply-To: <1343846124.13634.4.camel@talos>
References: <CAH3fwHgZXY+W-B8fjN43tc0qX6iEekak8Z6OKg4rEjBGT9eZzQ@mail.gmail.com>
	<CAB-GmL0WPMa0cqSo=sEHTyWoK-UoOHkeUYMiD5m-KTM7taw74w@mail.gmail.com>
	<50197393.10307@gmail.com> <1343846124.13634.4.camel@talos>
Message-ID: <CAH3fwHgJ_OfwOeQCMiy+J0P3NVJhzF1xmsQxZF9DoYmx+i=5gA@mail.gmail.com>

Hi Haz-Edine,

here is the file - https://www.dropbox.com/s/znof6vgfqbzew2y/file1.obj

Thank you,
George Stoynev


On Wed, Aug 1, 2012 at 2:35 PM, Haz-Edine Assemlal
<assemlal at cim.mcgill.ca>wrote:

> Hi George,
> Interesting. Could you point me to an object file which produces this
> error?
>
> Haz-Edine
>
> On Wed, 2012-08-01 at 14:21 -0400, Vladimir S. FONOV wrote:
> > Hello,
> >
> > actually , I think Display is supposed to work with just .obj file, but
> > it looks like one of the recent changes introduced a bug which is
> > triggered in this case.
> >
> >
> > On 12-08-01 02:01 PM, Mishkin Derakhshan wrote:
> > > Hi,
> > > I ran into this issue at some point as well.
> > > I think DIsplay always expects the first file to be a minc file so
> > > something like this worked for me:
> > > Display anymincfile.mnc file1.obj
> > >
> > > On Wed, Aug 1, 2012 at 1:56 PM, George Stoynev <
> gstoynev at biospective.com> wrote:
> > >> Hi all,
> > >>
> > >> I ran in interesting issue today.
> > >> Following the instructions in
> > >>
> http://www.bic.mni.mcgill.ca/ServicesSoftware/ServicesSoftwareMincToolKitI
> > >> installed the minc-toolkit 0.3.11, the minc-toolkit-testsuite and the
> > >> bic-mni-models on 64-bit Ubuntu 10.04.
> > >> Then I ran "source /opt/minc/minc-toolkit-config.sh" and successfully
> > >> completed the test run "bash /opt/minc/run_tests.sh TEST".
> > >>
> > >> Then I ran "Display file1.obj", where file1.obj is a 3D-object file
> and I
> > >> got Segmentation fault. But "Display file2.mnc" works correctly, if
> > >> 2D. "Display
> > >> -version" reports it as 1.6.
> > >> For comparison, I ran "/usr/local/bic/bin/Display file1.obj" and the
> file
> > >> successfully opened. This version of Display is reported as 1.3 and
> comes
> > >> from display-1.5.0-1maverick_amd64.deb.
> > >>
> > >> Did anybody else experienced such an issue?
> > >>
> > >> Thank you,
> > >> George Stoynev
> > >> _______________________________________________
> > >> MINC-users at bic.mni.mcgill.ca
> > >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > > _______________________________________________
> > > MINC-users at bic.mni.mcgill.ca
> > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
> >
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From pbellec at bic.mni.mcgill.ca  Thu Aug  2 12:25:06 2012
From: pbellec at bic.mni.mcgill.ca (Pierre Bellec)
Date: Thu, 2 Aug 2012 12:25:06 -0400
Subject: [MINC-users] space in file names
Message-ID: <CADPHwxB9Wbru8z3q=gxUHg7bRYSaU9jwF5nK4r0N0XwhDokXQQ@mail.gmail.com>

Dear Minc users,

I think I ran into a bug related to space in file names. If I run

$ mincheader /home/pbellec/Ubuntu\
One/articles/Marrelec_BMI/real_data/atoms.mnc

I get the following error:

/opt/minc/bin/mincheader: 107: [: /home/pbellec/Ubuntu: unexpected operator
mincheader: no such file /home/pbellec/Ubuntu
One/articles/Marrelec_BMI/real_data/atoms.mnc

Using an alternative method is not more successful:

$ mincheader "/home/pbellec/Ubuntu
One/articles/Marrelec_BMI/real_data/atoms.mnc"
/opt/minc/bin/mincheader: 107: [: /home/pbellec/Ubuntu: unexpected operator
mincheader: no such file /home/pbellec/Ubuntu
One/articles/Marrelec_BMI/real_data/atoms.mnc

Both methods will work with other commands such as "ls". You may just
think, who puts a space in a folder name anyway ? Well, the guys from
Ubuntu One do. Please let me know if you have an alternative method.

For info, the minc tools have been installed using the minc-toolkit package
of Vladimir. There is no "-version" option in mincheader, but the script
has the following info:
# Modifications:
#   $Log: mincheader,v $
#   Revision 6.4  2008-01-04 06:01:23  rotor
#    * updated shell scripting style and added more verbose help
#
# (...)

and mincdump -version gives
program: 2.1.20
libminc: 2.1.20
netcdf : 4.2 of Apr 19 2012 15:06:12 $
HDF5   : 1.8.8

As a sidenote, this means that the NIAK reader/writer breaks on files which
are located in a folder with spaces in the name. Interestingly the command
will work if the file is zipped (for minc1 files), beause for various
reasons NIAK will first copy the file in the tmp folder before unzipping it
(that part works regardless of spaces and the tmp folder does not have
space in the name). I suspect NIAK will break if the file name itself has
spaces in it, regardless of the zip status.

Best,

Pierre Bellec, PhD
Chercheur adjoint
Centre de recherche de l'institut de G?riatrie de Montr?al
D?partement d'informatique et de recherche op?rationnelle
Universit? de Montr?al
http://simexp-lab.org/brainwiki/doku.php?id=pierrebellec
(001)(514) 340 3540 #3367

From vladimir.fonov at gmail.com  Thu Aug  2 12:32:29 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Thu, 02 Aug 2012 12:32:29 -0400
Subject: [MINC-users] space in file names
In-Reply-To: <CADPHwxB9Wbru8z3q=gxUHg7bRYSaU9jwF5nK4r0N0XwhDokXQQ@mail.gmail.com>
References: <CADPHwxB9Wbru8z3q=gxUHg7bRYSaU9jwF5nK4r0N0XwhDokXQQ@mail.gmail.com>
Message-ID: <501AAB9D.8090307@gmail.com>

Hello,

I think it is because mincheader is actually a shell script, and the 
input file name is substituted as $1 in a couple of places.


On 12-08-02 12:25 PM, Pierre Bellec wrote:
> Dear Minc users,
>
> I think I ran into a bug related to space in file names. If I run
>
> $ mincheader /home/pbellec/Ubuntu\
> One/articles/Marrelec_BMI/real_data/atoms.mnc
>
> I get the following error:
>
> /opt/minc/bin/mincheader: 107: [: /home/pbellec/Ubuntu: unexpected operator
> mincheader: no such file /home/pbellec/Ubuntu
> One/articles/Marrelec_BMI/real_data/atoms.mnc
>
> Using an alternative method is not more successful:
>
> $ mincheader "/home/pbellec/Ubuntu
> One/articles/Marrelec_BMI/real_data/atoms.mnc"
> /opt/minc/bin/mincheader: 107: [: /home/pbellec/Ubuntu: unexpected operator
> mincheader: no such file /home/pbellec/Ubuntu
> One/articles/Marrelec_BMI/real_data/atoms.mnc
>
> Both methods will work with other commands such as "ls". You may just
> think, who puts a space in a folder name anyway ? Well, the guys from
> Ubuntu One do. Please let me know if you have an alternative method.
>
> For info, the minc tools have been installed using the minc-toolkit package
> of Vladimir. There is no "-version" option in mincheader, but the script
> has the following info:
> # Modifications:
> #   $Log: mincheader,v $
> #   Revision 6.4  2008-01-04 06:01:23  rotor
> #    * updated shell scripting style and added more verbose help
> #
> # (...)
>
> and mincdump -version gives
> program: 2.1.20
> libminc: 2.1.20
> netcdf : 4.2 of Apr 19 2012 15:06:12 $
> HDF5   : 1.8.8
>
> As a sidenote, this means that the NIAK reader/writer breaks on files which
> are located in a folder with spaces in the name. Interestingly the command
> will work if the file is zipped (for minc1 files), beause for various
> reasons NIAK will first copy the file in the tmp folder before unzipping it
> (that part works regardless of spaces and the tmp folder does not have
> space in the name). I suspect NIAK will break if the file name itself has
> spaces in it, regardless of the zip status.
>
> Best,
>
> Pierre Bellec, PhD
> Chercheur adjoint
> Centre de recherche de l'institut de G?riatrie de Montr?al
> D?partement d'informatique et de recherche op?rationnelle
> Universit? de Montr?al
> http://simexp-lab.org/brainwiki/doku.php?id=pierrebellec
> (001)(514) 340 3540 #3367
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


-- 
Best regards,

  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com

From a.janke at gmail.com  Fri Aug  3 01:52:04 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 3 Aug 2012 15:52:04 +1000
Subject: [MINC-users] space in file names
In-Reply-To: <501AAB9D.8090307@gmail.com>
References: <CADPHwxB9Wbru8z3q=gxUHg7bRYSaU9jwF5nK4r0N0XwhDokXQQ@mail.gmail.com>
	<501AAB9D.8090307@gmail.com>
Message-ID: <CAG0CB20fEAwjyQpA+35J4mR3yAL-jqp8jDJW+s=JBgzcoC7OCQ@mail.gmail.com>

Hi Pierre

On 3 August 2012 02:32, Vladimir S. FONOV <vladimir.fonov at gmail.com> wrote:
> I think it is because mincheader is actually a shell script, and the input
> file name is substituted as $1 in a couple of places.

Vlad is indeed correct (Although it goes a bit deeper than that).

Here is a commit for mincheader to fix this:

   https://github.com/BIC-MNI/minc/commit/524ade8bc2824c72dafa564eb34f8b4ae1b7c6c8

Problem is: you are going to strike this again and again and again if
you decide to continue down the wormhole of spaces in filenames. Yes
MINC itself might be safe from spaces in filenames but I have seen
hundreds of perl/shell scripts that aren't.

My "fix" for something like this would be a symlink:

   $ ln -s 'Ubuntu One' ubu1

And from then on in, use /home/pbellec/ubu1/....



a

PS: if you do decide to stick with filenames with spaces, be sure to
hunt down every single system call in perl scripts (or &do_cmd() for
my scripts or &Spawn for MNI::Perllib) and "arrayify" them.  ie:

   &do_cmd("mincheader -clobber $filename");

becomes:

   &do_cmd("mincheader", '-clobber', $filename);

Note that this now makes it far more convoluted to do things like this:

   &do_cmd("mincheader $filename > header");

As for fixing shell scripts just put quotes around anything that might
have a filename in it!  (and cross your fingers when shell scripts
call other shell scripts....)

From jackie.leung at alumni.utoronto.ca  Sat Aug  4 20:44:02 2012
From: jackie.leung at alumni.utoronto.ca (Jackie Leung)
Date: Sat, 4 Aug 2012 20:44:02 -0400
Subject: [MINC-users] am i using mincresample correctly
Message-ID: <CAEOrv3xA_YsTuk=8GDq3HsfuvXQCV2qOixMEv-7hfa=9pqvuhw@mail.gmail.com>

hello all,

I'm new to MINC and I'm not sure if my coregistration process is correct.

After getting the transform file from 'register', I apply it to my volumes
(it's a 4D dataset) with the following command:
mincresample -transformation matrix.xfm -tfm_input_sampling data.mnc
data_reg.mnc

when i view the output data using register, it looks the same as before.
I'm I running the tool correctly?  Or does it have something to do with the
world coordinates vs voxel coordinates thing?

thanks,
Jackie

From sorench at gmail.com  Sat Aug  4 21:57:08 2012
From: sorench at gmail.com (Soren Christensen)
Date: Sun, 5 Aug 2012 11:57:08 +1000
Subject: [MINC-users] am i using mincresample correctly
In-Reply-To: <CAEOrv3xA_YsTuk=8GDq3HsfuvXQCV2qOixMEv-7hfa=9pqvuhw@mail.gmail.com>
References: <CAEOrv3xA_YsTuk=8GDq3HsfuvXQCV2qOixMEv-7hfa=9pqvuhw@mail.gmail.com>
Message-ID: <CAHfsrRaBi2gAVn8k-uSUk5gC2KvTD2jNmQTOPCP2NiNCtOO6jQ@mail.gmail.com>

Hi Jackie,
I don't think they should look the same. What does xfm2param matrix.xfm say
(if xfm is close to identity then it will be hard to pick differences
visually)?
If you hit sync in register, is the cursor at the exact same spot?  When
you blend in register do you see differences?

Once you hit sync you will see a synchronous movement of the cursor in
world space - not voxel space.

Soren


On Aug 5, 2012 10:44 AM, "Jackie Leung" <jackie.leung at alumni.utoronto.ca>
wrote:

> hello all,
>
> I'm new to MINC and I'm not sure if my coregistration process is correct.
>
> After getting the transform file from 'register', I apply it to my volumes
> (it's a 4D dataset) with the following command:
> mincresample -transformation matrix.xfm -tfm_input_sampling data.mnc
> data_reg.mnc
>
> when i view the output data using register, it looks the same as before.
> I'm I running the tool correctly?  Or does it have something to do with the
> world coordinates vs voxel coordinates thing?
>
> thanks,
> Jackie
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From a.janke at gmail.com  Sun Aug  5 08:57:34 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 5 Aug 2012 22:57:34 +1000
Subject: [MINC-users] am i using mincresample correctly
In-Reply-To: <CAEOrv3xA_YsTuk=8GDq3HsfuvXQCV2qOixMEv-7hfa=9pqvuhw@mail.gmail.com>
References: <CAEOrv3xA_YsTuk=8GDq3HsfuvXQCV2qOixMEv-7hfa=9pqvuhw@mail.gmail.com>
Message-ID: <CAG0CB23HVbz89ksyZ2-s3wg0OO3XVuYQrb70fh_VoZKwru5SbQ@mail.gmail.com>

Hi Jackie,

On 5 August 2012 10:44, Jackie Leung <jackie.leung at alumni.utoronto.ca> wrote:
> I'm new to MINC and I'm not sure if my coregistration process is correct.
>
> After getting the transform file from 'register', I apply it to my volumes
> (it's a 4D dataset) with the following command:
> mincresample -transformation matrix.xfm -tfm_input_sampling data.mnc
> data_reg.mnc
>
> when i view the output data using register, it looks the same as before.
> I'm I running the tool correctly?  Or does it have something to do with the
> world coordinates vs voxel coordinates thing?

My guess is that you have actually done the right thing. Just remember
that register displays volumes in "voxel space" and
-tfm_input_sampling will in general just change the voxel to world
transform in a file. If you want to resample a file like another (the
target) you probably want this:

   mincresample -transformation matrix.xfm -like target.mnc data.mnc
data_reg.mnc

An explanation of what is going on is here:

   http://en.wikibooks.org/wiki/MINC/Tools/mni_autoreg

This is for minctracc, but the resampling section still applies.


a

From andrew.janke at cai.uq.edu.au  Mon Aug  6 02:07:36 2012
From: andrew.janke at cai.uq.edu.au (Andrew Janke)
Date: Mon, 6 Aug 2012 16:07:36 +1000
Subject: [MINC-users] Web based display of MINC data
Message-ID: <CAG0CB22rOb7eTr1w-s5J-OsaUjWTiPv-V+1Rns0642A0Wj5FhA@mail.gmail.com>

Hi all,

Some of you may be interested in a web based tool we have been working
on lately called TissueStack:

   http://caivm1.qern.qcif.edu.au/

The code is on github here:

   https://github.com/NIF-au/TissueStack

And there is a bit of a blog here:

   http://tissuestack.blogspot.com.au/

It's a combination of a server and a client. You can either pre-tile
data or use a tissuestack server at which point the server will
generate image tiles from your file (MINC/Nifti) on the fly. Let me
know if you are interested in contributing or would like to use the
code. It is licensed under a very liberal CC license at github.

The motivation for this was to display large overlaid
histology/blockface/MRI/CT datasets, something that we all seem to be
doing more and more of.


Thanks


--

============================================
Dr Andrew Janke
NIF Informatics Fellow
Centre for Advanced Imaging
University of Queensland
St Lucia, QLD, 4072. AUSTRALIA

Gehrmann Laboratory (Building 60),
Research Road

T: +61 7 3365 3392
F: +61 7 3365 3833
M: 0402 700 883
E: andrew.janke at cai.uq.edu.au
W: www.cai.uq.edu.au

CRICOS Provider Number #00025B
============================================


-- 

============================================
Dr Andrew Janke
NIF Informatics Fellow
Centre for Advanced Imaging
University of Queensland
St Lucia, QLD, 4072. AUSTRALIA

Gehrmann Laboratory (Building 60),
Research Road

T: +61 7 3365 3392
F: +61 7 3365 3833
M: 0402 700 883
E: andrew.janke at cai.uq.edu.au
W: www.cai.uq.edu.au

CRICOS Provider Number #00025B
============================================

From jackie.leung at alumni.utoronto.ca  Mon Aug  6 23:00:47 2012
From: jackie.leung at alumni.utoronto.ca (Jackie Leung)
Date: Mon, 6 Aug 2012 23:00:47 -0400
Subject: [MINC-users] am i using mincresample correctly
In-Reply-To: <CAG0CB23HVbz89ksyZ2-s3wg0OO3XVuYQrb70fh_VoZKwru5SbQ@mail.gmail.com>
References: <CAEOrv3xA_YsTuk=8GDq3HsfuvXQCV2qOixMEv-7hfa=9pqvuhw@mail.gmail.com>
	<CAG0CB23HVbz89ksyZ2-s3wg0OO3XVuYQrb70fh_VoZKwru5SbQ@mail.gmail.com>
Message-ID: <CAEOrv3yFPMqDa0CA4y2nqbBmKaqUz_TwBKTNoGmSP4oWXbNDjw@mail.gmail.com>

Thank you for the responses.  I am now fairly convinced that the transform
did take effect, but as Andrew said, I just don't see it using register.

Now this has led me to a second problem.  I wish to convert the registered
data into nifti format using mnc2nii, but this method doesn't seem to keep
my world coordinates, thus defeating the whole registration process.

I did try the -like option in mincresample, and that does work in
transforming the voxel space as well.  However, it also crops a significant
portion of my data as my target image has a lot fewer slices.

So, is there a way to apply a transform to the voxel space (not just world
space) while keeping the original field of view?  or another option would
be if mnc2nii can apply the world coordinates to the nifti output instead
of voxel space.

Any advice will be very much appreciated!!

Jackie

On Sun, Aug 5, 2012 at 8:57 AM, Andrew Janke <a.janke at gmail.com> wrote:

> Hi Jackie,
>
> On 5 August 2012 10:44, Jackie Leung <jackie.leung at alumni.utoronto.ca>
> wrote:
> > I'm new to MINC and I'm not sure if my coregistration process is correct.
> >
> > After getting the transform file from 'register', I apply it to my
> volumes
> > (it's a 4D dataset) with the following command:
> > mincresample -transformation matrix.xfm -tfm_input_sampling data.mnc
> > data_reg.mnc
> >
> > when i view the output data using register, it looks the same as before.
> > I'm I running the tool correctly?  Or does it have something to do with
> the
> > world coordinates vs voxel coordinates thing?
>
> My guess is that you have actually done the right thing. Just remember
> that register displays volumes in "voxel space" and
> -tfm_input_sampling will in general just change the voxel to world
> transform in a file. If you want to resample a file like another (the
> target) you probably want this:
>
>    mincresample -transformation matrix.xfm -like target.mnc data.mnc
> data_reg.mnc
>
> An explanation of what is going on is here:
>
>    http://en.wikibooks.org/wiki/MINC/Tools/mni_autoreg
>
> This is for minctracc, but the resampling section still applies.
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From sorench at gmail.com  Tue Aug  7 00:03:11 2012
From: sorench at gmail.com (Soren Christensen)
Date: Tue, 7 Aug 2012 14:03:11 +1000
Subject: [MINC-users] am i using mincresample correctly
In-Reply-To: <CAEOrv3yFPMqDa0CA4y2nqbBmKaqUz_TwBKTNoGmSP4oWXbNDjw@mail.gmail.com>
References: <CAEOrv3xA_YsTuk=8GDq3HsfuvXQCV2qOixMEv-7hfa=9pqvuhw@mail.gmail.com>
	<CAG0CB23HVbz89ksyZ2-s3wg0OO3XVuYQrb70fh_VoZKwru5SbQ@mail.gmail.com>
	<CAEOrv3yFPMqDa0CA4y2nqbBmKaqUz_TwBKTNoGmSP4oWXbNDjw@mail.gmail.com>
Message-ID: <CAHfsrRa2aEL80FxYvjg_pSON2d13rSJEpZL1OJ6cF8vKKeuOHA@mail.gmail.com>

I don't understand how you can not see differences in register if your
images are synced? Even if the images are identical on a voxel level,
they will differ by their cosines as mentioned by Andrew. So in
register you should indeed see a discrepancy in the composite view. I
tried it here with your arguments an I see the difference in the
composite image. You will not see the differences in the input columns
(column 1 and 2). I did a mincdiff on the source and target and as
Andrew said, the cosines differ, but the voxel content was identical -
but the difference is still there in register as it should be.

On the other issue, to achieve what you want (which sounds like a
sampling grid of the same dimensions and spacing as your input grid,
but centered on the grid of the target),  you would need to calculate
start and step sizes for your resampling grid based on the center and
orientation of the target grid (from where you would calculate start
and set step positions as desired) - you could then use this volume as
the "like" option.

If the input volumes intersect spatially, that is, they have roughly
the same center, then you can get away with a -like [inputvolume] in
your mincresample (replacing your -tfm_input_sampling). Depending on
the transform though, the image object may be shifted out of the FOV
of the source image and you will just get an empty or partial image.
Check your xfm file to see how much translation is going on.
So this would be  mincresample -like source -transformtation
source2target.xfm source
source_like_sourcegrid_but_transformed_to_match_target.mnc

To achieve the above (lacking the overlap), you can center the image
volumes relative to one another, by modifying the start coordinates of
one of the volumes so that the image volumes coincide centrally (this
of course will have implication for any dependencies on the spatial
details of this file, but often it can easily be done at the top of
your pipeline as a starting point).

There may be other ways too :)

Soren




On Tue, Aug 7, 2012 at 1:00 PM, Jackie Leung
<jackie.leung at alumni.utoronto.ca> wrote:
> Thank you for the responses.  I am now fairly convinced that the transform
> did take effect, but as Andrew said, I just don't see it using register.
>
> Now this has led me to a second problem.  I wish to convert the registered
> data into nifti format using mnc2nii, but this method doesn't seem to keep
> my world coordinates, thus defeating the whole registration process.
>
> I did try the -like option in mincresample, and that does work in
> transforming the voxel space as well.  However, it also crops a significant
> portion of my data as my target image has a lot fewer slices.
>
> So, is there a way to apply a transform to the voxel space (not just world
> space) while keeping the original field of view?  or another option would
> be if mnc2nii can apply the world coordinates to the nifti output instead
> of voxel space.
>
> Any advice will be very much appreciated!!
>
> Jackie
>
> On Sun, Aug 5, 2012 at 8:57 AM, Andrew Janke <a.janke at gmail.com> wrote:
>
>> Hi Jackie,
>>
>> On 5 August 2012 10:44, Jackie Leung <jackie.leung at alumni.utoronto.ca>
>> wrote:
>> > I'm new to MINC and I'm not sure if my coregistration process is correct.
>> >
>> > After getting the transform file from 'register', I apply it to my
>> volumes
>> > (it's a 4D dataset) with the following command:
>> > mincresample -transformation matrix.xfm -tfm_input_sampling data.mnc
>> > data_reg.mnc
>> >
>> > when i view the output data using register, it looks the same as before.
>> > I'm I running the tool correctly?  Or does it have something to do with
>> the
>> > world coordinates vs voxel coordinates thing?
>>
>> My guess is that you have actually done the right thing. Just remember
>> that register displays volumes in "voxel space" and
>> -tfm_input_sampling will in general just change the voxel to world
>> transform in a file. If you want to resample a file like another (the
>> target) you probably want this:
>>
>>    mincresample -transformation matrix.xfm -like target.mnc data.mnc
>> data_reg.mnc
>>
>> An explanation of what is going on is here:
>>
>>    http://en.wikibooks.org/wiki/MINC/Tools/mni_autoreg
>>
>> This is for minctracc, but the resampling section still applies.
>>
>>
>> a
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From a.janke at gmail.com  Tue Aug  7 08:26:25 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 7 Aug 2012 22:26:25 +1000
Subject: [MINC-users] am i using mincresample correctly
In-Reply-To: <CAEOrv3yFPMqDa0CA4y2nqbBmKaqUz_TwBKTNoGmSP4oWXbNDjw@mail.gmail.com>
References: <CAEOrv3xA_YsTuk=8GDq3HsfuvXQCV2qOixMEv-7hfa=9pqvuhw@mail.gmail.com>
	<CAG0CB23HVbz89ksyZ2-s3wg0OO3XVuYQrb70fh_VoZKwru5SbQ@mail.gmail.com>
	<CAEOrv3yFPMqDa0CA4y2nqbBmKaqUz_TwBKTNoGmSP4oWXbNDjw@mail.gmail.com>
Message-ID: <CAG0CB20vjhox77TtbXFG7k=uT6gL2w1Y5jPGaHKwZjqOdHF_7A@mail.gmail.com>

Hi Jackie,

On 7 August 2012 13:00, Jackie Leung <jackie.leung at alumni.utoronto.ca> wrote:
> Thank you for the responses.  I am now fairly convinced that the transform
> did take effect, but as Andrew said, I just don't see it using register.

Soren has answered this part pretty comprehensively already.

> Now this has led me to a second problem.  I wish to convert the registered
> data into nifti format using mnc2nii, but this method doesn't seem to keep
> my world coordinates, thus defeating the whole registration process.

mnc2nii does put this world to voxel transformation into the Nifti
header. Unfortunately for your various packages out there treat this
transformation differently. Some even ignore it completely.

> I did try the -like option in mincresample, and that does work in
> transforming the voxel space as well.  However, it also crops a significant
> portion of my data as my target image has a lot fewer slices.
>
> So, is there a way to apply a transform to the voxel space (not just world
> space) while keeping the original field of view?  or another option would
> be if mnc2nii can apply the world coordinates to the nifti output instead
> of voxel space.

I think you have two options.

1. resample the partial volume (the one with a lower resolution) to
the higher one. You currently seem to be going in the other direction.

2. As Soren mentioned define the sampling you want and resample to that.


a

From sorench at gmail.com  Tue Aug  7 21:10:52 2012
From: sorench at gmail.com (Soren Christensen)
Date: Wed, 8 Aug 2012 11:10:52 +1000
Subject: [MINC-users] am i using mincresample correctly
In-Reply-To: <CAG0CB20vjhox77TtbXFG7k=uT6gL2w1Y5jPGaHKwZjqOdHF_7A@mail.gmail.com>
References: <CAEOrv3xA_YsTuk=8GDq3HsfuvXQCV2qOixMEv-7hfa=9pqvuhw@mail.gmail.com>
	<CAG0CB23HVbz89ksyZ2-s3wg0OO3XVuYQrb70fh_VoZKwru5SbQ@mail.gmail.com>
	<CAEOrv3yFPMqDa0CA4y2nqbBmKaqUz_TwBKTNoGmSP4oWXbNDjw@mail.gmail.com>
	<CAG0CB20vjhox77TtbXFG7k=uT6gL2w1Y5jPGaHKwZjqOdHF_7A@mail.gmail.com>
Message-ID: <CAHfsrRZ01N7fk74yiAxSoJJiqyTd0x+VYgZsCSaeUtstyDaFBg@mail.gmail.com>

I just realized you ma have trouble using the composite view in
register if one or more of your volumes is 4D. At least for me, a 4D
volume will not render correctly in the composite view. You can work
around it by slicing out a single frame and doing away with the time
dimension using mincreshape. (eg -dimlenght time=0,0)

Soren

On Tue, Aug 7, 2012 at 10:26 PM, Andrew Janke <a.janke at gmail.com> wrote:
> Hi Jackie,
>
> On 7 August 2012 13:00, Jackie Leung <jackie.leung at alumni.utoronto.ca> wrote:
>> Thank you for the responses.  I am now fairly convinced that the transform
>> did take effect, but as Andrew said, I just don't see it using register.
>
> Soren has answered this part pretty comprehensively already.
>
>> Now this has led me to a second problem.  I wish to convert the registered
>> data into nifti format using mnc2nii, but this method doesn't seem to keep
>> my world coordinates, thus defeating the whole registration process.
>
> mnc2nii does put this world to voxel transformation into the Nifti
> header. Unfortunately for your various packages out there treat this
> transformation differently. Some even ignore it completely.
>
>> I did try the -like option in mincresample, and that does work in
>> transforming the voxel space as well.  However, it also crops a significant
>> portion of my data as my target image has a lot fewer slices.
>>
>> So, is there a way to apply a transform to the voxel space (not just world
>> space) while keeping the original field of view?  or another option would
>> be if mnc2nii can apply the world coordinates to the nifti output instead
>> of voxel space.
>
> I think you have two options.
>
> 1. resample the partial volume (the one with a lower resolution) to
> the higher one. You currently seem to be going in the other direction.
>
> 2. As Soren mentioned define the sampling you want and resample to that.
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From jackie.leung at alumni.utoronto.ca  Wed Aug  8 09:54:18 2012
From: jackie.leung at alumni.utoronto.ca (Jackie Leung)
Date: Wed, 8 Aug 2012 09:54:18 -0400
Subject: [MINC-users] am i using mincresample correctly
In-Reply-To: <CAHfsrRZ01N7fk74yiAxSoJJiqyTd0x+VYgZsCSaeUtstyDaFBg@mail.gmail.com>
References: <CAEOrv3xA_YsTuk=8GDq3HsfuvXQCV2qOixMEv-7hfa=9pqvuhw@mail.gmail.com>
	<CAG0CB23HVbz89ksyZ2-s3wg0OO3XVuYQrb70fh_VoZKwru5SbQ@mail.gmail.com>
	<CAEOrv3yFPMqDa0CA4y2nqbBmKaqUz_TwBKTNoGmSP4oWXbNDjw@mail.gmail.com>
	<CAG0CB20vjhox77TtbXFG7k=uT6gL2w1Y5jPGaHKwZjqOdHF_7A@mail.gmail.com>
	<CAHfsrRZ01N7fk74yiAxSoJJiqyTd0x+VYgZsCSaeUtstyDaFBg@mail.gmail.com>
Message-ID: <CAEOrv3y2b+ty_4qPrD2kT+J+W+WXYAXBV7XK6FS5QAvkhe0qiQ@mail.gmail.com>

OK, I tried using option 2...  that is, create a spatial template (if
that's the correct term) by expanding the FOV of the target data.  This is
the command I used:

mincresample target.mnc target_temp.mnc -xstart 30 -xnelements 250 -ystart
-50 -ynelements 250

then apply the transform to my data:

mincresample data.mnc data_reg.mnc -transformation matrix.xfm -like
target_temp.mnc

and it seems to work fine. Thank you Soren and Andrew for your advice.

I don't think I have the same issue with 4D data in register, but there is
one tiny thing I noticed. It appears that when I create target_temp.mnc,
the first slice of the first dynamic loses all its data and goes black.  I
even tried the simple command and got the same result:

mincresample target.mnc target_temp.mnc

This isn't a problem for my situation as the first data-point is not
necessary for my analysis anyways, but just wondering if this is some kind
of bug?

thanks,
jackie


On Tue, Aug 7, 2012 at 9:10 PM, Soren Christensen <sorench at gmail.com> wrote:

> I just realized you ma have trouble using the composite view in
> register if one or more of your volumes is 4D. At least for me, a 4D
> volume will not render correctly in the composite view. You can work
> around it by slicing out a single frame and doing away with the time
> dimension using mincreshape. (eg -dimlenght time=0,0)
>
> Soren
>
> On Tue, Aug 7, 2012 at 10:26 PM, Andrew Janke <a.janke at gmail.com> wrote:
> > Hi Jackie,
> >
> > On 7 August 2012 13:00, Jackie Leung <jackie.leung at alumni.utoronto.ca>
> wrote:
> >> Thank you for the responses.  I am now fairly convinced that the
> transform
> >> did take effect, but as Andrew said, I just don't see it using register.
> >
> > Soren has answered this part pretty comprehensively already.
> >
> >> Now this has led me to a second problem.  I wish to convert the
> registered
> >> data into nifti format using mnc2nii, but this method doesn't seem to
> keep
> >> my world coordinates, thus defeating the whole registration process.
> >
> > mnc2nii does put this world to voxel transformation into the Nifti
> > header. Unfortunately for your various packages out there treat this
> > transformation differently. Some even ignore it completely.
> >
> >> I did try the -like option in mincresample, and that does work in
> >> transforming the voxel space as well.  However, it also crops a
> significant
> >> portion of my data as my target image has a lot fewer slices.
> >>
> >> So, is there a way to apply a transform to the voxel space (not just
> world
> >> space) while keeping the original field of view?  or another option
> would
> >> be if mnc2nii can apply the world coordinates to the nifti output
> instead
> >> of voxel space.
> >
> > I think you have two options.
> >
> > 1. resample the partial volume (the one with a lower resolution) to
> > the higher one. You currently seem to be going in the other direction.
> >
> > 2. As Soren mentioned define the sampling you want and resample to that.
> >
> >
> > a
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From andrew.janke at cai.uq.edu.au  Wed Aug  8 12:17:04 2012
From: andrew.janke at cai.uq.edu.au (Andrew Janke)
Date: Thu, 9 Aug 2012 02:17:04 +1000
Subject: [MINC-users] Register GUI colour problem (OSX 10.7,
 minc-toolkit-0.3.11, register v1.4.00)
In-Reply-To: <3B90D905-A151-443A-8072-C84E907E18FD@uqconnect.edu.au>
References: <3B90D905-A151-443A-8072-C84E907E18FD@uqconnect.edu.au>
Message-ID: <CAG0CB23hYFNy755UMz9JDXmWyT_UJQ03RTGXQ4=0gPDpE2L4Sg@mail.gmail.com>

Hi Timothy,

This is caused by a long standing (and rather frustrating) change that
occurred in freeglut a while back. I have had success getting around
this by compiling register from source on some OSX machines. That said
I am yet to get this to work on some 10.7 machines.

I will attempt to recompile register on a 10.7.4 machine and if it
works put it up for download that you can then test.

a

On 3 August 2012 11:11, Timothy Tattersall
<timothy.tattersall at uqconnect.edu.au> wrote:
> Hi
>
> Does anyone know how I can fix my GUI colour scheme problem in register?
> The buttons are pink and red, and the text on the buttons is difficult to
> read.
>
> Here is a link to a screenshot
> http://s13.postimage.org/lxh1bpnef/Screen_Shot_2012_08_03_at_11_01_17_AM.p
> ng
>
> Thanks.
> Tim



-- 

============================================
Dr Andrew Janke
NIF Informatics Fellow
Centre for Advanced Imaging
University of Queensland
St Lucia, QLD, 4072. AUSTRALIA

Gehrmann Laboratory (Building 60),
Research Road

T: +61 7 3365 3392
F: +61 7 3365 3833
M: 0402 700 883
E: andrew.janke at cai.uq.edu.au
W: www.cai.uq.edu.au

CRICOS Provider Number #00025B
============================================

From a.janke at gmail.com  Wed Aug  8 23:54:16 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 9 Aug 2012 13:54:16 +1000
Subject: [MINC-users] Official Installation Instructions
In-Reply-To: <CAOq9ZoFyKMJG+5Q8SOwbJ6-Qy7Bg6wZ5-Jp3yp3t6FTj+Bc8tQ@mail.gmail.com>
References: <CAB-GmL0BjeNqn5YJwUtDa-WU_3o1rt+h1j1ZVXRETZ_hfauckw@mail.gmail.com>
	<4FF19819.2070607@gmail.com>
	<CAB-GmL0r1OpAkiBKcPjX6tniyY+guATavWo3P=3FnELvzEPNCw@mail.gmail.com>
	<4FF4D0B7.5030701@gmail.com>
	<CADPHwxAVc4MnCkyVJVUvJC0qbBsyN5ifNV58Jx_gcsQ3Z-pVBw@mail.gmail.com>
	<CAG0CB22M4tiDbN_3R3kyWTOkCav5uD-U5Mt5M0B5ytHPLFxJUA@mail.gmail.com>
	<4FF58536.8030400@gmail.com>
	<CAOq9ZoFyKMJG+5Q8SOwbJ6-Qy7Bg6wZ5-Jp3yp3t6FTj+Bc8tQ@mail.gmail.com>
Message-ID: <CAG0CB22UTRFKnoWgQw4KLR-z2x7CnDXA4kSUvZPD1n_adWi4Uw@mail.gmail.com>

Hi all,

On 6 July 2012 05:56, Luis Concha <lconcha at gmail.com> wrote:
> Thank you, Vlad and Andrew, for updating the binaries. I will also test
> them and come back with results.

On the note of stable binaries. I have updated a number of things with
the build and put some Ubuntu-precise packages here:

   http://packages.bic.mni.mcgill.ca/ubuntu-precise/

As per usual the install should simply involve adding this line to
/etc/apt/sources.list

   deb http://packages.bic.mni.mcgill.ca/ubuntu-precise ./

And then installing like this:

   $ apt-get install mincbundle

Note that as I don't generate keys or a signed repository so you will
get a message about installing from an untrusted source.


a

From eskild at gmail.com  Tue Aug 14 07:26:07 2012
From: eskild at gmail.com (Simon Eskildsen)
Date: Tue, 14 Aug 2012 13:26:07 +0200
Subject: [MINC-users] NIfTI to MINC revisited
Message-ID: <CAD3v437=An_Bch-xGh2sGritawoQesR_qDqnFkh5PHYUPLLQbg@mail.gmail.com>

Hi all,

I have problems keeping the right coordinate system(s) when converting
nifti to minc and back (after some minc magic). During my hunt for a
solution, I came across the discussion about the future of minc from
last year and noticed this statement from Andrew:

> I think we have "sufficient" compatibility with Nifti right now (nii2mnc, mnc2nii)

Let's see if my problem is covered by "sufficient" :)
A simple test:

$ nii2mnc -v
program: 2.1.20
libminc: 2.1.20
netcdf : 3.5.0 of Apr 21 2010 15:47:20 $
HDF5   : 1.8.5

$ mnc2nii -v
program: 2.1.20
libminc: 2.1.20
netcdf : 3.5.0 of Apr 21 2010 15:47:20 $
HDF5   : 1.8.5

$ nii2mnc anonymous.nii anonymous_minc.mnc
$ mnc2nii anonymous_minc.mnc recovered.nii

I found that the mapping to scanner space disappears, while the
mapping to standard space changes (see the headers below). In this
case these mappings are identical in the original file.
The original and recovered image do not align in any viewer I've tried
(itksnap, mricron, fslview).

I'm no expert in quaternions, direction cosines, and whatnot, so I
welcome suggestions.

Simon



The headers:


$ fslhd anonymous.nii
filename       anonymous.nii

sizeof_hdr     348
data_type      INT16
dim0           3
dim1           256
dim2           256
dim3           176
dim4           1
dim5           1
dim6           1
dim7           1
vox_units      mm
time_units     s
datatype       4
nbyper         2
bitpix         16
pixdim0        0.0000000000
pixdim1        1.0000000000
pixdim2        1.0000000000
pixdim3        1.0000000000
pixdim4        0.0000000000
pixdim5        0.0000000000
pixdim6        0.0000000000
pixdim7        0.0000000000
vox_offset     352
cal_max        0.0000
cal_min        0.0000
scl_slope      1.000000
scl_inter      0.000000
phase_dim      0
freq_dim       0
slice_dim      0
slice_name     Unknown
slice_code     0
slice_start    0
slice_end      0
slice_duration 0.000000
time_offset    0.000000
intent         Unknown
intent_code    0
intent_name
intent_p1      0.000000
intent_p2      0.000000
intent_p3      0.000000
qform_name     Scanner Anat
qform_code     1
qto_xyz:1      -0.015369  0.078765  0.996775  -95.418961
qto_xyz:2      -0.999882  -0.000984  -0.015340  164.075089
qto_xyz:3      0.000228  0.996893  -0.078770  -58.668182
qto_xyz:4      0.000000  0.000000  0.000000  1.000000
qform_xorient  Anterior-to-Posterior
qform_yorient  Inferior-to-Superior
qform_zorient  Left-to-Right
sform_name     Scanner Anat
sform_code     1
sto_xyz:1      -0.015369  0.078765  0.996775  -95.418961
sto_xyz:2      -0.999882  -0.000984  -0.015340  164.075089
sto_xyz:3      0.000228  0.996893  -0.078771  -58.668182
sto_xyz:4      0.000000  0.000000  0.000000  1.000000
sform_xorient  Anterior-to-Posterior
sform_yorient  Inferior-to-Superior
sform_zorient  Left-to-Right
file_type      NIFTI-1+
file_code      1
descrip        3T 3D GR\IR TR=2420ms/TE=3.7ms/FA=9deg 31-Mar-2011 16:25:15.378
aux_file


$ mincheader anonymous_minc.mnc
hdf5 anonymous_minc {
dimensions:
        xspace = 256 ;
        yspace = 256 ;
        zspace = 176 ;
variables:
        short image(zspace, yspace, xspace) ;
                image:dimorder = "zspace,yspace,xspace" ;
                image:varid = "MINC standard variable" ;
                image:vartype = "group________" ;
                image:version = "MINC Version    1.0" ;
                image:valid_range = 0., 1346. ;
                image:signtype = "signed__" ;
        double image-min ;
                image-min:varid = "MINC standard variable" ;
                image-min:version = "MINC Version    1.0" ;
                image-min:vartype = "var_attribute" ;
        double image-max ;
                image-max:varid = "MINC standard variable" ;
                image-max:version = "MINC Version    1.0" ;
                image-max:vartype = "var_attribute" ;
        int xspace ;
                xspace:length = 256 ;
                xspace:varid = "MINC standard variable" ;
                xspace:vartype = "dimension____" ;
                xspace:version = "MINC Version    1.0" ;
                xspace:comments = "X increases from patient left to right" ;
                xspace:spacing = "regular__" ;
                xspace:alignment = "centre" ;
                xspace:units = "mm" ;
                xspace:start = 162.602538854934 ;
                xspace:step = -1.00000000606898 ;
                xspace:direction_cosines = 0.0153694198465393,
0.999881857525793, -0.00022786915222191 ;
        int yspace ;
                yspace:length = 256 ;
                yspace:varid = "MINC standard variable" ;
                yspace:vartype = "dimension____" ;
                yspace:version = "MINC Version    1.0" ;
                yspace:comments = "Y increases from patient posterior
to anterior" ;
                yspace:spacing = "regular__" ;
                yspace:alignment = "centre" ;
                yspace:units = "mm" ;
                yspace:start = 66.1629031937321 ;
                yspace:step = -1.00000000035803 ;
                yspace:direction_cosines = -0.0787646993712715,
0.000983522855324584, -0.996892749906301 ;
        int zspace ;
                zspace:length = 176 ;
                zspace:varid = "MINC standard variable" ;
                zspace:vartype = "dimension____" ;
                zspace:version = "MINC Version    1.0" ;
                zspace:comments = "Z increases from patient inferior
to superior" ;
                zspace:spacing = "regular__" ;
                zspace:alignment = "centre" ;
                zspace:units = "mm" ;
                zspace:start = 93.0067360319189 ;
                zspace:step = -0.999999982764245 ;
                zspace:direction_cosines = -0.996774750246724,
0.0153396113625601, 0.0787705122100061 ;
        int acquisition ;
                acquisition:varid = "MINC standard variable" ;
                acquisition:vartype = "group________" ;
                acquisition:version = "MINC Version    1.0" ;
        int patient ;
                patient:varid = "MINC standard variable" ;
                patient:vartype = "group________" ;
                patient:version = "MINC Version    1.0" ;
                patient:full_name = "3T 3D GR\\IR
TR=2420ms/TE=3.7ms/FA=9deg 31-Mar-2011 16:25:15.378" ;
        int study ;
                study:varid = "MINC standard variable" ;
                study:vartype = "group________" ;
                study:version = "MINC Version    1.0" ;


$ fslhd recovered.nii
filename       recovered.nii

sizeof_hdr     348
data_type      FLOAT32
dim0           3
dim1           256
dim2           256
dim3           176
dim4           1
dim5           1
dim6           0
dim7           0
vox_units      mm
time_units     s
datatype       16
nbyper         4
bitpix         32
pixdim0        0.0000000000
pixdim1        1.0000000000
pixdim2        1.0000000000
pixdim3        1.0000000000
pixdim4        0.0000000000
pixdim5        1.0000000000
pixdim6        0.0000000000
pixdim7        0.0000000000
vox_offset     352
cal_max        0.0000
cal_min        0.0000
scl_slope      1.000000
scl_inter      0.000000
phase_dim      0
freq_dim       0
slice_dim      0
slice_name     Unknown
slice_code     0
slice_start    0
slice_end      0
slice_duration 0.000000
time_offset    0.000000
intent         Unknown
intent_code    0
intent_name
intent_p1      0.000000
intent_p2      0.000000
intent_p3      0.000000
qform_name     Unknown
qform_code     0
qto_xyz:1      1.000000  0.000000  0.000000  0.000000
qto_xyz:2      0.000000  1.000000  0.000000  0.000000
qto_xyz:3      0.000000  0.000000  1.000000  0.000000
qto_xyz:4      0.000000  0.000000  0.000000  1.000000
qform_xorient  Left-to-Right
qform_yorient  Posterior-to-Anterior
qform_zorient  Inferior-to-Superior
sform_name     Scanner Anat
sform_code     1
sto_xyz:1      0.015369  -0.078765  -0.996775  95.182411
sto_xyz:2      0.999882  0.000984  0.015340  -93.830009
sto_xyz:3      -0.000228  -0.996893  0.078771  181.812744
sto_xyz:4      0.000000  0.000000  0.000000  1.000000
sform_xorient  Posterior-to-Anterior
sform_yorient  Superior-to-Inferior
sform_zorient  Right-to-Left
file_type      NIFTI-1+
file_code      1
descrip        mnc2nii anonymous.mnc recovered.nii
aux_file

From a.janke at gmail.com  Tue Aug 14 08:16:47 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 14 Aug 2012 22:16:47 +1000
Subject: [MINC-users] NIfTI to MINC revisited
In-Reply-To: <CAD3v437=An_Bch-xGh2sGritawoQesR_qDqnFkh5PHYUPLLQbg@mail.gmail.com>
References: <CAD3v437=An_Bch-xGh2sGritawoQesR_qDqnFkh5PHYUPLLQbg@mail.gmail.com>
Message-ID: <CAG0CB235s0=GS2ed1V1V=7o_qXbCKOu5w0WauzgQ66MxWqJeQQ@mail.gmail.com>

Hi Simon,

On 14 August 2012 21:26, Simon Eskildsen <eskild at gmail.com> wrote:
> I found that the mapping to scanner space disappears, while the
> mapping to standard space changes (see the headers below). In this
> case these mappings are identical in the original file.
> The original and recovered image do not align in any viewer I've tried
> (itksnap, mricron, fslview).
>
> I'm no expert in quaternions, direction cosines, and whatnot, so I
> welcome suggestions.

I'll stand by my "sufficient" stance!  I am guessing that these .nii
images come from FSL (by the complete sform and qform
transformations). If so then what you would really need to write is a
fsl2mnc and mnc2fsl where the output of fsl2mnc would be a minc file
and a .xfm. The xfm would represent the transformation from native to
standard space from the FSL nii file (the qform transformation).

The conversion of a fsl .nii file to a minc will (from memory)
concatenate these two transformations into one and when you then
convert back to nii this will only be seen as an sform transformation.
This will manifest itself in what you are seeing.

So you have two options.

1) write fsl2mnc!

2) If you are just doing minc processing (no fiddling with
registration/co-ordinates) then I'd convert back to a .nii .img+.hdr
pair and replace the new header with the original.


a

From eskild at gmail.com  Tue Aug 14 08:33:19 2012
From: eskild at gmail.com (Simon Eskildsen)
Date: Tue, 14 Aug 2012 14:33:19 +0200
Subject: [MINC-users] NIfTI to MINC revisited
In-Reply-To: <CAG0CB235s0=GS2ed1V1V=7o_qXbCKOu5w0WauzgQ66MxWqJeQQ@mail.gmail.com>
References: <CAD3v437=An_Bch-xGh2sGritawoQesR_qDqnFkh5PHYUPLLQbg@mail.gmail.com>
	<CAG0CB235s0=GS2ed1V1V=7o_qXbCKOu5w0WauzgQ66MxWqJeQQ@mail.gmail.com>
Message-ID: <CAD3v43568ZTxuN4=x043NPUGeX=T8hryTRgGhAgWDnqHEpns+w@mail.gmail.com>

Hi Andrew,

On Tue, Aug 14, 2012 at 2:16 PM, Andrew Janke <a.janke at gmail.com> wrote:
> I'll stand by my "sufficient" stance!  I am guessing that these .nii
> images come from FSL (by the complete sform and qform
> transformations).

They have been converted from dicom using SPM, no fiddling (according
to my colleague).

> If so then what you would really need to write is a
> fsl2mnc and mnc2fsl where the output of fsl2mnc would be a minc file
> and a .xfm. The xfm would represent the transformation from native to
> standard space from the FSL nii file (the qform transformation).

Sounds like a fun project for the weekend.

> The conversion of a fsl .nii file to a minc will (from memory)
> concatenate these two transformations into one and when you then
> convert back to nii this will only be seen as an sform transformation.
> This will manifest itself in what you are seeing.

Makes sense.

> So you have two options.
>
> 1) write fsl2mnc!

Weekend project.

> 2) If you are just doing minc processing (no fiddling with
> registration/co-ordinates) then I'd convert back to a .nii .img+.hdr
> pair and replace the new header with the original.

This was my original plan. However, it turned out that importing minc1
(no support for minc2) files directly into SPM solved the issue. Maybe
my weekend is saved.

Simon

>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From vladimir.fonov at gmail.com  Tue Aug 14 09:04:15 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Tue, 14 Aug 2012 09:04:15 -0400
Subject: [MINC-users] NIfTI to MINC revisited
In-Reply-To: <CAD3v43568ZTxuN4=x043NPUGeX=T8hryTRgGhAgWDnqHEpns+w@mail.gmail.com>
References: <CAD3v437=An_Bch-xGh2sGritawoQesR_qDqnFkh5PHYUPLLQbg@mail.gmail.com>
	<CAG0CB235s0=GS2ed1V1V=7o_qXbCKOu5w0WauzgQ66MxWqJeQQ@mail.gmail.com>
	<CAD3v43568ZTxuN4=x043NPUGeX=T8hryTRgGhAgWDnqHEpns+w@mail.gmail.com>
Message-ID: <CAMCwi7PYR3ncuR8jAuqvZeEy0+sptKYt-kHGZJYu8GVBHCdHuQ@mail.gmail.com>

Hello Simon,

can you try itk_convert from minc-toolkit to perform conversion? (
/ipl/quarantine/experimental/mt/bin/itk_convert , source
/ipl/quarantine/experimental/mt/minc-toolkit-config.sh first)

On Tue, Aug 14, 2012 at 8:33 AM, Simon Eskildsen <eskild at gmail.com> wrote:
> Hi Andrew,
>
> On Tue, Aug 14, 2012 at 2:16 PM, Andrew Janke <a.janke at gmail.com> wrote:
>> I'll stand by my "sufficient" stance!  I am guessing that these .nii
>> images come from FSL (by the complete sform and qform
>> transformations).
>
> They have been converted from dicom using SPM, no fiddling (according
> to my colleague).
>
>> If so then what you would really need to write is a
>> fsl2mnc and mnc2fsl where the output of fsl2mnc would be a minc file
>> and a .xfm. The xfm would represent the transformation from native to
>> standard space from the FSL nii file (the qform transformation).
>
> Sounds like a fun project for the weekend.
>
>> The conversion of a fsl .nii file to a minc will (from memory)
>> concatenate these two transformations into one and when you then
>> convert back to nii this will only be seen as an sform transformation.
>> This will manifest itself in what you are seeing.
>
> Makes sense.
>
>> So you have two options.
>>
>> 1) write fsl2mnc!
>
> Weekend project.
>
>> 2) If you are just doing minc processing (no fiddling with
>> registration/co-ordinates) then I'd convert back to a .nii .img+.hdr
>> pair and replace the new header with the original.
>
> This was my original plan. However, it turned out that importing minc1
> (no support for minc2) files directly into SPM solved the issue. Maybe
> my weekend is saved.
>
> Simon
>
>>
>>
>> a
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users



-- 
Best regards,

 Vladimir S. Fonov ~ vladimir <dot> fonov <at> gmail <dot> com

From eskild at gmail.com  Tue Aug 14 10:50:28 2012
From: eskild at gmail.com (Simon Eskildsen)
Date: Tue, 14 Aug 2012 16:50:28 +0200
Subject: [MINC-users] NIfTI to MINC revisited
In-Reply-To: <CAMCwi7PYR3ncuR8jAuqvZeEy0+sptKYt-kHGZJYu8GVBHCdHuQ@mail.gmail.com>
References: <CAD3v437=An_Bch-xGh2sGritawoQesR_qDqnFkh5PHYUPLLQbg@mail.gmail.com>
	<CAG0CB235s0=GS2ed1V1V=7o_qXbCKOu5w0WauzgQ66MxWqJeQQ@mail.gmail.com>
	<CAD3v43568ZTxuN4=x043NPUGeX=T8hryTRgGhAgWDnqHEpns+w@mail.gmail.com>
	<CAMCwi7PYR3ncuR8jAuqvZeEy0+sptKYt-kHGZJYu8GVBHCdHuQ@mail.gmail.com>
Message-ID: <CAD3v436DrZ=RzHsOxJso=EmPu++O2Ktijm4Wizmc5LvRO59iBg@mail.gmail.com>

Hi Vlad,

On Tue, Aug 14, 2012 at 3:04 PM, Vladimir S. FONOV
<vladimir.fonov at gmail.com> wrote:
> can you try itk_convert from minc-toolkit to perform conversion? (
> /ipl/quarantine/experimental/mt/bin/itk_convert , source
> /ipl/quarantine/experimental/mt/minc-toolkit-config.sh first)

That seemed to work. The qform is preserved, though the code changes
from 1 to 2...?

$ diff a.hdr r.hdr
1c1
< filename       anonymous.nii
---
> filename       recovered.nii
14c14
< time_units     s
---
> time_units     Unknown
46,48c46,48
< qform_name     Scanner Anat
< qform_code     1
< qto_xyz:1      -0.015369  0.078765  0.996775  -95.418961
---
> qform_name     Aligned Anat
> qform_code     2
> qto_xyz:1      -0.015370  0.078765  0.996775  -95.418961
59c59
< sto_xyz:3      0.000228  0.996893  -0.078771  -58.668182
---
> sto_xyz:3      0.000228  0.996893  -0.078770  -58.668182
66c66
< descrip        3T 3D GR\IR TR=2420ms/TE=3.7ms/FA=9deg 31-Mar-2011 16:25:15.378
---
> descrip


Thanks,
Simon

From vladimir.fonov at gmail.com  Tue Aug 14 10:54:29 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Tue, 14 Aug 2012 10:54:29 -0400
Subject: [MINC-users] NIfTI to MINC revisited
In-Reply-To: <CAD3v436DrZ=RzHsOxJso=EmPu++O2Ktijm4Wizmc5LvRO59iBg@mail.gmail.com>
References: <CAD3v437=An_Bch-xGh2sGritawoQesR_qDqnFkh5PHYUPLLQbg@mail.gmail.com>
	<CAG0CB235s0=GS2ed1V1V=7o_qXbCKOu5w0WauzgQ66MxWqJeQQ@mail.gmail.com>
	<CAD3v43568ZTxuN4=x043NPUGeX=T8hryTRgGhAgWDnqHEpns+w@mail.gmail.com>
	<CAMCwi7PYR3ncuR8jAuqvZeEy0+sptKYt-kHGZJYu8GVBHCdHuQ@mail.gmail.com>
	<CAD3v436DrZ=RzHsOxJso=EmPu++O2Ktijm4Wizmc5LvRO59iBg@mail.gmail.com>
Message-ID: <502A66A5.8010409@gmail.com>

Hello Simon,


itk_convert is pretty straight-forward, it uses ITK IO mechanisms to 
read and write whatever  is supported, trying to preserve as much as 
possible.

On 12-08-14 10:50 AM, Simon Eskildsen wrote:
> Hi Vlad,
>
> On Tue, Aug 14, 2012 at 3:04 PM, Vladimir S. FONOV
> <vladimir.fonov at gmail.com> wrote:
>> can you try itk_convert from minc-toolkit to perform conversion? (
>> /ipl/quarantine/experimental/mt/bin/itk_convert , source
>> /ipl/quarantine/experimental/mt/minc-toolkit-config.sh first)
>
> That seemed to work. The qform is preserved, though the code changes
> from 1 to 2...?
>
> $ diff a.hdr r.hdr
> 1c1
> < filename       anonymous.nii
> ---
>> filename       recovered.nii
> 14c14
> < time_units     s
> ---
>> time_units     Unknown
> 46,48c46,48
> < qform_name     Scanner Anat
> < qform_code     1
> < qto_xyz:1      -0.015369  0.078765  0.996775  -95.418961
> ---
>> qform_name     Aligned Anat
>> qform_code     2
>> qto_xyz:1      -0.015370  0.078765  0.996775  -95.418961
> 59c59
> < sto_xyz:3      0.000228  0.996893  -0.078771  -58.668182
> ---
>> sto_xyz:3      0.000228  0.996893  -0.078770  -58.668182
> 66c66
> < descrip        3T 3D GR\IR TR=2420ms/TE=3.7ms/FA=9deg 31-Mar-2011 16:25:15.378
> ---
>> descrip
>
>
> Thanks,
> Simon
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


-- 
Best regards,

  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com