From sorench at gmail.com  Sat Nov  3 22:55:44 2007
From: sorench at gmail.com (Soren Christensen)
Date: Sun, 4 Nov 2007 13:55:44 +1100
Subject: [MINC-users] Display - global
In-Reply-To: <d6e2d6550710302212v26fdd85cl36716f99f92c3f65@mail.gmail.com>
References: <d6e2d6550710302212v26fdd85cl36716f99f92c3f65@mail.gmail.com>
Message-ID: <d6e2d6550711031955r712924cdg57c1a22ecab5acca@mail.gmail.com>

Hi,
 Just in case someone should google this in the future and need a
custom presentation of Display (I guess this can be written to a
config file, but I made these changes to the sources):

In global_variables.h make these changes:

//start with colormapping from 0.0 - 0.60 of max instead of 0.25-.75
DEF_GLOBAL( Initial_low_limit_position, Real, 0.0 )
DEF_GLOBAL( Initial_high_limit_position, Real, 0.60 )
//default colormap=gray
DEF_GLOBAL( Initial_colour_coding_type, int, 0 )
//reserve a larger portion of the slice window for the transverse sections
DEF_GLOBAL( Slice_divider_x_position, Real, 0.9 )
DEF_GLOBAL( Slice_divider_y_position, Real, 0.9 )

To startup Display bigger than the default 300x300 stamp size:
In Graphics/GLUT_windows/glut_windows.c
 #define DEFAULT_WINDOW_X_SIZE 800
 #define DEFAULT_WINDOW_Y_SIZE 800

These changes make it a lot easier to flick through a large number of patients.



Cheers
Soren


On 10/31/07, Soren Christensen <sorench at gmail.com> wrote:
> Hi,
>  Is there a good place to find documentation for how to use the Display
> -global option?
> I'd like to customize the window size and the proportion of the window
> allocated to the transverse section as well as the colormap windowing in
> order to speed up screening and QA of multiple subjects. The
> global_variables.h seem to contain default settings, but when I use them
> with the -global option it seems to have no effect.
> So what I am looking for is:
> 1) Name of the variables i need to change: (colormap min,max   window
> position and width+hight     size of transverse rendering inside window)
> 2) How to do this using the command line or alternatively configuration file
> or in another way.
>
>
> Cheers
> Soren

From penhunelab at gmail.com  Mon Nov  5 11:17:12 2007
From: penhunelab at gmail.com (Penhune Lab)
Date: Mon, 5 Nov 2007 11:17:12 -0500
Subject: [MINC-users] fMRI signal extraction -help request
Message-ID: <c983d2410711050817q6e88170bsb09262dbe9798d67@mail.gmail.com>

Greetings,

I have been having some problems creating percent BOLD signal change plots
for my contrasts and wondered if someone could point me in the right
direction.

I have an experiment with two conditions, L and I, and i am interested in
the learning of L across four fMRI runs.
L is a motor sequence; I is a motor baseline.
GOAL: I intend to use signal extractions to help identify the changes in
activity which occur during learning.

How I understand that signal extractions work:
1) Extract voxel values from _ef file of the L-I contrast
2) extract voxel values from _ef file of the I contrast
3) divide the two and multiply by 100 to give signal change of L relative to
I ( 100*(L-I)/abs(I) )
4) plot across the four runs, see how particular areas change with learning
of L

I did this using the extract.m function (with all of the proper coordinate
transforms) but ran into a bit of strangeness. Before multiplying by 100,
the (L-I)/I values normally vary between .01 and 4 or 5, with occasional
voxels giving me values of over 100 or more (both negative and positive
numbers)! Giving me 'normal' signal change variation of 1-500%, which
doesn't seem too normal... As far as I can tell, this was caused by I
contrast values which were very close to zero. This didn't really seem
reasonable, so I took some advice and tried to detrend my data before
specifying the conditions ( i.e., I ran the raw files through fmrilm with
trends= [3 1 1] and without specifying a design matrix). The intent was to
then run fmrilm with the design matrix and contrast specifications to
produce my contrast files, then run the extractions on them (the theory
being that this would be a better set of files to do the extractions on).
Unfortunately I was unable to test this as apparently there is a limit on
the number of frames which you can process in this way - my experiment
contains 265 frames and the limit appears to be 160 (emma gives an error).

So, I have two major questions. Is my understanding of extractions correct?
How can I extract the values properly, such that I can reach my goal?

Thank you in advance!
Chris

-- 
Laboratory for Motor Learning and Neural Plasticity
Directed by Dr. Virginia Penhune
Department of Psychology, Concordia University
SP-A 244, 7141 Sherbrooke St. W
Montreal, QC  H4B 1R6  Canada
(514)848-2424 ext. 7567
http://psychology.concordia.ca/fac/penhune/winindex.html

From sean at rogue-research.com  Mon Nov  5 14:10:31 2007
From: sean at rogue-research.com (Sean McBride)
Date: Mon, 5 Nov 2007 14:10:31 -0500
Subject: [MINC-users] [ANN] MINC1 & MINC2 Quick Look plugin for Mac OS X 10.5
Message-ID: <20071105191031.538708890@smtp1.sympatico.ca>

Hi all,

I hope this isn't too off-topic, but I know there are several Mac OS X
users on this list, so I wanted to point out that we (Rogue Research)
have released a Quick Look plugin for Mac OS X 10.5.  It allows you to
see previews of MINC1, MINC2, NIfTI, and DICOM files in the Finder and
other applications:

It's free (as in beer):
<http://www.rogue-research.com/BrainsightQuickLook1.0.dmg>

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr?al, Qu?bec, Canada



From nikelski at bic.mni.mcgill.ca  Tue Nov  6 19:06:09 2007
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Tue, 6 Nov 2007 19:06:09 -0500
Subject: [MINC-users] mritotal fails in autocrop during nlfit
Message-ID: <e12172550711061606r55fa3bb4v6520047a829e08b5@mail.gmail.com>

Hi all,

   I seem to be the only one (trying) to use mritotal to do nonlinear
fitting. Andrew fixed the xfmtool problem, but it now falls over in
autocrop. Specifically, if I say ...

==========
>>mritotal -verbose -modeldir /usr/local/mni/share/mni_autoreg -model
icbm_avg_152_t1_tal_lin -nonlinear -startlevel 16 -stoplevel 4b
-objective xcorr -nocrop invol.mnc outvol.mnc
==========

I get (eventually) ...

==========
[mritotal] [jnikelski at chimera:/data/raid01/userData/jnikelski/nlfit]
[2007-11-06 17:48:14] /usr/local/mni/bin/autocrop invol.mnc
/var/tmp/mritotal_10259//invol_headcrop.mnc -bbox
/var/tmp/mritotal_10259//invol_headmask.mnc -expand 6 6 6
set_options: must supply even number of args (option/value pairs) at
/usr/local/mni/bin/autocrop line 681
mritotal: crashed while running autocrop (termination status=65280)
==========

   The set_options reference is in Spawn::spawn, which seems to want
its arguments in pairs (dunno why).  Here are the autocrop details:

jnikelski at chimera:~/data/nlfit$ autocrop -version
autocrop 0.99.2, built from:
Package mni_autoreg 0.99.2, compiled by rotor at romeo
(i686-pc-linux-gnu) on Mon May  8 23:16:34 EDT 2006

-Jim

From vladimir.fonov at gmail.com  Tue Nov  6 22:23:05 2007
From: vladimir.fonov at gmail.com (Vladimir S. Fonov)
Date: Tue, 06 Nov 2007 22:23:05 -0500
Subject: [MINC-users] mritotal fails in autocrop during nlfit
In-Reply-To: <e12172550711061606r55fa3bb4v6520047a829e08b5@mail.gmail.com>
References: <e12172550711061606r55fa3bb4v6520047a829e08b5@mail.gmail.com>
Message-ID: <47312F99.1030308@gmail.com>

Hello,

EJ Nikelski wrote:
> Hi all,
>
>    I seem to be the only one (trying) to use mritotal to do nonlinear
> fitting. Andrew fixed the xfmtool problem, but it now falls over in
> autocrop. Specifically, if I say ...
>   
I thought I submitted  a fix to autocrop a long time ago, to fix this 
problem:

681c681
<    Spawn ("mincbbox -threshold $threshold -two_lines $volume", 
$bbox_file);
---
 >    Spawn ("mincbbox -threshold $threshold -two_lines $volume",stdout 
=> ">$bbox_file");

-- 
Best regards,
 Vladimir S. Fonov ~ vladimir.fonov <at> gmail.com


From claude at bic.mni.mcgill.ca  Tue Nov  6 23:38:53 2007
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Tue, 6 Nov 2007 23:38:53 -0500 (EST)
Subject: [MINC-users] mritotal fails in autocrop during nlfit
References: <e12172550711061606r55fa3bb4v6520047a829e08b5@mail.gmail.com>
Message-ID: <200711070438.lA74cr7w23768998@yorick.bic.mni.mcgill.ca>

Hi,

> I thought I submitted  a fix to autocrop a long time ago, to fix this 
> problem:
> 
> 681c681
> <    Spawn ("mincbbox -threshold $threshold -two_lines $volume", 
> $bbox_file);
> ---
>  >    Spawn ("mincbbox -threshold $threshold -two_lines $volume",stdout 
> => ">$bbox_file");

You are right, Vladimir. This fix is part of revision 1.10 in cvs;
however, the latest tagged version 0.99.3 uses revision 1.9, which
does not include this fix. Perhaps it's time to update the package
even if this is the only change in the last year. I'd say it's also
time to upgrade /usr/local/mni/bin and certainly enforce minc2. :-)

As for non-linear registration, CIVET does not use mritotal, so this
bug is not an issue. However, if you prefer to use mritotal, we'll
have to fix this sooner than later.

Claude

From bouffard at bic.mni.mcgill.ca  Wed Nov  7 15:22:04 2007
From: bouffard at bic.mni.mcgill.ca (Marc BOUFFARD)
Date: Wed, 7 Nov 2007 15:22:04 -0500
Subject: [MINC-users] nlpfit minctracc
Message-ID: <Pine.SGI.4.58.0711071503230.23986000@yorick.bic.mni.mcgill.ca>

Hello,

Using the following command on two separate computers (yorick and a linux
machine)

nlpfit -init_xfm lin.xfm source.mnc target.mnc nlin.xfm

and then using the resulting grid file to compute the determinant of the
jacobian using mincblob:

mincblob -det grid.mnc det.mnc


yields differing det.mnc files.  This is not caused by mincblob since this
command gives the same result given the same grid file.  Therefore the
differing det.mnc files are caused by differing grid files.  In
particular, on the linux machine there are many artifacts outside the
brain not present in the files obtained from yorick.  Inside the brain the
patterns are similar although the values are not exactly the same (within
about 15%).

The templates and files used on both computers are exactly the same.  The
only difference I could find was minctracc.  On yorick:

yorick 157% minctracc -version
The program <minctracc> was built from:
Package MNI AutoReg, version 0.98k, compiled by swmgr at yorick
(mips-sgi-irix6.5) on 2003-11-26 at 16:46:16

and on the linux machine:

oliver% minctracc -version
The program <minctracc> was built from:
Package mni_autoreg 0.99.2, compiled by rotor at romeo (i686-pc-linux-gnu) on
Mon May  8 23:16:34 EDT 2006


What between the two versions could cause the difference between the grid
files and consequently the det.mnc files?  The fact that most differences
are outside the brain and on the edges suggests a masking difference but I
have not defined a mask in either case.

Marc

From a.janke at gmail.com  Wed Nov  7 22:46:23 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 8 Nov 2007 14:46:23 +1100
Subject: [MINC-users] New packages available..
Message-ID: <d747ed50711071946v28d78897h139e943baa7ff3d7@mail.gmail.com>

Hi all,

Given the large number of changes in many of the MINC tools as of
late, I have finally got to building a bunch of binary packages using
MINC2 with all the latest patches.  So far I have built things for
i386 and amd64 Ubuntu.  Get them here:

   http://packages.bic.mni.mcgill.ca/ubuntu-feisty-amd64/

or

   http://packages.bic.mni.mcgill.ca/ubuntu-feisty-i386/

To make them work just add something like this to your /etc/apt/sources.list

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

I will get to OSX packages and the likes soon but these will all be
MINC2 as per the packages above.

Let me know if they work OK for you.

-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From kinomura at idac.tohoku.ac.jp  Thu Nov  8 02:12:17 2007
From: kinomura at idac.tohoku.ac.jp (=?ISO-2022-JP?B?GyRCTFpHN0I8GyhCIBskQj1FQ0sbKEI=?=)
Date: Thu, 8 Nov 2007 16:12:17 +0900
Subject: [MINC-users] New packages available..
In-Reply-To: <d747ed50711071946v28d78897h139e943baa7ff3d7@mail.gmail.com>
References: <d747ed50711071946v28d78897h139e943baa7ff3d7@mail.gmail.com>
Message-ID: <8B4FA427-C1DF-4E5D-923F-B087163B2EE5@idac.tohoku.ac.jp>

????
?????????
==============================
??? ??
?????????????
??????????????
e-mail: kinomura at idac.tohoku.ac.jp
??: 8559 / 8557
??PHS: 5435
==============================



On 2007/11/08, at 12:46, Andrew Janke wrote:

> Hi all,
>
> Given the large number of changes in many of the MINC tools as of
> late, I have finally got to building a bunch of binary packages using
> MINC2 with all the latest patches.  So far I have built things for
> i386 and amd64 Ubuntu.  Get them here:
>
>    http://packages.bic.mni.mcgill.ca/ubuntu-feisty-amd64/
>
> or
>
>    http://packages.bic.mni.mcgill.ca/ubuntu-feisty-i386/
>
> To make them work just add something like this to your /etc/apt/ 
> sources.list
>
>    deb http://packages.bic.mni.mcgill.ca/ubuntu-feisty-amd64 ./
>
> I will get to OSX packages and the likes soon but these will all be
> MINC2 as per the packages above.
>
> Let me know if they work OK for you.
>
> -- 
> Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia    +61 (402) 700 883
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


From alex at bic.mni.mcgill.ca  Thu Nov  8 13:27:59 2007
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Thu, 8 Nov 2007 13:27:59 -0500
Subject: [MINC-users] New packages available..
In-Reply-To: <d747ed50711071946v28d78897h139e943baa7ff3d7@mail.gmail.com>
References: <d747ed50711071946v28d78897h139e943baa7ff3d7@mail.gmail.com>
Message-ID: <e758a6650711081027l7eee4956ve18ca260fa96a9a5@mail.gmail.com>

Hi Andrew,

Thanks, and much needed! :)

Out of curiosity - how do these play with the MINC1 deb packages? All
the MINC2 installs in /usr/local/bic, whereas MINC1 goes in
/usr/local/mni, so theoretically they are safe to keep side-by-side
(leaving aside why one might want to do this), right?

But then package naming comes in - say one has all the MINC1 deb
packages installed, one adds a new line for the MINC2 packages to
sources.list, and runs apt-get update/upgrade. As far as I can tell
that will upgrade only minc and bicpl to MINC2, and leave a bunch of a
scattered minc1 and minc2 stuff in both /usr/local/{mni,bic}.

I suppose there is no way to keep a parallel MINC1 and MINC2 install
while relying on the deb packages?

On a related note, these packages install OK on debian sarge, but
won't run because libhdf5-1.6.5 does not seem to be available as a
sarge package (1.6.2 is).

-- A

On Nov 7, 2007 10:46 PM, Andrew Janke <a.janke at gmail.com> wrote:
> Hi all,
>
> Given the large number of changes in many of the MINC tools as of
> late, I have finally got to building a bunch of binary packages using
> MINC2 with all the latest patches.  So far I have built things for
> i386 and amd64 Ubuntu.  Get them here:
>
>    http://packages.bic.mni.mcgill.ca/ubuntu-feisty-amd64/
>
> or
>
>    http://packages.bic.mni.mcgill.ca/ubuntu-feisty-i386/
>
> To make them work just add something like this to your /etc/apt/sources.list
>
>    deb http://packages.bic.mni.mcgill.ca/ubuntu-feisty-amd64 ./
>
> I will get to OSX packages and the likes soon but these will all be
> MINC2 as per the packages above.
>
> Let me know if they work OK for you.
>
> --
> Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia    +61 (402) 700 883
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From a.janke at gmail.com  Thu Nov  8 17:33:59 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 9 Nov 2007 09:33:59 +1100
Subject: [MINC-users] New packages available..
In-Reply-To: <e758a6650711081027l7eee4956ve18ca260fa96a9a5@mail.gmail.com>
References: <d747ed50711071946v28d78897h139e943baa7ff3d7@mail.gmail.com>
	<e758a6650711081027l7eee4956ve18ca260fa96a9a5@mail.gmail.com>
Message-ID: <d747ed50711081433g7592fce7x9a8da95fee5648ee@mail.gmail.com>

> Out of curiosity - how do these play with the MINC1 deb packages? All
> the MINC2 installs in /usr/local/bic, whereas MINC1 goes in
> /usr/local/mni, so theoretically they are safe to keep side-by-side
> (leaving aside why one might want to do this), right?

I thought long and hard about this and finally came to realisation
that I did not want to call MINC 2 "minc2" if only for the obvious
reason that then what do I call mni-autoreg that is linked against
this?  mni-autoreg-minc2? etc.  So I stuck with the notion of
breaking/updating everything.

> But then package naming comes in - say one has all the MINC1 deb
> packages installed, one adds a new line for the MINC2 packages to
> sources.list, and runs apt-get update/upgrade. As far as I can tell
> that will upgrade only minc and bicpl to MINC2, and leave a bunch of a
> scattered minc1 and minc2 stuff in both /usr/local/{mni,bic}.

It should upgrade everything to MINC2 in time as I get to releasing
updated versions of packages. Note the "should". :)

> I suppose there is no way to keep a parallel MINC1 and MINC2 install
> while relying on the deb packages?

There is, but the only way that I know would be to rename all the old
packages minc1 or something. That seems just as ugly. I do know that
there are ways in which you can trick apt-get into keeping both but it
is not straight forward.

> On a related note, these packages install OK on debian sarge, but
> won't run because libhdf5-1.6.5 does not seem to be available as a
> sarge package (1.6.2 is).

Correct, I am slowly getting my virtual machines all working so that i
can build packages for all the various debians..

On that note, I would like to have some sort of informal vote:

What architectures are people using for MINC and thus which should I
build packages for?  I know we have these so far that are fairly well
used:

   * Ubuntu (Feisty + Gutsy in time)
   * OSX (10.4 and 10.5)


There are then also these ugly cousins:
   * XP + Cygwin  (not that well updated as I now have Vista)
   * Windows native (possible via CMake now but not pretty)

Get your votes in now! :)


a

From penhunelab at gmail.com  Thu Nov  8 18:15:32 2007
From: penhunelab at gmail.com (Penhune Lab)
Date: Thu, 8 Nov 2007 18:15:32 -0500
Subject: [MINC-users] New packages available..
In-Reply-To: <d747ed50711081433g7592fce7x9a8da95fee5648ee@mail.gmail.com>
References: <d747ed50711071946v28d78897h139e943baa7ff3d7@mail.gmail.com>
	<e758a6650711081027l7eee4956ve18ca260fa96a9a5@mail.gmail.com>
	<d747ed50711081433g7592fce7x9a8da95fee5648ee@mail.gmail.com>
Message-ID: <c983d2410711081515j3fcfaec6re971a1fdf8efcae0@mail.gmail.com>

i would like a windows native compile

On 11/8/07, Andrew Janke <a.janke at gmail.com> wrote:
>
> > Out of curiosity - how do these play with the MINC1 deb packages? All
> > the MINC2 installs in /usr/local/bic, whereas MINC1 goes in
> > /usr/local/mni, so theoretically they are safe to keep side-by-side
> > (leaving aside why one might want to do this), right?
>
> I thought long and hard about this and finally came to realisation
> that I did not want to call MINC 2 "minc2" if only for the obvious
> reason that then what do I call mni-autoreg that is linked against
> this?  mni-autoreg-minc2? etc.  So I stuck with the notion of
> breaking/updating everything.
>
> > But then package naming comes in - say one has all the MINC1 deb
> > packages installed, one adds a new line for the MINC2 packages to
> > sources.list, and runs apt-get update/upgrade. As far as I can tell
> > that will upgrade only minc and bicpl to MINC2, and leave a bunch of a
> > scattered minc1 and minc2 stuff in both /usr/local/{mni,bic}.
>
> It should upgrade everything to MINC2 in time as I get to releasing
> updated versions of packages. Note the "should". :)
>
> > I suppose there is no way to keep a parallel MINC1 and MINC2 install
> > while relying on the deb packages?
>
> There is, but the only way that I know would be to rename all the old
> packages minc1 or something. That seems just as ugly. I do know that
> there are ways in which you can trick apt-get into keeping both but it
> is not straight forward.
>
> > On a related note, these packages install OK on debian sarge, but
> > won't run because libhdf5-1.6.5 does not seem to be available as a
> > sarge package (1.6.2 is).
>
> Correct, I am slowly getting my virtual machines all working so that i
> can build packages for all the various debians..
>
> On that note, I would like to have some sort of informal vote:
>
> What architectures are people using for MINC and thus which should I
> build packages for?  I know we have these so far that are fairly well
> used:
>
>    * Ubuntu (Feisty + Gutsy in time)
>    * OSX (10.4 and 10.5)
>
>
> There are then also these ugly cousins:
>    * XP + Cygwin  (not that well updated as I now have Vista)
>    * Windows native (possible via CMake now but not pretty)
>
> Get your votes in now! :)
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
Laboratory for Motor Learning and Neural Plasticity
Directed by Dr. Virginia Penhune
Department of Psychology, Concordia University
SP-A 244, 7141 Sherbrooke St. W
Montreal, QC  H4B 1R6  Canada
(514)848-2424 ext. 7567
http://psychology.concordia.ca/fac/penhune/winindex.html

From nikelski at bic.mni.mcgill.ca  Sat Nov 10 13:47:45 2007
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Sat, 10 Nov 2007 13:47:45 -0500
Subject: [MINC-users] New packages available..
In-Reply-To: <e758a6650711081027l7eee4956ve18ca260fa96a9a5@mail.gmail.com>
References: <d747ed50711071946v28d78897h139e943baa7ff3d7@mail.gmail.com>
	<e758a6650711081027l7eee4956ve18ca260fa96a9a5@mail.gmail.com>
Message-ID: <e12172550711101047r3304b160g3253635570f3e7af@mail.gmail.com>

Hi Andrew,

   I'm currently building the tools from source ... and I have a
question about Szip usage in HDF5.  Are we building HDF5 to use Szip
for both compression and decompression? Or are we using zlib only for
compression? I would hate to build everything without Szip locally,
only to find that I am unable to read BIC-generated volumes.

Thanks,

-Jim


On 11/8/07, Alex Zijdenbos <alex at bic.mni.mcgill.ca> wrote:
> Hi Andrew,
>
> Thanks, and much needed! :)
>
> Out of curiosity - how do these play with the MINC1 deb packages? All
> the MINC2 installs in /usr/local/bic, whereas MINC1 goes in
> /usr/local/mni, so theoretically they are safe to keep side-by-side
> (leaving aside why one might want to do this), right?
>
> But then package naming comes in - say one has all the MINC1 deb
> packages installed, one adds a new line for the MINC2 packages to
> sources.list, and runs apt-get update/upgrade. As far as I can tell
> that will upgrade only minc and bicpl to MINC2, and leave a bunch of a
> scattered minc1 and minc2 stuff in both /usr/local/{mni,bic}.
>
> I suppose there is no way to keep a parallel MINC1 and MINC2 install
> while relying on the deb packages?
>
> On a related note, these packages install OK on debian sarge, but
> won't run because libhdf5-1.6.5 does not seem to be available as a
> sarge package (1.6.2 is).
>
> -- A
>
> On Nov 7, 2007 10:46 PM, Andrew Janke <a.janke at gmail.com> wrote:
> > Hi all,
> >
> > Given the large number of changes in many of the MINC tools as of
> > late, I have finally got to building a bunch of binary packages using
> > MINC2 with all the latest patches.  So far I have built things for
> > i386 and amd64 Ubuntu.  Get them here:
> >
> >    http://packages.bic.mni.mcgill.ca/ubuntu-feisty-amd64/
> >
> > or
> >
> >    http://packages.bic.mni.mcgill.ca/ubuntu-feisty-i386/
> >
> > To make them work just add something like this to your /etc/apt/sources.list
> >
> >    deb http://packages.bic.mni.mcgill.ca/ubuntu-feisty-amd64 ./
> >
> > I will get to OSX packages and the likes soon but these will all be
> > MINC2 as per the packages above.
> >
> > Let me know if they work OK for you.
> >
> > --
> > Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
> > Canberra->Australia    +61 (402) 700 883
> > _______________________________________________
> > 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
>


-- 
=================================
Jim Nikelski, Ph.D.
Postdoctoral Research Fellow
Bloomfield Centre for Research in Aging
Lady Davis Institute for Medical Research
Sir Mortimer B. Davis - Jewish General Hospital
McGill University
Tel: (514) 340-8222 x 2298
Fax: (514) 340-8295

From nikelski at bic.mni.mcgill.ca  Sat Nov 10 17:21:34 2007
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Sat, 10 Nov 2007 17:21:34 -0500
Subject: [MINC-users] minc2 build error in mincconvert
Message-ID: <e12172550711101421n1266323cl316493294cdf46e@mail.gmail.com>

Hi all,

   I finally decided to jump onto the minc2 train, however I've run
into a slight build problem. Here are the details:

1. I build and install some prerequisites ...
   zlib-1.2.3, szip-2.1, hdf5-1.6.6, netcdf-3.6.2

   .... all without a problem.

2.  I build minc2 with this ...

./configure
    --prefix=/data/raid01/quarantine/Nov2007/minc2
    --enable-minc2
    --enable-acr-nema
    --with-build-path=/data/raid01/quarantine/Nov2007/netcdf-3.6.2
                     :/data/raid01/quarantine/Nov2007/hdf5-1.6.6
                     :/data/raid01/quarantine/Nov2007/zlib-1.2.3

The ./configure works OK, but the make fails (ultimately) with an
error building mincconvert...

gcc -g -O2 -o mincconvert progs/mincconvert/mincconvert.o
-L/data/raid01/quarantine/Nov2007/netcdf-3.6.2/lib
-L/data/raid01/quarantine/Nov2007/hdf5-1.6.6/lib
-L/data/raid01/quarantine/Nov2007/zlib-1.2.3/lib
./.libs/libvolume_io2.a -L/data/raid01/quarantine/Nov2007/szip-2.1/lib
./.libs/libminc2.a
/data/raid01/quarantine/Nov2007/hdf5-1.6.6/lib/libhdf5.a
/data/raid01/quarantine/Nov2007/szip-2.1/lib/libsz.so -lz
/data/raid01/quarantine/Nov2007/netcdf-3.6.2/lib/libnetcdf.a -lm
-Wl,--rpath -Wl,/data/raid01/quarantine/Nov2007/szip-2.1/lib
-Wl,--rpath -Wl,/data/raid01/quarantine/Nov2007/szip-2.1/lib
/data/raid01/quarantine/Nov2007/zlib-1.2.3/lib/libz.a(compress.o): In
function `compress':
compress.c:(.text+0xe0): multiple definition of `compress'
progs/mincconvert/mincconvert.o:(.data+0x0): first defined here
/usr/bin/ld: Warning: size of symbol `compress' changed from 4 in
progs/mincconvert/mincconvert.o to 178 in
/data/raid01/quarantine/Nov2007/zlib-1.2.3/lib/libz.a(compress.o)
/usr/bin/ld: Warning: type of symbol `compress' changed from 1 to 2 in
/data/raid01/quarantine/Nov2007/zlib-1.2.3/lib/libz.a(compress.o)
collect2: ld returned 1 exit status
make[2]: *** [mincconvert] Error 1

Has anyone seen this before? Could this be an inconsistency in the
latest version of zlib?

PS: I'm building minc-2.0.14 on Ubuntu Edgy.


-Jim



-- 
=================================
Jim Nikelski, Ph.D.
Postdoctoral Research Fellow
Bloomfield Centre for Research in Aging
Lady Davis Institute for Medical Research
Sir Mortimer B. Davis - Jewish General Hospital
McGill University

From vladimir.fonov at gmail.com  Sat Nov 10 19:40:59 2007
From: vladimir.fonov at gmail.com (Vladimir S. Fonov)
Date: Sat, 10 Nov 2007 19:40:59 -0500
Subject: [MINC-users] minc2 build error in mincconvert
In-Reply-To: <e12172550711101421n1266323cl316493294cdf46e@mail.gmail.com>
References: <e12172550711101421n1266323cl316493294cdf46e@mail.gmail.com>
Message-ID: <47364F9B.8010700@gmail.com>

Hello,

EJ Nikelski wrote:
>    I finally decided to jump onto the minc2 train, however I've run
> into a slight build problem. Here are the details:
> 
> 1. I build and install some prerequisites ...
>    zlib-1.2.3, szip-2.1, hdf5-1.6.6, netcdf-3.6.2
> 
>    .... all without a problem.
> 
> 2.  I build minc2 with this ...
> 
> ./configure
>     --prefix=/data/raid01/quarantine/Nov2007/minc2
>     --enable-minc2
>     --enable-acr-nema
>     --with-build-path=/data/raid01/quarantine/Nov2007/netcdf-3.6.2
>                      :/data/raid01/quarantine/Nov2007/hdf5-1.6.6
>                      :/data/raid01/quarantine/Nov2007/zlib-1.2.3
>
Why don't you build all the libraries  with --prefix 
/data/raid01/quarantine/Nov2007 and then
./configure ..... --with-build-path=/data/raid01/quarantine/Nov2007

?
-- 
Best regards,
  Vladimir S. Fonov ~ vladimir.fonov <at> gmail.com

From rupe.brooks at gmail.com  Sun Nov 11 12:23:09 2007
From: rupe.brooks at gmail.com (Rupert Brooks)
Date: Sun, 11 Nov 2007 12:23:09 -0500
Subject: [MINC-users] autoconf trouble building minc2
Message-ID: <a6cc33f0711110923u520c5526k84ee5bc18d378d55@mail.gmail.com>

Hi,

I'm trying to build minc2 on a linux system which has (apparently) a
different version of autoconf from the one used to create the minc2
configure script.  So when i do

./configure --prefix=$HOME --enable-minc2

all seems well, but when i make, i get the error message shown below.
Make is wanting to do some autoconf stuff, and the wrong version of
autoconf is on that machine. The version of autoconf present on the
machine is:

[rupert at nunatak3 rupert]$ autoconf --version
autoconf (GNU Autoconf) 2.57
Written by David J. MacKenzie and Akim Demaille.

Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

It seems odd to me that the MINC code is distributed still requiring
autoconf to be run?  Is this a bug?  However, it successfully builds
on other systems so perhaps not.  The problem is i really don't know
how to use autoconf - Is there a way i can regenerate the build
scripts so that it will be happy?

I could try and pester the sysadmin to upgrade, but this may not be a
terribly successful road, as the machine is a cluster used by many
researchers and fixing my builds may of course break theirs.

Cheers
Rupert B.

PS - i experienced this with MINC-2.0.13 and 14.

Error messages:
==========================================================
[rupert at nunatak3 minc-2.0.13]$ make
cd . && /bin/sh
/global/home/rupert/src/minc-2.0.13/ac_config_aux/missing --run
aclocal-1.10 -I m4
/global/home/rupert/src/minc-2.0.13/ac_config_aux/missing: line 54:
aclocal-1.10: command not found
WARNING: `aclocal-1.10' is missing on your system.  You should only need it if
         you modified `acinclude.m4' or `configure.in'.  You might want
         to install the `Automake' and `Perl' packages.  Grab them from
         any GNU archive site.
 cd . && /bin/sh
/global/home/rupert/src/minc-2.0.13/ac_config_aux/missing --run
automake-1.10 --gnu
/global/home/rupert/src/minc-2.0.13/ac_config_aux/missing: line 54:
automake-1.10: command not found
WARNING: `automake-1.10' is missing on your system.  You should only need it if
         you modified `Makefile.am', `acinclude.m4' or `configure.in'.
         You might want to install the `Automake' and `Perl' packages.
         Grab them from any GNU archive site.
cd . && /bin/sh
/global/home/rupert/src/minc-2.0.13/ac_config_aux/missing --run
autoconf
aclocal.m4:17: error: this file was generated for autoconf 2.61.
You have another version of autoconf.  If you want to use that,
you should regenerate the build system entirely.
aclocal.m4:17: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
make: *** [configure] Error 1
[rupert at nunatak3 minc-2.0.13]$ autoconf
aclocal.m4:17: error: this file was generated for autoconf 2.61.
You have another version of autoconf.  If you want to use that,
you should regenerate the build system entirely.
aclocal.m4:17: the top level
autom4te: /usr/bin/m4 failed with exit status: 63



-- 
--------------------------------------------------------------
Rupert Brooks
McGill Centre for Intelligent Machines (www.cim.mcgill.ca)
Ph.D Student, Electrical and Computer Engineering
http://www.cyberus.ca/~rbrooks

From a.janke at gmail.com  Mon Nov 12 07:07:39 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 12 Nov 2007 23:07:39 +1100
Subject: [MINC-users] autoconf trouble building minc2
In-Reply-To: <a6cc33f0711110923u520c5526k84ee5bc18d378d55@mail.gmail.com>
References: <a6cc33f0711110923u520c5526k84ee5bc18d378d55@mail.gmail.com>
Message-ID: <d747ed50711120407l30185d0fk68973f798db3cc08@mail.gmail.com>

Hi Rupert,

You are right, this is not supposed to happen.  Are you perhaps
building this on an NFS mounted dir in which build time-stamps are
getting messed with?  You can test this by building in /tmp (providing
this is also not NFS mounted!)

I will be most interested to know how you get on as this is supposed
to be the advantage of autoconf/automake!

In any case, you can always just download and install
autoconf/automake and thus aclocal in your own directory. they are
just big fandangled perl scripts in the most part and are perfectly
happy to be configured like this:

   ./configure --prefix=~rbrooks/opt

a

On Nov 12, 2007 4:23 AM, Rupert Brooks <rupe.brooks at gmail.com> wrote:
> Hi,
>
> I'm trying to build minc2 on a linux system which has (apparently) a
> different version of autoconf from the one used to create the minc2
> configure script.  So when i do
>
> ./configure --prefix=$HOME --enable-minc2
>
> all seems well, but when i make, i get the error message shown below.
> Make is wanting to do some autoconf stuff, and the wrong version of
> autoconf is on that machine. The version of autoconf present on the
> machine is:
>
> [rupert at nunatak3 rupert]$ autoconf --version
> autoconf (GNU Autoconf) 2.57
> Written by David J. MacKenzie and Akim Demaille.
>
> Copyright 2002 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> It seems odd to me that the MINC code is distributed still requiring
> autoconf to be run?  Is this a bug?  However, it successfully builds
> on other systems so perhaps not.  The problem is i really don't know
> how to use autoconf - Is there a way i can regenerate the build
> scripts so that it will be happy?
>
> I could try and pester the sysadmin to upgrade, but this may not be a
> terribly successful road, as the machine is a cluster used by many
> researchers and fixing my builds may of course break theirs.
>
> Cheers
> Rupert B.
>
> PS - i experienced this with MINC-2.0.13 and 14.
>
> Error messages:
> ==========================================================
> [rupert at nunatak3 minc-2.0.13]$ make
> cd . && /bin/sh
> /global/home/rupert/src/minc-2.0.13/ac_config_aux/missing --run
> aclocal-1.10 -I m4
> /global/home/rupert/src/minc-2.0.13/ac_config_aux/missing: line 54:
> aclocal-1.10: command not found
> WARNING: `aclocal-1.10' is missing on your system.  You should only need it if
>          you modified `acinclude.m4' or `configure.in'.  You might want
>          to install the `Automake' and `Perl' packages.  Grab them from
>          any GNU archive site.
>  cd . && /bin/sh
> /global/home/rupert/src/minc-2.0.13/ac_config_aux/missing --run
> automake-1.10 --gnu
> /global/home/rupert/src/minc-2.0.13/ac_config_aux/missing: line 54:
> automake-1.10: command not found
> WARNING: `automake-1.10' is missing on your system.  You should only need it if
>          you modified `Makefile.am', `acinclude.m4' or `configure.in'.
>          You might want to install the `Automake' and `Perl' packages.
>          Grab them from any GNU archive site.
> cd . && /bin/sh
> /global/home/rupert/src/minc-2.0.13/ac_config_aux/missing --run
> autoconf
> aclocal.m4:17: error: this file was generated for autoconf 2.61.
> You have another version of autoconf.  If you want to use that,
> you should regenerate the build system entirely.
> aclocal.m4:17: the top level
> autom4te: /usr/bin/m4 failed with exit status: 63
> make: *** [configure] Error 1
> [rupert at nunatak3 minc-2.0.13]$ autoconf
> aclocal.m4:17: error: this file was generated for autoconf 2.61.
> You have another version of autoconf.  If you want to use that,
> you should regenerate the build system entirely.
> aclocal.m4:17: the top level
> autom4te: /usr/bin/m4 failed with exit status: 63
>
>
>
> --
> --------------------------------------------------------------
> Rupert Brooks
> McGill Centre for Intelligent Machines (www.cim.mcgill.ca)
> Ph.D Student, Electrical and Computer Engineering
> http://www.cyberus.ca/~rbrooks
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From a.janke at gmail.com  Mon Nov 12 07:17:19 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 12 Nov 2007 23:17:19 +1100
Subject: [MINC-users] minc2 build error in mincconvert
In-Reply-To: <e12172550711101421n1266323cl316493294cdf46e@mail.gmail.com>
References: <e12172550711101421n1266323cl316493294cdf46e@mail.gmail.com>
Message-ID: <d747ed50711120417y505bbe3ds62a021f5f8289a2@mail.gmail.com>

Hi Jim,

I have only every used zlib compression in hdf5, I am currently using
zlib 1.2.3 (as per yourself) and hdf5 1/6.5 although in my case I use
the std debian/ubuntu libraries as compared to building them myself.

I echo Vlads comment and would add that if you really do want separate
sub-dirs for each "product" then I would reccomend using something
like GNU stow to bring it all back together or you will have
horrendous link-lines and LD_LIBRARY_PATH's.

Alright, perhaps not horrendous, but decidedly "whiffy". :)

As for the specific build error you are having I would guess that
there is a compress in both zlib and szip? I have certainly not seen
this error anyhow.


a


On Nov 11, 2007 9:21 AM, EJ Nikelski <nikelski at bic.mni.mcgill.ca> wrote:
> Hi all,
>
>    I finally decided to jump onto the minc2 train, however I've run
> into a slight build problem. Here are the details:
>
> 1. I build and install some prerequisites ...
>    zlib-1.2.3, szip-2.1, hdf5-1.6.6, netcdf-3.6.2
>
>    .... all without a problem.
>
> 2.  I build minc2 with this ...
>
> ./configure
>     --prefix=/data/raid01/quarantine/Nov2007/minc2
>     --enable-minc2
>     --enable-acr-nema
>     --with-build-path=/data/raid01/quarantine/Nov2007/netcdf-3.6.2
>                      :/data/raid01/quarantine/Nov2007/hdf5-1.6.6
>                      :/data/raid01/quarantine/Nov2007/zlib-1.2.3
>
> The ./configure works OK, but the make fails (ultimately) with an
> error building mincconvert...
>
> gcc -g -O2 -o mincconvert progs/mincconvert/mincconvert.o
> -L/data/raid01/quarantine/Nov2007/netcdf-3.6.2/lib
> -L/data/raid01/quarantine/Nov2007/hdf5-1.6.6/lib
> -L/data/raid01/quarantine/Nov2007/zlib-1.2.3/lib
> ./.libs/libvolume_io2.a -L/data/raid01/quarantine/Nov2007/szip-2.1/lib
> ./.libs/libminc2.a
> /data/raid01/quarantine/Nov2007/hdf5-1.6.6/lib/libhdf5.a
> /data/raid01/quarantine/Nov2007/szip-2.1/lib/libsz.so -lz
> /data/raid01/quarantine/Nov2007/netcdf-3.6.2/lib/libnetcdf.a -lm
> -Wl,--rpath -Wl,/data/raid01/quarantine/Nov2007/szip-2.1/lib
> -Wl,--rpath -Wl,/data/raid01/quarantine/Nov2007/szip-2.1/lib
> /data/raid01/quarantine/Nov2007/zlib-1.2.3/lib/libz.a(compress.o): In
> function `compress':
> compress.c:(.text+0xe0): multiple definition of `compress'
> progs/mincconvert/mincconvert.o:(.data+0x0): first defined here
> /usr/bin/ld: Warning: size of symbol `compress' changed from 4 in
> progs/mincconvert/mincconvert.o to 178 in
> /data/raid01/quarantine/Nov2007/zlib-1.2.3/lib/libz.a(compress.o)
> /usr/bin/ld: Warning: type of symbol `compress' changed from 1 to 2 in
> /data/raid01/quarantine/Nov2007/zlib-1.2.3/lib/libz.a(compress.o)
> collect2: ld returned 1 exit status
> make[2]: *** [mincconvert] Error 1
>
> Has anyone seen this before? Could this be an inconsistency in the
> latest version of zlib?
>
> PS: I'm building minc-2.0.14 on Ubuntu Edgy.
>
>
> -Jim
>
>
>
> --
> =================================
> Jim Nikelski, Ph.D.
> Postdoctoral Research Fellow
> Bloomfield Centre for Research in Aging
> Lady Davis Institute for Medical Research
> Sir Mortimer B. Davis - Jewish General Hospital
> McGill University
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From a.janke at gmail.com  Mon Nov 12 07:20:23 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 12 Nov 2007 23:20:23 +1100
Subject: [MINC-users] New packages available..
In-Reply-To: <e12172550711101047r3304b160g3253635570f3e7af@mail.gmail.com>
References: <d747ed50711071946v28d78897h139e943baa7ff3d7@mail.gmail.com>
	<e758a6650711081027l7eee4956ve18ca260fa96a9a5@mail.gmail.com>
	<e12172550711101047r3304b160g3253635570f3e7af@mail.gmail.com>
Message-ID: <d747ed50711120420o5ed0dfdfo534da250a3579f9e@mail.gmail.com>

>    I'm currently building the tools from source ... and I have a
> question about Szip usage in HDF5.  Are we building HDF5 to use Szip
> for both compression and decompression? Or are we using zlib only for
> compression? I would hate to build everything without Szip locally,
> only to find that I am unable to read BIC-generated volumes.

Zlib only.

Mind you no compression will be used by default unless you
specifically tell minc2 to compress things using mincconvert or the
likes.


a

From a.janke at gmail.com  Mon Nov 12 08:31:11 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 13 Nov 2007 00:31:11 +1100
Subject: [MINC-users] nlpfit minctracc
In-Reply-To: <Pine.SGI.4.58.0711071503230.23986000@yorick.bic.mni.mcgill.ca>
References: <Pine.SGI.4.58.0711071503230.23986000@yorick.bic.mni.mcgill.ca>
Message-ID: <d747ed50711120531k3f59c06esf4afb932c0036436@mail.gmail.com>

> Using the following command on two separate computers (yorick and a linux
> machine)
>
> nlpfit -init_xfm lin.xfm source.mnc target.mnc nlin.xfm
> mincblob -det grid.mnc det.mnc
>
> yields differing det.mnc files.   Inside the brain the
> patterns are similar although the values are not exactly the same (within
> about 15%).
>
> yorick 157% minctracc -version
> Package MNI AutoReg, version 0.98k, compiled by swmgr at yorick
> (mips-sgi-irix6.5) on 2003-11-26 at 16:46:16
>
> oliver% minctracc -version
> Package mni_autoreg 0.99.2, compiled by rotor at romeo (i686-pc-linux-gnu) on
> Mon May  8 23:16:34 EDT 2006
>
> What between the two versions could cause the difference between the grid
> files and consequently the det.mnc files?  The fact that most differences
> are outside the brain and on the edges suggests a masking difference but I
> have not defined a mask in either case.

Erk! that is a very old version of minctracc on yorick! There have
been many changes to the way that minctracc does nonlinear fitting
(specifically around the edges of masks) in this time. The most likely
place this occurred was between versions 0.98s and 0.98t.  This is the
NEWS file from then:

Release 0.98t
-------------

* 30% speed increase due to changes in nonlinear fitting code
* Corrected masking in sub-lattice (Patricia Le Nezet and Irina Kezele)


There were also some changes regarding direction cosines reading
errors around 2004 that may be affecting you.
I would suggest that you rely on the results from the later version! :)





-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From nikelski at bic.mni.mcgill.ca  Mon Nov 12 11:51:00 2007
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Mon, 12 Nov 2007 11:51:00 -0500
Subject: [MINC-users] minc2 build error in mincconvert
In-Reply-To: <d747ed50711120417y505bbe3ds62a021f5f8289a2@mail.gmail.com>
References: <e12172550711101421n1266323cl316493294cdf46e@mail.gmail.com>
	<d747ed50711120417y505bbe3ds62a021f5f8289a2@mail.gmail.com>
Message-ID: <e12172550711120851lb2bf520oe0931a3c2d06c5cc@mail.gmail.com>

Hi again,

   Thanks for the feedback, Vlad & Andrew.  I've changed the build
paths to be more sane (less "whiffy"?), and am now building everything
into a "minc2' directory.

   I decided to build hdf5 w/o szip -- hoping that I never encounter a
minc2 volume using that compression (or does hdf5 build szip decoding
in by default?) -- as it looked to be causing some sort of a namespace
clash (with compress).  You know, this sort of namespace problem
doesn't happen with C++ ...

   So, I rebuilt, .. and am still getting a problem with "compress"
when building minc2 (everything else tested OK).  Specifically, I see
..

==============================================
01/quarantine/Nov2007/minc2/include  -g -O2 -MT
progs/mincconvert/mincconvert.o -MD -MP -MF $depbase.Tpo -c -o
progs/mincconvert/mincconvert.o progs/mincconvert/mincconvert.c &&\
        mv -f $depbase.Tpo $depbase.Po
/bin/sh ./libtool --tag=CC   --mode=link gcc  -g -O2
-L/data/raid01/quarantine/Nov2007/minc2/lib -o mincconvert
progs/mincconvert/mincconvert.o libvolume_io2.la libminc2.la -lhdf5
-lz -lnetcdf -lm
libtool: link: warning: library
`/data/raid01/quarantine/Nov2007/minc2/lib/libnetcdf.la' was moved.
libtool: link: warning: library
`/data/raid01/quarantine/Nov2007/minc2/lib/libnetcdf.la' was moved.
gcc -g -O2 -o mincconvert progs/mincconvert/mincconvert.o
-L/data/raid01/quarantine/Nov2007/minc2/lib ./.libs/libvolume_io2.a
./.libs/libminc2.a /data/raid01/quarantine/Nov2007/minc2/lib/libhdf5.a
-lz /data/raid01/quarantine/Nov2007/minc2/lib/libnetcdf.a -lm
/data/raid01/quarantine/Nov2007/minc2/lib/libz.a(compress.o): In
function `compress':
compress.c:(.text+0xe0): multiple definition of `compress'
progs/mincconvert/mincconvert.o:(.data+0x0): first defined here
/usr/bin/ld: Warning: size of symbol `compress' changed from 4 in
progs/mincconvert/mincconvert.o to 178 in
/data/raid01/quarantine/Nov2007/minc2/lib/libz.a(compress.o)
/usr/bin/ld: Warning: type of symbol `compress' changed from 1 to 2 in
/data/raid01/quarantine/Nov2007/minc2/lib/libz.a(compress.o)
collect2: ld returned 1 exit status
make[2]: *** [mincconvert] Error 1
===============================

   BTW, note the libtool message ...
>>>libtool: link: warning: library
`/data/raid01/quarantine/Nov2007/minc2/lib/libnetcdf.la' was moved.

  Beats me what's causing this message. netcdf was "make cleaned" and
rebuilt from scratch. Nothing was "moved".  Also, mincconvert *does*
use an int called "compress", and zlib *does* have a function called
"compress".  Ideas?

As before, I'm using Ubuntu Edgy, and gcc as follows:
jnikelski at chimera:~/software/HClab_build/Nov2007/minc2/minc-2.0.14$
gcc --version
gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)

The build process is pretty quick, so I'd be willing to give pretty
much anything a try.

-Jim



On 11/12/07, Andrew Janke <a.janke at gmail.com> wrote:
> Hi Jim,
>
> I have only every used zlib compression in hdf5, I am currently using
> zlib 1.2.3 (as per yourself) and hdf5 1/6.5 although in my case I use
> the std debian/ubuntu libraries as compared to building them myself.
>
> I echo Vlads comment and would add that if you really do want separate
> sub-dirs for each "product" then I would reccomend using something
> like GNU stow to bring it all back together or you will have
> horrendous link-lines and LD_LIBRARY_PATH's.
>
> Alright, perhaps not horrendous, but decidedly "whiffy". :)
>
> As for the specific build error you are having I would guess that
> there is a compress in both zlib and szip? I have certainly not seen
> this error anyhow.
>
>
> a
>
>
> On Nov 11, 2007 9:21 AM, EJ Nikelski <nikelski at bic.mni.mcgill.ca> wrote:
> > Hi all,
> >
> >    I finally decided to jump onto the minc2 train, however I've run
> > into a slight build problem. Here are the details:
> >
> > 1. I build and install some prerequisites ...
> >    zlib-1.2.3, szip-2.1, hdf5-1.6.6, netcdf-3.6.2
> >
> >    .... all without a problem.
> >
> > 2.  I build minc2 with this ...
> >
> > ./configure
> >     --prefix=/data/raid01/quarantine/Nov2007/minc2
> >     --enable-minc2
> >     --enable-acr-nema
> >     --with-build-path=/data/raid01/quarantine/Nov2007/netcdf-3.6.2
> >                      :/data/raid01/quarantine/Nov2007/hdf5-1.6.6
> >                      :/data/raid01/quarantine/Nov2007/zlib-1.2.3
> >
> > The ./configure works OK, but the make fails (ultimately) with an
> > error building mincconvert...
> >
> > gcc -g -O2 -o mincconvert progs/mincconvert/mincconvert.o
> > -L/data/raid01/quarantine/Nov2007/netcdf-3.6.2/lib
> > -L/data/raid01/quarantine/Nov2007/hdf5-1.6.6/lib
> > -L/data/raid01/quarantine/Nov2007/zlib-1.2.3/lib
> > ./.libs/libvolume_io2.a -L/data/raid01/quarantine/Nov2007/szip-2.1/lib
> > ./.libs/libminc2.a
> > /data/raid01/quarantine/Nov2007/hdf5-1.6.6/lib/libhdf5.a
> > /data/raid01/quarantine/Nov2007/szip-2.1/lib/libsz.so -lz
> > /data/raid01/quarantine/Nov2007/netcdf-3.6.2/lib/libnetcdf.a -lm
> > -Wl,--rpath -Wl,/data/raid01/quarantine/Nov2007/szip-2.1/lib
> > -Wl,--rpath -Wl,/data/raid01/quarantine/Nov2007/szip-2.1/lib
> > /data/raid01/quarantine/Nov2007/zlib-1.2.3/lib/libz.a(compress.o): In
> > function `compress':
> > compress.c:(.text+0xe0): multiple definition of `compress'
> > progs/mincconvert/mincconvert.o:(.data+0x0): first defined here
> > /usr/bin/ld: Warning: size of symbol `compress' changed from 4 in
> > progs/mincconvert/mincconvert.o to 178 in
> > /data/raid01/quarantine/Nov2007/zlib-1.2.3/lib/libz.a(compress.o)
> > /usr/bin/ld: Warning: type of symbol `compress' changed from 1 to 2 in
> > /data/raid01/quarantine/Nov2007/zlib-1.2.3/lib/libz.a(compress.o)
> > collect2: ld returned 1 exit status
> > make[2]: *** [mincconvert] Error 1
> >
> > Has anyone seen this before? Could this be an inconsistency in the
> > latest version of zlib?
> >
> > PS: I'm building minc-2.0.14 on Ubuntu Edgy.
> >
> >
> > -Jim
> >
> >
> >
> > --
> > =================================
> > Jim Nikelski, Ph.D.
> > Postdoctoral Research Fellow
> > Bloomfield Centre for Research in Aging
> > Lady Davis Institute for Medical Research
> > Sir Mortimer B. Davis - Jewish General Hospital
> > McGill University
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
>
>
>
> --
> Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia    +61 (402) 700 883
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


-- 
=================================
Jim Nikelski, Ph.D.
Postdoctoral Research Fellow
Bloomfield Centre for Research in Aging
Lady Davis Institute for Medical Research
Sir Mortimer B. Davis - Jewish General Hospital
McGill University
Tel: (514) 340-8222 x 2298
Fax: (514) 340-8295

From rupe.brooks at gmail.com  Mon Nov 12 20:17:37 2007
From: rupe.brooks at gmail.com (Rupert Brooks)
Date: Mon, 12 Nov 2007 20:17:37 -0500
Subject: [MINC-users] autoconf trouble building minc2
In-Reply-To: <d747ed50711120407l30185d0fk68973f798db3cc08@mail.gmail.com>
References: <a6cc33f0711110923u520c5526k84ee5bc18d378d55@mail.gmail.com>
	<d747ed50711120407l30185d0fk68973f798db3cc08@mail.gmail.com>
Message-ID: <a6cc33f0711121717k60d28c16qa6eddd5766fd5574@mail.gmail.com>

Andrew

It must be a messed up time stamp issue. It builds fine in /tmp.  I
can't detect the time difference doing something like

date;touch foo;ls -l foo

so it must be pretty small.

Anyways im good to go now.

Rupert

On Nov 12, 2007 7:07 AM, Andrew Janke <a.janke at gmail.com> wrote:
> Hi Rupert,
>
> You are right, this is not supposed to happen.  Are you perhaps
> building this on an NFS mounted dir in which build time-stamps are
> getting messed with?  You can test this by building in /tmp (providing
> this is also not NFS mounted!)
>
> I will be most interested to know how you get on as this is supposed
> to be the advantage of autoconf/automake!
>
> In any case, you can always just download and install
> autoconf/automake and thus aclocal in your own directory. they are
> just big fandangled perl scripts in the most part and are perfectly
> happy to be configured like this:
>
>   ./configure --prefix=~rbrooks/opt
>
> a
>
>
> On Nov 12, 2007 4:23 AM, Rupert Brooks <rupe.brooks at gmail.com> wrote:
> > Hi,
> >
> > I'm trying to build minc2 on a linux system which has (apparently) a
> > different version of autoconf from the one used to create the minc2
> > configure script.  So when i do
> >
> > ./configure --prefix=$HOME --enable-minc2
> >
> > all seems well, but when i make, i get the error message shown below.
> > Make is wanting to do some autoconf stuff, and the wrong version of
> > autoconf is on that machine. The version of autoconf present on the
> > machine is:
> >
> > [rupert at nunatak3 rupert]$ autoconf --version
> > autoconf (GNU Autoconf) 2.57
> > Written by David J. MacKenzie and Akim Demaille.
> >
> > Copyright 2002 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >
> > It seems odd to me that the MINC code is distributed still requiring
> > autoconf to be run?  Is this a bug?  However, it successfully builds
> > on other systems so perhaps not.  The problem is i really don't know
> > how to use autoconf - Is there a way i can regenerate the build
> > scripts so that it will be happy?
> >
> > I could try and pester the sysadmin to upgrade, but this may not be a
> > terribly successful road, as the machine is a cluster used by many
> > researchers and fixing my builds may of course break theirs.
> >
> > Cheers
> > Rupert B.
> >
> > PS - i experienced this with MINC-2.0.13 and 14.
> >
> > Error messages:
> > ==========================================================
> > [rupert at nunatak3 minc-2.0.13]$ make
> > cd . && /bin/sh
> > /global/home/rupert/src/minc-2.0.13/ac_config_aux/missing --run
> > aclocal-1.10 -I m4
> > /global/home/rupert/src/minc-2.0.13/ac_config_aux/missing: line 54:
> > aclocal-1.10: command not found
> > WARNING: `aclocal-1.10' is missing on your system.  You should only need it if
> >          you modified `acinclude.m4' or `configure.in'.  You might want
> >          to install the `Automake' and `Perl' packages.  Grab them from
> >          any GNU archive site.
> >  cd . && /bin/sh
> > /global/home/rupert/src/minc-2.0.13/ac_config_aux/missing --run
> > automake-1.10 --gnu
> > /global/home/rupert/src/minc-2.0.13/ac_config_aux/missing: line 54:
> > automake-1.10: command not found
> > WARNING: `automake-1.10' is missing on your system.  You should only need it if
> >          you modified `Makefile.am', `acinclude.m4' or `configure.in'.
> >          You might want to install the `Automake' and `Perl' packages.
> >          Grab them from any GNU archive site.
> > cd . && /bin/sh
> > /global/home/rupert/src/minc-2.0.13/ac_config_aux/missing --run
> > autoconf
> > aclocal.m4:17: error: this file was generated for autoconf 2.61.
> > You have another version of autoconf.  If you want to use that,
> > you should regenerate the build system entirely.
> > aclocal.m4:17: the top level
> > autom4te: /usr/bin/m4 failed with exit status: 63
> > make: *** [configure] Error 1
> > [rupert at nunatak3 minc-2.0.13]$ autoconf
> > aclocal.m4:17: error: this file was generated for autoconf 2.61.
> > You have another version of autoconf.  If you want to use that,
> > you should regenerate the build system entirely.
> > aclocal.m4:17: the top level
> > autom4te: /usr/bin/m4 failed with exit status: 63
> >
> >
> >
> > --
> > --------------------------------------------------------------
> > Rupert Brooks
> > McGill Centre for Intelligent Machines (www.cim.mcgill.ca)
> > Ph.D Student, Electrical and Computer Engineering
> > http://www.cyberus.ca/~rbrooks
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
>
>
>
> --
> Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia    +61 (402) 700 883
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
--------------------------------------------------------------
Rupert Brooks
McGill Centre for Intelligent Machines (www.cim.mcgill.ca)
Ph.D Student, Electrical and Computer Engineering
http://www.cyberus.ca/~rbrooks

From steve at sumost.ca  Tue Nov 13 22:57:04 2007
From: steve at sumost.ca (Steve M. Robbins)
Date: Tue, 13 Nov 2007 21:57:04 -0600
Subject: [MINC-users] MINC 2.0.13
Message-ID: <20071114035704.GL4960@sumost.ca>

On Fri, Oct 05, 2007 at 12:51:23PM +1000, Andrew Janke wrote:
> I wrote:
>
> > That's good news.  I'd like to package this version for Debian, either
> > alongside the current Debian minc package (version 1.5) or replacing
> > it.
> > The library versioning, however, remains a problem.  Packagers such as
> > Debian prefer to ship shared libraries.  For this to work
> > successfully, the software must correctly version the shared libraries.
> > Since you're using libtool, you need only follow the rules outlined
> > in http://www.gnu.org/software/libtool/manual.html#Versioning,
> > specifically section 6.3.
> >
> > It would be helpful if the MINC maintainers would commit to following
> > this procedure.  Is this possible?
> 
> Possible, although I suspect the more deep-seated problem is that minc
> really needs to be split into libminc and minc-tools within CVS to
> make life easier I guess?

Nope; that's not an issue at all.


> I had thought that we were following libtool style versioning though?
> (from what I can read of that page you mention) or am I missing
> something? (likely).

It's not enough to follow "libtool style" of versioning.  You must
follow the entire procedure.  For each release, the releaser must look
at the changes and decide whether any public interfaces have been
added, removed, or changed.

Even if nothing has changed, the REVISION must be incremented.  I note
that this was not done from 2.0.13 --> 2.0.14, for example.  In fact,
CVS shows the following history:

6.1          (stever   08-Jan-03): libminc_la_LDFLAGS = -version-info 0:0:0
6.11         (stever   14-Nov-03): libminc_la_LDFLAGS = -version-info 1:0:1
6.12         (bert     27-Apr-04): libminc2_la_LDFLAGS = -version-info 2:0:1
6.27         (claude   19-Apr-06): libminc2_la_LDFLAGS = -version-info 2:0:10
6.28         (claude   19-Apr-06): libminc2_la_LDFLAGS = -version-info 2:0:1

So one is forced to conclude that MINC2 is not properly versioned,
since it has gone through something like 14 releases.


> The other note of contention is that I presume you will be building
> shared versions of libminc whereas typically in the past everything
> has been static.

Debian's MINC has always built shared libraries.  They are, however,
installed in /usr/lib, so the standard argument against shared libs
does not apply.


> Then to add another cat into the mix I have been working on a CMake
> (shudder) build of MINC for the ITK integration stuff and suffice to
> say I have found no easy way to sync the two build processes. :(  It's
> hard enough to find any documentation on CMake out there without
> buying the book as it is so getting the thing to behave as I expect
> has proved problematic (make install,dist,distcheck etc).
> 
> Do you have any thoughts on CMake steve?  All those who use it seem to
> crow its praises over autoconf/make but from what I have seen of it so
> far it is easy(ish) to use but the lack of documentation and worked
> examples of how things should be done is slowing me up a lot.

We use CMake at work.  It's main selling feature is that it can
produce MSVC project files as easily as Makefiles, whereas autoconf
heavily depends on having the unix suite of commandline tools.

Myself, I haven't written CMake rules for "install", let alone "dist"
and the like.  I'd imagine that ITK itself should supply enough of an
example to get you going.  Good luck.


Cheers,
-Steve


From se at hst.aau.dk  Thu Nov 15 08:41:53 2007
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Thu, 15 Nov 2007 14:41:53 +0100
Subject: [MINC-users] Custom kernels in mincmorph
Message-ID: <473C4CA1.6090308@hst.aau.dk>

Hi all,

I tried out the custom kernel option (-kernel) in mincmorph. In lack of 
documentation I had to go through the source code to find the syntax for 
the input ascii kernel. In the process I stumbled upon what seems to be 
the use of an uninitialized variable which resulted in a segmentation fault.
So my question is: Has anyone ever used the -kernel option in mincmorph 
successfully?

Andrew, it is line 120 in kernel_io.c that worries me (kernel is freed 
right before calling input_kernel). I'm using version 1.4.

Thanks,
Simon

From a.janke at gmail.com  Thu Nov 15 09:04:23 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 16 Nov 2007 01:04:23 +1100
Subject: [MINC-users] Custom kernels in mincmorph
In-Reply-To: <473C4CA1.6090308@hst.aau.dk>
References: <473C4CA1.6090308@hst.aau.dk>
Message-ID: <d747ed50711150604r2e15e987yd65baeb3cf82c641@mail.gmail.com>

> I tried out the custom kernel option (-kernel) in mincmorph. In lack of
> documentation I had to go through the source code to find the syntax for
> the input ascii kernel. In the process I stumbled upon what seems to be
> the use of an uninitialized variable which resulted in a segmentation fault.
> So my question is: Has anyone ever used the -kernel option in mincmorph
> successfully?

Well it certainly works for me.. :)

Given that you seem to have the source take a look in the kernels/
directory in the mincmorph package, there are a few examples in there.

I also have a few more that I can post if others want them.

> Andrew, it is line 120 in kernel_io.c that worries me (kernel is freed
> right before calling input_kernel). I'm using version 1.4.

You lost me. Do you mean in kernel_io.c or mincmorph.c? input_kernel()
is defined in kernel_io.c

In any case I am sure that there still might be a bug!  It certainly
has happened before this day.




a

From se at hst.aau.dk  Thu Nov 15 09:35:55 2007
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Thu, 15 Nov 2007 15:35:55 +0100
Subject: [MINC-users] Custom kernels in mincmorph
In-Reply-To: <d747ed50711150604r2e15e987yd65baeb3cf82c641@mail.gmail.com>
References: <473C4CA1.6090308@hst.aau.dk>
	<d747ed50711150604r2e15e987yd65baeb3cf82c641@mail.gmail.com>
Message-ID: <473C594B.4000305@hst.aau.dk>

>> I tried out the custom kernel option (-kernel) in mincmorph. In lack of
>> documentation I had to go through the source code to find the syntax for
>> the input ascii kernel. In the process I stumbled upon what seems to be
>> the use of an uninitialized variable which resulted in a segmentation fault.
>> So my question is: Has anyone ever used the -kernel option in mincmorph
>> successfully?
> 
> Well it certainly works for me.. :)
> 
> Given that you seem to have the source take a look in the kernels/
> directory in the mincmorph package, there are a few examples in there.

I'm not sure where to look:
tar ztf mincmorph-1.4.tar.gz | grep kernel
mincmorph-1.4/kernel_io.c
mincmorph-1.4/kernel_ops.c
mincmorph-1.4/kernel_io.h
mincmorph-1.4/kernel_ops.h

I have the source from http://packages.bic.mni.mcgill.ca/tgz/

> I also have a few more that I can post if others want them.
> 
>> Andrew, it is line 120 in kernel_io.c that worries me (kernel is freed
>> right before calling input_kernel). I'm using version 1.4.
> 
> You lost me. Do you mean in kernel_io.c or mincmorph.c? input_kernel()
> is defined in kernel_io.c

kernel is freed at line 505 in mincmorph.c subsequently input_kernel() 
is called where (line 120 in kernel_io.c) kernel imho is used uninitialized.

Simon

From a.janke at gmail.com  Thu Nov 15 09:46:42 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 16 Nov 2007 01:46:42 +1100
Subject: [MINC-users] Custom kernels in mincmorph
In-Reply-To: <473C594B.4000305@hst.aau.dk>
References: <473C4CA1.6090308@hst.aau.dk>
	<d747ed50711150604r2e15e987yd65baeb3cf82c641@mail.gmail.com>
	<473C594B.4000305@hst.aau.dk>
Message-ID: <d747ed50711150646x3ee68560g72065e1986813a18@mail.gmail.com>

> > Given that you seem to have the source take a look in the kernels/
> > directory in the mincmorph package, there are a few examples in there.
>
> I'm not sure where to look:
> tar ztf mincmorph-1.4.tar.gz | grep kernel
> mincmorph-1.4/kernel_io.c
> mincmorph-1.4/kernel_ops.c
> mincmorph-1.4/kernel_io.h
> mincmorph-1.4/kernel_ops.h
>
> I have the source from http://packages.bic.mni.mcgill.ca/tgz/

OK, I will rephrase that to "there should be a directory...."  seems
that it missed the make dist. <sigh>.  In any case here is an example
of a mincmorph 2D sobel edge detector. Note that anything starting
with % is a comment.

Each line in the kernel file represents on point in a structuring
element/kernel and is described as a delta/offset from the 0 position.
 My bit of dodgy ASCII art at the top in the comments should explain
things somewhat.

I will have a look into the bug.



a

---cut here---

MNI Morphology Kernel File
%
% 2D sobel edge detector ie:
%
%   1  2  1
%   0  0  0
%  -1 -2 -1
%
% 0 - center voxel
% Format:  offset for voxel in 5 dimensions (x,y,z,t,v) then multiplier.

Kernel_Type = Normal_Kernel;
Kernel =
%    x    y    z    t    v     coeff
% -----------------------------------
  -1.0  1.0  0.0  0.0  0.0     1.0
   0.0  1.0  0.0  0.0  0.0     2.0
   1.0  1.0  0.0  0.0  0.0     1.0
%
  -1.0  0.0  0.0  0.0  0.0     0.0
   0.0  0.0  0.0  0.0  0.0     0.0
   1.0  0.0  0.0  0.0  0.0     0.0
%
  -1.0 -1.0  0.0  0.0  0.0    -1.0
   0.0 -1.0  0.0  0.0  0.0    -2.0
   1.0 -1.0  0.0  0.0  0.0    -1.0;

---and here---

From se at hst.aau.dk  Thu Nov 15 10:07:53 2007
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Thu, 15 Nov 2007 16:07:53 +0100
Subject: [MINC-users] Custom kernels in mincmorph
In-Reply-To: <d747ed50711150646x3ee68560g72065e1986813a18@mail.gmail.com>
References: <473C4CA1.6090308@hst.aau.dk>	<d747ed50711150604r2e15e987yd65baeb3cf82c641@mail.gmail.com>	<473C594B.4000305@hst.aau.dk>
	<d747ed50711150646x3ee68560g72065e1986813a18@mail.gmail.com>
Message-ID: <473C60C9.7070906@hst.aau.dk>

> OK, I will rephrase that to "there should be a directory...."  seems
> that it missed the make dist. <sigh>.  In any case here is an example
> of a mincmorph 2D sobel edge detector. Note that anything starting
> with % is a comment.

Still no luck:

mincmorph -verbose -kernel sobel.kernel template.mnc.gz test.mnc
---Checking Operation(s): B---
   Op[02] B = 1          range: [-1.79769e+308:1.79769e+308] fg/bg: [1:0]

---Doing 3 Operation(s)---
Reading [sobel.kernel]Segmentation fault


Simon

From claude at bic.mni.mcgill.ca  Thu Nov 15 10:21:55 2007
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Thu, 15 Nov 2007 10:21:55 -0500 (EST)
Subject: [MINC-users] Custom kernels in mincmorph
References: <473C4CA1.6090308@hst.aau.dk>
	<d747ed50711150604r2e15e987yd65baeb3cf82c641@mail.gmail.com>	<473C594B.4000305@hst.aau.dk>
	<d747ed50711150646x3ee68560g72065e1986813a18@mail.gmail.com>
Message-ID: <200711151521.lAFFLtn041134495@yorick.bic.mni.mcgill.ca>

Simon,

Which compiler are you using to compile mincmorph? (version?).

Claude

From mojdeh.zamyadi at utoronto.ca  Thu Nov 15 11:24:03 2007
From: mojdeh.zamyadi at utoronto.ca (mojdeh.zamyadi@utoronto.ca)
Date: Thu, 15 Nov 2007 11:24:03 -0500
Subject: [MINC-users] minc_displacement
Message-ID: <20071115112403.ngec7vrk00k4ss8c@webmail.utoronto.ca>

Hi all,

Does anyone know what minc_displacement does? I couldn't find any  
explanation in the man page!

Thanks,
Mojdeh


From se at hst.aau.dk  Thu Nov 15 11:25:52 2007
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Thu, 15 Nov 2007 17:25:52 +0100
Subject: [MINC-users] Custom kernels in mincmorph
In-Reply-To: <200711151521.lAFFLtn041134495@yorick.bic.mni.mcgill.ca>
References: <473C4CA1.6090308@hst.aau.dk>	<d747ed50711150604r2e15e987yd65baeb3cf82c641@mail.gmail.com>	<473C594B.4000305@hst.aau.dk>	<d747ed50711150646x3ee68560g72065e1986813a18@mail.gmail.com>
	<200711151521.lAFFLtn041134495@yorick.bic.mni.mcgill.ca>
Message-ID: <473C7310.5050409@hst.aau.dk>

> Which compiler are you using to compile mincmorph? (version?).
gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)

Simon

From jason at bic.mni.mcgill.ca  Thu Nov 15 12:12:52 2007
From: jason at bic.mni.mcgill.ca (Jason Lerch)
Date: Thu, 15 Nov 2007 12:12:52 -0500
Subject: [MINC-users] minc_displacement
In-Reply-To: <20071115112403.ngec7vrk00k4ss8c@webmail.utoronto.ca>
References: <20071115112403.ngec7vrk00k4ss8c@webmail.utoronto.ca>
Message-ID: <473C7E14.6060409@bic.mni.mcgill.ca>

Hello Mojdeh,

it's a tool that I wrote which, at every voxel of a volume, evaluates a 
transform (.xfm file) and writes out a vector at every voxel describing 
the straight line path to which the transform would take that voxel.

Cheers,

Jason

mojdeh.zamyadi at utoronto.ca wrote:
> Hi all,
>
> Does anyone know what minc_displacement does? I couldn't find any  
> explanation in the man page!
>
> Thanks,
> Mojdeh
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>   


From mojdeh.zamyadi at utoronto.ca  Mon Nov 19 12:51:00 2007
From: mojdeh.zamyadi at utoronto.ca (mojdeh.zamyadi@utoronto.ca)
Date: Mon, 19 Nov 2007 12:51:00 -0500
Subject: [MINC-users] tagtoxfm
Message-ID: <20071119125100.571i6h7c0goc8s8g@webmail.utoronto.ca>

Dear all,

Could someone please tell me what algorithm is used in "tagtoxfm" to  
calculate the 6-param transformation (lsq6) between pairs of tag  
points. Does it optimize for translational and rotational components  
separately?

Thanks,

Mojdeh


From a.janke at gmail.com  Mon Nov 19 23:09:48 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 20 Nov 2007 15:09:48 +1100
Subject: [MINC-users] tagtoxfm
In-Reply-To: <20071119125100.571i6h7c0goc8s8g@webmail.utoronto.ca>
References: <20071119125100.571i6h7c0goc8s8g@webmail.utoronto.ca>
Message-ID: <d747ed50711192009u66299fcftf5d087b734a64649@mail.gmail.com>

Hi Mojdeh,

tagtoxfm (And also register) uses a linear least squares approach.

The function that does all the work, compute_transform_from_tags() is
part of bicpl and can be found here:

http://www.bic.mni.mcgill.ca/software/bicpl/compute__xfm_8c-source.html


a

On Nov 20, 2007 4:51 AM,  <mojdeh.zamyadi at utoronto.ca> wrote:
> Dear all,
>
> Could someone please tell me what algorithm is used in "tagtoxfm" to
> calculate the 6-param transformation (lsq6) between pairs of tag
> points. Does it optimize for translational and rotational components
> separately?
>
> Thanks,
>
> Mojdeh
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From Michel.Audette at medizin.uni-leipzig.de  Tue Nov 20 09:17:18 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Tue, 20 Nov 2007 15:17:18 +0100
Subject: [MINC-users] dicom3_to_minc argument list too long
References: <d747ed50711071946v28d78897h139e943baa7ff3d7@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E690201FB5A@MRZS152229.medizin.uni-leipzig.de>

Dear all, 

I'm playing with a 7T MR dicom volume, and trying to convert it to minc, I'm getting 

dicom3_to_minc MR.1.3_mnc/ MR.1.3_dicom/*
bash: /usr/local/bin/dicom3_to_minc: /usr/bin/env: bad interpreter: Argument list too long

Can anyone suggest a fix? 

Michel

Michel Audette, Ph.D.  
Innovation Center Computer Assisted Surgery (ICCAS)  
Semmelweisstra?e 14
Leipzig, Germany
Phone: ++49 (0) 341 / 97 - 1 20 13
Fax: ++49 (0) 341 / 97 - 1 20 09

P.S.: according to the list of dicom files, looks like about 1827 slices. 
ls MR.1.3_dicom/
MR.1.3.12.2.1107.5.2.34.18918.30000007091410181973400000000  MR.1.3.12.2.1107.5.2.34.18918.30000007091410181973400000916
...
MR.1.3.12.2.1107.5.2.34.18918.30000007091410181973400001826
MR.1.3.12.2.1107.5.2.34.18918.30000007091410181973400000915

From vladimir.fonov at gmail.com  Tue Nov 20 09:24:56 2007
From: vladimir.fonov at gmail.com (Vladimir S. Fonov)
Date: Tue, 20 Nov 2007 09:24:56 -0500
Subject: [MINC-users] dicom3_to_minc argument list too long
In-Reply-To: <160E3DD4FB702C4CB860C65186686E690201FB5A@MRZS152229.medizin.uni-leipzig.de>
References: <d747ed50711071946v28d78897h139e943baa7ff3d7@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E690201FB5A@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <4742EE38.7010201@gmail.com>

Hello,

Audette, Michel wrote:
> I'm playing with a 7T MR dicom volume, and trying to convert it to minc, I'm getting 
> 
> dicom3_to_minc MR.1.3_mnc/ MR.1.3_dicom/*
> bash: /usr/local/bin/dicom3_to_minc: /usr/bin/env: bad interpreter: Argument list too long
> 
> Can anyone suggest a fix? 

maybe

find MR.1.3_dicom | dcm2mnc -stdin MR.1.3_mnc

would work?

-- 
Best regards,
  Vladimir S. Fonov ~ vladimir.fonov <at> gmail.com

From Michel.Audette at medizin.uni-leipzig.de  Tue Nov 20 10:22:53 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Tue, 20 Nov 2007 16:22:53 +0100
Subject: [MINC-users] dicom3_to_minc argument list too long
References: <d747ed50711071946v28d78897h139e943baa7ff3d7@mail.gmail.com><160E3DD4FB702C4CB860C65186686E690201FB5A@MRZS152229.medizin.uni-leipzig.de>
	<4742EE38.7010201@gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E690201FB62@MRZS152229.medizin.uni-leipzig.de>

Hi Vladimir, 

thanks. That did the trick. I truly appreciate your help. 

Cheers, 

Michel

-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Vladimir S. Fonov
Sent: Tue 11/20/2007 3:24 PM
To: MINC users mailing list
Subject: Re: [MINC-users] dicom3_to_minc argument list too long
 
Hello,

Audette, Michel wrote:
> I'm playing with a 7T MR dicom volume, and trying to convert it to minc, I'm getting 
> 
> dicom3_to_minc MR.1.3_mnc/ MR.1.3_dicom/*
> bash: /usr/local/bin/dicom3_to_minc: /usr/bin/env: bad interpreter: Argument list too long
> 
> Can anyone suggest a fix? 

maybe

find MR.1.3_dicom | dcm2mnc -stdin MR.1.3_mnc

would work?

-- 
Best regards,
  Vladimir S. Fonov ~ vladimir.fonov <at> gmail.com
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From Michel.Audette at medizin.uni-leipzig.de  Tue Nov 20 11:40:19 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Tue, 20 Nov 2007 17:40:19 +0100
Subject: [MINC-users] rawtominc & nu_correct difficulties
In-Reply-To: <160E3DD4FB702C4CB860C65186686E6901145608@MRZS152229.medizin.uni-leipzig.de>
References: <160E3DD4FB702C4CB860C65186686E69011455D7@MRZS152229.medizin.uni-leipzig.de><ea3878950708010539v6110b029g71e652bb9c84178a@mail.gmail.com><160E3DD4FB702C4CB860C65186686E69011455F6@MRZS152229.medizin.uni-leipzig.de><d747ed50708010838u24671911k51679008539ced52@mail.gmail.com><160E3DD4FB702C4CB860C65186686E69011455F7@MRZS152229.medizin.uni-leipzig.de><d747ed50708010852m4524af85nac388f6d49e095ce@mail.gmail.com><160E3DD4FB702C4CB860C65186686E6901145601@MRZS152229.medizin.uni-leipzig.de><d747ed50708020539t7e381519n33daac2fa4fcdab0@mail.gmail.com><ea3878950708020552n79d1e68cjd36b44d57fbf33da@mail.gmail.com><160E3DD4FB702C4CB860C65186686E6901145603@MRZS152229.medizin.uni-leipzig.de><ea3878950708020845s2d8fcd34o165b0427610c092f@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E6901145608@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <160E3DD4FB702C4CB860C65186686E69015F1E3F@MRZS152229.medizin.uni-leipzig.de>

Dear all, 

a while back, when I was dealing with an inner ear micro-MR model, some of you suggested that I change the header to 1mm resolution, nu_correct it, then change it back to its original resolution. And it worked terrifically.

I now have a large pelvic volume (I have several simulation projects here...), of 7T data 0.33x0.33x0.5mm voxels, in other words, much larger than the head, and finer than 1mm isotropic voxels. Can you suggest how to proceed? The inhomogeneity is very significant... 

Best regards, 

Michel

Michel Audette, Ph.D.   
Innovation Center Computer Assisted Surgery (ICCAS)   
Semmelweisstra?e 14  
Leipzig, Germany  
Phone: ++49 (0) 341 / 97 - 1 20 13  
Fax: ++49 (0) 341 / 97 - 1 20 09 
 

 

-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca [mailto:minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Audette, Michel
Sent: August 2, 2007 6:26 PM
To: Vladimir FONOV
Cc: minc-users at bic.mni.mcgill.ca; Andrew Janke
Subject: Re: [MINC-users] rawtominc & nu_correct difficulties

Hi again Vladimir, 

it worked! This result is as good as anyone can expect. Can you explain to me the significance of the parameters, and why exactly it worked? 

Actually, I may have to go back and redo it with the actual voxel spacing, because the non-rigid registration with patient data, which comes afterward, must be applied to anatomical meshing... but everything scales accordingly, right? 

Cheers, 

Michel


-----Original Message-----
From: Vladimir FONOV [mailto:vladimir.fonov at gmail.com]
Sent: Thu 8/2/2007 5:45 PM
To: Audette, Michel
Cc: Andrew Janke
Subject: Re: [MINC-users] rawtominc & nu_correct difficulties
 
Hello,

On 8/2/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> Hi Vladimir,
>
> thanks for the suggestion. The data is 3D MR microscopy. http://cbaweb2.med.unc.edu/henson_mrm/pages/Scans_Primates.html
>
I tried playing with Human13959, got some success:

rawtominc -byte -range 0 255 -orange 0 255 -real_range 0 255 -unsigned
-zyx -xstep 1 -ystep 1 -zstep 1 -xstart 0 -ystart 0 -zstart 0 -clob
-oshort Human13959_Stack.mnc 176 187 256  < Human13959_Stack.gray

minccalc -expression '255-A[0]' Human13959_Stack.mnc Human13959_Stack_inv.mnc

nu_correct -clob Human13959_Stack_inv.mnc Human13959_Stack_inv_nuc.mnc
-iter 100 -stop 0.0001 -fwhm 0.1

 minccalc -expression 'clamp(255-A[0],0,255)'
Human13959_Stack_inv_nuc.mnc Human13959_Stack_nuc.mnc -clob

see attached images.

P.S. note that I used step size of 1mm instead of 0.025um as indicated
in the dataset

-- 
Best regards,
 Vladimir S. Fonov ~ vladimir.fonov <at> gmail.com


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


From bouffard at bic.mni.mcgill.ca  Tue Nov 20 14:26:49 2007
From: bouffard at bic.mni.mcgill.ca (Marc BOUFFARD)
Date: Tue, 20 Nov 2007 14:26:49 -0500
Subject: [MINC-users] mnc2nii
Message-ID: <Pine.SGI.4.58.0711201348060.69439829@yorick.bic.mni.mcgill.ca>

Hello,

when using mnc2nii, version:

program: 1.4
libminc: 1.4
netcdf : 3.6.1 of Jul  5 2006 14:12:05 $

mnc2nii -short -unsigned -nii file.mnc

sometimes, randomly as far as I can tell, it produces a segmentation fault
see below:


*************first output***********************************************
<nifti_image
  nifti_type = 'NIFTI-1+'
  header_filename = 'file_name.nii'
  image_filename = 'file_name.nii'
  image_offset = '0'
  ndim = '3'
  nx = '91'
  ny = '109'
  nz = '91'
  dx = '2'
  dy = '2'
  dz = '2'
  datatype = '512'
  datatype_name = 'UINT16'
  nvox = '902629'
  nbyper = '2'
  byteorder = 'LSB_FIRST'
  scl_slope = '2.06785e-05'
  scl_inter = '0.677592'
  xyz_units = '2'
  xyz_units_name = 'mm'
  time_units = '8'
  time_units_name = 's'
  descrip = 'mnc2nii mask_2mm_roy_barbara_mri.mnc'
  sform_code = '3'
  sform_code_name = 'Talairach'
  sto_xyz_matrix = '2 0 0 -90 0 2 0 -126 0 0 2 -72 0 0 0 1'
  sto_ijk matrix = '0.5 0 0 45 0 0.5 0 63 0 0 0.5 36 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: 91 0 1
1: 109 1 1
2: 91 2 1
bytes per voxel 2
# of voxels 902629
Segmentation fault
*********************************************************

This does not create a corresponding .nii file.  Now if the name of the
file is change to say file_.nii and mnc2nii is rerun with the name change
it works:

**************second output******************************
<nifti_image
  nifti_type = 'NIFTI-1+'
  header_filename = 'file_.nii'
  image_filename = 'file_.nii'
  image_offset = '0'
  ndim = '3'
  nx = '91'
  ny = '109'
  nz = '91'
  dx = '2'
  dy = '2'
  dz = '2'
  datatype = '512'
  datatype_name = 'UINT16'
  nvox = '902629'
  nbyper = '2'
  byteorder = 'LSB_FIRST'
  scl_slope = '2.06785e-05'
  scl_inter = '0.677592'
  xyz_units = '2'
  xyz_units_name = 'mm'
  time_units = '8'
  time_units_name = 's'
  descrip = 'mnc2nii mask_2mm_roy_barb_mri.mnc'
  sform_code = '3'
  sform_code_name = 'Talairach'
  sto_xyz_matrix = '2 0 0 -90 0 2 0 -126 0 0 2 -72 0 0 0 1'
  sto_ijk matrix = '0.5 0 0 45 0 0.5 0 63 0 0 0.5 36 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: 91 0 1
1: 109 1 1
2: 91 2 1
bytes per voxel 2
# of voxels 902629
0 0 0 => -90.000000 -126.000000 -72.000000
10 0 0 => -70.000000 -126.000000 -72.000000
0 10 0 => -90.000000 -106.000000 -72.000000
0 0 10 => -90.000000 -126.000000 -52.000000
10 10 10 => -70.000000 -106.000000 -52.000000
*******************************************************************

Sometimes it takes another name change before it finally creates the .nii.
When the .nii file is created it looks valid though (using MRIcro).  This
seems to be random so out of 20 files converted there may be somehting
like 5 that don't get created and have to be renamed before re-running
mnc2nii.  Why is this occuring?

Marc

From mpievani at fatebenefratelli.it  Tue Nov 20 14:34:28 2007
From: mpievani at fatebenefratelli.it (Michela Pievani)
Date: Tue, 20 Nov 2007 19:34:28 +0000
Subject: [MINC-users] nu_correct and surface coil
Message-ID: <132.206.178.40.990288526.1195587268@webmail.inet.it>

Hi all,
I'm using N3 to remove extremes non-uniformities from a surface coil MRI. I tried using different options than the default ones (for example: -iterations 200, -stop 0.00001, -mask ICBM_template), but they don't improve significantly my results.
Do you have any suggestion?
Thanks,
Michela


From vladimir.fonov at gmail.com  Tue Nov 20 14:55:45 2007
From: vladimir.fonov at gmail.com (Vladimir FONOV)
Date: Tue, 20 Nov 2007 14:55:45 -0500
Subject: [MINC-users] mnc2nii
In-Reply-To: <Pine.SGI.4.58.0711201348060.69439829@yorick.bic.mni.mcgill.ca>
References: <Pine.SGI.4.58.0711201348060.69439829@yorick.bic.mni.mcgill.ca>
Message-ID: <47433BC1.2080502@gmail.com>

Marc BOUFFARD wrote:
> Hello,
> 
> when using mnc2nii, version:
> 
> program: 1.4
> libminc: 1.4
> netcdf : 3.6.1 of Jul  5 2006 14:12:05 $
> 
> mnc2nii -short -unsigned -nii file.mnc
> 
> sometimes, randomly as far as I can tell, it produces a segmentation fault
> see below:
> 

For me it usually fails if I specify the file extension
i.e
mnc2nii -short -unsigned -nii file.mnc output.nii   - may fail
mnc2nii -short -unsigned -nii file.mnc output   - would work , producing 
output.nii

-- 
Best regards,
  Vladimir S. Fonov ~ vladimir dot fonov at gmail dot com

From bouffard at bic.mni.mcgill.ca  Tue Nov 20 15:15:11 2007
From: bouffard at bic.mni.mcgill.ca (Marc BOUFFARD)
Date: Tue, 20 Nov 2007 15:15:11 -0500
Subject: [MINC-users] mnc2nii
In-Reply-To: <47433BC1.2080502@gmail.com>
References: <Pine.SGI.4.58.0711201348060.69439829@yorick.bic.mni.mcgill.ca>
	<47433BC1.2080502@gmail.com>
Message-ID: <Pine.SGI.4.58.0711201506390.69526634@yorick.bic.mni.mcgill.ca>



On Tue, 20 Nov 2007, Vladimir FONOV wrote:

> Marc BOUFFARD wrote:
> > Hello,
> >
> > when using mnc2nii, version:
> >
> > program: 1.4
> > libminc: 1.4
> > netcdf : 3.6.1 of Jul  5 2006 14:12:05 $
> >
> > mnc2nii -short -unsigned -nii file.mnc
> >
> > sometimes, randomly as far as I can tell, it produces a segmentation fault
> > see below:
> >
>
> For me it usually fails if I specify the file extension
> i.e
> mnc2nii -short -unsigned -nii file.mnc output.nii   - may fail
> mnc2nii -short -unsigned -nii file.mnc output   - would work , producing
> output.nii
>
Specifying the output file without or without an extension or not
specifying any output file at all makes no difference in my experience.
The only fix that seems to work is repetitively changing the input file
name until mnc2nii succeeds.

Marc

From vladimir.fonov at gmail.com  Tue Nov 20 15:56:21 2007
From: vladimir.fonov at gmail.com (Vladimir FONOV)
Date: Tue, 20 Nov 2007 15:56:21 -0500
Subject: [MINC-users] mnc2nii
In-Reply-To: <Pine.SGI.4.58.0711201506390.69526634@yorick.bic.mni.mcgill.ca>
References: <Pine.SGI.4.58.0711201348060.69439829@yorick.bic.mni.mcgill.ca>	<47433BC1.2080502@gmail.com>
	<Pine.SGI.4.58.0711201506390.69526634@yorick.bic.mni.mcgill.ca>
Message-ID: <474349F5.3030607@gmail.com>

Hello,

Marc BOUFFARD wrote:
>>> when using mnc2nii, version:
>>>
>>> program: 1.4
>>> libminc: 1.4
>>> netcdf : 3.6.1 of Jul  5 2006 14:12:05 $
>>>
>>> mnc2nii -short -unsigned -nii file.mnc
>>>
>>> sometimes, randomly as far as I can tell, it produces a segmentation fault
>>> see below:
>>>
>> For me it usually fails if I specify the file extension
>> i.e
>> mnc2nii -short -unsigned -nii file.mnc output.nii   - may fail
>> mnc2nii -short -unsigned -nii file.mnc output   - would work , producing
>> output.nii
>>
> Specifying the output file without or without an extension or not
> specifying any output file at all makes no difference in my experience.
> The only fix that seems to work is repetitively changing the input file
> name until mnc2nii succeeds.
Actually , I just noticed that I use newer version of this program:
mnc2nii -version
program: 1.5.1
libminc: 1.5.1
netcdf : 3.6.0-p1 of Sep  2 2005 14:12:07 $

-- 
Best regards,
  Vladimir S. Fonov ~ vladimir dot fonov at gmail dot com

From claude at bic.mni.mcgill.ca  Tue Nov 20 16:02:20 2007
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Tue, 20 Nov 2007 16:02:20 -0500 (EST)
Subject: [MINC-users] mnc2nii
References: <Pine.SGI.4.58.0711201348060.69439829@yorick.bic.mni.mcgill.ca>
	<47433BC1.2080502@gmail.com>
Message-ID: <200711202102.lAKL2KZS69508431@yorick.bic.mni.mcgill.ca>

Marc,

Can you try the latest mnc2nii version on the BIC system (Linux)?

minc1:

/data/aces/aces1/quarantines/Linux-i686/Dec-20-2006/bin/mnc2nii
program: 1.5
libminc: 1.5
netcdf : 3.6.1 of Dec 19 2006 17:53:57 $


minc2:

/data/aces/aces1/quarantines/Linux-i686/Oct-10-2007/bin/mnc2nii
program: 2.0.14
libminc: 2.0.14
netcdf : 3.6.1 of Jul 17 2007 12:02:58 $
HDF5   : 1.6.5

The minc2 converter will produce minc1 output by default, unless you
tell it to produce minc2 output (-2 option). Try with and without -2
option to see if minc1/minc2 makes a difference.

Yours,

Claude

From vladimir.fonov at gmail.com  Tue Nov 20 16:04:26 2007
From: vladimir.fonov at gmail.com (Vladimir FONOV)
Date: Tue, 20 Nov 2007 16:04:26 -0500
Subject: [MINC-users] mnc2nii
In-Reply-To: <200711202102.lAKL2KZS69508431@yorick.bic.mni.mcgill.ca>
References: <Pine.SGI.4.58.0711201348060.69439829@yorick.bic.mni.mcgill.ca>	<47433BC1.2080502@gmail.com>
	<200711202102.lAKL2KZS69508431@yorick.bic.mni.mcgill.ca>
Message-ID: <47434BDA.4010706@gmail.com>

Hello,

Claude LEPAGE wrote:
> Marc,
> 
> Can you try the latest mnc2nii version on the BIC system (Linux)?
> 
> 
> The minc2 converter will produce minc1 output by default, unless you
> tell it to produce minc2 output (-2 option). Try with and without -2
> option to see if minc1/minc2 makes a difference.

I don't think you can have minc2 nifti file  yet :)

-- 
Best regards,
  Vladimir S. Fonov ~ vladimir dot fonov at gmail dot com

From kojinet at bic.mni.mcgill.ca  Tue Nov 20 17:57:47 2007
From: kojinet at bic.mni.mcgill.ca (Ji Hyum KO)
Date: Tue, 20 Nov 2007 17:57:47 -0500
Subject: [MINC-users] mincmath -percentdiff
Message-ID: <Pine.SGI.4.58.0711201745190.69713298@yorick.bic.mni.mcgill.ca>

Hello,

mincmath -percentdiff A_BPmap1.mnc A_BPmap2.mnc A_BPdiff.mnc

This command should give me the precentage difference of BPmap2.mnc
compared to BPmap1.mnc, but it gives right values for subject A, but not
for subject B.

For subject B, all the values in the minc file is set to 3796.17 except
several dots and those dots were set to some wierd value as well.

I tried to use minccalc to do the same operation, -expression
'(A[0]-A[1])/A[1]*100', but it gave me the same result.

The input files were the binding potential map of raclopride, and they
were generated by RPM. The images were transformed to Talairach space using
pet_resample (mritotal and mritopet). The transformation was manually
adjusted and added to the original xfm files.

The PET images were obtained outside of MNI.

Both subject A and B were scanned in the same scanner.

Could you help me to fix this problem?

Thanks,

Ji Hyun

From a.janke at gmail.com  Tue Nov 20 18:19:15 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 21 Nov 2007 10:19:15 +1100
Subject: [MINC-users] mincmath -percentdiff
In-Reply-To: <Pine.SGI.4.58.0711201745190.69713298@yorick.bic.mni.mcgill.ca>
References: <Pine.SGI.4.58.0711201745190.69713298@yorick.bic.mni.mcgill.ca>
Message-ID: <d747ed50711201519o705a874dy4257794136d9f23f@mail.gmail.com>

Hi,

I suspect that your second volume has a few voxels in it that are 0.
Thus you will get range problems.

There are a few ways around this but something like this should work

   minccalc -expression "(abs(A[1]) < 0.0001) ? 0 : (A[0]-A[1])/A[1]*100" ....


a

On Nov 21, 2007 9:57 AM, Ji Hyum KO <kojinet at bic.mni.mcgill.ca> wrote:
> Hello,
>
> mincmath -percentdiff A_BPmap1.mnc A_BPmap2.mnc A_BPdiff.mnc
>
> This command should give me the precentage difference of BPmap2.mnc
> compared to BPmap1.mnc, but it gives right values for subject A, but not
> for subject B.
>
> For subject B, all the values in the minc file is set to 3796.17 except
> several dots and those dots were set to some wierd value as well.
>
> I tried to use minccalc to do the same operation, -expression
> '(A[0]-A[1])/A[1]*100', but it gave me the same result.
>
> The input files were the binding potential map of raclopride, and they
> were generated by RPM. The images were transformed to Talairach space using
> pet_resample (mritotal and mritopet). The transformation was manually
> adjusted and added to the original xfm files.
>
> The PET images were obtained outside of MNI.
>
> Both subject A and B were scanned in the same scanner.
>
> Could you help me to fix this problem?
>
> Thanks,
>
> Ji Hyun
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From a.janke at gmail.com  Wed Nov 21 00:46:36 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 21 Nov 2007 16:46:36 +1100
Subject: [MINC-users] nu_correct and surface coil
In-Reply-To: <132.206.178.40.990288526.1195587268@webmail.inet.it>
References: <132.206.178.40.990288526.1195587268@webmail.inet.it>
Message-ID: <d747ed50711202146n55962d84n80be34d1bf0171ba@mail.gmail.com>

Hi Michela,

N3 is not really designed for surface coil non-uniformity but you
might have some success if you modify the -distance parameter.  This
given the characteristic distance over which the variation occurs. I
would guess a value around 30-40 will get you something.

This of course depends on what you are imaging...  N3 works by
minimising the entropy in a histogram, this may or may not be
applicable with your data.

a


On Nov 21, 2007 6:34 AM, Michela Pievani <mpievani at fatebenefratelli.it> wrote:
> Hi all,
> I'm using N3 to remove extremes non-uniformities from a surface coil MRI. I tried using different options than the default ones (for example: -iterations 200, -stop 0.00001, -mask ICBM_template), but they don't improve significantly my results.
> Do you have any suggestion?
> Thanks,
> Michela
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From kojinet at bic.mni.mcgill.ca  Wed Nov 21 10:33:46 2007
From: kojinet at bic.mni.mcgill.ca (Ji Hyum KO)
Date: Wed, 21 Nov 2007 10:33:46 -0500
Subject: [MINC-users] mincmath -percentdiff
In-Reply-To: <d747ed50711201519o705a874dy4257794136d9f23f@mail.gmail.com>
References: <Pine.SGI.4.58.0711201745190.69713298@yorick.bic.mni.mcgill.ca>
	<d747ed50711201519o705a874dy4257794136d9f23f@mail.gmail.com>
Message-ID: <Pine.SGI.4.58.0711211032440.69103328@yorick.bic.mni.mcgill.ca>

Hi,

It worked!
Additionally, I used a mask for the striatum, and it worked, too.

Thanks!

Ji Hyun

On Wed, 21 Nov 2007, Andrew Janke wrote:

> Hi,
>
> I suspect that your second volume has a few voxels in it that are 0.
> Thus you will get range problems.
>
> There are a few ways around this but something like this should work
>
>    minccalc -expression "(abs(A[1]) < 0.0001) ? 0 : (A[0]-A[1])/A[1]*100" ....
>
>
> a
>
> On Nov 21, 2007 9:57 AM, Ji Hyum KO <kojinet at bic.mni.mcgill.ca> wrote:
> > Hello,
> >
> > mincmath -percentdiff A_BPmap1.mnc A_BPmap2.mnc A_BPdiff.mnc
> >
> > This command should give me the precentage difference of BPmap2.mnc
> > compared to BPmap1.mnc, but it gives right values for subject A, but not
> > for subject B.
> >
> > For subject B, all the values in the minc file is set to 3796.17 except
> > several dots and those dots were set to some wierd value as well.
> >
> > I tried to use minccalc to do the same operation, -expression
> > '(A[0]-A[1])/A[1]*100', but it gave me the same result.
> >
> > The input files were the binding potential map of raclopride, and they
> > were generated by RPM. The images were transformed to Talairach space using
> > pet_resample (mritotal and mritopet). The transformation was manually
> > adjusted and added to the original xfm files.
> >
> > The PET images were obtained outside of MNI.
> >
> > Both subject A and B were scanned in the same scanner.
> >
> > Could you help me to fix this problem?
> >
> > Thanks,
> >
> > Ji Hyun
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
>
>
>
> --
> Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia    +61 (402) 700 883
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From se at hst.aau.dk  Thu Nov 22 06:17:17 2007
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Thu, 22 Nov 2007 12:17:17 +0100
Subject: [MINC-users] minctracc and cropped images
Message-ID: <4745653D.8080104@hst.aau.dk>

Hi all,

I have a number of bitmap images. Each image is a coronal slice from a 
T1 MRI. Using rawtominc I have managed to create a minc volume from the 
bitmaps.
I have the original scan in dicom, which I have converted to minc using 
dcm2mnc.
Now I would like to align my volume created by rawtominc (let's call it 
"bitmap volume") with the original scan. However, the bitmap volume is 
cropped compared to the original scan, and minctracc does not seem to do 
a very good job aligning the two volumes. Is there a way to let 
minctracc know that the source does not have to match all of the target? 
Also, I don't need rotations in the transformation. Is there a way to 
force minctracc to not use rotations, only translations and scale?

Thanks,
Simon

From oliver.gress at medizin.uni-leipzig.de  Thu Nov 22 06:55:24 2007
From: oliver.gress at medizin.uni-leipzig.de (Oliver Gress)
Date: Thu, 22 Nov 2007 13:55:24 +0200
Subject: [MINC-users] minctracc and cropped images
In-Reply-To: <4745653D.8080104@hst.aau.dk>
References: <4745653D.8080104@hst.aau.dk>
Message-ID: <200711221255.24653.oliver.gress@medizin.uni-leipzig.de>

Hi Simon,

I think the easiest way is to use "-w_rotations 0 0 0". It sets the weights 
for rotations to zero for the optimization, so no rotation will be present in 
the estimated transformation.
To exclude parts of a volume from the estimation, you can set masks for the 
target and source volumes with "-model_mask <filename>" and "-source_mask 
<filename>". I think the mask files are binary minc files, so coordinates of 
your MRI volumes that fall into regions of zero value in the mask files will 
not be used for the optimization of the objective function.

Best regards
Oliver

On Thursday 22 November 2007 12:17, Simon Fristed Eskildsen wrote:
> Hi all,
>
> I have a number of bitmap images. Each image is a coronal slice from a
> T1 MRI. Using rawtominc I have managed to create a minc volume from the
> bitmaps.
> I have the original scan in dicom, which I have converted to minc using
> dcm2mnc.
> Now I would like to align my volume created by rawtominc (let's call it
> "bitmap volume") with the original scan. However, the bitmap volume is
> cropped compared to the original scan, and minctracc does not seem to do
> a very good job aligning the two volumes. Is there a way to let
> minctracc know that the source does not have to match all of the target?
> Also, I don't need rotations in the transformation. Is there a way to
> force minctracc to not use rotations, only translations and scale?
>
> Thanks,
> Simon

From se at hst.aau.dk  Thu Nov 22 07:34:24 2007
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Thu, 22 Nov 2007 13:34:24 +0100
Subject: [MINC-users] minctracc and cropped images
In-Reply-To: <200711221255.24653.oliver.gress@medizin.uni-leipzig.de>
References: <4745653D.8080104@hst.aau.dk>
	<200711221255.24653.oliver.gress@medizin.uni-leipzig.de>
Message-ID: <47457750.6070302@hst.aau.dk>

Hi Oliver,

Thanks for the quick reply.
If the weights are 0 the optimization will still be able to change the 
rotations, right?

In any case, with -w_rotations 0 0 0, I get:
-rotation      -0.84230   -0.25758   87.84906

where default is:
-rotation      -3.17860   -8.78379   80.04449

I will try with a mask, but my problem is that I have no way to estimate 
the size of the mask used for the target, as I only know that my source 
is a subset of my target (not how big a subset).

Simon

Oliver Gress wrote:
> Hi Simon,
> 
> I think the easiest way is to use "-w_rotations 0 0 0". It sets the weights 
> for rotations to zero for the optimization, so no rotation will be present in 
> the estimated transformation.
> To exclude parts of a volume from the estimation, you can set masks for the 
> target and source volumes with "-model_mask <filename>" and "-source_mask 
> <filename>". I think the mask files are binary minc files, so coordinates of 
> your MRI volumes that fall into regions of zero value in the mask files will 
> not be used for the optimization of the objective function.
> 
> Best regards
> Oliver
> 
> On Thursday 22 November 2007 12:17, Simon Fristed Eskildsen wrote:
>> Hi all,
>>
>> I have a number of bitmap images. Each image is a coronal slice from a
>> T1 MRI. Using rawtominc I have managed to create a minc volume from the
>> bitmaps.
>> I have the original scan in dicom, which I have converted to minc using
>> dcm2mnc.
>> Now I would like to align my volume created by rawtominc (let's call it
>> "bitmap volume") with the original scan. However, the bitmap volume is
>> cropped compared to the original scan, and minctracc does not seem to do
>> a very good job aligning the two volumes. Is there a way to let
>> minctracc know that the source does not have to match all of the target?
>> Also, I don't need rotations in the transformation. Is there a way to
>> force minctracc to not use rotations, only translations and scale?
>>
>> Thanks,
>> Simon
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From oliver.gress at medizin.uni-leipzig.de  Thu Nov 22 09:05:35 2007
From: oliver.gress at medizin.uni-leipzig.de (Oliver Gress)
Date: Thu, 22 Nov 2007 16:05:35 +0200
Subject: [MINC-users] minctracc and cropped images
In-Reply-To: <47457750.6070302@hst.aau.dk>
References: <4745653D.8080104@hst.aau.dk>
	<200711221255.24653.oliver.gress@medizin.uni-leipzig.de>
	<47457750.6070302@hst.aau.dk>
Message-ID: <200711221505.35597.oliver.gress@medizin.uni-leipzig.de>

Hi Simon,

in my case, I used -w_rotations 0 0 1 to set the rotation around x- and y-axis 
to zero and it worked, so I always got something like
-rotation       0.00000    0.00000    0.01142
I wonder why you get rotations (your "-rotation" output is from xfm2param, 
right?). A look into the minctracc manual tells, that the weights are set for 
the optimization. In my understanding it means that no rotation should be 
estimated. Perhaps someone from the BIC knows more exactly how the weights 
are incorporated in the optimization. I'm sorry that I can't help you better.

To your other problem, if it is a one-time task, you could manually find an 
initial translation (and perhaps scaling) and create an initial 
transformation (param2xfm) that you can feed to minctracc with 
"-transformation <file.xfm>", but then you probably could also build a coarse 
mask. And without a mask, I could imagine that the objective function (i.e. 
the default crosscorrelation) could give better values when the subset is in 
some way stretched to cover a great part of the full set.

I hope that helps a little

Oliver


On Thursday 22 November 2007 13:34, Simon Fristed Eskildsen wrote:
> Hi Oliver,
>
> Thanks for the quick reply.
> If the weights are 0 the optimization will still be able to change the
> rotations, right?
>
> In any case, with -w_rotations 0 0 0, I get:
> -rotation      -0.84230   -0.25758   87.84906
>
> where default is:
> -rotation      -3.17860   -8.78379   80.04449
>
> I will try with a mask, but my problem is that I have no way to estimate
> the size of the mask used for the target, as I only know that my source
> is a subset of my target (not how big a subset).
>
> Simon
>
> Oliver Gress wrote:
> > Hi Simon,
> >
> > I think the easiest way is to use "-w_rotations 0 0 0". It sets the
> > weights for rotations to zero for the optimization, so no rotation will
> > be present in the estimated transformation.
> > To exclude parts of a volume from the estimation, you can set masks for
> > the target and source volumes with "-model_mask <filename>" and
> > "-source_mask <filename>". I think the mask files are binary minc files,
> > so coordinates of your MRI volumes that fall into regions of zero value
> > in the mask files will not be used for the optimization of the objective
> > function.
> >
> > Best regards
> > Oliver
> >
> > On Thursday 22 November 2007 12:17, Simon Fristed Eskildsen wrote:
> >> Hi all,
> >>
> >> I have a number of bitmap images. Each image is a coronal slice from a
> >> T1 MRI. Using rawtominc I have managed to create a minc volume from the
> >> bitmaps.
> >> I have the original scan in dicom, which I have converted to minc using
> >> dcm2mnc.
> >> Now I would like to align my volume created by rawtominc (let's call it
> >> "bitmap volume") with the original scan. However, the bitmap volume is
> >> cropped compared to the original scan, and minctracc does not seem to do
> >> a very good job aligning the two volumes. Is there a way to let
> >> minctracc know that the source does not have to match all of the target?
> >> Also, I don't need rotations in the transformation. Is there a way to
> >> force minctracc to not use rotations, only translations and scale?
> >>
> >> Thanks,
> >> Simon
> >
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From a.janke at gmail.com  Thu Nov 22 09:32:20 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 23 Nov 2007 01:32:20 +1100
Subject: [MINC-users] minctracc and cropped images
In-Reply-To: <200711221505.35597.oliver.gress@medizin.uni-leipzig.de>
References: <4745653D.8080104@hst.aau.dk>
	<200711221255.24653.oliver.gress@medizin.uni-leipzig.de>
	<47457750.6070302@hst.aau.dk>
	<200711221505.35597.oliver.gress@medizin.uni-leipzig.de>
Message-ID: <d747ed50711220632t5299d82ekf2766a0b33787913@mail.gmail.com>

Hi Simon,

Oliver is correct, you should be messing with the -w_* parameters.
Unfortunately with the way that minctracc works there is no easy way
to completely remove rotations from a registration (That I am aware
of).   In theory the 0 0 0 solution should work but doesnt due to the
way the decomposition is done IIRC.  In any case I suspect that
instead of fiddling with the rotation parameter you probably should be
changing the scale parameters.

What size of scale difference is there between the two images?
Typically scale is weighted very low in minctracc as this is not a
very common difference between heads.  As a quick test I just did this
with some success (partial to complete).

   # make an evil transform
   $ param2xfm -translation 10 0 0 -scale 2 2 2 xfm.xfm

   # apply it
   $ mincresample -use_input_sampling \
         /usr/local/bic/share/mni_autoreg/icbm_avg_152_t1_tal_lin.mnc trans.mnc

   $ ln -s /usr/local/bic/share/mni_autoreg/icbm_avg_152_t1_tal_lin.mnc .

   # registration time
   $ minctracc -identity -lsq7 -w_scales 0.5 0.5 0.5 \
         trans.mnc icbm_avg_152_t1_tal_lin.mnc a.xfm

   $ xfm2param a.xfm
-center         0.00000    0.00000    0.00000
-translation    3.51257    2.31355   14.91390
-rotation      -1.38063   -1.11240   -4.42853
-scale          2.99839    2.99839    2.99839
-shear          0.00000   -0.00000   -0.00000

Close enough for a first hack to me.. :)


FWIW: there is no way to "tell" minctracc that one image is partial.
The code should deal with this without problem.

I would also guess that you would be best to work on something like a
gradient image if your images are far apart to start with.  I use the
-identity above to ensure that the initial registration is not
dependant on a PAT xfm (the default in minctracc) that would not be
the best in this case given that it uses things like COG's of volumes.

With the right parameters you will be able to make it work, but be
aware that it may be a multi-step process to get it to work.

a


On Nov 23, 2007 1:05 AM, Oliver Gress
<oliver.gress at medizin.uni-leipzig.de> wrote:
> Hi Simon,
>
> in my case, I used -w_rotations 0 0 1 to set the rotation around x- and y-axis
> to zero and it worked, so I always got something like
> -rotation       0.00000    0.00000    0.01142
> I wonder why you get rotations (your "-rotation" output is from xfm2param,
> right?). A look into the minctracc manual tells, that the weights are set for
> the optimization. In my understanding it means that no rotation should be
> estimated. Perhaps someone from the BIC knows more exactly how the weights
> are incorporated in the optimization. I'm sorry that I can't help you better.
>
> To your other problem, if it is a one-time task, you could manually find an
> initial translation (and perhaps scaling) and create an initial
> transformation (param2xfm) that you can feed to minctracc with
> "-transformation <file.xfm>", but then you probably could also build a coarse
> mask. And without a mask, I could imagine that the objective function (i.e.
> the default crosscorrelation) could give better values when the subset is in
> some way stretched to cover a great part of the full set.
>
> I hope that helps a little
>
> Oliver
>
>
>
> On Thursday 22 November 2007 13:34, Simon Fristed Eskildsen wrote:
> > Hi Oliver,
> >
> > Thanks for the quick reply.
> > If the weights are 0 the optimization will still be able to change the
> > rotations, right?
> >
> > In any case, with -w_rotations 0 0 0, I get:
> > -rotation      -0.84230   -0.25758   87.84906
> >
> > where default is:
> > -rotation      -3.17860   -8.78379   80.04449
> >
> > I will try with a mask, but my problem is that I have no way to estimate
> > the size of the mask used for the target, as I only know that my source
> > is a subset of my target (not how big a subset).
> >
> > Simon
> >
> > Oliver Gress wrote:
> > > Hi Simon,
> > >
> > > I think the easiest way is to use "-w_rotations 0 0 0". It sets the
> > > weights for rotations to zero for the optimization, so no rotation will
> > > be present in the estimated transformation.
> > > To exclude parts of a volume from the estimation, you can set masks for
> > > the target and source volumes with "-model_mask <filename>" and
> > > "-source_mask <filename>". I think the mask files are binary minc files,
> > > so coordinates of your MRI volumes that fall into regions of zero value
> > > in the mask files will not be used for the optimization of the objective
> > > function.
> > >
> > > Best regards
> > > Oliver
> > >
> > > On Thursday 22 November 2007 12:17, Simon Fristed Eskildsen wrote:
> > >> Hi all,
> > >>
> > >> I have a number of bitmap images. Each image is a coronal slice from a
> > >> T1 MRI. Using rawtominc I have managed to create a minc volume from the
> > >> bitmaps.
> > >> I have the original scan in dicom, which I have converted to minc using
> > >> dcm2mnc.
> > >> Now I would like to align my volume created by rawtominc (let's call it
> > >> "bitmap volume") with the original scan. However, the bitmap volume is
> > >> cropped compared to the original scan, and minctracc does not seem to do
> > >> a very good job aligning the two volumes. Is there a way to let
> > >> minctracc know that the source does not have to match all of the target?
> > >> Also, I don't need rotations in the transformation. Is there a way to
> > >> force minctracc to not use rotations, only translations and scale?
> > >>
> > >> Thanks,
> > >> Simon
> > >
> > > _______________________________________________
> > > 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
>



-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From a.janke at gmail.com  Thu Nov 22 09:35:13 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 23 Nov 2007 01:35:13 +1100
Subject: [MINC-users] minctracc and cropped images
In-Reply-To: <d747ed50711220632t5299d82ekf2766a0b33787913@mail.gmail.com>
References: <4745653D.8080104@hst.aau.dk>
	<200711221255.24653.oliver.gress@medizin.uni-leipzig.de>
	<47457750.6070302@hst.aau.dk>
	<200711221505.35597.oliver.gress@medizin.uni-leipzig.de>
	<d747ed50711220632t5299d82ekf2766a0b33787913@mail.gmail.com>
Message-ID: <d747ed50711220635q192a6452u6e67082c9310b057@mail.gmail.com>

>    $ xfm2param a.xfm
> -center         0.00000    0.00000    0.00000
> -translation    3.51257    2.31355   14.91390
> -rotation      -1.38063   -1.11240   -4.42853
> -scale          2.99839    2.99839    2.99839
> -shear          0.00000   -0.00000   -0.00000

oops, wrong transform...  (I started fiddling with -mi quickly with
not much success) here is the correct one:


gordon:foo$ xfm2param a.xfm
after parameter extraction
-center         0.00000    0.00000    0.00000
-translation   -5.87375   -2.46452    3.77487
-rotation       6.11522    2.82864    3.44776
-scale          0.49651    0.49651    0.49651
-shear          0.00000    0.00000    0.00000
gordon:foo$

A bit better!


a

From oliver.gress at medizin.uni-leipzig.de  Thu Nov 22 10:07:09 2007
From: oliver.gress at medizin.uni-leipzig.de (Oliver Gress)
Date: Thu, 22 Nov 2007 17:07:09 +0200
Subject: [MINC-users] minc volume size limit
In-Reply-To: <d747ed50711220635q192a6452u6e67082c9310b057@mail.gmail.com>
References: <4745653D.8080104@hst.aau.dk>
	<d747ed50711220632t5299d82ekf2766a0b33787913@mail.gmail.com>
	<d747ed50711220635q192a6452u6e67082c9310b057@mail.gmail.com>
Message-ID: <200711221607.09264.oliver.gress@medizin.uni-leipzig.de>

Hi all,

I've got a question about the size limit of a minc volume. As I work with 
quite dense data, I sometimes ran into errors like the following, that seems 
to arise when I want to create a too large volume:

Processing:.mincconcat: ncx.c:1716: ncx_put_size_t: Assertion `*ulp <= 
4294967295U' failed.
Aborted

Has anyone experience with that error that in my opinion is produced by a 
overflow? I could concatenate slices to a volume by a workaround at first, 
but now I want to create a larger volume. Is there a defined size limit to 
minc volumes?

Best regards
Oliver

From a.janke at gmail.com  Thu Nov 22 10:19:15 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 23 Nov 2007 02:19:15 +1100
Subject: [MINC-users] minc volume size limit
In-Reply-To: <200711221607.09264.oliver.gress@medizin.uni-leipzig.de>
References: <4745653D.8080104@hst.aau.dk>
	<d747ed50711220632t5299d82ekf2766a0b33787913@mail.gmail.com>
	<d747ed50711220635q192a6452u6e67082c9310b057@mail.gmail.com>
	<200711221607.09264.oliver.gress@medizin.uni-leipzig.de>
Message-ID: <d747ed50711220719k5b752529uff29261a07d54049@mail.gmail.com>

On Nov 23, 2007 2:07 AM, Oliver Gress
<oliver.gress at medizin.uni-leipzig.de> wrote:
> I've got a question about the size limit of a minc volume. As I work with
> quite dense data, I sometimes ran into errors like the following, that seems
> to arise when I want to create a too large volume:
>
> Processing:.mincconcat: ncx.c:1716: ncx_put_size_t: Assertion `*ulp <=
> 4294967295U' failed.
> Aborted

Which version of mincconcat are you running?  And if it is MINC 2 is
the file netcdf or HDF?

One of the primary reasons for the shift to MINC2 (and thus HDF5) was
to get around the size limitations of netcdf. If you are using large
volumes be sure to either use '-2' when you originally create all your
data in MINC (and then it will flow on) or to be sure set this env
variable:

   export MINC_FORCE_V2=1

you can check on your file types using "file".

ie:

gordon:map$ file /tmp/foo/*.mnc
/tmp/foo/green.mnc:                   Hierarchical Data Format (version 5) data
/tmp/foo/out.mnc:                     NetCDF Data Format data
/tmp/foo/trans.mnc:                   NetCDF Data Format data

You can convert a netcdf MINC file to HDF very easily using the following:

   $ mincconvert -2 in.mnc out.mnc


-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From se at hst.aau.dk  Thu Nov 22 10:24:46 2007
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Thu, 22 Nov 2007 16:24:46 +0100
Subject: [MINC-users] minctracc and cropped images
In-Reply-To: <d747ed50711220632t5299d82ekf2766a0b33787913@mail.gmail.com>
References: <4745653D.8080104@hst.aau.dk>	<200711221255.24653.oliver.gress@medizin.uni-leipzig.de>	<47457750.6070302@hst.aau.dk>	<200711221505.35597.oliver.gress@medizin.uni-leipzig.de>
	<d747ed50711220632t5299d82ekf2766a0b33787913@mail.gmail.com>
Message-ID: <47459F3E.6020908@hst.aau.dk>

Thanks Oliver and Andrew,
Unfortunately, this is not a one-time task. I tried fiddling with the 
-w_* parameters but it seems that the more weight I put on scale, the 
smaller the scale in the transformation becomes.

I did a manual registration for this first image and removed the rotations:
-center         0.00000    0.00000    0.00000
-translation    1.68332   14.59561   12.16452
-rotation       0.00000    0.00000    0.00000
-scale          0.76397    0.91574    0.76318
-shear          0.00000    0.00000    0.00000
This is close enough.

minctracc -identity -lsq7 -w_scales 0.5 0.5 0.5 gives:
-center         0.00000    0.00000    0.00000
-translation   -3.36057    5.93894    3.07303
-rotation      -2.83953   -3.54900   21.45400
-scale          0.00442    0.00442    0.00442
-shear         -0.00000   -0.00000    0.00000

Maybe I'm approaching the problem the wrong way. Allow me to elaborate 
on the problem. The original scans are 4mm coronal slices (18-27 
slices). Some radiographer looks through the slices in some windoze app 
and draws contours around the hippocampus. He then gives me bitmap 
images of his drawings, always only 12 consecutive slices. These bitmaps 
are cropped.
So in reality the problem can be reduced to finding the match between 
one, say the first, bitmap slice and one minc slice, and the global 
(x,z) scale between these slices. Then I can use Imagemagick and 
rawtominc to produce a volume that matches the original scan. With such 
a solution I will only get resampling artifacts in 2D (x,z plane) 
instead of in 3D.

Maybe I should write a program for this problem?

for each coronal slice in scan.mnc do
   for scale=0.1 to 1.0 do
     min = xcorr(scale(bitmap),slice) < min ? xcorr(scale(bitmap)) : min
   done
   globalmin = min < globalmin ? min : globalmin
done

...and of course keep track of best slice and scale :-)

Simon

Andrew Janke wrote:
> Hi Simon,
> 
> Oliver is correct, you should be messing with the -w_* parameters.
> Unfortunately with the way that minctracc works there is no easy way
> to completely remove rotations from a registration (That I am aware
> of).   In theory the 0 0 0 solution should work but doesnt due to the
> way the decomposition is done IIRC.  In any case I suspect that
> instead of fiddling with the rotation parameter you probably should be
> changing the scale parameters.
> 
> What size of scale difference is there between the two images?
> Typically scale is weighted very low in minctracc as this is not a
> very common difference between heads.  As a quick test I just did this
> with some success (partial to complete).
> 
>    # make an evil transform
>    $ param2xfm -translation 10 0 0 -scale 2 2 2 xfm.xfm
> 
>    # apply it
>    $ mincresample -use_input_sampling \
>          /usr/local/bic/share/mni_autoreg/icbm_avg_152_t1_tal_lin.mnc trans.mnc
> 
>    $ ln -s /usr/local/bic/share/mni_autoreg/icbm_avg_152_t1_tal_lin.mnc .
> 
>    # registration time
>    $ minctracc -identity -lsq7 -w_scales 0.5 0.5 0.5 \
>          trans.mnc icbm_avg_152_t1_tal_lin.mnc a.xfm
> 
>    $ xfm2param a.xfm
> -center         0.00000    0.00000    0.00000
> -translation    3.51257    2.31355   14.91390
> -rotation      -1.38063   -1.11240   -4.42853
> -scale          2.99839    2.99839    2.99839
> -shear          0.00000   -0.00000   -0.00000
> 
> Close enough for a first hack to me.. :)
> 
> 
> FWIW: there is no way to "tell" minctracc that one image is partial.
> The code should deal with this without problem.
> 
> I would also guess that you would be best to work on something like a
> gradient image if your images are far apart to start with.  I use the
> -identity above to ensure that the initial registration is not
> dependant on a PAT xfm (the default in minctracc) that would not be
> the best in this case given that it uses things like COG's of volumes.
> 
> With the right parameters you will be able to make it work, but be
> aware that it may be a multi-step process to get it to work.
> 
> a
> 
> 
> On Nov 23, 2007 1:05 AM, Oliver Gress
> <oliver.gress at medizin.uni-leipzig.de> wrote:
>> Hi Simon,
>>
>> in my case, I used -w_rotations 0 0 1 to set the rotation around x- and y-axis
>> to zero and it worked, so I always got something like
>> -rotation       0.00000    0.00000    0.01142
>> I wonder why you get rotations (your "-rotation" output is from xfm2param,
>> right?). A look into the minctracc manual tells, that the weights are set for
>> the optimization. In my understanding it means that no rotation should be
>> estimated. Perhaps someone from the BIC knows more exactly how the weights
>> are incorporated in the optimization. I'm sorry that I can't help you better.
>>
>> To your other problem, if it is a one-time task, you could manually find an
>> initial translation (and perhaps scaling) and create an initial
>> transformation (param2xfm) that you can feed to minctracc with
>> "-transformation <file.xfm>", but then you probably could also build a coarse
>> mask. And without a mask, I could imagine that the objective function (i.e.
>> the default crosscorrelation) could give better values when the subset is in
>> some way stretched to cover a great part of the full set.
>>
>> I hope that helps a little
>>
>> Oliver
>>
>>
>>
>> On Thursday 22 November 2007 13:34, Simon Fristed Eskildsen wrote:
>>> Hi Oliver,
>>>
>>> Thanks for the quick reply.
>>> If the weights are 0 the optimization will still be able to change the
>>> rotations, right?
>>>
>>> In any case, with -w_rotations 0 0 0, I get:
>>> -rotation      -0.84230   -0.25758   87.84906
>>>
>>> where default is:
>>> -rotation      -3.17860   -8.78379   80.04449
>>>
>>> I will try with a mask, but my problem is that I have no way to estimate
>>> the size of the mask used for the target, as I only know that my source
>>> is a subset of my target (not how big a subset).
>>>
>>> Simon
>>>
>>> Oliver Gress wrote:
>>>> Hi Simon,
>>>>
>>>> I think the easiest way is to use "-w_rotations 0 0 0". It sets the
>>>> weights for rotations to zero for the optimization, so no rotation will
>>>> be present in the estimated transformation.
>>>> To exclude parts of a volume from the estimation, you can set masks for
>>>> the target and source volumes with "-model_mask <filename>" and
>>>> "-source_mask <filename>". I think the mask files are binary minc files,
>>>> so coordinates of your MRI volumes that fall into regions of zero value
>>>> in the mask files will not be used for the optimization of the objective
>>>> function.
>>>>
>>>> Best regards
>>>> Oliver
>>>>
>>>> On Thursday 22 November 2007 12:17, Simon Fristed Eskildsen wrote:
>>>>> Hi all,
>>>>>
>>>>> I have a number of bitmap images. Each image is a coronal slice from a
>>>>> T1 MRI. Using rawtominc I have managed to create a minc volume from the
>>>>> bitmaps.
>>>>> I have the original scan in dicom, which I have converted to minc using
>>>>> dcm2mnc.
>>>>> Now I would like to align my volume created by rawtominc (let's call it
>>>>> "bitmap volume") with the original scan. However, the bitmap volume is
>>>>> cropped compared to the original scan, and minctracc does not seem to do
>>>>> a very good job aligning the two volumes. Is there a way to let
>>>>> minctracc know that the source does not have to match all of the target?
>>>>> Also, I don't need rotations in the transformation. Is there a way to
>>>>> force minctracc to not use rotations, only translations and scale?
>>>>>
>>>>> Thanks,
>>>>> Simon
>>>> _______________________________________________
>>>> 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 oliver.gress at medizin.uni-leipzig.de  Thu Nov 22 10:42:43 2007
From: oliver.gress at medizin.uni-leipzig.de (Oliver Gress)
Date: Thu, 22 Nov 2007 17:42:43 +0200
Subject: [MINC-users] minc volume size limit
In-Reply-To: <d747ed50711220719k5b752529uff29261a07d54049@mail.gmail.com>
References: <4745653D.8080104@hst.aau.dk>
	<200711221607.09264.oliver.gress@medizin.uni-leipzig.de>
	<d747ed50711220719k5b752529uff29261a07d54049@mail.gmail.com>
Message-ID: <200711221642.43222.oliver.gress@medizin.uni-leipzig.de>

Hi Andrew,

thanks for your reply. 
I'm using MINC 1.4, but the HDF type is a very good reason to change to MINC 
2. 
I have written applications with the minc libraries of version 1.4, mainly the 
volume_io lib. Can you tell me if I can just use the minc2 libs or do I have 
to be aware of changes, because I'm running out of time for big 
reimplementations. 

Best regards
Oliver

On Thursday 22 November 2007 16:19, Andrew Janke wrote:
> On Nov 23, 2007 2:07 AM, Oliver Gress
>
> <oliver.gress at medizin.uni-leipzig.de> wrote:
> > I've got a question about the size limit of a minc volume. As I work with
> > quite dense data, I sometimes ran into errors like the following, that
> > seems to arise when I want to create a too large volume:
> >
> > Processing:.mincconcat: ncx.c:1716: ncx_put_size_t: Assertion `*ulp <=
> > 4294967295U' failed.
> > Aborted
>
> Which version of mincconcat are you running?  And if it is MINC 2 is
> the file netcdf or HDF?
>
> One of the primary reasons for the shift to MINC2 (and thus HDF5) was
> to get around the size limitations of netcdf. If you are using large
> volumes be sure to either use '-2' when you originally create all your
> data in MINC (and then it will flow on) or to be sure set this env
> variable:
>
>    export MINC_FORCE_V2=1
>
> you can check on your file types using "file".
>
> ie:
>
> gordon:map$ file /tmp/foo/*.mnc
> /tmp/foo/green.mnc:                   Hierarchical Data Format (version 5)
> data /tmp/foo/out.mnc:                     NetCDF Data Format data
> /tmp/foo/trans.mnc:                   NetCDF Data Format data
>
> You can convert a netcdf MINC file to HDF very easily using the following:
>
>    $ mincconvert -2 in.mnc out.mnc

From a.janke at gmail.com  Thu Nov 22 10:51:40 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 23 Nov 2007 02:51:40 +1100
Subject: [MINC-users] minc volume size limit
In-Reply-To: <200711221642.43222.oliver.gress@medizin.uni-leipzig.de>
References: <4745653D.8080104@hst.aau.dk>
	<200711221607.09264.oliver.gress@medizin.uni-leipzig.de>
	<d747ed50711220719k5b752529uff29261a07d54049@mail.gmail.com>
	<200711221642.43222.oliver.gress@medizin.uni-leipzig.de>
Message-ID: <d747ed50711220751t97a1863kba827e92a985df2c@mail.gmail.com>

> thanks for your reply.
> I'm using MINC 1.4, but the HDF type is a very good reason to change to MINC
> 2.

That it is.  Get to http://packages.bic.mni.mcill.ca/ as fast as you can... ;)

> I have written applications with the minc libraries of version 1.4, mainly the
> volume_io lib. Can you tell me if I can just use the minc2 libs or do I have
> to be aware of changes, because I'm running out of time for big
> reimplementations.

We have striven to make MINC2 100% compatible with MINC1 so your
volume_io programs will work just fine against minc2.   (just change
to -lminc2 -lvolume_io2 -lnetcdf -lhdf5 -lm)

Jason has written some very nice MINC2 API tutorials here:

   http://en.wikibooks.org/wiki/MINC/Tutorials

The programming section.


a

> Best regards
> Oliver
>
>
> On Thursday 22 November 2007 16:19, Andrew Janke wrote:
> > On Nov 23, 2007 2:07 AM, Oliver Gress
> >
> > <oliver.gress at medizin.uni-leipzig.de> wrote:
> > > I've got a question about the size limit of a minc volume. As I work with
> > > quite dense data, I sometimes ran into errors like the following, that
> > > seems to arise when I want to create a too large volume:
> > >
> > > Processing:.mincconcat: ncx.c:1716: ncx_put_size_t: Assertion `*ulp <=
> > > 4294967295U' failed.
> > > Aborted
> >
> > Which version of mincconcat are you running?  And if it is MINC 2 is
> > the file netcdf or HDF?
> >
> > One of the primary reasons for the shift to MINC2 (and thus HDF5) was
> > to get around the size limitations of netcdf. If you are using large
> > volumes be sure to either use '-2' when you originally create all your
> > data in MINC (and then it will flow on) or to be sure set this env
> > variable:
> >
> >    export MINC_FORCE_V2=1
> >
> > you can check on your file types using "file".
> >
> > ie:
> >
> > gordon:map$ file /tmp/foo/*.mnc
> > /tmp/foo/green.mnc:                   Hierarchical Data Format (version 5)
> > data /tmp/foo/out.mnc:                     NetCDF Data Format data
> > /tmp/foo/trans.mnc:                   NetCDF Data Format data
> >
> > You can convert a netcdf MINC file to HDF very easily using the following:
> >
> >    $ mincconvert -2 in.mnc out.mnc
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From claude at bic.mni.mcgill.ca  Thu Nov 22 15:44:39 2007
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Thu, 22 Nov 2007 15:44:39 -0500 (EST)
Subject: [MINC-users] Custom kernels in mincmorph
References: <473C4CA1.6090308@hst.aau.dk>
	<d747ed50711150604r2e15e987yd65baeb3cf82c641@mail.gmail.com>
Message-ID: <200711222044.lAMKidxo70703935@yorick.bic.mni.mcgill.ca>

Simon, Andrew,

Has this issue been resolved?

> >> Andrew, it is line 120 in kernel_io.c that worries me (kernel is freed
> >> right before calling input_kernel). I'm using version 1.4.
> > 
> > You lost me. Do you mean in kernel_io.c or mincmorph.c? input_kernel()
> > is defined in kernel_io.c
> 
> kernel is freed at line 505 in mincmorph.c subsequently input_kernel() 
> is called where (line 120 in kernel_io.c) kernel imho is used uninitialized.

ok. I see this. I think the current code is safe, since kernel is first 
initialized at line 436 of mincmorph.c:

   /* init and then do some operations */
   kernel = new_kernel(0);

At line 505, this default kernel is freed in order to read in the user-supplied
one. Looks fine to me.

Communicate with me, Simon, if you are still getting a seg fault with mincmorph.
To help you, I will need the inputs in order to reproduce the problem.

Claude

From kojinet at bic.mni.mcgill.ca  Thu Nov 22 19:21:55 2007
From: kojinet at bic.mni.mcgill.ca (Ji Hyum KO)
Date: Thu, 22 Nov 2007 19:21:55 -0500
Subject: [MINC-users] mritotal for striatum
Message-ID: <Pine.SGI.4.58.0711221915510.71049951@yorick.bic.mni.mcgill.ca>

Hello,

Sometimes, due to the huge individual variances in the size of ventricles,
mritotal cannot do a proper job in fitting the caudate nucleus.

Since I am now trying to analyze a raclopride PET data, I want to be very
precise for fitting the caudate nucleus into Talairach space.

Using a manual transformation using register and tagtoxfm with nonlinear
option can solve this problem, but it is really cumbersome.

Is there any other way to do the mritotal or do_mritotal with an emphasis
on caudate nucleus or striatum?

Thanks,

Ji Hyun

From jason at bic.mni.mcgill.ca  Fri Nov 23 08:12:57 2007
From: jason at bic.mni.mcgill.ca (Jason Lerch)
Date: Fri, 23 Nov 2007 08:12:57 -0500
Subject: [MINC-users] mritotal for striatum
In-Reply-To: <Pine.SGI.4.58.0711221915510.71049951@yorick.bic.mni.mcgill.ca>
References: <Pine.SGI.4.58.0711221915510.71049951@yorick.bic.mni.mcgill.ca>
Message-ID: <48C3C974-11D2-4AC5-BB6B-900E7AE07421@bic.mni.mcgill.ca>

Hi Ji Hyun,

you could use minctracc (the underlying registration tool used by  
mritotal) directly with a mask option which covers only the basal  
ganglia. That way you ought to get good linear or non-linear  
registration of those structures.

Cheers,

Jason

On 22-Nov-07, at 7:21 PM, Ji Hyum KO wrote:

> Hello,
>
> Sometimes, due to the huge individual variances in the size of  
> ventricles,
> mritotal cannot do a proper job in fitting the caudate nucleus.
>
> Since I am now trying to analyze a raclopride PET data, I want to  
> be very
> precise for fitting the caudate nucleus into Talairach space.
>
> Using a manual transformation using register and tagtoxfm with  
> nonlinear
> option can solve this problem, but it is really cumbersome.
>
> Is there any other way to do the mritotal or do_mritotal with an  
> emphasis
> on caudate nucleus or striatum?
>
> Thanks,
>
> Ji Hyun
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From kojinet at bic.mni.mcgill.ca  Tue Nov 27 18:12:25 2007
From: kojinet at bic.mni.mcgill.ca (Ji Hyum KO)
Date: Tue, 27 Nov 2007 18:12:25 -0500
Subject: [MINC-users] compiling RMS.c for mincrealign
In-Reply-To: <48C3C974-11D2-4AC5-BB6B-900E7AE07421@bic.mni.mcgill.ca>
References: <Pine.SGI.4.58.0711221915510.71049951@yorick.bic.mni.mcgill.ca>
	<48C3C974-11D2-4AC5-BB6B-900E7AE07421@bic.mni.mcgill.ca>
Message-ID: <Pine.SGI.4.58.0711271806400.71539052@yorick.bic.mni.mcgill.ca>

Hello,

I am trying to compile RMS.c to mincrealign with option of -target_for_RMS
of MRI file.

I think I have all the necessary header files, ie., volume_io.h and etc,
but it gives me the following errors when I tried to compile it.
My gcc version is 3.3.5 (Debian).

Could anybody help me?

ursula:/usr/local/mni/data/jihyun/mincrealign/RMS/src# gcc RMS.c
-I/usr/local/mni/include/
/tmp/ccIcUkSO.o(.text+0x66): In function `main':
: undefined reference to `input_volume'
/tmp/ccIcUkSO.o(.text+0x8e): In function `main':
: undefined reference to `get_volume_sizes'
/tmp/ccIcUkSO.o(.text+0xa8): In function `main':
: undefined reference to `input_transform_file'
/tmp/ccIcUkSO.o(.text+0x141): In function `main':
: undefined reference to `get_cached_volume_voxel'
/tmp/ccIcUkSO.o(.text+0x376): In function `main':
: undefined reference to `convert_voxel_to_value'
/tmp/ccIcUkSO.o(.text+0x3c9): In function `main':
: undefined reference to `convert_3D_voxel_to_world'
/tmp/ccIcUkSO.o(.text+0x401): In function `main':
: undefined reference to `general_inverse_transform_point'
/tmp/ccIcUkSO.o(.text+0x419): In function `main':
: undefined reference to `pow'
/tmp/ccIcUkSO.o(.text+0x437): In function `main':
: undefined reference to `pow'
/tmp/ccIcUkSO.o(.text+0x45d): In function `main':
: undefined reference to `pow'
/tmp/ccIcUkSO.o(.text+0x4a1): In function `main':
: undefined reference to `sqrt'
collect2: ld returned 1 exit status

Thanks,

Ji Hyun


From a.janke at gmail.com  Tue Nov 27 18:33:37 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 28 Nov 2007 10:33:37 +1100
Subject: [MINC-users] compiling RMS.c for mincrealign
In-Reply-To: <Pine.SGI.4.58.0711271806400.71539052@yorick.bic.mni.mcgill.ca>
References: <Pine.SGI.4.58.0711221915510.71049951@yorick.bic.mni.mcgill.ca>
	<48C3C974-11D2-4AC5-BB6B-900E7AE07421@bic.mni.mcgill.ca>
	<Pine.SGI.4.58.0711271806400.71539052@yorick.bic.mni.mcgill.ca>
Message-ID: <d747ed50711271533q35ba12c9h2fa5132cbb384cf7@mail.gmail.com>

Hi Ji,

I have no idea what RMS.c or mincrealign are but it looks to me that
you are missing the minc/volume_io libraries.

This should work:

   gcc RMS.c -L/usr/local/mni/lib -I/usr/local/mni/include -lvolume_io
-lminc -lm

Presuming of course that RMS.c is the main C program (has a main() in it).

a


On Nov 28, 2007 10:12 AM, Ji Hyum KO <kojinet at bic.mni.mcgill.ca> wrote:
> Hello,
>
> I am trying to compile RMS.c to mincrealign with option of -target_for_RMS
> of MRI file.
>
> I think I have all the necessary header files, ie., volume_io.h and etc,
> but it gives me the following errors when I tried to compile it.
> My gcc version is 3.3.5 (Debian).
>
> Could anybody help me?
>
> ursula:/usr/local/mni/data/jihyun/mincrealign/RMS/src# gcc RMS.c
> -I/usr/local/mni/include/
> /tmp/ccIcUkSO.o(.text+0x66): In function `main':
> : undefined reference to `input_volume'
> /tmp/ccIcUkSO.o(.text+0x8e): In function `main':
> : undefined reference to `get_volume_sizes'
> /tmp/ccIcUkSO.o(.text+0xa8): In function `main':
> : undefined reference to `input_transform_file'
> /tmp/ccIcUkSO.o(.text+0x141): In function `main':
> : undefined reference to `get_cached_volume_voxel'
> /tmp/ccIcUkSO.o(.text+0x376): In function `main':
> : undefined reference to `convert_voxel_to_value'
> /tmp/ccIcUkSO.o(.text+0x3c9): In function `main':
> : undefined reference to `convert_3D_voxel_to_world'
> /tmp/ccIcUkSO.o(.text+0x401): In function `main':
> : undefined reference to `general_inverse_transform_point'
> /tmp/ccIcUkSO.o(.text+0x419): In function `main':
> : undefined reference to `pow'
> /tmp/ccIcUkSO.o(.text+0x437): In function `main':
> : undefined reference to `pow'
> /tmp/ccIcUkSO.o(.text+0x45d): In function `main':
> : undefined reference to `pow'
> /tmp/ccIcUkSO.o(.text+0x4a1): In function `main':
> : undefined reference to `sqrt'
> collect2: ld returned 1 exit status
>
> Thanks,
>
> Ji Hyun
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From kojinet at bic.mni.mcgill.ca  Tue Nov 27 18:58:05 2007
From: kojinet at bic.mni.mcgill.ca (Ji Hyum KO)
Date: Tue, 27 Nov 2007 18:58:05 -0500
Subject: [MINC-users] compiling RMS.c for mincrealign
In-Reply-To: <d747ed50711271533q35ba12c9h2fa5132cbb384cf7@mail.gmail.com>
References: <Pine.SGI.4.58.0711221915510.71049951@yorick.bic.mni.mcgill.ca>
	<48C3C974-11D2-4AC5-BB6B-900E7AE07421@bic.mni.mcgill.ca>
	<Pine.SGI.4.58.0711271806400.71539052@yorick.bic.mni.mcgill.ca>
	<d747ed50711271533q35ba12c9h2fa5132cbb384cf7@mail.gmail.com>
Message-ID: <Pine.SGI.4.58.0711271854300.71806582@yorick.bic.mni.mcgill.ca>

Hello Andrew,

Thanks for your help.
Well, it somehow changed the outcome, so I guess there was a progress, but
it gives more lines of errors.

I cannot copy and paste all of it, but the followings are a fraction of
the messages.

ursula:/usr/local/mni/data/jihyun/mincrealign/RMS/src# gcc RMS.c
-L/usr/local/mni/lib -I/usr/local/mni/include -lvolume_io -lminc -lm
/usr/local/mni/lib/libvolume_io.a(input_mnc.o)(.text+0xf): In function
`get_minc_file_n_dimensions':
volume_io/Volumes/input_mnc.c:55: undefined reference to `ncopts'
/usr/local/mni/lib/libvolume_io.a(input_mnc.o)(.text+0x50):volume_io/Volumes/input_mnc.c:72:
undefined reference to `ncvarid'
/usr/local/mni/lib/libvolume_io.a(input_mnc.o)(.text+0x86):volume_io/Volumes/input_mnc.c:74:
undefined reference to `ncvarinq'
/usr/local/mni/lib/libvolume_io.a(input_mnc.o)(.text+0x178): In function
`initialize_minc_input_from_minc_id':

Thanks,

Ji Hyun


On Wed, 28 Nov 2007, Andrew Janke wrote:

> Hi Ji,
>
> I have no idea what RMS.c or mincrealign are but it looks to me that
> you are missing the minc/volume_io libraries.
>
> This should work:
>
>    gcc RMS.c -L/usr/local/mni/lib -I/usr/local/mni/include -lvolume_io
> -lminc -lm
>
> Presuming of course that RMS.c is the main C program (has a main() in it).
>
> a
>
>
> On Nov 28, 2007 10:12 AM, Ji Hyum KO <kojinet at bic.mni.mcgill.ca> wrote:
> > Hello,
> >
> > I am trying to compile RMS.c to mincrealign with option of -target_for_RMS
> > of MRI file.
> >
> > I think I have all the necessary header files, ie., volume_io.h and etc,
> > but it gives me the following errors when I tried to compile it.
> > My gcc version is 3.3.5 (Debian).
> >
> > Could anybody help me?
> >
> > ursula:/usr/local/mni/data/jihyun/mincrealign/RMS/src# gcc RMS.c
> > -I/usr/local/mni/include/
> > /tmp/ccIcUkSO.o(.text+0x66): In function `main':
> > : undefined reference to `input_volume'
> > /tmp/ccIcUkSO.o(.text+0x8e): In function `main':
> > : undefined reference to `get_volume_sizes'
> > /tmp/ccIcUkSO.o(.text+0xa8): In function `main':
> > : undefined reference to `input_transform_file'
> > /tmp/ccIcUkSO.o(.text+0x141): In function `main':
> > : undefined reference to `get_cached_volume_voxel'
> > /tmp/ccIcUkSO.o(.text+0x376): In function `main':
> > : undefined reference to `convert_voxel_to_value'
> > /tmp/ccIcUkSO.o(.text+0x3c9): In function `main':
> > : undefined reference to `convert_3D_voxel_to_world'
> > /tmp/ccIcUkSO.o(.text+0x401): In function `main':
> > : undefined reference to `general_inverse_transform_point'
> > /tmp/ccIcUkSO.o(.text+0x419): In function `main':
> > : undefined reference to `pow'
> > /tmp/ccIcUkSO.o(.text+0x437): In function `main':
> > : undefined reference to `pow'
> > /tmp/ccIcUkSO.o(.text+0x45d): In function `main':
> > : undefined reference to `pow'
> > /tmp/ccIcUkSO.o(.text+0x4a1): In function `main':
> > : undefined reference to `sqrt'
> > collect2: ld returned 1 exit status
> >
> > Thanks,
> >
> > Ji Hyun
> >
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
>
>
>
> --
> Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia    +61 (402) 700 883
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From a.janke at gmail.com  Tue Nov 27 19:27:56 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 28 Nov 2007 11:27:56 +1100
Subject: [MINC-users] compiling RMS.c for mincrealign
In-Reply-To: <Pine.SGI.4.58.0711271854300.71806582@yorick.bic.mni.mcgill.ca>
References: <Pine.SGI.4.58.0711221915510.71049951@yorick.bic.mni.mcgill.ca>
	<48C3C974-11D2-4AC5-BB6B-900E7AE07421@bic.mni.mcgill.ca>
	<Pine.SGI.4.58.0711271806400.71539052@yorick.bic.mni.mcgill.ca>
	<d747ed50711271533q35ba12c9h2fa5132cbb384cf7@mail.gmail.com>
	<Pine.SGI.4.58.0711271854300.71806582@yorick.bic.mni.mcgill.ca>
Message-ID: <d747ed50711271627j474b3b4eve05c135b39708e1a@mail.gmail.com>

> Thanks for your help.
> Well, it somehow changed the outcome, so I guess there was a progress, but
> it gives more lines of errors.

I forgot netcdf...

 gcc RMS.c -L/usr/local/mni/lib -I/usr/local/mni/include -lvolume_io
-lminc -lnetcdf -lm



a

From kojinet at bic.mni.mcgill.ca  Tue Nov 27 19:41:17 2007
From: kojinet at bic.mni.mcgill.ca (Ji Hyum KO)
Date: Tue, 27 Nov 2007 19:41:17 -0500
Subject: [MINC-users] compiling RMS.c for mincrealign
In-Reply-To: <d747ed50711271627j474b3b4eve05c135b39708e1a@mail.gmail.com>
References: <Pine.SGI.4.58.0711221915510.71049951@yorick.bic.mni.mcgill.ca>
	<48C3C974-11D2-4AC5-BB6B-900E7AE07421@bic.mni.mcgill.ca>
	<Pine.SGI.4.58.0711271806400.71539052@yorick.bic.mni.mcgill.ca>
	<d747ed50711271533q35ba12c9h2fa5132cbb384cf7@mail.gmail.com>
	<Pine.SGI.4.58.0711271854300.71806582@yorick.bic.mni.mcgill.ca>
	<d747ed50711271627j474b3b4eve05c135b39708e1a@mail.gmail.com>
Message-ID: <Pine.SGI.4.58.0711271940580.72266920@yorick.bic.mni.mcgill.ca>

Perfect!!
It worked!

Thank you so much!

Ji Hyun

On Wed, 28 Nov 2007, Andrew Janke wrote:

> > Thanks for your help.
> > Well, it somehow changed the outcome, so I guess there was a progress, but
> > it gives more lines of errors.
>
> I forgot netcdf...
>
>  gcc RMS.c -L/usr/local/mni/lib -I/usr/local/mni/include -lvolume_io
> -lminc -lnetcdf -lm
>
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>