From a.janke at gmail.com  Thu Mar  1 12:35:31 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 2 Mar 2012 03:35:31 +1000
Subject: [MINC-users] Problem building Display
In-Reply-To: <201202290440.q1T4eHPg029639@cassio.bic.mni.mcgill.ca>
References: <CAE1j2uh3CkP6bogb6iQ4EqdHW7fxWMUidRvfMMsxOg_6vD8u7A@mail.gmail.com>
	<201202290440.q1T4eHPg029639@cassio.bic.mni.mcgill.ca>
Message-ID: <CAG0CB20ZhZ9zATzP5z_UbO-0mKmgFwShfgy9pgAdnmNCLfecGg@mail.gmail.com>

On 29 February 2012 14:40, Claude LEPAGE <claude at bic.mni.mcgill.ca> wrote:
> This is probably the known bug that Andrew and I know how to
> fix but haven't taken the time to do so.

Probably guilty as charged, but from what I can see this "bug" is not
a bug in minc, it seems to be in libtool.

I'd be very curious to know if running

   $ libtoolize --automake --copy

In the Display directory and then re-running:

   $ ./autogen.sh

and

   $ ./configure --with-build-path=/usr/local/bic ...

fixes things.

ta


a

From assemlal at cim.mcgill.ca  Thu Mar  1 13:29:33 2012
From: assemlal at cim.mcgill.ca (Haz-Edine Assemlal)
Date: Thu, 01 Mar 2012 13:29:33 -0500
Subject: [MINC-users] Problem building Display
In-Reply-To: <CAG0CB20ZhZ9zATzP5z_UbO-0mKmgFwShfgy9pgAdnmNCLfecGg@mail.gmail.com>
References: <CAE1j2uh3CkP6bogb6iQ4EqdHW7fxWMUidRvfMMsxOg_6vD8u7A@mail.gmail.com>
	<201202290440.q1T4eHPg029639@cassio.bic.mni.mcgill.ca>
	<CAG0CB20ZhZ9zATzP5z_UbO-0mKmgFwShfgy9pgAdnmNCLfecGg@mail.gmail.com>
Message-ID: <1330626573.4435.27.camel@talos>

Hi,

Alternatively, I've been working a bit on Display recently. You are
welcome give it a try. The latest version is using CMake in place of
autotools:

https://github.com/hassemlal/Display/tags

Haz-Edine



On Fri, 2012-03-02 at 03:35 +1000, Andrew Janke wrote:
> On 29 February 2012 14:40, Claude LEPAGE <claude at bic.mni.mcgill.ca> wrote:
> > This is probably the known bug that Andrew and I know how to
> > fix but haven't taken the time to do so.
> 
> Probably guilty as charged, but from what I can see this "bug" is not
> a bug in minc, it seems to be in libtool.
> 
> I'd be very curious to know if running
> 
>    $ libtoolize --automake --copy
> 
> In the Display directory and then re-running:
> 
>    $ ./autogen.sh
> 
> and
> 
>    $ ./configure --with-build-path=/usr/local/bic ...
> 
> fixes things.
> 
> ta
> 
> 
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users



From maudette at odu.edu  Thu Mar  1 16:21:39 2012
From: maudette at odu.edu (Audette, Michel A.)
Date: Thu, 1 Mar 2012 16:21:39 -0500
Subject: [MINC-users] Problem building Display
In-Reply-To: <1330626573.4435.27.camel@talos>
References: <CAE1j2uh3CkP6bogb6iQ4EqdHW7fxWMUidRvfMMsxOg_6vD8u7A@mail.gmail.com>
	<201202290440.q1T4eHPg029639@cassio.bic.mni.mcgill.ca>
	<CAG0CB20ZhZ9zATzP5z_UbO-0mKmgFwShfgy9pgAdnmNCLfecGg@mail.gmail.com>,
	<1330626573.4435.27.camel@talos>
Message-ID: <5D094B4A0B15E441811066CCC54AE4FC20BEAA230F@MUFASA.ts.odu.edu>

Hi Haz-Edine, 

we're trying your solution, but we're having a build problem... 
Linking C executable Display
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2dimdef'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_get'
/usr/local/lib/libvolume_io2.so: undefined reference to `miattputdbl'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_free'
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2varinq'
/usr/local/lib/libvolume_io2.so: undefined reference to `miattgetstr'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_put'
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2attput'
/usr/local/lib/libvolume_io2.so: undefined reference to `miget_valid_range'
/usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_var_values'
/usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_atts'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_inqdbl'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_detach'
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2attinq'
/usr/local/lib/libvolume_io2.so: undefined reference to `mivarput'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setint'
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2endef'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setdbl'
/usr/local/lib/libvolume_io2.so: undefined reference to `miattget'
/usr/local/lib/libvolume_io2.so: undefined reference to `miclose'
/usr/local/lib/libvolume_io2.so: undefined reference to `mivarput1'
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2attdel'
/usr/local/lib/libvolume_io2.so: undefined reference to `micreate_std_variable'
/usr/local/lib/libvolume_io2.so: undefined reference to `micreate'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setstr'
/usr/local/lib/libvolume_io2.so: undefined reference to `miattputstr'
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2varid'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_create'
/usr/local/lib/libvolume_io2.so: undefined reference to `micreate_tempfile'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_attach'
/usr/local/lib/libvolume_io2.so: undefined reference to `mivarget'
/usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_var_defs'
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2diminq'
/usr/local/lib/libvolume_io2.so: undefined reference to `miset_valid_range'
/usr/local/lib/libvolume_io2.so: undefined reference to `miattget1'
/usr/local/lib/libvolume_io2.so: undefined reference to `miopen'
collect2: ld returned 1 exit status

I've tried both static and shared minc2 libraries. We're using ccmake as follows...

 MINC_INCLUDE_DIR                 /usr/local/include                                                                                                                                     
 MINC_minc2_LIBRARY               /usr/local/lib/libminc2.a                                                                                                                              
 MINC_volume_io2_LIBRARY          /usr/local/lib/libvolume_io2.so                                                                                                                        

Thanks for your kind support.

Michel

Michel Audette, Ph.D.
Assistant Professor,
Department of Modeling, Simulation and Visualization Engineering,
Old Dominion University,
Norfolk, VA.
________________________________________
From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Haz-Edine Assemlal [assemlal at cim.mcgill.ca]
Sent: Thursday, March 01, 2012 1:29 PM
To: MINC users mailing list
Subject: Re: [MINC-users] Problem building Display

Hi,

Alternatively, I've been working a bit on Display recently. You are
welcome give it a try. The latest version is using CMake in place of
autotools:

https://github.com/hassemlal/Display/tags

Haz-Edine



On Fri, 2012-03-02 at 03:35 +1000, Andrew Janke wrote:
> On 29 February 2012 14:40, Claude LEPAGE <claude at bic.mni.mcgill.ca> wrote:
> > This is probably the known bug that Andrew and I know how to
> > fix but haven't taken the time to do so.
>
> Probably guilty as charged, but from what I can see this "bug" is not
> a bug in minc, it seems to be in libtool.
>
> I'd be very curious to know if running
>
>    $ libtoolize --automake --copy
>
> In the Display directory and then re-running:
>
>    $ ./autogen.sh
>
> and
>
>    $ ./configure --with-build-path=/usr/local/bic ...
>
> fixes things.
>
> ta
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


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


--
BEGIN-ANTISPAM-VOTING-LINKS
------------------------------------------------------

Teach CanIt if this mail (ID 621880803) is spam:
Spam:        https://www.spamtrap.odu.edu/b.php?i=621880803&m=d6984ee8f895&t=20120301&c=s
Not spam:    https://www.spamtrap.odu.edu/b.php?i=621880803&m=d6984ee8f895&t=20120301&c=n
Forget vote: https://www.spamtrap.odu.edu/b.php?i=621880803&m=d6984ee8f895&t=20120301&c=f
------------------------------------------------------
END-ANTISPAM-VOTING-LINKS


From assemlal at cim.mcgill.ca  Thu Mar  1 17:04:19 2012
From: assemlal at cim.mcgill.ca (Haz-Edine Assemlal)
Date: Thu, 01 Mar 2012 17:04:19 -0500
Subject: [MINC-users] Problem building Display
In-Reply-To: <5D094B4A0B15E441811066CCC54AE4FC20BEAA230F@MUFASA.ts.odu.edu>
References: <CAE1j2uh3CkP6bogb6iQ4EqdHW7fxWMUidRvfMMsxOg_6vD8u7A@mail.gmail.com>
	<201202290440.q1T4eHPg029639@cassio.bic.mni.mcgill.ca>
	<CAG0CB20ZhZ9zATzP5z_UbO-0mKmgFwShfgy9pgAdnmNCLfecGg@mail.gmail.com>
	, <1330626573.4435.27.camel@talos>
	<5D094B4A0B15E441811066CCC54AE4FC20BEAA230F@MUFASA.ts.odu.edu>
Message-ID: <1330639459.4435.42.camel@talos>

Hi Audette,

This error is typical of incoherency between the header and the shared
library. Maybe you have two MINC2 libraries (maybe headers only)
installed in your system.

Can you go the Display source directory and do:
$ make clean
$ make VERBOSE=1

and send me the output.

Thanks,
Haz-Edine


On Thu, 2012-03-01 at 16:21 -0500, Audette, Michel A. wrote:
> Hi Haz-Edine, 
> 
> we're trying your solution, but we're having a build problem... 
> Linking C executable Display
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2dimdef'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_get'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattputdbl'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_free'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varinq'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattgetstr'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_put'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attput'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miget_valid_range'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_var_values'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_atts'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_inqdbl'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_detach'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attinq'
> /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setint'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2endef'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setdbl'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattget'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miclose'
> /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput1'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attdel'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micreate_std_variable'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micreate'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setstr'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattputstr'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varid'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_create'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micreate_tempfile'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_attach'
> /usr/local/lib/libvolume_io2.so: undefined reference to `mivarget'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_var_defs'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2diminq'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miset_valid_range'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattget1'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miopen'
> collect2: ld returned 1 exit status
> 
> I've tried both static and shared minc2 libraries. We're using ccmake as follows...
> 
>  MINC_INCLUDE_DIR                 /usr/local/include                                                                                                                                     
>  MINC_minc2_LIBRARY               /usr/local/lib/libminc2.a                                                                                                                              
>  MINC_volume_io2_LIBRARY          /usr/local/lib/libvolume_io2.so                                                                                                                        
> 
> Thanks for your kind support.
> 
> Michel
> 
> Michel Audette, Ph.D.
> Assistant Professor,
> Department of Modeling, Simulation and Visualization Engineering,
> Old Dominion University,
> Norfolk, VA.
> ________________________________________
> From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Haz-Edine Assemlal [assemlal at cim.mcgill.ca]
> Sent: Thursday, March 01, 2012 1:29 PM
> To: MINC users mailing list
> Subject: Re: [MINC-users] Problem building Display
> 
> Hi,
> 
> Alternatively, I've been working a bit on Display recently. You are
> welcome give it a try. The latest version is using CMake in place of
> autotools:
> 
> https://github.com/hassemlal/Display/tags
> 
> Haz-Edine
> 
> 
> 
> On Fri, 2012-03-02 at 03:35 +1000, Andrew Janke wrote:
> > On 29 February 2012 14:40, Claude LEPAGE <claude at bic.mni.mcgill.ca> wrote:
> > > This is probably the known bug that Andrew and I know how to
> > > fix but haven't taken the time to do so.
> >
> > Probably guilty as charged, but from what I can see this "bug" is not
> > a bug in minc, it seems to be in libtool.
> >
> > I'd be very curious to know if running
> >
> >    $ libtoolize --automake --copy
> >
> > In the Display directory and then re-running:
> >
> >    $ ./autogen.sh
> >
> > and
> >
> >    $ ./configure --with-build-path=/usr/local/bic ...
> >
> > fixes things.
> >
> > ta
> >
> >
> > a
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> 
> 
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> 
> 
> --
> BEGIN-ANTISPAM-VOTING-LINKS
> ------------------------------------------------------
> 
> Teach CanIt if this mail (ID 621880803) is spam:
> Spam:        https://www.spamtrap.odu.edu/b.php?i=621880803&m=d6984ee8f895&t=20120301&c=s
> Not spam:    https://www.spamtrap.odu.edu/b.php?i=621880803&m=d6984ee8f895&t=20120301&c=n
> Forget vote: https://www.spamtrap.odu.edu/b.php?i=621880803&m=d6984ee8f895&t=20120301&c=f
> ------------------------------------------------------
> END-ANTISPAM-VOTING-LINKS
> 
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users



From maudette at odu.edu  Thu Mar  1 18:37:12 2012
From: maudette at odu.edu (Audette, Michel A.)
Date: Thu, 1 Mar 2012 18:37:12 -0500
Subject: [MINC-users] Problem building Display
In-Reply-To: <1330639459.4435.42.camel@talos>
References: <CAE1j2uh3CkP6bogb6iQ4EqdHW7fxWMUidRvfMMsxOg_6vD8u7A@mail.gmail.com>
	<201202290440.q1T4eHPg029639@cassio.bic.mni.mcgill.ca>
	<CAG0CB20ZhZ9zATzP5z_UbO-0mKmgFwShfgy9pgAdnmNCLfecGg@mail.gmail.com>	, 
	<1330626573.4435.27.camel@talos>
	<5D094B4A0B15E441811066CCC54AE4FC20BEAA230F@MUFASA.ts.odu.edu>,
	<1330639459.4435.42.camel@talos>
Message-ID: <5D094B4A0B15E441811066CCC54AE4FC20BEAA2317@MUFASA.ts.odu.edu>

Hi Haz-edine, 

I'll ask my student Tanweer to get in touch with you with this output. 

Thanks for your kind support. 

Michel
Michel Audette, Ph.D.
Assistant Professor,
Department of Modeling, Simulation and Visualization Engineering,
Old Dominion University,
Norfolk, VA.
________________________________________
From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Haz-Edine Assemlal [assemlal at cim.mcgill.ca]
Sent: Thursday, March 01, 2012 5:04 PM
To: MINC users mailing list
Subject: Re: [MINC-users] Problem building Display

Hi Audette,

This error is typical of incoherency between the header and the shared
library. Maybe you have two MINC2 libraries (maybe headers only)
installed in your system.

Can you go the Display source directory and do:
$ make clean
$ make VERBOSE=1

and send me the output.

Thanks,
Haz-Edine


On Thu, 2012-03-01 at 16:21 -0500, Audette, Michel A. wrote:
> Hi Haz-Edine,
>
> we're trying your solution, but we're having a build problem...
> Linking C executable Display
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2dimdef'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_get'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattputdbl'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_free'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varinq'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattgetstr'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_put'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attput'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miget_valid_range'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_var_values'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_atts'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_inqdbl'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_detach'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attinq'
> /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setint'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2endef'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setdbl'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattget'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miclose'
> /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput1'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attdel'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micreate_std_variable'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micreate'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setstr'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattputstr'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varid'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_create'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micreate_tempfile'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_attach'
> /usr/local/lib/libvolume_io2.so: undefined reference to `mivarget'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_var_defs'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2diminq'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miset_valid_range'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattget1'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miopen'
> collect2: ld returned 1 exit status
>
> I've tried both static and shared minc2 libraries. We're using ccmake as follows...
>
>  MINC_INCLUDE_DIR                 /usr/local/include
>  MINC_minc2_LIBRARY               /usr/local/lib/libminc2.a
>  MINC_volume_io2_LIBRARY          /usr/local/lib/libvolume_io2.so
>
> Thanks for your kind support.
>
> Michel
>
> Michel Audette, Ph.D.
> Assistant Professor,
> Department of Modeling, Simulation and Visualization Engineering,
> Old Dominion University,
> Norfolk, VA.
> ________________________________________
> From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Haz-Edine Assemlal [assemlal at cim.mcgill.ca]
> Sent: Thursday, March 01, 2012 1:29 PM
> To: MINC users mailing list
> Subject: Re: [MINC-users] Problem building Display
>
> Hi,
>
> Alternatively, I've been working a bit on Display recently. You are
> welcome give it a try. The latest version is using CMake in place of
> autotools:
>
> https://github.com/hassemlal/Display/tags
>
> Haz-Edine
>
>
>
> On Fri, 2012-03-02 at 03:35 +1000, Andrew Janke wrote:
> > On 29 February 2012 14:40, Claude LEPAGE <claude at bic.mni.mcgill.ca> wrote:
> > > This is probably the known bug that Andrew and I know how to
> > > fix but haven't taken the time to do so.
> >
> > Probably guilty as charged, but from what I can see this "bug" is not
> > a bug in minc, it seems to be in libtool.
> >
> > I'd be very curious to know if running
> >
> >    $ libtoolize --automake --copy
> >
> > In the Display directory and then re-running:
> >
> >    $ ./autogen.sh
> >
> > and
> >
> >    $ ./configure --with-build-path=/usr/local/bic ...
> >
> > fixes things.
> >
> > ta
> >
> >
> > a
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>
> --
>
> _______________________________________________
> 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


--
BEGIN-ANTISPAM-VOTING-LINKS
------------------------------------------------------

Teach CanIt if this mail (ID 621969739) is spam:
Spam:        https://www.spamtrap.odu.edu/b.php?i=621969739&m=b64baa469f6e&t=20120301&c=s
Not spam:    https://www.spamtrap.odu.edu/b.php?i=621969739&m=b64baa469f6e&t=20120301&c=n
Forget vote: https://www.spamtrap.odu.edu/b.php?i=621969739&m=b64baa469f6e&t=20120301&c=f
------------------------------------------------------
END-ANTISPAM-VOTING-LINKS


From trash001 at odu.edu  Fri Mar  2 13:12:18 2012
From: trash001 at odu.edu (Tanweer Rashid)
Date: Fri, 2 Mar 2012 13:12:18 -0500
Subject: [MINC-users] Problem building Display
In-Reply-To: <5D094B4A0B15E441811066CCC54AE4FC20BEAA2317@MUFASA.ts.odu.edu>
References: <CAE1j2uh3CkP6bogb6iQ4EqdHW7fxWMUidRvfMMsxOg_6vD8u7A@mail.gmail.com>
	<201202290440.q1T4eHPg029639@cassio.bic.mni.mcgill.ca>
	<CAG0CB20ZhZ9zATzP5z_UbO-0mKmgFwShfgy9pgAdnmNCLfecGg@mail.gmail.com>
	<1330626573.4435.27.camel@talos>
	<5D094B4A0B15E441811066CCC54AE4FC20BEAA230F@MUFASA.ts.odu.edu>
	<1330639459.4435.42.camel@talos>
	<5D094B4A0B15E441811066CCC54AE4FC20BEAA2317@MUFASA.ts.odu.edu>
Message-ID: <CAE1j2uj2d4bSqbkddq6qHAKkwPtOXgaBq4pWsKn23+9g1Hd8vA@mail.gmail.com>

Hi,

I did have two minc2 libs, but I removed one of them, and after that, this
is what we're seeing...


trash001 at ubuntu:~/Desktop/hassemlal-Display-305f573Build$ make clean
trash001 at ubuntu:~/Desktop/hassemlal-Display-305f573Build$ make VERBOSE=1
/usr/bin/cmake -H/home/trash001/Desktop/hassemlal-Display-305f573
-B/home/trash001/Desktop/hassemlal-Display-305f573Build
--check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start
/home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles
/home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory
`/home/trash001/Desktop/hassemlal-Display-305f573Build'
make -f CMakeFiles/Display.dir/build.make CMakeFiles/Display.dir/depend
make[2]: Entering directory
`/home/trash001/Desktop/hassemlal-Display-305f573Build'
cd /home/trash001/Desktop/hassemlal-Display-305f573Build && /usr/bin/cmake
-E cmake_depends "Unix Makefiles"
/home/trash001/Desktop/hassemlal-Display-305f573
/home/trash001/Desktop/hassemlal-Display-305f573
/home/trash001/Desktop/hassemlal-Display-305f573Build
/home/trash001/Desktop/hassemlal-Display-305f573Build
/home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles/Display.dir/DependInfo.cmake
--color=
make[2]: Leaving directory
`/home/trash001/Desktop/hassemlal-Display-305f573Build'
make -f CMakeFiles/Display.dir/build.make CMakeFiles/Display.dir/build
make[2]: Entering directory
`/home/trash001/Desktop/hassemlal-Display-305f573Build'
/usr/bin/cmake -E cmake_progress_report
/home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles
[  0%] Building C object CMakeFiles/Display.dir/atlas/atlas.c.o
/usr/bin/gcc  -DMINC2
-I/home/trash001/Desktop/hassemlal-Display-305f573Build
-I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/OpenGL_graphics/Include
-I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/Include
-I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/GLUT_windows/Include
-I/home/trash001/Desktop/hassemlal-Display-305f573/Include
-I/usr/local/include    -o CMakeFiles/Display.dir/atlas/atlas.c.o   -c
/home/trash001/Desktop/hassemlal-Display-305f573/atlas/atlas.c
/usr/bin/cmake -E cmake_progress_report
/home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles 1

...

[100%] Building C object CMakeFiles/Display.dir/dummy.c.o
/usr/bin/gcc  -DMINC2
-I/home/trash001/Desktop/hassemlal-Display-305f573Build
-I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/OpenGL_graphics/Include
-I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/Include
-I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/GLUT_windows/Include
-I/home/trash001/Desktop/hassemlal-Display-305f573/Include
-I/usr/local/include    -o CMakeFiles/Display.dir/dummy.c.o   -c
/home/trash001/Desktop/hassemlal-Display-305f573/dummy.c
Linking C executable Display
/usr/bin/cmake -E cmake_link_script CMakeFiles/Display.dir/link.txt
--verbose=1
/usr/bin/gcc      CMakeFiles/Display.dir/atlas/atlas.c.o
CMakeFiles/Display.dir/input_files/input_files.c.o
CMakeFiles/Display.dir/input_files/volume_file.c.o
CMakeFiles/Display.dir/tubes/convert_lines.c.o
CMakeFiles/Display.dir/callbacks/volume_ops.c.o
CMakeFiles/Display.dir/callbacks/surf_segmenting.c.o
CMakeFiles/Display.dir/callbacks/file.c.o
CMakeFiles/Display.dir/callbacks/view_ops.c.o
CMakeFiles/Display.dir/callbacks/regions.c.o
CMakeFiles/Display.dir/callbacks/polygon_ops.c.o
CMakeFiles/Display.dir/callbacks/surface_curves.c.o
CMakeFiles/Display.dir/callbacks/call_globals.c.o
CMakeFiles/Display.dir/callbacks/quit.c.o
CMakeFiles/Display.dir/callbacks/marker_ops.c.o
CMakeFiles/Display.dir/callbacks/colour_coding.c.o
CMakeFiles/Display.dir/callbacks/render_ops.c.o
CMakeFiles/Display.dir/callbacks/segmenting.c.o
CMakeFiles/Display.dir/callbacks/atlas.c.o
CMakeFiles/Display.dir/callbacks/object_ops.c.o
CMakeFiles/Display.dir/callbacks/surface_extract.c.o
CMakeFiles/Display.dir/callbacks/line_ops.c.o
CMakeFiles/Display.dir/callbacks/volume_transform_ops.c.o
CMakeFiles/Display.dir/callbacks/georges.c.o
CMakeFiles/Display.dir/main/event_loop.c.o
CMakeFiles/Display.dir/main/transforms.c.o
CMakeFiles/Display.dir/main/three_d.c.o
CMakeFiles/Display.dir/main/graphics.c.o
CMakeFiles/Display.dir/main/display.c.o
CMakeFiles/Display.dir/main/main.c.o
CMakeFiles/Display.dir/cursor_contours/contours.c.o
CMakeFiles/Display.dir/markers/markers.c.o
CMakeFiles/Display.dir/images/images.c.o
CMakeFiles/Display.dir/segmenting/segment_polygons.c.o
CMakeFiles/Display.dir/segmenting/painting.c.o
CMakeFiles/Display.dir/segmenting/segmenting.c.o
CMakeFiles/Display.dir/segmenting/cut_neighbours.c.o
CMakeFiles/Display.dir/menu/text.c.o
CMakeFiles/Display.dir/menu/build_menu.c.o
CMakeFiles/Display.dir/menu/selected.c.o
CMakeFiles/Display.dir/menu/cursor_pos.c.o
CMakeFiles/Display.dir/menu/input_menu.c.o
CMakeFiles/Display.dir/menu/menu.c.o
CMakeFiles/Display.dir/structures/fit_view.c.o
CMakeFiles/Display.dir/structures/action_table.c.o
CMakeFiles/Display.dir/structures/lights.c.o
CMakeFiles/Display.dir/structures/window.c.o
CMakeFiles/Display.dir/structures/render.c.o
CMakeFiles/Display.dir/structures/view.c.o
CMakeFiles/Display.dir/voxel_scan/scan_objects.c.o
CMakeFiles/Display.dir/surface_extraction/surface.c.o
CMakeFiles/Display.dir/surface_extraction/extract.c.o
CMakeFiles/Display.dir/surface_extraction/surface_events.c.o
CMakeFiles/Display.dir/surface_extraction/init_surface.c.o
CMakeFiles/Display.dir/surface_extraction/data_structs.c.o
CMakeFiles/Display.dir/surface_extraction/boundary_extraction.c.o
CMakeFiles/Display.dir/immediate_mode/draw_immed.c.o
CMakeFiles/Display.dir/cursor/cursor_icon.c.o
CMakeFiles/Display.dir/cursor/cursor.c.o
CMakeFiles/Display.dir/Graphics/G_graphics/event_loop.c.o
CMakeFiles/Display.dir/Graphics/G_graphics/lights.c.o
CMakeFiles/Display.dir/Graphics/G_graphics/draw_objects.c.o
CMakeFiles/Display.dir/Graphics/G_graphics/windows.c.o
CMakeFiles/Display.dir/Graphics/G_graphics/graphics_structs.c.o
CMakeFiles/Display.dir/Graphics/G_graphics/render.c.o
CMakeFiles/Display.dir/Graphics/G_graphics/draw.c.o
CMakeFiles/Display.dir/Graphics/G_graphics/view.c.o
CMakeFiles/Display.dir/Graphics/G_graphics/random_order.c.o
CMakeFiles/Display.dir/Graphics/GLUT_windows/glut_windows.c.o
CMakeFiles/Display.dir/Graphics/GLUT_windows/copy_x_colours.c.o
CMakeFiles/Display.dir/Graphics/dummy.c.o
CMakeFiles/Display.dir/Graphics/OpenGL_graphics/event_loop.c.o
CMakeFiles/Display.dir/Graphics/OpenGL_graphics/lights.c.o
CMakeFiles/Display.dir/Graphics/OpenGL_graphics/windows.c.o
CMakeFiles/Display.dir/Graphics/OpenGL_graphics/colour_def.c.o
CMakeFiles/Display.dir/Graphics/OpenGL_graphics/render.c.o
CMakeFiles/Display.dir/Graphics/OpenGL_graphics/draw.c.o
CMakeFiles/Display.dir/Graphics/OpenGL_graphics/view.c.o
CMakeFiles/Display.dir/edit_surface/segment.c.o
CMakeFiles/Display.dir/edit_surface/connected.c.o
CMakeFiles/Display.dir/edit_surface/edit.c.o
CMakeFiles/Display.dir/surface_curves/edge_distance.c.o
CMakeFiles/Display.dir/surface_curves/closest_line.c.o
CMakeFiles/Display.dir/surface_curves/events.c.o
CMakeFiles/Display.dir/current_obj/current_obj.c.o
CMakeFiles/Display.dir/intersect/ray_polygons.c.o
CMakeFiles/Display.dir/intersect/plane_polygons.c.o
CMakeFiles/Display.dir/events/mouse.c.o
CMakeFiles/Display.dir/events/utilities.c.o
CMakeFiles/Display.dir/events/clip_plane.c.o
CMakeFiles/Display.dir/events/rotate_slice.c.o
CMakeFiles/Display.dir/events/mouse_trans.c.o
CMakeFiles/Display.dir/events/magnify.c.o
CMakeFiles/Display.dir/events/change_markers.c.o
CMakeFiles/Display.dir/events/pick_object.c.o
CMakeFiles/Display.dir/events/virt_sb.c.o
CMakeFiles/Display.dir/events/pick_view.c.o
CMakeFiles/Display.dir/events/window_man.c.o
CMakeFiles/Display.dir/events/spaceball.c.o
CMakeFiles/Display.dir/events/film_loop.c.o
CMakeFiles/Display.dir/slice_window/slice_3d.c.o
CMakeFiles/Display.dir/slice_window/slice_events.c.o
CMakeFiles/Display.dir/slice_window/quadmesh.c.o
CMakeFiles/Display.dir/slice_window/pick_angle.c.o
CMakeFiles/Display.dir/slice_window/slice.c.o
CMakeFiles/Display.dir/slice_window/colour_coding.c.o
CMakeFiles/Display.dir/slice_window/crop.c.o
CMakeFiles/Display.dir/slice_window/histogram.c.o
CMakeFiles/Display.dir/slice_window/colour_bar.c.o
CMakeFiles/Display.dir/slice_window/undo.c.o
CMakeFiles/Display.dir/slice_window/draw_slice.c.o
CMakeFiles/Display.dir/slice_window/view.c.o
CMakeFiles/Display.dir/dummy.c.o  -o Display -rdynamic
/usr/local/lib/libminc2.so /usr/local/lib/libvolume_io2.so -lnetcdf
/usr/local/lib/libbicpl.a -lglut -lGL -Wl,-rpath,/usr/local/lib:
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2dimdef'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_get'
/usr/local/lib/libvolume_io2.so: undefined reference to `miattputdbl'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_free'
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2varinq'
/usr/local/lib/libvolume_io2.so: undefined reference to `miattgetstr'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_put'
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2attput'
/usr/local/lib/libvolume_io2.so: undefined reference to `miget_valid_range'
/usr/local/lib/libvolume_io2.so: undefined reference to
`micopy_all_var_values'
/usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_atts'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_inqdbl'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_detach'
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2attinq'
/usr/local/lib/libvolume_io2.so: undefined reference to `mivarput'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setint'
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2endef'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setdbl'
/usr/local/lib/libvolume_io2.so: undefined reference to `miattget'
/usr/local/lib/libvolume_io2.so: undefined reference to `miclose'
/usr/local/lib/libvolume_io2.so: undefined reference to `mivarput1'
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2attdel'
/usr/local/lib/libvolume_io2.so: undefined reference to
`micreate_std_variable'
/usr/local/lib/libvolume_io2.so: undefined reference to `micreate'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setstr'
/usr/local/lib/libvolume_io2.so: undefined reference to `miattputstr'
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2varid'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_create'
/usr/local/lib/libvolume_io2.so: undefined reference to `micreate_tempfile'
/usr/local/lib/libvolume_io2.so: undefined reference to `miicv_attach'
/usr/local/lib/libvolume_io2.so: undefined reference to `mivarget'
/usr/local/lib/libvolume_io2.so: undefined reference to
`micopy_all_var_defs'
/usr/local/lib/libvolume_io2.so: undefined reference to `MI2diminq'
/usr/local/lib/libvolume_io2.so: undefined reference to `miset_valid_range'
/usr/local/lib/libvolume_io2.so: undefined reference to `miattget1'
/usr/local/lib/libvolume_io2.so: undefined reference to `miopen'
collect2: ld returned 1 exit status


Thank you for your help.

- - - Tanweer Rashid


On Thu, Mar 1, 2012 at 6:37 PM, Audette, Michel A. <maudette at odu.edu> wrote:

> Hi Haz-edine,
>
> I'll ask my student Tanweer to get in touch with you with this output.
>
> Thanks for your kind support.
>
> Michel
> Michel Audette, Ph.D.
> Assistant Professor,
> Department of Modeling, Simulation and Visualization Engineering,
> Old Dominion University,
> Norfolk, VA.
> ________________________________________
> From: minc-users-bounces at bic.mni.mcgill.ca [
> minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Haz-Edine Assemlal [
> assemlal at cim.mcgill.ca]
> Sent: Thursday, March 01, 2012 5:04 PM
> To: MINC users mailing list
> Subject: Re: [MINC-users] Problem building Display
>
> Hi Audette,
>
> This error is typical of incoherency between the header and the shared
> library. Maybe you have two MINC2 libraries (maybe headers only)
> installed in your system.
>
> Can you go the Display source directory and do:
> $ make clean
> $ make VERBOSE=1
>
> and send me the output.
>
> Thanks,
> Haz-Edine
>
>
> On Thu, 2012-03-01 at 16:21 -0500, Audette, Michel A. wrote:
> > Hi Haz-Edine,
> >
> > we're trying your solution, but we're having a build problem...
> > Linking C executable Display
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2dimdef'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_get'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miattputdbl'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_free'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varinq'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miattgetstr'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_put'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attput'
> > /usr/local/lib/libvolume_io2.so: undefined reference to
> `miget_valid_range'
> > /usr/local/lib/libvolume_io2.so: undefined reference to
> `micopy_all_var_values'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_atts'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_inqdbl'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_detach'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attinq'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setint'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2endef'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setdbl'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miattget'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miclose'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput1'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attdel'
> > /usr/local/lib/libvolume_io2.so: undefined reference to
> `micreate_std_variable'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `micreate'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setstr'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miattputstr'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varid'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_create'
> > /usr/local/lib/libvolume_io2.so: undefined reference to
> `micreate_tempfile'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_attach'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `mivarget'
> > /usr/local/lib/libvolume_io2.so: undefined reference to
> `micopy_all_var_defs'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2diminq'
> > /usr/local/lib/libvolume_io2.so: undefined reference to
> `miset_valid_range'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miattget1'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miopen'
> > collect2: ld returned 1 exit status
> >
> > I've tried both static and shared minc2 libraries. We're using ccmake as
> follows...
> >
> >  MINC_INCLUDE_DIR                 /usr/local/include
> >  MINC_minc2_LIBRARY               /usr/local/lib/libminc2.a
> >  MINC_volume_io2_LIBRARY          /usr/local/lib/libvolume_io2.so
> >
> > Thanks for your kind support.
> >
> > Michel
> >
> > Michel Audette, Ph.D.
> > Assistant Professor,
> > Department of Modeling, Simulation and Visualization Engineering,
> > Old Dominion University,
> > Norfolk, VA.
> > ________________________________________
> > From: minc-users-bounces at bic.mni.mcgill.ca [
> minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Haz-Edine Assemlal [
> assemlal at cim.mcgill.ca]
> > Sent: Thursday, March 01, 2012 1:29 PM
> > To: MINC users mailing list
> > Subject: Re: [MINC-users] Problem building Display
> >
> > Hi,
> >
> > Alternatively, I've been working a bit on Display recently. You are
> > welcome give it a try. The latest version is using CMake in place of
> > autotools:
> >
> > https://github.com/hassemlal/Display/tags
> >
> > Haz-Edine
> >
> >
> >
> > On Fri, 2012-03-02 at 03:35 +1000, Andrew Janke wrote:
> > > On 29 February 2012 14:40, Claude LEPAGE <claude at bic.mni.mcgill.ca>
> wrote:
> > > > This is probably the known bug that Andrew and I know how to
> > > > fix but haven't taken the time to do so.
> > >
> > > Probably guilty as charged, but from what I can see this "bug" is not
> > > a bug in minc, it seems to be in libtool.
> > >
> > > I'd be very curious to know if running
> > >
> > >    $ libtoolize --automake --copy
> > >
> > > In the Display directory and then re-running:
> > >
> > >    $ ./autogen.sh
> > >
> > > and
> > >
> > >    $ ./configure --with-build-path=/usr/local/bic ...
> > >
> > > fixes things.
> > >
> > > ta
> > >
> > >
> > > a
> > > _______________________________________________
> > > MINC-users at bic.mni.mcgill.ca
> > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
> >
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
> >
> > --
> >
> > _______________________________________________
> > 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
>
>
> --
> BEGIN-ANTISPAM-VOTING-LINKS
> ------------------------------------------------------
>
> Teach CanIt if this mail (ID 621969739) is spam:
> Spam:
> https://www.spamtrap.odu.edu/b.php?i=621969739&m=b64baa469f6e&t=20120301&c=s
> Not spam:
> https://www.spamtrap.odu.edu/b.php?i=621969739&m=b64baa469f6e&t=20120301&c=n
> Forget vote:
> https://www.spamtrap.odu.edu/b.php?i=621969739&m=b64baa469f6e&t=20120301&c=f
> ------------------------------------------------------
> END-ANTISPAM-VOTING-LINKS
>
>


-- 
Tanweer Rashid
Graduate Teaching & Research Assistant
Department of Modeling, Simulation and Visualization Engineering
Old Dominion University

From assemlal at cim.mcgill.ca  Fri Mar  2 14:28:54 2012
From: assemlal at cim.mcgill.ca (Haz-Edine Assemlal)
Date: Fri, 02 Mar 2012 14:28:54 -0500
Subject: [MINC-users] Problem building Display
In-Reply-To: <CAE1j2uj2d4bSqbkddq6qHAKkwPtOXgaBq4pWsKn23+9g1Hd8vA@mail.gmail.com>
References: <CAE1j2uh3CkP6bogb6iQ4EqdHW7fxWMUidRvfMMsxOg_6vD8u7A@mail.gmail.com>
	<201202290440.q1T4eHPg029639@cassio.bic.mni.mcgill.ca>
	<CAG0CB20ZhZ9zATzP5z_UbO-0mKmgFwShfgy9pgAdnmNCLfecGg@mail.gmail.com>
	<1330626573.4435.27.camel@talos>
	<5D094B4A0B15E441811066CCC54AE4FC20BEAA230F@MUFASA.ts.odu.edu>
	<1330639459.4435.42.camel@talos>
	<5D094B4A0B15E441811066CCC54AE4FC20BEAA2317@MUFASA.ts.odu.edu>
	<CAE1j2uj2d4bSqbkddq6qHAKkwPtOXgaBq4pWsKn23+9g1Hd8vA@mail.gmail.com>
Message-ID: <1330716534.4435.55.camel@talos>

Hi Tanweer,

Which minc files did you remove from your system?

The simplest fix is to remove every files of the minc library and then
reinstall it.

Best,
Haz-Edine


On Fri, 2012-03-02 at 13:12 -0500, Tanweer Rashid wrote:
> Hi,
> 
> I did have two minc2 libs, but I removed one of them, and after that, this
> is what we're seeing...
> 
> 
> trash001 at ubuntu:~/Desktop/hassemlal-Display-305f573Build$ make clean
> trash001 at ubuntu:~/Desktop/hassemlal-Display-305f573Build$ make VERBOSE=1
> /usr/bin/cmake -H/home/trash001/Desktop/hassemlal-Display-305f573
> -B/home/trash001/Desktop/hassemlal-Display-305f573Build
> --check-build-system CMakeFiles/Makefile.cmake 0
> /usr/bin/cmake -E cmake_progress_start
> /home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles
> /home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles/progress.marks
> make -f CMakeFiles/Makefile2 all
> make[1]: Entering directory
> `/home/trash001/Desktop/hassemlal-Display-305f573Build'
> make -f CMakeFiles/Display.dir/build.make CMakeFiles/Display.dir/depend
> make[2]: Entering directory
> `/home/trash001/Desktop/hassemlal-Display-305f573Build'
> cd /home/trash001/Desktop/hassemlal-Display-305f573Build && /usr/bin/cmake
> -E cmake_depends "Unix Makefiles"
> /home/trash001/Desktop/hassemlal-Display-305f573
> /home/trash001/Desktop/hassemlal-Display-305f573
> /home/trash001/Desktop/hassemlal-Display-305f573Build
> /home/trash001/Desktop/hassemlal-Display-305f573Build
> /home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles/Display.dir/DependInfo.cmake
> --color=
> make[2]: Leaving directory
> `/home/trash001/Desktop/hassemlal-Display-305f573Build'
> make -f CMakeFiles/Display.dir/build.make CMakeFiles/Display.dir/build
> make[2]: Entering directory
> `/home/trash001/Desktop/hassemlal-Display-305f573Build'
> /usr/bin/cmake -E cmake_progress_report
> /home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles
> [  0%] Building C object CMakeFiles/Display.dir/atlas/atlas.c.o
> /usr/bin/gcc  -DMINC2
> -I/home/trash001/Desktop/hassemlal-Display-305f573Build
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/OpenGL_graphics/Include
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/Include
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/GLUT_windows/Include
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Include
> -I/usr/local/include    -o CMakeFiles/Display.dir/atlas/atlas.c.o   -c
> /home/trash001/Desktop/hassemlal-Display-305f573/atlas/atlas.c
> /usr/bin/cmake -E cmake_progress_report
> /home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles 1
> 
> ...
> 
> [100%] Building C object CMakeFiles/Display.dir/dummy.c.o
> /usr/bin/gcc  -DMINC2
> -I/home/trash001/Desktop/hassemlal-Display-305f573Build
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/OpenGL_graphics/Include
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/Include
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/GLUT_windows/Include
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Include
> -I/usr/local/include    -o CMakeFiles/Display.dir/dummy.c.o   -c
> /home/trash001/Desktop/hassemlal-Display-305f573/dummy.c
> Linking C executable Display
> /usr/bin/cmake -E cmake_link_script CMakeFiles/Display.dir/link.txt
> --verbose=1
> /usr/bin/gcc      CMakeFiles/Display.dir/atlas/atlas.c.o
> CMakeFiles/Display.dir/input_files/input_files.c.o
> CMakeFiles/Display.dir/input_files/volume_file.c.o
> CMakeFiles/Display.dir/tubes/convert_lines.c.o
> CMakeFiles/Display.dir/callbacks/volume_ops.c.o
> CMakeFiles/Display.dir/callbacks/surf_segmenting.c.o
> CMakeFiles/Display.dir/callbacks/file.c.o
> CMakeFiles/Display.dir/callbacks/view_ops.c.o
> CMakeFiles/Display.dir/callbacks/regions.c.o
> CMakeFiles/Display.dir/callbacks/polygon_ops.c.o
> CMakeFiles/Display.dir/callbacks/surface_curves.c.o
> CMakeFiles/Display.dir/callbacks/call_globals.c.o
> CMakeFiles/Display.dir/callbacks/quit.c.o
> CMakeFiles/Display.dir/callbacks/marker_ops.c.o
> CMakeFiles/Display.dir/callbacks/colour_coding.c.o
> CMakeFiles/Display.dir/callbacks/render_ops.c.o
> CMakeFiles/Display.dir/callbacks/segmenting.c.o
> CMakeFiles/Display.dir/callbacks/atlas.c.o
> CMakeFiles/Display.dir/callbacks/object_ops.c.o
> CMakeFiles/Display.dir/callbacks/surface_extract.c.o
> CMakeFiles/Display.dir/callbacks/line_ops.c.o
> CMakeFiles/Display.dir/callbacks/volume_transform_ops.c.o
> CMakeFiles/Display.dir/callbacks/georges.c.o
> CMakeFiles/Display.dir/main/event_loop.c.o
> CMakeFiles/Display.dir/main/transforms.c.o
> CMakeFiles/Display.dir/main/three_d.c.o
> CMakeFiles/Display.dir/main/graphics.c.o
> CMakeFiles/Display.dir/main/display.c.o
> CMakeFiles/Display.dir/main/main.c.o
> CMakeFiles/Display.dir/cursor_contours/contours.c.o
> CMakeFiles/Display.dir/markers/markers.c.o
> CMakeFiles/Display.dir/images/images.c.o
> CMakeFiles/Display.dir/segmenting/segment_polygons.c.o
> CMakeFiles/Display.dir/segmenting/painting.c.o
> CMakeFiles/Display.dir/segmenting/segmenting.c.o
> CMakeFiles/Display.dir/segmenting/cut_neighbours.c.o
> CMakeFiles/Display.dir/menu/text.c.o
> CMakeFiles/Display.dir/menu/build_menu.c.o
> CMakeFiles/Display.dir/menu/selected.c.o
> CMakeFiles/Display.dir/menu/cursor_pos.c.o
> CMakeFiles/Display.dir/menu/input_menu.c.o
> CMakeFiles/Display.dir/menu/menu.c.o
> CMakeFiles/Display.dir/structures/fit_view.c.o
> CMakeFiles/Display.dir/structures/action_table.c.o
> CMakeFiles/Display.dir/structures/lights.c.o
> CMakeFiles/Display.dir/structures/window.c.o
> CMakeFiles/Display.dir/structures/render.c.o
> CMakeFiles/Display.dir/structures/view.c.o
> CMakeFiles/Display.dir/voxel_scan/scan_objects.c.o
> CMakeFiles/Display.dir/surface_extraction/surface.c.o
> CMakeFiles/Display.dir/surface_extraction/extract.c.o
> CMakeFiles/Display.dir/surface_extraction/surface_events.c.o
> CMakeFiles/Display.dir/surface_extraction/init_surface.c.o
> CMakeFiles/Display.dir/surface_extraction/data_structs.c.o
> CMakeFiles/Display.dir/surface_extraction/boundary_extraction.c.o
> CMakeFiles/Display.dir/immediate_mode/draw_immed.c.o
> CMakeFiles/Display.dir/cursor/cursor_icon.c.o
> CMakeFiles/Display.dir/cursor/cursor.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/event_loop.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/lights.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/draw_objects.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/windows.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/graphics_structs.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/render.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/draw.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/view.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/random_order.c.o
> CMakeFiles/Display.dir/Graphics/GLUT_windows/glut_windows.c.o
> CMakeFiles/Display.dir/Graphics/GLUT_windows/copy_x_colours.c.o
> CMakeFiles/Display.dir/Graphics/dummy.c.o
> CMakeFiles/Display.dir/Graphics/OpenGL_graphics/event_loop.c.o
> CMakeFiles/Display.dir/Graphics/OpenGL_graphics/lights.c.o
> CMakeFiles/Display.dir/Graphics/OpenGL_graphics/windows.c.o
> CMakeFiles/Display.dir/Graphics/OpenGL_graphics/colour_def.c.o
> CMakeFiles/Display.dir/Graphics/OpenGL_graphics/render.c.o
> CMakeFiles/Display.dir/Graphics/OpenGL_graphics/draw.c.o
> CMakeFiles/Display.dir/Graphics/OpenGL_graphics/view.c.o
> CMakeFiles/Display.dir/edit_surface/segment.c.o
> CMakeFiles/Display.dir/edit_surface/connected.c.o
> CMakeFiles/Display.dir/edit_surface/edit.c.o
> CMakeFiles/Display.dir/surface_curves/edge_distance.c.o
> CMakeFiles/Display.dir/surface_curves/closest_line.c.o
> CMakeFiles/Display.dir/surface_curves/events.c.o
> CMakeFiles/Display.dir/current_obj/current_obj.c.o
> CMakeFiles/Display.dir/intersect/ray_polygons.c.o
> CMakeFiles/Display.dir/intersect/plane_polygons.c.o
> CMakeFiles/Display.dir/events/mouse.c.o
> CMakeFiles/Display.dir/events/utilities.c.o
> CMakeFiles/Display.dir/events/clip_plane.c.o
> CMakeFiles/Display.dir/events/rotate_slice.c.o
> CMakeFiles/Display.dir/events/mouse_trans.c.o
> CMakeFiles/Display.dir/events/magnify.c.o
> CMakeFiles/Display.dir/events/change_markers.c.o
> CMakeFiles/Display.dir/events/pick_object.c.o
> CMakeFiles/Display.dir/events/virt_sb.c.o
> CMakeFiles/Display.dir/events/pick_view.c.o
> CMakeFiles/Display.dir/events/window_man.c.o
> CMakeFiles/Display.dir/events/spaceball.c.o
> CMakeFiles/Display.dir/events/film_loop.c.o
> CMakeFiles/Display.dir/slice_window/slice_3d.c.o
> CMakeFiles/Display.dir/slice_window/slice_events.c.o
> CMakeFiles/Display.dir/slice_window/quadmesh.c.o
> CMakeFiles/Display.dir/slice_window/pick_angle.c.o
> CMakeFiles/Display.dir/slice_window/slice.c.o
> CMakeFiles/Display.dir/slice_window/colour_coding.c.o
> CMakeFiles/Display.dir/slice_window/crop.c.o
> CMakeFiles/Display.dir/slice_window/histogram.c.o
> CMakeFiles/Display.dir/slice_window/colour_bar.c.o
> CMakeFiles/Display.dir/slice_window/undo.c.o
> CMakeFiles/Display.dir/slice_window/draw_slice.c.o
> CMakeFiles/Display.dir/slice_window/view.c.o
> CMakeFiles/Display.dir/dummy.c.o  -o Display -rdynamic
> /usr/local/lib/libminc2.so /usr/local/lib/libvolume_io2.so -lnetcdf
> /usr/local/lib/libbicpl.a -lglut -lGL -Wl,-rpath,/usr/local/lib:
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2dimdef'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_get'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattputdbl'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_free'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varinq'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattgetstr'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_put'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attput'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miget_valid_range'
> /usr/local/lib/libvolume_io2.so: undefined reference to
> `micopy_all_var_values'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_atts'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_inqdbl'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_detach'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attinq'
> /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setint'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2endef'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setdbl'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattget'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miclose'
> /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput1'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attdel'
> /usr/local/lib/libvolume_io2.so: undefined reference to
> `micreate_std_variable'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micreate'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setstr'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattputstr'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varid'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_create'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micreate_tempfile'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_attach'
> /usr/local/lib/libvolume_io2.so: undefined reference to `mivarget'
> /usr/local/lib/libvolume_io2.so: undefined reference to
> `micopy_all_var_defs'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2diminq'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miset_valid_range'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattget1'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miopen'
> collect2: ld returned 1 exit status
> 
> 
> Thank you for your help.
> 
> - - - Tanweer Rashid
> 
> 
> On Thu, Mar 1, 2012 at 6:37 PM, Audette, Michel A. <maudette at odu.edu> wrote:
> 
> > Hi Haz-edine,
> >
> > I'll ask my student Tanweer to get in touch with you with this output.
> >
> > Thanks for your kind support.
> >
> > Michel
> > Michel Audette, Ph.D.
> > Assistant Professor,
> > Department of Modeling, Simulation and Visualization Engineering,
> > Old Dominion University,
> > Norfolk, VA.
> > ________________________________________
> > From: minc-users-bounces at bic.mni.mcgill.ca [
> > minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Haz-Edine Assemlal [
> > assemlal at cim.mcgill.ca]
> > Sent: Thursday, March 01, 2012 5:04 PM
> > To: MINC users mailing list
> > Subject: Re: [MINC-users] Problem building Display
> >
> > Hi Audette,
> >
> > This error is typical of incoherency between the header and the shared
> > library. Maybe you have two MINC2 libraries (maybe headers only)
> > installed in your system.
> >
> > Can you go the Display source directory and do:
> > $ make clean
> > $ make VERBOSE=1
> >
> > and send me the output.
> >
> > Thanks,
> > Haz-Edine
> >
> >
> > On Thu, 2012-03-01 at 16:21 -0500, Audette, Michel A. wrote:
> > > Hi Haz-Edine,
> > >
> > > we're trying your solution, but we're having a build problem...
> > > Linking C executable Display
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2dimdef'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_get'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miattputdbl'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_free'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varinq'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miattgetstr'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_put'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attput'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > `miget_valid_range'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > `micopy_all_var_values'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_atts'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_inqdbl'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_detach'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attinq'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setint'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2endef'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setdbl'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miattget'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miclose'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput1'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attdel'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > `micreate_std_variable'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `micreate'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setstr'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miattputstr'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varid'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_create'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > `micreate_tempfile'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_attach'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `mivarget'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > `micopy_all_var_defs'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2diminq'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > `miset_valid_range'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miattget1'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miopen'
> > > collect2: ld returned 1 exit status
> > >
> > > I've tried both static and shared minc2 libraries. We're using ccmake as
> > follows...
> > >
> > >  MINC_INCLUDE_DIR                 /usr/local/include
> > >  MINC_minc2_LIBRARY               /usr/local/lib/libminc2.a
> > >  MINC_volume_io2_LIBRARY          /usr/local/lib/libvolume_io2.so
> > >
> > > Thanks for your kind support.
> > >
> > > Michel
> > >
> > > Michel Audette, Ph.D.
> > > Assistant Professor,
> > > Department of Modeling, Simulation and Visualization Engineering,
> > > Old Dominion University,
> > > Norfolk, VA.
> > > ________________________________________
> > > From: minc-users-bounces at bic.mni.mcgill.ca [
> > minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Haz-Edine Assemlal [
> > assemlal at cim.mcgill.ca]
> > > Sent: Thursday, March 01, 2012 1:29 PM
> > > To: MINC users mailing list
> > > Subject: Re: [MINC-users] Problem building Display
> > >
> > > Hi,
> > >
> > > Alternatively, I've been working a bit on Display recently. You are
> > > welcome give it a try. The latest version is using CMake in place of
> > > autotools:
> > >
> > > https://github.com/hassemlal/Display/tags
> > >
> > > Haz-Edine
> > >
> > >
> > >
> > > On Fri, 2012-03-02 at 03:35 +1000, Andrew Janke wrote:
> > > > On 29 February 2012 14:40, Claude LEPAGE <claude at bic.mni.mcgill.ca>
> > wrote:
> > > > > This is probably the known bug that Andrew and I know how to
> > > > > fix but haven't taken the time to do so.
> > > >
> > > > Probably guilty as charged, but from what I can see this "bug" is not
> > > > a bug in minc, it seems to be in libtool.
> > > >
> > > > I'd be very curious to know if running
> > > >
> > > >    $ libtoolize --automake --copy
> > > >
> > > > In the Display directory and then re-running:
> > > >
> > > >    $ ./autogen.sh
> > > >
> > > > and
> > > >
> > > >    $ ./configure --with-build-path=/usr/local/bic ...
> > > >
> > > > fixes things.
> > > >
> > > > ta
> > > >
> > > >
> > > > a
> > > > _______________________________________________
> > > > MINC-users at bic.mni.mcgill.ca
> > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > >
> > >
> > > _______________________________________________
> > > MINC-users at bic.mni.mcgill.ca
> > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > >
> > >
> > > --
> > >
> > > _______________________________________________
> > > 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
> >
> >
> > --
> > BEGIN-ANTISPAM-VOTING-LINKS
> > ------------------------------------------------------
> >
> > Teach CanIt if this mail (ID 621969739) is spam:
> > Spam:
> > https://www.spamtrap.odu.edu/b.php?i=621969739&m=b64baa469f6e&t=20120301&c=s
> > Not spam:
> > https://www.spamtrap.odu.edu/b.php?i=621969739&m=b64baa469f6e&t=20120301&c=n
> > Forget vote:
> > https://www.spamtrap.odu.edu/b.php?i=621969739&m=b64baa469f6e&t=20120301&c=f
> > ------------------------------------------------------
> > END-ANTISPAM-VOTING-LINKS
> >
> >
> 
> 



From maudette at odu.edu  Fri Mar  2 15:36:16 2012
From: maudette at odu.edu (Audette, Michel A.)
Date: Fri, 2 Mar 2012 15:36:16 -0500
Subject: [MINC-users] Problem building Display
In-Reply-To: <1330716534.4435.55.camel@talos>
References: <CAE1j2uh3CkP6bogb6iQ4EqdHW7fxWMUidRvfMMsxOg_6vD8u7A@mail.gmail.com>
	<201202290440.q1T4eHPg029639@cassio.bic.mni.mcgill.ca>
	<CAG0CB20ZhZ9zATzP5z_UbO-0mKmgFwShfgy9pgAdnmNCLfecGg@mail.gmail.com>
	<1330626573.4435.27.camel@talos>
	<5D094B4A0B15E441811066CCC54AE4FC20BEAA230F@MUFASA.ts.odu.edu>
	<1330639459.4435.42.camel@talos>
	<5D094B4A0B15E441811066CCC54AE4FC20BEAA2317@MUFASA.ts.odu.edu>
	<CAE1j2uj2d4bSqbkddq6qHAKkwPtOXgaBq4pWsKn23+9g1Hd8vA@mail.gmail.com>,
	<1330716534.4435.55.camel@talos>
Message-ID: <5D094B4A0B15E441811066CCC54AE4FC20BEAA232A@MUFASA.ts.odu.edu>

Hello Haz-edine,

do you recommend recompiling Minc from source for your version of Display? If so, which version?

Best wishes,

Mcihel
Michel Audette, Ph.D.
Assistant Professor,
Department of Modeling, Simulation and Visualization Engineering,
Old Dominion University,
Norfolk, VA.
________________________________________
From: Haz-Edine Assemlal [assemlal at cim.mcgill.ca]
Sent: Friday, March 02, 2012 2:28 PM
To: MINC users mailing list
Cc: Audette, Michel A.; RASHID, TANWEER
Subject: Re: [MINC-users] Problem building Display

Hi Tanweer,

Which minc files did you remove from your system?

The simplest fix is to remove every files of the minc library and then
reinstall it.

Best,
Haz-Edine


On Fri, 2012-03-02 at 13:12 -0500, Tanweer Rashid wrote:
> Hi,
>
> I did have two minc2 libs, but I removed one of them, and after that, this
> is what we're seeing...
>
>
> trash001 at ubuntu:~/Desktop/hassemlal-Display-305f573Build$ make clean
> trash001 at ubuntu:~/Desktop/hassemlal-Display-305f573Build$ make VERBOSE=1
> /usr/bin/cmake -H/home/trash001/Desktop/hassemlal-Display-305f573
> -B/home/trash001/Desktop/hassemlal-Display-305f573Build
> --check-build-system CMakeFiles/Makefile.cmake 0
> /usr/bin/cmake -E cmake_progress_start
> /home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles
> /home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles/progress.marks
> make -f CMakeFiles/Makefile2 all
> make[1]: Entering directory
> `/home/trash001/Desktop/hassemlal-Display-305f573Build'
> make -f CMakeFiles/Display.dir/build.make CMakeFiles/Display.dir/depend
> make[2]: Entering directory
> `/home/trash001/Desktop/hassemlal-Display-305f573Build'
> cd /home/trash001/Desktop/hassemlal-Display-305f573Build && /usr/bin/cmake
> -E cmake_depends "Unix Makefiles"
> /home/trash001/Desktop/hassemlal-Display-305f573
> /home/trash001/Desktop/hassemlal-Display-305f573
> /home/trash001/Desktop/hassemlal-Display-305f573Build
> /home/trash001/Desktop/hassemlal-Display-305f573Build
> /home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles/Display.dir/DependInfo.cmake
> --color=
> make[2]: Leaving directory
> `/home/trash001/Desktop/hassemlal-Display-305f573Build'
> make -f CMakeFiles/Display.dir/build.make CMakeFiles/Display.dir/build
> make[2]: Entering directory
> `/home/trash001/Desktop/hassemlal-Display-305f573Build'
> /usr/bin/cmake -E cmake_progress_report
> /home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles
> [  0%] Building C object CMakeFiles/Display.dir/atlas/atlas.c.o
> /usr/bin/gcc  -DMINC2
> -I/home/trash001/Desktop/hassemlal-Display-305f573Build
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/OpenGL_graphics/Include
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/Include
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/GLUT_windows/Include
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Include
> -I/usr/local/include    -o CMakeFiles/Display.dir/atlas/atlas.c.o   -c
> /home/trash001/Desktop/hassemlal-Display-305f573/atlas/atlas.c
> /usr/bin/cmake -E cmake_progress_report
> /home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles 1
>
> ...
>
> [100%] Building C object CMakeFiles/Display.dir/dummy.c.o
> /usr/bin/gcc  -DMINC2
> -I/home/trash001/Desktop/hassemlal-Display-305f573Build
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/OpenGL_graphics/Include
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/Include
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/GLUT_windows/Include
> -I/home/trash001/Desktop/hassemlal-Display-305f573/Include
> -I/usr/local/include    -o CMakeFiles/Display.dir/dummy.c.o   -c
> /home/trash001/Desktop/hassemlal-Display-305f573/dummy.c
> Linking C executable Display
> /usr/bin/cmake -E cmake_link_script CMakeFiles/Display.dir/link.txt
> --verbose=1
> /usr/bin/gcc      CMakeFiles/Display.dir/atlas/atlas.c.o
> CMakeFiles/Display.dir/input_files/input_files.c.o
> CMakeFiles/Display.dir/input_files/volume_file.c.o
> CMakeFiles/Display.dir/tubes/convert_lines.c.o
> CMakeFiles/Display.dir/callbacks/volume_ops.c.o
> CMakeFiles/Display.dir/callbacks/surf_segmenting.c.o
> CMakeFiles/Display.dir/callbacks/file.c.o
> CMakeFiles/Display.dir/callbacks/view_ops.c.o
> CMakeFiles/Display.dir/callbacks/regions.c.o
> CMakeFiles/Display.dir/callbacks/polygon_ops.c.o
> CMakeFiles/Display.dir/callbacks/surface_curves.c.o
> CMakeFiles/Display.dir/callbacks/call_globals.c.o
> CMakeFiles/Display.dir/callbacks/quit.c.o
> CMakeFiles/Display.dir/callbacks/marker_ops.c.o
> CMakeFiles/Display.dir/callbacks/colour_coding.c.o
> CMakeFiles/Display.dir/callbacks/render_ops.c.o
> CMakeFiles/Display.dir/callbacks/segmenting.c.o
> CMakeFiles/Display.dir/callbacks/atlas.c.o
> CMakeFiles/Display.dir/callbacks/object_ops.c.o
> CMakeFiles/Display.dir/callbacks/surface_extract.c.o
> CMakeFiles/Display.dir/callbacks/line_ops.c.o
> CMakeFiles/Display.dir/callbacks/volume_transform_ops.c.o
> CMakeFiles/Display.dir/callbacks/georges.c.o
> CMakeFiles/Display.dir/main/event_loop.c.o
> CMakeFiles/Display.dir/main/transforms.c.o
> CMakeFiles/Display.dir/main/three_d.c.o
> CMakeFiles/Display.dir/main/graphics.c.o
> CMakeFiles/Display.dir/main/display.c.o
> CMakeFiles/Display.dir/main/main.c.o
> CMakeFiles/Display.dir/cursor_contours/contours.c.o
> CMakeFiles/Display.dir/markers/markers.c.o
> CMakeFiles/Display.dir/images/images.c.o
> CMakeFiles/Display.dir/segmenting/segment_polygons.c.o
> CMakeFiles/Display.dir/segmenting/painting.c.o
> CMakeFiles/Display.dir/segmenting/segmenting.c.o
> CMakeFiles/Display.dir/segmenting/cut_neighbours.c.o
> CMakeFiles/Display.dir/menu/text.c.o
> CMakeFiles/Display.dir/menu/build_menu.c.o
> CMakeFiles/Display.dir/menu/selected.c.o
> CMakeFiles/Display.dir/menu/cursor_pos.c.o
> CMakeFiles/Display.dir/menu/input_menu.c.o
> CMakeFiles/Display.dir/menu/menu.c.o
> CMakeFiles/Display.dir/structures/fit_view.c.o
> CMakeFiles/Display.dir/structures/action_table.c.o
> CMakeFiles/Display.dir/structures/lights.c.o
> CMakeFiles/Display.dir/structures/window.c.o
> CMakeFiles/Display.dir/structures/render.c.o
> CMakeFiles/Display.dir/structures/view.c.o
> CMakeFiles/Display.dir/voxel_scan/scan_objects.c.o
> CMakeFiles/Display.dir/surface_extraction/surface.c.o
> CMakeFiles/Display.dir/surface_extraction/extract.c.o
> CMakeFiles/Display.dir/surface_extraction/surface_events.c.o
> CMakeFiles/Display.dir/surface_extraction/init_surface.c.o
> CMakeFiles/Display.dir/surface_extraction/data_structs.c.o
> CMakeFiles/Display.dir/surface_extraction/boundary_extraction.c.o
> CMakeFiles/Display.dir/immediate_mode/draw_immed.c.o
> CMakeFiles/Display.dir/cursor/cursor_icon.c.o
> CMakeFiles/Display.dir/cursor/cursor.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/event_loop.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/lights.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/draw_objects.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/windows.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/graphics_structs.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/render.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/draw.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/view.c.o
> CMakeFiles/Display.dir/Graphics/G_graphics/random_order.c.o
> CMakeFiles/Display.dir/Graphics/GLUT_windows/glut_windows.c.o
> CMakeFiles/Display.dir/Graphics/GLUT_windows/copy_x_colours.c.o
> CMakeFiles/Display.dir/Graphics/dummy.c.o
> CMakeFiles/Display.dir/Graphics/OpenGL_graphics/event_loop.c.o
> CMakeFiles/Display.dir/Graphics/OpenGL_graphics/lights.c.o
> CMakeFiles/Display.dir/Graphics/OpenGL_graphics/windows.c.o
> CMakeFiles/Display.dir/Graphics/OpenGL_graphics/colour_def.c.o
> CMakeFiles/Display.dir/Graphics/OpenGL_graphics/render.c.o
> CMakeFiles/Display.dir/Graphics/OpenGL_graphics/draw.c.o
> CMakeFiles/Display.dir/Graphics/OpenGL_graphics/view.c.o
> CMakeFiles/Display.dir/edit_surface/segment.c.o
> CMakeFiles/Display.dir/edit_surface/connected.c.o
> CMakeFiles/Display.dir/edit_surface/edit.c.o
> CMakeFiles/Display.dir/surface_curves/edge_distance.c.o
> CMakeFiles/Display.dir/surface_curves/closest_line.c.o
> CMakeFiles/Display.dir/surface_curves/events.c.o
> CMakeFiles/Display.dir/current_obj/current_obj.c.o
> CMakeFiles/Display.dir/intersect/ray_polygons.c.o
> CMakeFiles/Display.dir/intersect/plane_polygons.c.o
> CMakeFiles/Display.dir/events/mouse.c.o
> CMakeFiles/Display.dir/events/utilities.c.o
> CMakeFiles/Display.dir/events/clip_plane.c.o
> CMakeFiles/Display.dir/events/rotate_slice.c.o
> CMakeFiles/Display.dir/events/mouse_trans.c.o
> CMakeFiles/Display.dir/events/magnify.c.o
> CMakeFiles/Display.dir/events/change_markers.c.o
> CMakeFiles/Display.dir/events/pick_object.c.o
> CMakeFiles/Display.dir/events/virt_sb.c.o
> CMakeFiles/Display.dir/events/pick_view.c.o
> CMakeFiles/Display.dir/events/window_man.c.o
> CMakeFiles/Display.dir/events/spaceball.c.o
> CMakeFiles/Display.dir/events/film_loop.c.o
> CMakeFiles/Display.dir/slice_window/slice_3d.c.o
> CMakeFiles/Display.dir/slice_window/slice_events.c.o
> CMakeFiles/Display.dir/slice_window/quadmesh.c.o
> CMakeFiles/Display.dir/slice_window/pick_angle.c.o
> CMakeFiles/Display.dir/slice_window/slice.c.o
> CMakeFiles/Display.dir/slice_window/colour_coding.c.o
> CMakeFiles/Display.dir/slice_window/crop.c.o
> CMakeFiles/Display.dir/slice_window/histogram.c.o
> CMakeFiles/Display.dir/slice_window/colour_bar.c.o
> CMakeFiles/Display.dir/slice_window/undo.c.o
> CMakeFiles/Display.dir/slice_window/draw_slice.c.o
> CMakeFiles/Display.dir/slice_window/view.c.o
> CMakeFiles/Display.dir/dummy.c.o  -o Display -rdynamic
> /usr/local/lib/libminc2.so /usr/local/lib/libvolume_io2.so -lnetcdf
> /usr/local/lib/libbicpl.a -lglut -lGL -Wl,-rpath,/usr/local/lib:
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2dimdef'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_get'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattputdbl'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_free'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varinq'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattgetstr'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_put'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attput'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miget_valid_range'
> /usr/local/lib/libvolume_io2.so: undefined reference to
> `micopy_all_var_values'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_atts'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_inqdbl'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_detach'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attinq'
> /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setint'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2endef'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setdbl'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattget'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miclose'
> /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput1'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attdel'
> /usr/local/lib/libvolume_io2.so: undefined reference to
> `micreate_std_variable'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micreate'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setstr'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattputstr'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varid'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_create'
> /usr/local/lib/libvolume_io2.so: undefined reference to `micreate_tempfile'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_attach'
> /usr/local/lib/libvolume_io2.so: undefined reference to `mivarget'
> /usr/local/lib/libvolume_io2.so: undefined reference to
> `micopy_all_var_defs'
> /usr/local/lib/libvolume_io2.so: undefined reference to `MI2diminq'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miset_valid_range'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miattget1'
> /usr/local/lib/libvolume_io2.so: undefined reference to `miopen'
> collect2: ld returned 1 exit status
>
>
> Thank you for your help.
>
> - - - Tanweer Rashid
>
>
> On Thu, Mar 1, 2012 at 6:37 PM, Audette, Michel A. <maudette at odu.edu> wrote:
>
> > Hi Haz-edine,
> >
> > I'll ask my student Tanweer to get in touch with you with this output.
> >
> > Thanks for your kind support.
> >
> > Michel
> > Michel Audette, Ph.D.
> > Assistant Professor,
> > Department of Modeling, Simulation and Visualization Engineering,
> > Old Dominion University,
> > Norfolk, VA.
> > ________________________________________
> > From: minc-users-bounces at bic.mni.mcgill.ca [
> > minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Haz-Edine Assemlal [
> > assemlal at cim.mcgill.ca]
> > Sent: Thursday, March 01, 2012 5:04 PM
> > To: MINC users mailing list
> > Subject: Re: [MINC-users] Problem building Display
> >
> > Hi Audette,
> >
> > This error is typical of incoherency between the header and the shared
> > library. Maybe you have two MINC2 libraries (maybe headers only)
> > installed in your system.
> >
> > Can you go the Display source directory and do:
> > $ make clean
> > $ make VERBOSE=1
> >
> > and send me the output.
> >
> > Thanks,
> > Haz-Edine
> >
> >
> > On Thu, 2012-03-01 at 16:21 -0500, Audette, Michel A. wrote:
> > > Hi Haz-Edine,
> > >
> > > we're trying your solution, but we're having a build problem...
> > > Linking C executable Display
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2dimdef'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_get'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miattputdbl'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_free'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varinq'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miattgetstr'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_put'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attput'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > `miget_valid_range'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > `micopy_all_var_values'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_atts'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_inqdbl'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_detach'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attinq'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setint'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2endef'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setdbl'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miattget'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miclose'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput1'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attdel'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > `micreate_std_variable'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `micreate'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setstr'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miattputstr'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varid'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_create'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > `micreate_tempfile'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_attach'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `mivarget'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > `micopy_all_var_defs'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2diminq'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > `miset_valid_range'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miattget1'
> > > /usr/local/lib/libvolume_io2.so: undefined reference to `miopen'
> > > collect2: ld returned 1 exit status
> > >
> > > I've tried both static and shared minc2 libraries. We're using ccmake as
> > follows...
> > >
> > >  MINC_INCLUDE_DIR                 /usr/local/include
> > >  MINC_minc2_LIBRARY               /usr/local/lib/libminc2.a
> > >  MINC_volume_io2_LIBRARY          /usr/local/lib/libvolume_io2.so
> > >
> > > Thanks for your kind support.
> > >
> > > Michel
> > >
> > > Michel Audette, Ph.D.
> > > Assistant Professor,
> > > Department of Modeling, Simulation and Visualization Engineering,
> > > Old Dominion University,
> > > Norfolk, VA.
> > > ________________________________________
> > > From: minc-users-bounces at bic.mni.mcgill.ca [
> > minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Haz-Edine Assemlal [
> > assemlal at cim.mcgill.ca]
> > > Sent: Thursday, March 01, 2012 1:29 PM
> > > To: MINC users mailing list
> > > Subject: Re: [MINC-users] Problem building Display
> > >
> > > Hi,
> > >
> > > Alternatively, I've been working a bit on Display recently. You are
> > > welcome give it a try. The latest version is using CMake in place of
> > > autotools:
> > >
> > > https://github.com/hassemlal/Display/tags
> > >
> > > Haz-Edine
> > >
> > >
> > >
> > > On Fri, 2012-03-02 at 03:35 +1000, Andrew Janke wrote:
> > > > On 29 February 2012 14:40, Claude LEPAGE <claude at bic.mni.mcgill.ca>
> > wrote:
> > > > > This is probably the known bug that Andrew and I know how to
> > > > > fix but haven't taken the time to do so.
> > > >
> > > > Probably guilty as charged, but from what I can see this "bug" is not
> > > > a bug in minc, it seems to be in libtool.
> > > >
> > > > I'd be very curious to know if running
> > > >
> > > >    $ libtoolize --automake --copy
> > > >
> > > > In the Display directory and then re-running:
> > > >
> > > >    $ ./autogen.sh
> > > >
> > > > and
> > > >
> > > >    $ ./configure --with-build-path=/usr/local/bic ...
> > > >
> > > > fixes things.
> > > >
> > > > ta
> > > >
> > > >
> > > > a
> > > > _______________________________________________
> > > > MINC-users at bic.mni.mcgill.ca
> > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > >
> > >
> > > _______________________________________________
> > > MINC-users at bic.mni.mcgill.ca
> > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > >
> > >
> > > --
> > >
> > > _______________________________________________
> > > 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
> >
> >
> > --
> >
> >
>
>




--
BEGIN-ANTISPAM-VOTING-LINKS
------------------------------------------------------

Teach CanIt if this mail (ID 622463808) is spam:
Spam:        https://www.spamtrap.odu.edu/b.php?i=622463808&m=39be79098f56&t=20120302&c=s
Not spam:    https://www.spamtrap.odu.edu/b.php?i=622463808&m=39be79098f56&t=20120302&c=n
Forget vote: https://www.spamtrap.odu.edu/b.php?i=622463808&m=39be79098f56&t=20120302&c=f
------------------------------------------------------
END-ANTISPAM-VOTING-LINKS


From assemlal at cim.mcgill.ca  Fri Mar  2 16:20:44 2012
From: assemlal at cim.mcgill.ca (Haz-Edine Assemlal)
Date: Fri, 02 Mar 2012 16:20:44 -0500
Subject: [MINC-users] Problem building Display
In-Reply-To: <5D094B4A0B15E441811066CCC54AE4FC20BEAA232A@MUFASA.ts.odu.edu>
References: <CAE1j2uh3CkP6bogb6iQ4EqdHW7fxWMUidRvfMMsxOg_6vD8u7A@mail.gmail.com>
	<201202290440.q1T4eHPg029639@cassio.bic.mni.mcgill.ca>
	<CAG0CB20ZhZ9zATzP5z_UbO-0mKmgFwShfgy9pgAdnmNCLfecGg@mail.gmail.com>
	<1330626573.4435.27.camel@talos>
	<5D094B4A0B15E441811066CCC54AE4FC20BEAA230F@MUFASA.ts.odu.edu>
	<1330639459.4435.42.camel@talos>
	<5D094B4A0B15E441811066CCC54AE4FC20BEAA2317@MUFASA.ts.odu.edu>
	<CAE1j2uj2d4bSqbkddq6qHAKkwPtOXgaBq4pWsKn23+9g1Hd8vA@mail.gmail.com>
	, <1330716534.4435.55.camel@talos>
	<5D094B4A0B15E441811066CCC54AE4FC20BEAA232A@MUFASA.ts.odu.edu>
Message-ID: <1330723244.4435.69.camel@talos>

Indeed, I recommend recompiling the MINC2 library, the latest one if
possible (2.1.1) but it is not a requirement. Also you would need to
recompile the BICpl library after that.

But first, it is essential to clean the system from existing MINC
librairies files. To help you track those files, a list is available at:

http://packages.ubuntu.com/lucid/i386/libminc-dev/filelist

Haz-Edine

On Fri, 2012-03-02 at 15:36 -0500, Audette, Michel A. wrote:
> Hello Haz-edine,
> 
> do you recommend recompiling Minc from source for your version of Display? If so, which version?
> 
> Best wishes,
> 
> Mcihel
> Michel Audette, Ph.D.
> Assistant Professor,
> Department of Modeling, Simulation and Visualization Engineering,
> Old Dominion University,
> Norfolk, VA.
> ________________________________________
> From: Haz-Edine Assemlal [assemlal at cim.mcgill.ca]
> Sent: Friday, March 02, 2012 2:28 PM
> To: MINC users mailing list
> Cc: Audette, Michel A.; RASHID, TANWEER
> Subject: Re: [MINC-users] Problem building Display
> 
> Hi Tanweer,
> 
> Which minc files did you remove from your system?
> 
> The simplest fix is to remove every files of the minc library and then
> reinstall it.
> 
> Best,
> Haz-Edine
> 
> 
> On Fri, 2012-03-02 at 13:12 -0500, Tanweer Rashid wrote:
> > Hi,
> >
> > I did have two minc2 libs, but I removed one of them, and after that, this
> > is what we're seeing...
> >
> >
> > trash001 at ubuntu:~/Desktop/hassemlal-Display-305f573Build$ make clean
> > trash001 at ubuntu:~/Desktop/hassemlal-Display-305f573Build$ make VERBOSE=1
> > /usr/bin/cmake -H/home/trash001/Desktop/hassemlal-Display-305f573
> > -B/home/trash001/Desktop/hassemlal-Display-305f573Build
> > --check-build-system CMakeFiles/Makefile.cmake 0
> > /usr/bin/cmake -E cmake_progress_start
> > /home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles
> > /home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles/progress.marks
> > make -f CMakeFiles/Makefile2 all
> > make[1]: Entering directory
> > `/home/trash001/Desktop/hassemlal-Display-305f573Build'
> > make -f CMakeFiles/Display.dir/build.make CMakeFiles/Display.dir/depend
> > make[2]: Entering directory
> > `/home/trash001/Desktop/hassemlal-Display-305f573Build'
> > cd /home/trash001/Desktop/hassemlal-Display-305f573Build && /usr/bin/cmake
> > -E cmake_depends "Unix Makefiles"
> > /home/trash001/Desktop/hassemlal-Display-305f573
> > /home/trash001/Desktop/hassemlal-Display-305f573
> > /home/trash001/Desktop/hassemlal-Display-305f573Build
> > /home/trash001/Desktop/hassemlal-Display-305f573Build
> > /home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles/Display.dir/DependInfo.cmake
> > --color=
> > make[2]: Leaving directory
> > `/home/trash001/Desktop/hassemlal-Display-305f573Build'
> > make -f CMakeFiles/Display.dir/build.make CMakeFiles/Display.dir/build
> > make[2]: Entering directory
> > `/home/trash001/Desktop/hassemlal-Display-305f573Build'
> > /usr/bin/cmake -E cmake_progress_report
> > /home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles
> > [  0%] Building C object CMakeFiles/Display.dir/atlas/atlas.c.o
> > /usr/bin/gcc  -DMINC2
> > -I/home/trash001/Desktop/hassemlal-Display-305f573Build
> > -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/OpenGL_graphics/Include
> > -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/Include
> > -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/GLUT_windows/Include
> > -I/home/trash001/Desktop/hassemlal-Display-305f573/Include
> > -I/usr/local/include    -o CMakeFiles/Display.dir/atlas/atlas.c.o   -c
> > /home/trash001/Desktop/hassemlal-Display-305f573/atlas/atlas.c
> > /usr/bin/cmake -E cmake_progress_report
> > /home/trash001/Desktop/hassemlal-Display-305f573Build/CMakeFiles 1
> >
> > ...
> >
> > [100%] Building C object CMakeFiles/Display.dir/dummy.c.o
> > /usr/bin/gcc  -DMINC2
> > -I/home/trash001/Desktop/hassemlal-Display-305f573Build
> > -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/OpenGL_graphics/Include
> > -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/Include
> > -I/home/trash001/Desktop/hassemlal-Display-305f573/Graphics/GLUT_windows/Include
> > -I/home/trash001/Desktop/hassemlal-Display-305f573/Include
> > -I/usr/local/include    -o CMakeFiles/Display.dir/dummy.c.o   -c
> > /home/trash001/Desktop/hassemlal-Display-305f573/dummy.c
> > Linking C executable Display
> > /usr/bin/cmake -E cmake_link_script CMakeFiles/Display.dir/link.txt
> > --verbose=1
> > /usr/bin/gcc      CMakeFiles/Display.dir/atlas/atlas.c.o
> > CMakeFiles/Display.dir/input_files/input_files.c.o
> > CMakeFiles/Display.dir/input_files/volume_file.c.o
> > CMakeFiles/Display.dir/tubes/convert_lines.c.o
> > CMakeFiles/Display.dir/callbacks/volume_ops.c.o
> > CMakeFiles/Display.dir/callbacks/surf_segmenting.c.o
> > CMakeFiles/Display.dir/callbacks/file.c.o
> > CMakeFiles/Display.dir/callbacks/view_ops.c.o
> > CMakeFiles/Display.dir/callbacks/regions.c.o
> > CMakeFiles/Display.dir/callbacks/polygon_ops.c.o
> > CMakeFiles/Display.dir/callbacks/surface_curves.c.o
> > CMakeFiles/Display.dir/callbacks/call_globals.c.o
> > CMakeFiles/Display.dir/callbacks/quit.c.o
> > CMakeFiles/Display.dir/callbacks/marker_ops.c.o
> > CMakeFiles/Display.dir/callbacks/colour_coding.c.o
> > CMakeFiles/Display.dir/callbacks/render_ops.c.o
> > CMakeFiles/Display.dir/callbacks/segmenting.c.o
> > CMakeFiles/Display.dir/callbacks/atlas.c.o
> > CMakeFiles/Display.dir/callbacks/object_ops.c.o
> > CMakeFiles/Display.dir/callbacks/surface_extract.c.o
> > CMakeFiles/Display.dir/callbacks/line_ops.c.o
> > CMakeFiles/Display.dir/callbacks/volume_transform_ops.c.o
> > CMakeFiles/Display.dir/callbacks/georges.c.o
> > CMakeFiles/Display.dir/main/event_loop.c.o
> > CMakeFiles/Display.dir/main/transforms.c.o
> > CMakeFiles/Display.dir/main/three_d.c.o
> > CMakeFiles/Display.dir/main/graphics.c.o
> > CMakeFiles/Display.dir/main/display.c.o
> > CMakeFiles/Display.dir/main/main.c.o
> > CMakeFiles/Display.dir/cursor_contours/contours.c.o
> > CMakeFiles/Display.dir/markers/markers.c.o
> > CMakeFiles/Display.dir/images/images.c.o
> > CMakeFiles/Display.dir/segmenting/segment_polygons.c.o
> > CMakeFiles/Display.dir/segmenting/painting.c.o
> > CMakeFiles/Display.dir/segmenting/segmenting.c.o
> > CMakeFiles/Display.dir/segmenting/cut_neighbours.c.o
> > CMakeFiles/Display.dir/menu/text.c.o
> > CMakeFiles/Display.dir/menu/build_menu.c.o
> > CMakeFiles/Display.dir/menu/selected.c.o
> > CMakeFiles/Display.dir/menu/cursor_pos.c.o
> > CMakeFiles/Display.dir/menu/input_menu.c.o
> > CMakeFiles/Display.dir/menu/menu.c.o
> > CMakeFiles/Display.dir/structures/fit_view.c.o
> > CMakeFiles/Display.dir/structures/action_table.c.o
> > CMakeFiles/Display.dir/structures/lights.c.o
> > CMakeFiles/Display.dir/structures/window.c.o
> > CMakeFiles/Display.dir/structures/render.c.o
> > CMakeFiles/Display.dir/structures/view.c.o
> > CMakeFiles/Display.dir/voxel_scan/scan_objects.c.o
> > CMakeFiles/Display.dir/surface_extraction/surface.c.o
> > CMakeFiles/Display.dir/surface_extraction/extract.c.o
> > CMakeFiles/Display.dir/surface_extraction/surface_events.c.o
> > CMakeFiles/Display.dir/surface_extraction/init_surface.c.o
> > CMakeFiles/Display.dir/surface_extraction/data_structs.c.o
> > CMakeFiles/Display.dir/surface_extraction/boundary_extraction.c.o
> > CMakeFiles/Display.dir/immediate_mode/draw_immed.c.o
> > CMakeFiles/Display.dir/cursor/cursor_icon.c.o
> > CMakeFiles/Display.dir/cursor/cursor.c.o
> > CMakeFiles/Display.dir/Graphics/G_graphics/event_loop.c.o
> > CMakeFiles/Display.dir/Graphics/G_graphics/lights.c.o
> > CMakeFiles/Display.dir/Graphics/G_graphics/draw_objects.c.o
> > CMakeFiles/Display.dir/Graphics/G_graphics/windows.c.o
> > CMakeFiles/Display.dir/Graphics/G_graphics/graphics_structs.c.o
> > CMakeFiles/Display.dir/Graphics/G_graphics/render.c.o
> > CMakeFiles/Display.dir/Graphics/G_graphics/draw.c.o
> > CMakeFiles/Display.dir/Graphics/G_graphics/view.c.o
> > CMakeFiles/Display.dir/Graphics/G_graphics/random_order.c.o
> > CMakeFiles/Display.dir/Graphics/GLUT_windows/glut_windows.c.o
> > CMakeFiles/Display.dir/Graphics/GLUT_windows/copy_x_colours.c.o
> > CMakeFiles/Display.dir/Graphics/dummy.c.o
> > CMakeFiles/Display.dir/Graphics/OpenGL_graphics/event_loop.c.o
> > CMakeFiles/Display.dir/Graphics/OpenGL_graphics/lights.c.o
> > CMakeFiles/Display.dir/Graphics/OpenGL_graphics/windows.c.o
> > CMakeFiles/Display.dir/Graphics/OpenGL_graphics/colour_def.c.o
> > CMakeFiles/Display.dir/Graphics/OpenGL_graphics/render.c.o
> > CMakeFiles/Display.dir/Graphics/OpenGL_graphics/draw.c.o
> > CMakeFiles/Display.dir/Graphics/OpenGL_graphics/view.c.o
> > CMakeFiles/Display.dir/edit_surface/segment.c.o
> > CMakeFiles/Display.dir/edit_surface/connected.c.o
> > CMakeFiles/Display.dir/edit_surface/edit.c.o
> > CMakeFiles/Display.dir/surface_curves/edge_distance.c.o
> > CMakeFiles/Display.dir/surface_curves/closest_line.c.o
> > CMakeFiles/Display.dir/surface_curves/events.c.o
> > CMakeFiles/Display.dir/current_obj/current_obj.c.o
> > CMakeFiles/Display.dir/intersect/ray_polygons.c.o
> > CMakeFiles/Display.dir/intersect/plane_polygons.c.o
> > CMakeFiles/Display.dir/events/mouse.c.o
> > CMakeFiles/Display.dir/events/utilities.c.o
> > CMakeFiles/Display.dir/events/clip_plane.c.o
> > CMakeFiles/Display.dir/events/rotate_slice.c.o
> > CMakeFiles/Display.dir/events/mouse_trans.c.o
> > CMakeFiles/Display.dir/events/magnify.c.o
> > CMakeFiles/Display.dir/events/change_markers.c.o
> > CMakeFiles/Display.dir/events/pick_object.c.o
> > CMakeFiles/Display.dir/events/virt_sb.c.o
> > CMakeFiles/Display.dir/events/pick_view.c.o
> > CMakeFiles/Display.dir/events/window_man.c.o
> > CMakeFiles/Display.dir/events/spaceball.c.o
> > CMakeFiles/Display.dir/events/film_loop.c.o
> > CMakeFiles/Display.dir/slice_window/slice_3d.c.o
> > CMakeFiles/Display.dir/slice_window/slice_events.c.o
> > CMakeFiles/Display.dir/slice_window/quadmesh.c.o
> > CMakeFiles/Display.dir/slice_window/pick_angle.c.o
> > CMakeFiles/Display.dir/slice_window/slice.c.o
> > CMakeFiles/Display.dir/slice_window/colour_coding.c.o
> > CMakeFiles/Display.dir/slice_window/crop.c.o
> > CMakeFiles/Display.dir/slice_window/histogram.c.o
> > CMakeFiles/Display.dir/slice_window/colour_bar.c.o
> > CMakeFiles/Display.dir/slice_window/undo.c.o
> > CMakeFiles/Display.dir/slice_window/draw_slice.c.o
> > CMakeFiles/Display.dir/slice_window/view.c.o
> > CMakeFiles/Display.dir/dummy.c.o  -o Display -rdynamic
> > /usr/local/lib/libminc2.so /usr/local/lib/libvolume_io2.so -lnetcdf
> > /usr/local/lib/libbicpl.a -lglut -lGL -Wl,-rpath,/usr/local/lib:
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2dimdef'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_get'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miattputdbl'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_free'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varinq'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miattgetstr'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_put'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attput'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miget_valid_range'
> > /usr/local/lib/libvolume_io2.so: undefined reference to
> > `micopy_all_var_values'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_atts'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_inqdbl'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_detach'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attinq'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setint'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2endef'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setdbl'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miattget'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miclose'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput1'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attdel'
> > /usr/local/lib/libvolume_io2.so: undefined reference to
> > `micreate_std_variable'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `micreate'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setstr'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miattputstr'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varid'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_create'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `micreate_tempfile'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_attach'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `mivarget'
> > /usr/local/lib/libvolume_io2.so: undefined reference to
> > `micopy_all_var_defs'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2diminq'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miset_valid_range'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miattget1'
> > /usr/local/lib/libvolume_io2.so: undefined reference to `miopen'
> > collect2: ld returned 1 exit status
> >
> >
> > Thank you for your help.
> >
> > - - - Tanweer Rashid
> >
> >
> > On Thu, Mar 1, 2012 at 6:37 PM, Audette, Michel A. <maudette at odu.edu> wrote:
> >
> > > Hi Haz-edine,
> > >
> > > I'll ask my student Tanweer to get in touch with you with this output.
> > >
> > > Thanks for your kind support.
> > >
> > > Michel
> > > Michel Audette, Ph.D.
> > > Assistant Professor,
> > > Department of Modeling, Simulation and Visualization Engineering,
> > > Old Dominion University,
> > > Norfolk, VA.
> > > ________________________________________
> > > From: minc-users-bounces at bic.mni.mcgill.ca [
> > > minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Haz-Edine Assemlal [
> > > assemlal at cim.mcgill.ca]
> > > Sent: Thursday, March 01, 2012 5:04 PM
> > > To: MINC users mailing list
> > > Subject: Re: [MINC-users] Problem building Display
> > >
> > > Hi Audette,
> > >
> > > This error is typical of incoherency between the header and the shared
> > > library. Maybe you have two MINC2 libraries (maybe headers only)
> > > installed in your system.
> > >
> > > Can you go the Display source directory and do:
> > > $ make clean
> > > $ make VERBOSE=1
> > >
> > > and send me the output.
> > >
> > > Thanks,
> > > Haz-Edine
> > >
> > >
> > > On Thu, 2012-03-01 at 16:21 -0500, Audette, Michel A. wrote:
> > > > Hi Haz-Edine,
> > > >
> > > > we're trying your solution, but we're having a build problem...
> > > > Linking C executable Display
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2dimdef'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_get'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miattputdbl'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_free'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varinq'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miattgetstr'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_put'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attput'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > > `miget_valid_range'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > > `micopy_all_var_values'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `micopy_all_atts'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_inqdbl'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_detach'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attinq'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setint'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2endef'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setdbl'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miattget'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miclose'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `mivarput1'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2attdel'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > > `micreate_std_variable'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `micreate'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_setstr'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miattputstr'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2varid'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_create'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > > `micreate_tempfile'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miicv_attach'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `mivarget'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > > `micopy_all_var_defs'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `MI2diminq'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to
> > > `miset_valid_range'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miattget1'
> > > > /usr/local/lib/libvolume_io2.so: undefined reference to `miopen'
> > > > collect2: ld returned 1 exit status
> > > >
> > > > I've tried both static and shared minc2 libraries. We're using ccmake as
> > > follows...
> > > >
> > > >  MINC_INCLUDE_DIR                 /usr/local/include
> > > >  MINC_minc2_LIBRARY               /usr/local/lib/libminc2.a
> > > >  MINC_volume_io2_LIBRARY          /usr/local/lib/libvolume_io2.so
> > > >
> > > > Thanks for your kind support.
> > > >
> > > > Michel
> > > >
> > > > Michel Audette, Ph.D.
> > > > Assistant Professor,
> > > > Department of Modeling, Simulation and Visualization Engineering,
> > > > Old Dominion University,
> > > > Norfolk, VA.
> > > > ________________________________________
> > > > From: minc-users-bounces at bic.mni.mcgill.ca [
> > > minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Haz-Edine Assemlal [
> > > assemlal at cim.mcgill.ca]
> > > > Sent: Thursday, March 01, 2012 1:29 PM
> > > > To: MINC users mailing list
> > > > Subject: Re: [MINC-users] Problem building Display
> > > >
> > > > Hi,
> > > >
> > > > Alternatively, I've been working a bit on Display recently. You are
> > > > welcome give it a try. The latest version is using CMake in place of
> > > > autotools:
> > > >
> > > > https://github.com/hassemlal/Display/tags
> > > >
> > > > Haz-Edine
> > > >
> > > >
> > > >
> > > > On Fri, 2012-03-02 at 03:35 +1000, Andrew Janke wrote:
> > > > > On 29 February 2012 14:40, Claude LEPAGE <claude at bic.mni.mcgill.ca>
> > > wrote:
> > > > > > This is probably the known bug that Andrew and I know how to
> > > > > > fix but haven't taken the time to do so.
> > > > >
> > > > > Probably guilty as charged, but from what I can see this "bug" is not
> > > > > a bug in minc, it seems to be in libtool.
> > > > >
> > > > > I'd be very curious to know if running
> > > > >
> > > > >    $ libtoolize --automake --copy
> > > > >
> > > > > In the Display directory and then re-running:
> > > > >
> > > > >    $ ./autogen.sh
> > > > >
> > > > > and
> > > > >
> > > > >    $ ./configure --with-build-path=/usr/local/bic ...
> > > > >
> > > > > fixes things.
> > > > >
> > > > > ta
> > > > >
> > > > >
> > > > > a
> > > > > _______________________________________________
> > > > > MINC-users at bic.mni.mcgill.ca
> > > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > > >
> > > >
> > > > _______________________________________________
> > > > MINC-users at bic.mni.mcgill.ca
> > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > > >
> > > >
> > > > --
> > > >
> > > > _______________________________________________
> > > > 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
> > >
> > >
> > > --
> > >
> > >
> >
> >
> 
> 
> 
> 
> --
> BEGIN-ANTISPAM-VOTING-LINKS
> ------------------------------------------------------
> 
> Teach CanIt if this mail (ID 622463808) is spam:
> Spam:        https://www.spamtrap.odu.edu/b.php?i=622463808&m=39be79098f56&t=20120302&c=s
> Not spam:    https://www.spamtrap.odu.edu/b.php?i=622463808&m=39be79098f56&t=20120302&c=n
> Forget vote: https://www.spamtrap.odu.edu/b.php?i=622463808&m=39be79098f56&t=20120302&c=f
> ------------------------------------------------------
> END-ANTISPAM-VOTING-LINKS
> 
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users



From yang.ding at mail.mcgill.ca  Fri Mar  2 11:51:25 2012
From: yang.ding at mail.mcgill.ca (Yang Ding)
Date: Fri, 2 Mar 2012 11:51:25 -0500
Subject: [MINC-users] nii2mnc error on CBRAIN.
Message-ID: <CAOQx59ZuHV7LOGnAMR2-UcPMMVe9-TRTVKr2S36p0sztx33koQ@mail.gmail.com>

Dear all,

I am a new user to CBrain and encountered error with nii2mnc tool
implemented there. I keep running into error when trying to convert
"img/hdr" type of NIFTI files into MINC.* *
*
*
*
*
*
*
Technical Details about the Error:

While executing command: *nii2mnc CNSCNSA02.003494.0002an.img
 CNSCNSA02.003494.0002an.img.mnc*

*** ERROR (nifti_image_read): failed to find header file for
> 'CNSCNSA02.003494.0002an.img' *

*/opt/gridengine/cbrain/spool/brainstorm/job_scripts/5865: line 48: 17390
> Segmentation fault (core dumped) nii2mnc CNSCNSA02.003494.0002an.img
> CNSCNSA02.003494.0002an.img.mnc*


The headerfile *'CNSCNSA02.003494.0002an.hdr'* is in the same directory as
IMG files and assigned with the proper project. I was also able open this
img/hdr file pair in SPM8 without issue locally (not on the server).


While executing command: *nii2mnc CNSCNSA02.003494.0002an.hdr
 CNSCNSA02.003494.0002an.hdr.mnc*

*** ERROR (nifti_image_load_prep): cannot open data file
> 'CNSCNSA02.003494.0002an.img'
> ** nifti_image_load, failed load_prep
> /opt/gridengine/cbrain/spool/brainstorm/job_scripts/5866: line 48: 17803
> Segmentation fault (core dumped) nii2mnc CNSCNSA02.003494.0002an.hdr
> CNSCNSA02.003494.0002an.hdr.mnc*


The "data file" is again, located in the same directory as IMG files and
assigned with the proper project. I was also able open this img/hdr file
pair in SPM8 without issue.

Anyone with more experience of the tool on CBRAIN, please feel free to
comment.


Things I have tried:

   - Setting permission on the files to read/write instead of read only.
   - Use a shorter name (e.g. Sub01.img/hdr from another project of mine
   failed too)
   - Convert to .nii using MRIcroN before using the nii2mnc tool. *This
   actually worked* but MRIcroN does not do batch conversion of .img/hdr to
   .nii for the 100 subjects that I have to work with...


Please let me know if you have any other suggestions to resolve this
problem. Thank you very much for all the support.




Sincerely,

Yang Ding


Graduate Student
Integrated Program in Neuroscience

McGill Group for Suicide Studies (MGSS)

514-761-6131 ext 6197

Rm. F-3145, Frank B Common Pavilion,
Douglas Mental Health University Institute
6875 LaSalle Blvd.
Verdun, Quebec, Canada, H4H 1R3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Education's purpose is to replace an empty mind with an open one." -
Malcolm Forbes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From gang.liang.2011 at gmail.com  Fri Mar  2 18:47:47 2012
From: gang.liang.2011 at gmail.com (Gang Liang)
Date: Fri, 2 Mar 2012 18:47:47 -0500
Subject: [MINC-users] nii2mnc error on CBRAIN.
In-Reply-To: <CAOQx59ZuHV7LOGnAMR2-UcPMMVe9-TRTVKr2S36p0sztx33koQ@mail.gmail.com>
References: <CAOQx59ZuHV7LOGnAMR2-UcPMMVe9-TRTVKr2S36p0sztx33koQ@mail.gmail.com>
Message-ID: <CAOmOcj_61cQTQGDN8oo8FS0NxoW3t_LOV2PNQxFmvt7pqUiwNQ@mail.gmail.com>

fsl have 2 data types: niftii and analyze(old)

to convert analyze format to nii, use fslchfiletype, then use nii2mnc to
convert it to minc
to convert analyze format to minc, use analyze2mnc or ana2mnc

Hope this help

Gang

On Fri, Mar 2, 2012 at 11:51 AM, Yang Ding <yang.ding at mail.mcgill.ca> wrote:

> Dear all,
>
> I am a new user to CBrain and encountered error with nii2mnc tool
> implemented there. I keep running into error when trying to convert
> "img/hdr" type of NIFTI files into MINC.* *
> *
> *
> *
> *
> *
> *
> Technical Details about the Error:
>
> While executing command: *nii2mnc CNSCNSA02.003494.0002an.img
>  CNSCNSA02.003494.0002an.img.mnc*
>
> *** ERROR (nifti_image_read): failed to find header file for
> > 'CNSCNSA02.003494.0002an.img' *
>
> */opt/gridengine/cbrain/spool/brainstorm/job_scripts/5865: line 48: 17390
> > Segmentation fault (core dumped) nii2mnc CNSCNSA02.003494.0002an.img
> > CNSCNSA02.003494.0002an.img.mnc*
>
>
> The headerfile *'CNSCNSA02.003494.0002an.hdr'* is in the same directory as
> IMG files and assigned with the proper project. I was also able open this
> img/hdr file pair in SPM8 without issue locally (not on the server).
>
>
> While executing command: *nii2mnc CNSCNSA02.003494.0002an.hdr
>  CNSCNSA02.003494.0002an.hdr.mnc*
>
> *** ERROR (nifti_image_load_prep): cannot open data file
> > 'CNSCNSA02.003494.0002an.img'
> > ** nifti_image_load, failed load_prep
> > /opt/gridengine/cbrain/spool/brainstorm/job_scripts/5866: line 48: 17803
> > Segmentation fault (core dumped) nii2mnc CNSCNSA02.003494.0002an.hdr
> > CNSCNSA02.003494.0002an.hdr.mnc*
>
>
> The "data file" is again, located in the same directory as IMG files and
> assigned with the proper project. I was also able open this img/hdr file
> pair in SPM8 without issue.
>
> Anyone with more experience of the tool on CBRAIN, please feel free to
> comment.
>
>
> Things I have tried:
>
>   - Setting permission on the files to read/write instead of read only.
>   - Use a shorter name (e.g. Sub01.img/hdr from another project of mine
>   failed too)
>   - Convert to .nii using MRIcroN before using the nii2mnc tool. *This
>   actually worked* but MRIcroN does not do batch conversion of .img/hdr to
>   .nii for the 100 subjects that I have to work with...
>
>
> Please let me know if you have any other suggestions to resolve this
> problem. Thank you very much for all the support.
>
>
>
>
> Sincerely,
>
> Yang Ding
>
>
> Graduate Student
> Integrated Program in Neuroscience
>
> McGill Group for Suicide Studies (MGSS)
>
> 514-761-6131 ext 6197
>
> Rm. F-3145, Frank B Common Pavilion,
> Douglas Mental Health University Institute
> 6875 LaSalle Blvd.
> Verdun, Quebec, Canada, H4H 1R3
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Education's purpose is to replace an empty mind with an open one." -
> Malcolm Forbes
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From kie_woo.nam at kcl.ac.uk  Mon Mar  5 08:33:15 2012
From: kie_woo.nam at kcl.ac.uk (Nam, Kie Woo)
Date: Mon, 5 Mar 2012 13:33:15 +0000
Subject: [MINC-users] Does unc2mnc do left-right flip?
Message-ID: <194921E98A6CEC41B0C14C804A56CC903636C5@DB3PRD0302MB115.eurprd03.prod.outlook.com>

Dear MINC users,

I have a question about the "unc2mnc" script (for converting UNC images to MINC images; downloadable from https://sites.google.com/site/ajanke/unc2mnc-1.0.tar.gz).

Could someone please let me know whether it flips the image during conversion (i.e. left of UNC image becomes right of MNC image?)?

Many thanks,

Kie Woo



Kie Woo Nam
Postgraduate Research Student
Division of Psychological Medicine
Department of Psychosis Studies
Institute of Psychiatry, King?s College London
De Crespigny Park, Denmark Hill
London SE5 8AF, UK
Tel: +44 (0)20 7848 0061

From a.janke at gmail.com  Mon Mar  5 09:13:59 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 6 Mar 2012 00:13:59 +1000
Subject: [MINC-users] Does unc2mnc do left-right flip?
In-Reply-To: <194921E98A6CEC41B0C14C804A56CC903636C5@DB3PRD0302MB115.eurprd03.prod.outlook.com>
References: <194921E98A6CEC41B0C14C804A56CC903636C5@DB3PRD0302MB115.eurprd03.prod.outlook.com>
Message-ID: <CAG0CB20YZ4Q_s9LMGqUXXgjKBwnDWicoSBX96-1RPzMdpVmq+w@mail.gmail.com>

Hi Kie Woo,

> I have a question about the "unc2mnc" script (for converting UNC images to MINC images; downloadable from https://sites.google.com/site/ajanke/unc2mnc-1.0.tar.gz).
>
> Could someone please let me know whether it flips the image during conversion (i.e. left of UNC image becomes right of MNC image?)?

I just had a quick look through the code (its been a long time since I
wrote that!) and there is nothing specific in there to flip the data.

That said, remember that the convention in MINC viewers is
neurological orientation. Data also is stored according to a
coordinate system and not in a specific orientation.  I am unsure of
the conventions of UNC and the conventions of your particular viewer
so like all things in the conversion game you'd be best off to check
your conversion with a Phantom.

good luck!


a

From trash001 at odu.edu  Mon Mar 12 14:50:50 2012
From: trash001 at odu.edu (Tanweer Rashid)
Date: Mon, 12 Mar 2012 14:50:50 -0400
Subject: [MINC-users] Documentation for Display
Message-ID: <CAE1j2ujxYeW7+-WdxAW8R7Bi782WjdqMUNECDC-49JPN9fqaeQ@mail.gmail.com>

Hi everyone,
Is there any documentation for the Display program? The link
http://www.bic.mni.mcgill.ca/software/Display/Display.html doesn't get me
anything.

Thanks,
-- 
Tanweer Rashid
Graduate Teaching & Research Assistant
Department of Modeling, Simulation and Visualization Engineering
Old Dominion University

From jared.rowley at gmail.com  Mon Mar 12 14:55:19 2012
From: jared.rowley at gmail.com (Jared Rowley)
Date: Mon, 12 Mar 2012 14:55:19 -0400
Subject: [MINC-users] Documentation for Display
In-Reply-To: <CAE1j2ujxYeW7+-WdxAW8R7Bi782WjdqMUNECDC-49JPN9fqaeQ@mail.gmail.com>
References: <CAE1j2ujxYeW7+-WdxAW8R7Bi782WjdqMUNECDC-49JPN9fqaeQ@mail.gmail.com>
Message-ID: <CACHMmjNTP2335-DZogE_yG5-xH_qJCRLjmbbjRyQdyZ6gow+Nw@mail.gmail.com>

Hi Tanweer,

There is a bit of documentation here:

http://wiki.bic.mni.mcgill.ca/index.php/DisplayManual

Jared

On Mon, Mar 12, 2012 at 2:50 PM, Tanweer Rashid <trash001 at odu.edu> wrote:
> Hi everyone,
> Is there any documentation for the Display program? The link
> http://www.bic.mni.mcgill.ca/software/Display/Display.html doesn't get me
> anything.
>
> Thanks,
> --
> Tanweer Rashid
> Graduate Teaching & Research Assistant
> Department of Modeling, Simulation and Visualization Engineering
> Old Dominion University
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users



-- 
Jared Rowley
Translational Neuroimaging Laboratory
McGill Centre for Studies in Aging
Douglas Hospital Research Center
McGill University
6825 LaSalle Blvd.
Montreal, QC Canada
H4H 1R3

From jonathan.m.dubois at gmail.com  Wed Mar 14 00:02:33 2012
From: jonathan.m.dubois at gmail.com (Jonathan DuBois)
Date: Wed, 14 Mar 2012 00:02:33 -0400
Subject: [MINC-users] MINC script for Monte Carlo simulation for multiple
	comparison correction
Message-ID: <EE174F9B-668B-4047-BA4B-6F1C07430BC8@gmail.com>

Hi Minc Users, 

I have a PET dataset in which I have run a number of structurally related comparisons. Therefore, I was wondering if there was a minc script for monte carlo simulation that would allow for an accurate correction for multiple comparisons? 

Thanks 
Jonathan

From zijdenbos at gmail.com  Thu Mar 15 07:14:42 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Thu, 15 Mar 2012 12:14:42 +0100
Subject: [MINC-users] dcm2mnc bug (?)
Message-ID: <9C75B0C2329C43C6AE4642A019C019C5@gmail.com>

Hello all,

I am having trouble converting some PET DICOM data to MINC. Using this ancient version dcm2mnc:

program: 2.0.06 built Dec 19 2006 17:56:04
libminc: 1.5
netcdf : 3.6.1 of Dec 19 2006 17:53:57 $


I obtain a "good" (4D) MINC volume; however, with any more recent version of dcm2mnc the resulting MINC volume has no time dimension and seems to store only one frame - my impression is that the time series is simply collapsed. When run with -debug, it does at some point report "Time axis length 4", but still does not generate a time dimension in the output file. 

I have placed this DICOM set here:

ADNI_PET_DICOM.tar.gz (http://cl.ly/023e0P3E3T2T2I3G1f30)

Thanks,

-- Alex

From a.janke at gmail.com  Thu Mar 15 09:19:51 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 15 Mar 2012 23:19:51 +1000
Subject: [MINC-users] dcm2mnc bug (?)
In-Reply-To: <9C75B0C2329C43C6AE4642A019C019C5@gmail.com>
References: <9C75B0C2329C43C6AE4642A019C019C5@gmail.com>
Message-ID: <CAG0CB21TREx+4Mm6E-nw8q0OL163uLBoTy6h1MYe4fiYdfk_yA@mail.gmail.com>

Hi Alex,

On 15 March 2012 21:14, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> I am having trouble converting some PET DICOM data to MINC. Using this ancient version dcm2mnc:
>
> program: 2.0.06 built Dec 19 2006 17:56:04
> libminc: 1.5
> netcdf : 3.6.1 of Dec 19 2006 17:53:57 $

DICOM conversion really seems like a cat and mouse game from time to time.

Have you tried to run this data through something like OSIRIX (and
then export, and convert that with the latest dcm2mnc)?


a

From gang.liang.2011 at gmail.com  Thu Mar 15 09:57:38 2012
From: gang.liang.2011 at gmail.com (Gang Liang)
Date: Thu, 15 Mar 2012 09:57:38 -0400
Subject: [MINC-users] dcm2mnc bug (?)
In-Reply-To: <CAG0CB21TREx+4Mm6E-nw8q0OL163uLBoTy6h1MYe4fiYdfk_yA@mail.gmail.com>
References: <9C75B0C2329C43C6AE4642A019C019C5@gmail.com>
	<CAG0CB21TREx+4Mm6E-nw8q0OL163uLBoTy6h1MYe4fiYdfk_yA@mail.gmail.com>
Message-ID: <CAOmOcj8jt9irVj9rqkBenyZdwxgCpDp=+6fPGqUMsYPZHXZXNg@mail.gmail.com>

Alex,

If you failed on all dcm2mncS, the crazy idea is to use dcm2nii first, and
then nii2mnc.  I mean mricron version of dcm2nii.


Gang

On Thu, Mar 15, 2012 at 9:19 AM, Andrew Janke <a.janke at gmail.com> wrote:

> Hi Alex,
>
> On 15 March 2012 21:14, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> > I am having trouble converting some PET DICOM data to MINC. Using this
> ancient version dcm2mnc:
> >
> > program: 2.0.06 built Dec 19 2006 17:56:04
> > libminc: 1.5
> > netcdf : 3.6.1 of Dec 19 2006 17:53:57 $
>
> DICOM conversion really seems like a cat and mouse game from time to time.
>
> Have you tried to run this data through something like OSIRIX (and
> then export, and convert that with the latest dcm2mnc)?
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From zijdenbos at gmail.com  Thu Mar 15 09:58:41 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Thu, 15 Mar 2012 14:58:41 +0100
Subject: [MINC-users] dcm2mnc bug (?)
In-Reply-To: <CAG0CB21TREx+4Mm6E-nw8q0OL163uLBoTy6h1MYe4fiYdfk_yA@mail.gmail.com>
References: <9C75B0C2329C43C6AE4642A019C019C5@gmail.com>
	<CAG0CB21TREx+4Mm6E-nw8q0OL163uLBoTy6h1MYe4fiYdfk_yA@mail.gmail.com>
Message-ID: <CABEEk14W-pmKwn=t5WHeteTNBUDeEfJCtD-tQRcU3m53Dwsi_w@mail.gmail.com>

Hi Andrew,

On Thu, Mar 15, 2012 at 2:19 PM, Andrew Janke <a.janke at gmail.com> wrote:

> Hi Alex,
>
> On 15 March 2012 21:14, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> > I am having trouble converting some PET DICOM data to MINC. Using this
> ancient version dcm2mnc:
> >
> > program: 2.0.06 built Dec 19 2006 17:56:04
> > libminc: 1.5
> > netcdf : 3.6.1 of Dec 19 2006 17:53:57 $
>
> DICOM conversion really seems like a cat and mouse game from time to time
>

:) seriously


> Have you tried to run this data through something like OSIRIX (and
> then export, and convert that with the latest dcm2mnc)?
>

 Tried that now using OsiriX; with exactly the same result. In other words,
the import/export by OsiriX doesn't fix the problem.

-- A

From zijdenbos at gmail.com  Thu Mar 15 10:04:37 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Thu, 15 Mar 2012 15:04:37 +0100
Subject: [MINC-users] dcm2mnc bug (?)
In-Reply-To: <CAOmOcj8jt9irVj9rqkBenyZdwxgCpDp=+6fPGqUMsYPZHXZXNg@mail.gmail.com>
References: <9C75B0C2329C43C6AE4642A019C019C5@gmail.com>
	<CAG0CB21TREx+4Mm6E-nw8q0OL163uLBoTy6h1MYe4fiYdfk_yA@mail.gmail.com>
	<CAOmOcj8jt9irVj9rqkBenyZdwxgCpDp=+6fPGqUMsYPZHXZXNg@mail.gmail.com>
Message-ID: <CABEEk15qjD5tRZpahyKsZW-u_-bMmKfaNTQsrGKM5eGu5s8qHQ@mail.gmail.com>

Hi Gang,

Well it seems to fail on much, if not all, of the ADNI PET data. Since an
old version of dcm2mnc seems to work correctly on these data I can in
practice of course use that; but this looks like a bug in the current
version of dcm2mnc that should nevertheless be fixed. I'd rather avoid
multiple conversions as that often has other side effects :)

-- A

On Thu, Mar 15, 2012 at 2:57 PM, Gang Liang <gang.liang.2011 at gmail.com>wrote:

> Alex,
>
> If you failed on all dcm2mncS, the crazy idea is to use dcm2nii first, and
> then nii2mnc.  I mean mricron version of dcm2nii.
>
>
> Gang
>
> On Thu, Mar 15, 2012 at 9:19 AM, Andrew Janke <a.janke at gmail.com> wrote:
>
> > Hi Alex,
> >
> > On 15 March 2012 21:14, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> > > I am having trouble converting some PET DICOM data to MINC. Using this
> > ancient version dcm2mnc:
> > >
> > > program: 2.0.06 built Dec 19 2006 17:56:04
> > > libminc: 1.5
> > > netcdf : 3.6.1 of Dec 19 2006 17:53:57 $
> >
> > DICOM conversion really seems like a cat and mouse game from time to
> time.
> >
> > Have you tried to run this data through something like OSIRIX (and
> > then export, and convert that with the latest dcm2mnc)?
> >
> >
> > a
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From a.janke at gmail.com  Thu Mar 15 10:16:05 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 16 Mar 2012 00:16:05 +1000
Subject: [MINC-users] dcm2mnc bug (?)
In-Reply-To: <CABEEk14W-pmKwn=t5WHeteTNBUDeEfJCtD-tQRcU3m53Dwsi_w@mail.gmail.com>
References: <9C75B0C2329C43C6AE4642A019C019C5@gmail.com>
	<CAG0CB21TREx+4Mm6E-nw8q0OL163uLBoTy6h1MYe4fiYdfk_yA@mail.gmail.com>
	<CABEEk14W-pmKwn=t5WHeteTNBUDeEfJCtD-tQRcU3m53Dwsi_w@mail.gmail.com>
Message-ID: <CAG0CB20JWZmxkDKV72ULdGmsVDLGZr6TdBs6jLrrOi0XT=4VkQ@mail.gmail.com>

On 15 March 2012 23:58, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
>> Have you tried to run this data through something like OSIRIX (and
>> then export, and convert that with the latest dcm2mnc)?
>>
>
> ?Tried that now using OsiriX; with exactly the same result. In other words,
> the import/export by OsiriX doesn't fix the problem.

Well, so much for that idea.

I am sure that the older version didn't take much notice of frame
names or times and just concatenated every one it sees into the output
(4D) file. The difference is that the new version started checking,
again if memory serves correctly this was to deal with diffusion
images.

If you use dcmdump do the time frames have differing ID's or time codes?

I am also assuming you've tried "-splitdynamic"?


a

From zijdenbos at gmail.com  Thu Mar 15 10:36:02 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Thu, 15 Mar 2012 15:36:02 +0100
Subject: [MINC-users] dcm2mnc bug (?)
In-Reply-To: <CAG0CB20JWZmxkDKV72ULdGmsVDLGZr6TdBs6jLrrOi0XT=4VkQ@mail.gmail.com>
References: <9C75B0C2329C43C6AE4642A019C019C5@gmail.com>
	<CAG0CB21TREx+4Mm6E-nw8q0OL163uLBoTy6h1MYe4fiYdfk_yA@mail.gmail.com>
	<CABEEk14W-pmKwn=t5WHeteTNBUDeEfJCtD-tQRcU3m53Dwsi_w@mail.gmail.com>
	<CAG0CB20JWZmxkDKV72ULdGmsVDLGZr6TdBs6jLrrOi0XT=4VkQ@mail.gmail.com>
Message-ID: <CABEEk14Ly-1bQt86K0U4CvJVd03Tu9oXXkOfNmzAVaHn9sqdPg@mail.gmail.com>

> I am sure that the older version didn't take much notice of frame
> names or times and just concatenated every one it sees into the output
> (4D) file. The difference is that the new version started checking,
> again if memory serves correctly this was to deal with diffusion
> images.
>
> If you use dcmdump do the time frames have differing ID's or time codes?

Yes, 'FrameReferenceTime' has four different values in the set of
slices (presumably corresponding to the 4 different time frames that
the 'old' converter generated).

> I am also assuming you've tried "-splitdynamic"?

Yes, no difference

-- A

From kie_woo.nam at kcl.ac.uk  Sun Mar 18 14:07:21 2012
From: kie_woo.nam at kcl.ac.uk (Nam, Kie Woo)
Date: Sun, 18 Mar 2012 18:07:21 +0000
Subject: [MINC-users] Best plane (axial or coronal) for CIVET processing?
Message-ID: <194921E98A6CEC41B0C14C804A56CC90CFF0B4@DBXPRD0310MB382.eurprd03.prod.outlook.com>

Dear experts,

I know this mailing list is not particularly for CIVET pipeline, but could someone please advise me the best plane (axial or coronal) for images to be in for CIVET processing?

I've recently run CIVET on an image in coronal and axial planes (i.e. 2 identical images just in different planes), and noticed that the outputs differed. This was noticeable in the "clasp" images as well as the text files (example shown below).

...brainmask_qc.txt

Axial image: native skull mask in stx space (10.83%)

Coronal image: native skull mask in stx space (11.96%)

My original images were in coronal plane, so I'm thinking of doing CIVET processing on coronal images. However, I'm not convinced whether this is a good choice. So, if anyone would please advise me on this, I would much appreciate it.

Best wishes,

Kie Woo

Kie Woo Nam
Postgraduate Research Student
Division of Psychological Medicine
Department of Psychosis Studies
Institute of Psychiatry, King?s College London
De Crespigny Park, Denmark Hill
London SE5 8AF, UK
Tel: +44 (0)20 7848 0061

From zijdenbos at gmail.com  Sun Mar 18 17:43:20 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Sun, 18 Mar 2012 17:43:20 -0400
Subject: [MINC-users] Best plane (axial or coronal) for CIVET processing?
In-Reply-To: <194921E98A6CEC41B0C14C804A56CC90CFF0B4@DBXPRD0310MB382.eurprd03.prod.outlook.com>
References: <194921E98A6CEC41B0C14C804A56CC90CFF0B4@DBXPRD0310MB382.eurprd03.prod.outlook.com>
Message-ID: <CABEEk15OETNOP61yqqVbDn0zTRxLOub16FsrJ3nB9ETEtc8utw@mail.gmail.com>

Hello Kie Woo,

Are you referring to two images _acquired_ in different orientations
(i.e., two different acquisitions), or two images simply (re)sampled
(or reshaped) to have different dimension ordering? In the latter case
you really should obtain identical results (unless you changed voxel
sizes or manipulated the data in some other way); so I assume you are
talking about the former, i.e., you have two different acquisitions.
In this case you would expect to get slightly different results -
there is an inherent scan-rescan variability associated with any type
of image processing tool, simply because the image you provide is a
different one. In other words, if you would take two axial or two
coronal scans acquired in sequence, you would also see a difference in
image processing results.

The only reason I can think of why coronally scanned data would yield
more or less accurate results as compared to axial images is if there
is a difference in the image quality, in terms of intensity uniformity
for example. Otherwise I would say the results should be equivalent.
Being consistent however is always good; for example, I would
definitely not change your acquisition protocol in the middle of a
longitudinal study, if that is what you are contemplating.

-- Alex

On Sun, Mar 18, 2012 at 2:07 PM, Nam, Kie Woo <kie_woo.nam at kcl.ac.uk> wrote:
> Dear experts,
>
> I know this mailing list is not particularly for CIVET pipeline, but could someone please advise me the best plane (axial or coronal) for images to be in for CIVET processing?
>
> I've recently run CIVET on an image in coronal and axial planes (i.e. 2 identical images just in different planes), and noticed that the outputs differed. This was noticeable in the "clasp" images as well as the text files (example shown below).
>
> ...brainmask_qc.txt
>
> Axial image: native skull mask in stx space (10.83%)
>
> Coronal image: native skull mask in stx space (11.96%)
>
> My original images were in coronal plane, so I'm thinking of doing CIVET processing on coronal images. However, I'm not convinced whether this is a good choice. So, if anyone would please advise me on this, I would much appreciate it.
>
> Best wishes,
>
> Kie Woo
>
> Kie Woo Nam
> Postgraduate Research Student
> Division of Psychological Medicine
> Department of Psychosis Studies
> Institute of Psychiatry, King?s College London
> De Crespigny Park, Denmark Hill
> London SE5 8AF, UK
> Tel: +44 (0)20 7848 0061
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From kie_woo.nam at kcl.ac.uk  Mon Mar 19 18:52:51 2012
From: kie_woo.nam at kcl.ac.uk (Nam, Kie Woo)
Date: Mon, 19 Mar 2012 22:52:51 +0000
Subject: [MINC-users]  Best plane (axial or coronal) for CIVET processing?
Message-ID: <194921E98A6CEC41B0C14C804A56CC90CFF141@DBXPRD0310MB382.eurprd03.prod.outlook.com>

Dear Alex,

I much appreciate your quick and detailed reply.

I find your advice very useful, but my image has been acquired only in the coronal plane in UNC format. I've converted it into Analyze format in coronal (using "unc2analyze") and axial (using "coronal2axial") planes. After that, I've converted both Analyze images into MNC format using "ana2mnc<http://packages.bic.mni.mcgill.ca/scripts/ana2mnc-1.3d>".

I've compared the axial and coronal Analyze images and checked that the signal intensities were the same in a few randomly picked voxels. I couldn't check the MNC images properly because of difficulty selecting exact same voxels in both images (using MNC viewing software like "Display" and "register"), but I couldn't tell any visual difference between the axial and coronal MNC images.

Anyway, thank you very much again for your advice. For now, I'll just stick to the images in the original (i.e. coronal) plane.

Best wishes,

Kie Woo



----------------------------------------------------------------------

Message: 1
Date: Sun, 18 Mar 2012 18:07:21 +0000
From: "Nam, Kie Woo" <kie_woo.nam at kcl.ac.uk>
Subject: [MINC-users] Best plane (axial or coronal) for CIVET
processing?
To: "minc-users at bic.mni.mcgill.ca" <minc-users at bic.mni.mcgill.ca>
Cc: "Simmons, Andy" <andy.simmons at kcl.ac.uk>
Message-ID:
<194921E98A6CEC41B0C14C804A56CC90CFF0B4 at DBXPRD0310MB382.eurprd03.prod.outlook.com>

Content-Type: text/plain; charset="Windows-1252"

Dear experts,

I know this mailing list is not particularly for CIVET pipeline, but could someone please advise me the best plane (axial or coronal) for images to be in for CIVET processing?

I've recently run CIVET on an image in coronal and axial planes (i.e. 2 identical images just in different planes), and noticed that the outputs differed. This was noticeable in the "clasp" images as well as the text files (example shown below).

...brainmask_qc.txt

Axial image: native skull mask in stx space (10.83%)

Coronal image: native skull mask in stx space (11.96%)

My original images were in coronal plane, so I'm thinking of doing CIVET processing on coronal images. However, I'm not convinced whether this is a good choice. So, if anyone would please advise me on this, I would much appreciate it.

Best wishes,

Kie Woo

Kie Woo Nam
Postgraduate Research Student
Division of Psychological Medicine
Department of Psychosis Studies
Institute of Psychiatry, King?s College London
De Crespigny Park, Denmark Hill
London SE5 8AF, UK
Tel: +44 (0)20 7848 0061


------------------------------

Message: 2
Date: Sun, 18 Mar 2012 17:43:20 -0400
From: Alex Zijdenbos <zijdenbos at gmail.com>
Subject: Re: [MINC-users] Best plane (axial or coronal) for CIVET
processing?
To: MINC users mailing list <minc-users at bic.mni.mcgill.ca>
Message-ID:
<CABEEk15OETNOP61yqqVbDn0zTRxLOub16FsrJ3nB9ETEtc8utw at mail.gmail.com>
Content-Type: text/plain; charset=windows-1252

Hello Kie Woo,

Are you referring to two images _acquired_ in different orientations
(i.e., two different acquisitions), or two images simply (re)sampled
(or reshaped) to have different dimension ordering? In the latter case
you really should obtain identical results (unless you changed voxel
sizes or manipulated the data in some other way); so I assume you are
talking about the former, i.e., you have two different acquisitions.
In this case you would expect to get slightly different results -
there is an inherent scan-rescan variability associated with any type
of image processing tool, simply because the image you provide is a
different one. In other words, if you would take two axial or two
coronal scans acquired in sequence, you would also see a difference in
image processing results.

The only reason I can think of why coronally scanned data would yield
more or less accurate results as compared to axial images is if there
is a difference in the image quality, in terms of intensity uniformity
for example. Otherwise I would say the results should be equivalent.
Being consistent however is always good; for example, I would
definitely not change your acquisition protocol in the middle of a
longitudinal study, if that is what you are contemplating.

-- Alex

On Sun, Mar 18, 2012 at 2:07 PM, Nam, Kie Woo <kie_woo.nam at kcl.ac.uk> wrote:
> Dear experts,
>
> I know this mailing list is not particularly for CIVET pipeline, but could someone please advise me the best plane (axial or coronal) for images to be in for CIVET processing?
>
> I've recently run CIVET on an image in coronal and axial planes (i.e. 2 identical images just in different planes), and noticed that the outputs differed. This was noticeable in the "clasp" images as well as the text files (example shown below).
>
> ...brainmask_qc.txt
>
> Axial image: native skull mask in stx space (10.83%)
>
> Coronal image: native skull mask in stx space (11.96%)
>
> My original images were in coronal plane, so I'm thinking of doing CIVET processing on coronal images. However, I'm not convinced whether this is a good choice. So, if anyone would please advise me on this, I would much appreciate it.
>
> Best wishes,
>
> Kie Woo
>
> Kie Woo Nam
> Postgraduate Research Student
> Division of Psychological Medicine
> Department of Psychosis Studies
> Institute of Psychiatry, King?s College London
> De Crespigny Park, Denmark Hill
> London SE5 8AF, UK
> Tel: +44 (0)20 7848 0061
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


------------------------------

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


End of MINC-users Digest, Vol 80, Issue 9
*****************************************


From zijdenbos at gmail.com  Tue Mar 20 09:34:07 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Tue, 20 Mar 2012 09:34:07 -0400
Subject: [MINC-users] Best plane (axial or coronal) for CIVET processing?
In-Reply-To: <194921E98A6CEC41B0C14C804A56CC90CFF141@DBXPRD0310MB382.eurprd03.prod.outlook.com>
References: <AQHNBfbevLz1rSPyCES+Dkgd+bEuIg==>
	<194921E98A6CEC41B0C14C804A56CC90CFF141@DBXPRD0310MB382.eurprd03.prod.outlook.com>
Message-ID: <CABEEk14Avb=A-dKmoD884hAPcu8TR56noyC6_Ju-Ny8C-MH7Bw@mail.gmail.com>

Hello Kie Woo,

>From what you are describing, I think that the issue you came across
is not an issue with CIVET but with the format conversion you used,
and/or the way the Analyze data were resliced. I would guess that in
the reslicing the world coordinate information (and probably other
metadata) was not maintained; so when you then convert these two
resulting images to MINC independently the images would - from the
MINC/CIVET perspective - be different and may thus yield different
processing results.

If the images would actually be the same, you would be able to load
them both in "register" and they would align; if they don't do that
(as you say), you have at minimum lost the world coordinate
information in the conversion or reslicing process.

To properly test the impact of dimension ordering, you should convert
the image to MINC once, and then use the MINC tools to perform the
reordering, for example like so:

   mincreshape -transverse <coronal.mnc> <transverse.mnc>

which will properly maintain the image metadata. In this case the
results you get from processing <coronal.mnc> and <transverse.mnc>
using CIVET should be the same; these two images should also line up
in "register" and have the exact same voxel values at the same spatial
coordinates.

The important thing to remember is that MINC stores much more useful
information than most other file formats, so if those other formats or
tools do not support those features, doing multiple conversions will
almost certainly get you into trouble.

-- Alex

On Mon, Mar 19, 2012 at 6:52 PM, Nam, Kie Woo <kie_woo.nam at kcl.ac.uk> wrote:
> Dear Alex,
>
> I much appreciate your quick and detailed reply.
>
> I find your advice very useful, but my image has been acquired only in the
> coronal plane in UNC format. I've converted it into Analyze format in
> coronal (using "unc2analyze") and axial (using "coronal2axial") planes.
> After that, I've converted both Analyze images into MNC format using
> "ana2mnc".
>
> I've compared the?axial and coronal Analyze images and checked that?the
> signal intensities were the same in a few randomly picked voxels. I couldn't
> check the MNC images properly because of difficulty selecting exact same
> voxels in both images (using MNC viewing software like "Display" and
> "register"), but I couldn't tell any visual difference between the axial and
> coronal MNC images.
>
> Anyway, thank you very much again for your advice. For now, I'll just stick
> to the images in the original (i.e. coronal) plane.
>
> Best wishes,
>
> Kie Woo
>
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 18 Mar 2012 18:07:21 +0000
> From: "Nam, Kie Woo" <kie_woo.nam at kcl.ac.uk>
> Subject: [MINC-users] Best plane (axial or coronal) for CIVET
> processing?
> To: "minc-users at bic.mni.mcgill.ca" <minc-users at bic.mni.mcgill.ca>
> Cc: "Simmons, Andy" <andy.simmons at kcl.ac.uk>
> Message-ID:
> <194921E98A6CEC41B0C14C804A56CC90CFF0B4 at DBXPRD0310MB382.eurprd03.prod.outlook.com>
>
> Content-Type: text/plain; charset="Windows-1252"
>
> Dear experts,
>
> I know this mailing list is not particularly for CIVET pipeline, but could
> someone please advise me the best plane (axial or coronal) for images to be
> in for CIVET processing?
>
> I've recently run CIVET on an image in coronal and axial planes (i.e. 2
> identical images just in different planes), and noticed that the outputs
> differed. This was noticeable in the "clasp" images as well as the text
> files (example shown below).
>
> ...brainmask_qc.txt
>
> Axial image: native skull mask in stx space (10.83%)
>
> Coronal image: native skull mask in stx space (11.96%)
>
> My original images were in coronal plane, so I'm thinking of doing CIVET
> processing on coronal images. However, I'm not convinced whether this is a
> good choice. So, if anyone would please advise me on this, I would much
> appreciate it.
>
> Best wishes,
>
> Kie Woo
>
> Kie Woo Nam
> Postgraduate Research Student
> Division of Psychological Medicine
> Department of Psychosis Studies
> Institute of Psychiatry, King?s College London
> De Crespigny Park, Denmark Hill
> London SE5 8AF, UK
> Tel: +44 (0)20 7848 0061
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 18 Mar 2012 17:43:20 -0400
> From: Alex Zijdenbos <zijdenbos at gmail.com>
> Subject: Re: [MINC-users] Best plane (axial or coronal) for CIVET
> processing?
> To: MINC users mailing list <minc-users at bic.mni.mcgill.ca>
> Message-ID:
> <CABEEk15OETNOP61yqqVbDn0zTRxLOub16FsrJ3nB9ETEtc8utw at mail.gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> Hello Kie Woo,
>
> Are you referring to two images _acquired_ in different orientations
> (i.e., two different acquisitions), or two images simply (re)sampled
> (or reshaped) to have different dimension ordering? In the latter case
> you really should obtain identical results (unless you changed voxel
> sizes or manipulated the data in some other way); so I assume you are
> talking about the former, i.e., you have two different acquisitions.
> In this case you would expect to get slightly different results -
> there is an inherent scan-rescan variability associated with any type
> of image processing tool, simply because the image you provide is a
> different one. In other words, if you would take two axial or two
> coronal scans acquired in sequence, you would also see a difference in
> image processing results.
>
> The only reason I can think of why coronally scanned data would yield
> more or less accurate results as compared to axial images is if there
> is a difference in the image quality, in terms of intensity uniformity
> for example. Otherwise I would say the results should be equivalent.
> Being consistent however is always good; for example, I would
> definitely not change your acquisition protocol in the middle of a
> longitudinal study, if that is what you are contemplating.
>
> -- Alex
>
> On Sun, Mar 18, 2012 at 2:07 PM, Nam, Kie Woo <kie_woo.nam at kcl.ac.uk> wrote:
>> Dear experts,
>>
>> I know this mailing list is not particularly for CIVET pipeline, but could
>> someone please advise me the best plane (axial or coronal) for images to be
>> in for CIVET processing?
>>
>> I've recently run CIVET on an image in coronal and axial planes (i.e. 2
>> identical images just in different planes), and noticed that the outputs
>> differed. This was noticeable in the "clasp" images as well as the text
>> files (example shown below).
>>
>> ...brainmask_qc.txt
>>
>> Axial image: native skull mask in stx space (10.83%)
>>
>> Coronal image: native skull mask in stx space (11.96%)
>>
>> My original images were in coronal plane, so I'm thinking of doing CIVET
>> processing on coronal images. However, I'm not convinced whether this is a
>> good choice. So, if anyone would please advise me on this, I would much
>> appreciate it.
>>
>> Best wishes,
>>
>> Kie Woo
>>
>> Kie Woo Nam
>> Postgraduate Research Student
>> Division of Psychological Medicine
>> Department of Psychosis Studies
>> Institute of Psychiatry, King?s College London
>> De Crespigny Park, Denmark Hill
>> London SE5 8AF, UK
>> Tel: +44 (0)20 7848 0061
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>
>
> ------------------------------
>
> _______________________________________________
> MINC-users mailing list
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>
> End of MINC-users Digest, Vol 80, Issue 9
> *****************************************
>

From a.janke at gmail.com  Wed Mar 21 07:26:02 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 21 Mar 2012 21:26:02 +1000
Subject: [MINC-users] MINC packages
Message-ID: <CAG0CB22mGu2MjXwU0sVrBLN7HE3qqsVENK_mLPJqRae_iRSg9g@mail.gmail.com>

Hi all,

Thanks to a lot of work (predominately by Vladimir Fonov), development
of all the MINC packages will now be shifting to here:

   https://github.com/BIC-MNI

Official releases will still be on
http://packages.bic.mni.mcgill.ca/tgz for some time yet.

ta


a

From usteph08 at student.aau.dk  Wed Mar 21 08:43:12 2012
From: usteph08 at student.aau.dk (Ulrik Landberg Stephansen)
Date: Wed, 21 Mar 2012 12:43:12 +0000
Subject: [MINC-users] Compute distance map from BIC .obj file
Message-ID: <46F6D4D7-E443-4EBE-9497-A793217011E4@student.aau.dk>

Hi,

I would like to compute the (signed) distance map from a BIC .obj file based on the sampling options in a template MINC volume and save it as a new MINC volume. I.e. for each voxel in the template volume, compute the shortest distance to the surface of the object and use that value as the grayscale value of the corresponding voxel in the output volume.

Does such a tool exist, or is it possible using a combination of existing tools?

Ulrik

From eskild at gmail.com  Wed Mar 21 08:54:20 2012
From: eskild at gmail.com (Simon Eskildsen)
Date: Wed, 21 Mar 2012 13:54:20 +0100
Subject: [MINC-users] Compute distance map from BIC .obj file
In-Reply-To: <46F6D4D7-E443-4EBE-9497-A793217011E4@student.aau.dk>
References: <46F6D4D7-E443-4EBE-9497-A793217011E4@student.aau.dk>
Message-ID: <CAD3v435O0zDD884i-U=eBERk5n-Ki=2G-hkCyTR8-L919kqROw@mail.gmail.com>

Hi Ulrik,

You can use scan_object_to_volume from conglomerate and mincchamfer to
get a distance map. Of course the precision will be limited to the
voxel sizes and you will not get a signed distance. By signed you mean
inside / outside the object, right? If the object is closed you'll be
able to generate the sign with surface_mask2, also from conglomerate.

Simon

On Wed, Mar 21, 2012 at 1:43 PM, Ulrik Landberg Stephansen
<usteph08 at student.aau.dk> wrote:
> Hi,
>
> I would like to compute the (signed) distance map from a BIC .obj file based on the sampling options in a template MINC volume and save it as a new MINC volume. I.e. for each voxel in the template volume, compute the shortest distance to the surface of the object and use that value as the grayscale value of the corresponding voxel in the output volume.
>
> Does such a tool exist, or is it possible using a combination of existing tools?
>
> Ulrik
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From kie_woo.nam at kcl.ac.uk  Wed Mar 21 14:07:25 2012
From: kie_woo.nam at kcl.ac.uk (Nam, Kie Woo)
Date: Wed, 21 Mar 2012 18:07:25 +0000
Subject: [MINC-users] Best plane (axial or coronal) for CIVET processing?
In-Reply-To: <CABEEk14Avb=A-dKmoD884hAPcu8TR56noyC6_Ju-Ny8C-MH7Bw@mail.gmail.com>
References: <AQHNBfbevLz1rSPyCES+Dkgd+bEuIg==>
	<194921E98A6CEC41B0C14C804A56CC90CFF141@DBXPRD0310MB382.eurprd03.prod.outlook.com>,
	<CABEEk14Avb=A-dKmoD884hAPcu8TR56noyC6_Ju-Ny8C-MH7Bw@mail.gmail.com>
Message-ID: <194921E98A6CEC41B0C14C804A56CC90CFF237@DBXPRD0310MB382.eurprd03.prod.outlook.com>

Hello, Alex.

Thank you for your further explanation.

As you advised, I've loaded both my axial and coronal MINC images using "register" and checked that they do not align - I've tried "mincreshape -transverse" and then they aligned.

I suspect that the discrepancy between the axial and coronal MINC images was made during "ana2mnc" conversion. That's because I've checked that the axial and coronal Analyze images are identical by (1) checking their headers and (2) running "fslstats" to extract some values.

Or I guess, as you mentioned, it could be due to the information loss during "unc2analyze" or "coronal2axial" conversion. I keep getting the following message during "ana2mnc" conversion, and maybe it reflects lack of information which could have been lost during conversion into the Analyze format.

ana2mnc: No x origin info found, guessing..
ana2mnc: No y origin info found, guessing..
ana2mnc: No z origin info found, guessing..

Anyway, thanks to your clarification, my concern is not about whether to use axial or coronal images any more. Instead, I now wish to check whether the "ana2mnc" worked correctly.

So, I'll soon email Dr Andrew Janke, who wrote "ana2mnc", and Cc you.

Thank you very much again for your detailed help.

Kie Woo


________________________________________
From: Alex Zijdenbos [zijdenbos at gmail.com]
Sent: 20 March 2012 13:34
To: Nam, Kie Woo
Cc: minc-users at bic.mni.mcgill.ca; Simmons, Andy
Subject: Re: [MINC-users] Best plane (axial or coronal) for CIVET processing?

Hello Kie Woo,

>From what you are describing, I think that the issue you came across
is not an issue with CIVET but with the format conversion you used,
and/or the way the Analyze data were resliced. I would guess that in
the reslicing the world coordinate information (and probably other
metadata) was not maintained; so when you then convert these two
resulting images to MINC independently the images would - from the
MINC/CIVET perspective - be different and may thus yield different
processing results.

If the images would actually be the same, you would be able to load
them both in "register" and they would align; if they don't do that
(as you say), you have at minimum lost the world coordinate
information in the conversion or reslicing process.

To properly test the impact of dimension ordering, you should convert
the image to MINC once, and then use the MINC tools to perform the
reordering, for example like so:

mincreshape -transverse <coronal.mnc> <transverse.mnc>

which will properly maintain the image metadata. In this case the
results you get from processing <coronal.mnc> and <transverse.mnc>
using CIVET should be the same; these two images should also line up
in "register" and have the exact same voxel values at the same spatial
coordinates.

The important thing to remember is that MINC stores much more useful
information than most other file formats, so if those other formats or
tools do not support those features, doing multiple conversions will
almost certainly get you into trouble.

-- Alex

On Mon, Mar 19, 2012 at 6:52 PM, Nam, Kie Woo <kie_woo.nam at kcl.ac.uk> wrote:
> Dear Alex,
>
> I much appreciate your quick and detailed reply.
>
> I find your advice very useful, but my image has been acquired only in the
> coronal plane in UNC format. I've converted it into Analyze format in
> coronal (using "unc2analyze") and axial (using "coronal2axial") planes.
> After that, I've converted both Analyze images into MNC format using
> "ana2mnc".
>
> I've compared the axial and coronal Analyze images and checked that the
> signal intensities were the same in a few randomly picked voxels. I couldn't
> check the MNC images properly because of difficulty selecting exact same
> voxels in both images (using MNC viewing software like "Display" and
> "register"), but I couldn't tell any visual difference between the axial and
> coronal MNC images.
>
> Anyway, thank you very much again for your advice. For now, I'll just stick
> to the images in the original (i.e. coronal) plane.
>
> Best wishes,
>
> Kie Woo
>
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 18 Mar 2012 18:07:21 +0000
> From: "Nam, Kie Woo" <kie_woo.nam at kcl.ac.uk>
> Subject: [MINC-users] Best plane (axial or coronal) for CIVET
> processing?
> To: "minc-users at bic.mni.mcgill.ca" <minc-users at bic.mni.mcgill.ca>
> Cc: "Simmons, Andy" <andy.simmons at kcl.ac.uk>
> Message-ID:
> <194921E98A6CEC41B0C14C804A56CC90CFF0B4 at DBXPRD0310MB382.eurprd03.prod.outlook.com>
>
> Content-Type: text/plain; charset="Windows-1252"
>
> Dear experts,
>
> I know this mailing list is not particularly for CIVET pipeline, but could
> someone please advise me the best plane (axial or coronal) for images to be
> in for CIVET processing?
>
> I've recently run CIVET on an image in coronal and axial planes (i.e. 2
> identical images just in different planes), and noticed that the outputs
> differed. This was noticeable in the "clasp" images as well as the text
> files (example shown below).
>
> ...brainmask_qc.txt
>
> Axial image: native skull mask in stx space (10.83%)
>
> Coronal image: native skull mask in stx space (11.96%)
>
> My original images were in coronal plane, so I'm thinking of doing CIVET
> processing on coronal images. However, I'm not convinced whether this is a
> good choice. So, if anyone would please advise me on this, I would much
> appreciate it.
>
> Best wishes,
>
> Kie Woo
>
> Kie Woo Nam
> Postgraduate Research Student
> Division of Psychological Medicine
> Department of Psychosis Studies
> Institute of Psychiatry, King?s College London
> De Crespigny Park, Denmark Hill
> London SE5 8AF, UK
> Tel: +44 (0)20 7848 0061
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 18 Mar 2012 17:43:20 -0400
> From: Alex Zijdenbos <zijdenbos at gmail.com>
> Subject: Re: [MINC-users] Best plane (axial or coronal) for CIVET
> processing?
> To: MINC users mailing list <minc-users at bic.mni.mcgill.ca>
> Message-ID:
> <CABEEk15OETNOP61yqqVbDn0zTRxLOub16FsrJ3nB9ETEtc8utw at mail.gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> Hello Kie Woo,
>
> Are you referring to two images _acquired_ in different orientations
> (i.e., two different acquisitions), or two images simply (re)sampled
> (or reshaped) to have different dimension ordering? In the latter case
> you really should obtain identical results (unless you changed voxel
> sizes or manipulated the data in some other way); so I assume you are
> talking about the former, i.e., you have two different acquisitions.
> In this case you would expect to get slightly different results -
> there is an inherent scan-rescan variability associated with any type
> of image processing tool, simply because the image you provide is a
> different one. In other words, if you would take two axial or two
> coronal scans acquired in sequence, you would also see a difference in
> image processing results.
>
> The only reason I can think of why coronally scanned data would yield
> more or less accurate results as compared to axial images is if there
> is a difference in the image quality, in terms of intensity uniformity
> for example. Otherwise I would say the results should be equivalent.
> Being consistent however is always good; for example, I would
> definitely not change your acquisition protocol in the middle of a
> longitudinal study, if that is what you are contemplating.
>
> -- Alex
>
> On Sun, Mar 18, 2012 at 2:07 PM, Nam, Kie Woo <kie_woo.nam at kcl.ac.uk> wrote:
>> Dear experts,
>>
>> I know this mailing list is not particularly for CIVET pipeline, but could
>> someone please advise me the best plane (axial or coronal) for images to be
>> in for CIVET processing?
>>
>> I've recently run CIVET on an image in coronal and axial planes (i.e. 2
>> identical images just in different planes), and noticed that the outputs
>> differed. This was noticeable in the "clasp" images as well as the text
>> files (example shown below).
>>
>> ...brainmask_qc.txt
>>
>> Axial image: native skull mask in stx space (10.83%)
>>
>> Coronal image: native skull mask in stx space (11.96%)
>>
>> My original images were in coronal plane, so I'm thinking of doing CIVET
>> processing on coronal images. However, I'm not convinced whether this is a
>> good choice. So, if anyone would please advise me on this, I would much
>> appreciate it.
>>
>> Best wishes,
>>
>> Kie Woo
>>
>> Kie Woo Nam
>> Postgraduate Research Student
>> Division of Psychological Medicine
>> Department of Psychosis Studies
>> Institute of Psychiatry, King?s College London
>> De Crespigny Park, Denmark Hill
>> London SE5 8AF, UK
>> Tel: +44 (0)20 7848 0061
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>
>
> ------------------------------
>
> _______________________________________________
> MINC-users mailing list
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>
> End of MINC-users Digest, Vol 80, Issue 9
> *****************************************
>


From usteph08 at student.aau.dk  Wed Mar 21 15:11:21 2012
From: usteph08 at student.aau.dk (Ulrik Landberg Stephansen)
Date: Wed, 21 Mar 2012 19:11:21 +0000
Subject: [MINC-users] Compute distance map from BIC .obj file
In-Reply-To: <CAD3v435O0zDD884i-U=eBERk5n-Ki=2G-hkCyTR8-L919kqROw@mail.gmail.com>
References: <46F6D4D7-E443-4EBE-9497-A793217011E4@student.aau.dk>
	<CAD3v435O0zDD884i-U=eBERk5n-Ki=2G-hkCyTR8-L919kqROw@mail.gmail.com>
Message-ID: <E20ACFF8-F5A6-449F-B708-4F2F7CB2C2DC@student.aau.dk>

Hi Simon,

What I am looking for is a tool to do this without having to convert the object to a binary image, which should (in theory) result in a more accurate distance map.

By signed I mean negative inside and positive outside, yes (or vice versa). The object is closed.

Ulrik


Den 21/03/2012 kl. 13.54 skrev Simon Eskildsen:

> Hi Ulrik,
> 
> You can use scan_object_to_volume from conglomerate and mincchamfer to
> get a distance map. Of course the precision will be limited to the
> voxel sizes and you will not get a signed distance. By signed you mean
> inside / outside the object, right? If the object is closed you'll be
> able to generate the sign with surface_mask2, also from conglomerate.
> 
> Simon
> 
> On Wed, Mar 21, 2012 at 1:43 PM, Ulrik Landberg Stephansen
> <usteph08 at student.aau.dk> wrote:
>> Hi,
>> 
>> I would like to compute the (signed) distance map from a BIC .obj file based on the sampling options in a template MINC volume and save it as a new MINC volume. I.e. for each voxel in the template volume, compute the shortest distance to the surface of the object and use that value as the grayscale value of the corresponding voxel in the output volume.
>> 
>> Does such a tool exist, or is it possible using a combination of existing tools?
>> 
>> Ulrik
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From a.janke at gmail.com  Wed Mar 21 16:09:38 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 22 Mar 2012 06:09:38 +1000
Subject: [MINC-users] Best plane (axial or coronal) for CIVET processing?
In-Reply-To: <194921E98A6CEC41B0C14C804A56CC90CFF237@DBXPRD0310MB382.eurprd03.prod.outlook.com>
References: <194921E98A6CEC41B0C14C804A56CC90CFF141@DBXPRD0310MB382.eurprd03.prod.outlook.com>
	<CABEEk14Avb=A-dKmoD884hAPcu8TR56noyC6_Ju-Ny8C-MH7Bw@mail.gmail.com>
	<194921E98A6CEC41B0C14C804A56CC90CFF237@DBXPRD0310MB382.eurprd03.prod.outlook.com>
Message-ID: <CAG0CB236vyF+1DRNbKsKtq3E-S_Q_5jvaD9+hZC5Z9Rw5GXJWQ@mail.gmail.com>

Hi all,

On 22 March 2012 04:07, Nam, Kie Woo <kie_woo.nam at kcl.ac.uk> wrote:
> ana2mnc: No x origin info found, guessing..
> ana2mnc: No y origin info found, guessing..
> ana2mnc: No z origin info found, guessing..
>
> Anyway, thanks to your clarification, my concern is not about whether to use axial or coronal images any more. Instead, I now wish to check whether the "ana2mnc" worked correctly.

I'm curious as to why you are using ana2mnc and not nii2mnc?  nii2mnc
is part of MINC itself and can handle both ANALYZE and Nifti-1 data.
nii2mnc was written as a replacement to ana2mnc a while back.


a

From kie_woo.nam at kcl.ac.uk  Thu Mar 22 14:35:04 2012
From: kie_woo.nam at kcl.ac.uk (Nam, Kie Woo)
Date: Thu, 22 Mar 2012 18:35:04 +0000
Subject: [MINC-users] Best plane (axial or coronal) for CIVET processing?
In-Reply-To: <CAG0CB236vyF+1DRNbKsKtq3E-S_Q_5jvaD9+hZC5Z9Rw5GXJWQ@mail.gmail.com>
References: <194921E98A6CEC41B0C14C804A56CC90CFF141@DBXPRD0310MB382.eurprd03.prod.outlook.com>
	<CABEEk14Avb=A-dKmoD884hAPcu8TR56noyC6_Ju-Ny8C-MH7Bw@mail.gmail.com>
	<194921E98A6CEC41B0C14C804A56CC90CFF237@DBXPRD0310MB382.eurprd03.prod.outlook.com>,
	<CAG0CB236vyF+1DRNbKsKtq3E-S_Q_5jvaD9+hZC5Z9Rw5GXJWQ@mail.gmail.com>
Message-ID: <194921E98A6CEC41B0C14C804A56CC90CFF300@DBXPRD0310MB382.eurprd03.prod.outlook.com>

Dear Dr Andrew Janke,

Thank you very much for this precious information. The reason why I've been using "ana2mnc" was just that it came up on top of the google search results list.

Anyway, I've now used "nii2mnc", and have further questions. So, I would very much appreciate your further advice.




I've checked that the axial and coronal MINC images do not align when loaded using "register" (shown in attached the image) even though both the coronal and axial images have the same (1) messages displayed on terminal during nii2mnc conversion, (2) "mincheader" outputs and (3) "mincstats" outputs (shown in attached the Excel sheet).




So, could you please tell me whether the nii2mnc conversion has been done properly? If not, I would be grateful if you would advise me on how to fix this. Please be reminded that my interest is not in having both axial and coronal MINC images, but just making sure the UNC-to-Analyze-to-MNC has been done successfully whether it's is in axial or coronal plane.

Many thanks,

Kie Woo


________________________________________
From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Andrew Janke [a.janke at gmail.com]
Sent: 21 March 2012 20:09
To: MINC users mailing list
Cc: Simmons, Andy
Subject: Re: [MINC-users] Best plane (axial or coronal) for CIVET processing?

Hi all,

On 22 March 2012 04:07, Nam, Kie Woo <kie_woo.nam at kcl.ac.uk> wrote:
> ana2mnc: No x origin info found, guessing..
> ana2mnc: No y origin info found, guessing..
> ana2mnc: No z origin info found, guessing..
>
> Anyway, thanks to your clarification, my concern is not about whether to use axial or coronal images any more. Instead, I now wish to check whether the "ana2mnc" worked correctly.

I'm curious as to why you are using ana2mnc and not nii2mnc? nii2mnc
is part of MINC itself and can handle both ANALYZE and Nifti-1 data.
nii2mnc was written as a replacement to ana2mnc a while back.


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


From kie_woo.nam at kcl.ac.uk  Thu Mar 22 14:43:50 2012
From: kie_woo.nam at kcl.ac.uk (Nam, Kie Woo)
Date: Thu, 22 Mar 2012 18:43:50 +0000
Subject: [MINC-users] Left-right orientation of outputs in neurological
	convention
Message-ID: <194921E98A6CEC41B0C14C804A56CC90CFF329@DBXPRD0310MB382.eurprd03.prod.outlook.com>

Dear Dr Andrew Janke,

My apologies for the repetitive questioning, but could you please confirm if the following are true about the left-right orientation of the neurological convention? I clearly understand the case of the coronal slice, but I am not sure how to interpret the picture of cortical surfaces (e.g. CLASP image (CIVET pipeline output)) and hemisphere-specific data (e.g. ".txt" and ".obj" for each hemisphere (CIVET pipeline output)).


  *   Neurological convention
     *   Coronal slice: Image left = True left
     *   Picture of cortical surfaces: Frontal shot left = True right (as the frontal shot has been labelled in attached the picture)
     *   Hemisphere-specific data: "Left" = True left

*Frontal shot: picture taken from the front of the brain (as if I'm standing if front of the person)



In addition, would you say, for the picture of cortical surfaces, "Frontal shot left = True right" is the appropriate way to display images for publications? I assume it is so because this is how the brain would look from the front (as opposed to looking left-right flipped), but I would still appreciate your advice on this.




Thank you very much for your great patience and help.

Kie Woo




Kie Woo Nam
Postgraduate Research Student
Division of Psychological Medicine
Department of Psychosis Studies
Institute of Psychiatry, King?s College London
De Crespigny Park, Denmark Hill
London SE5 8AF, UK
Tel: +44 (0)20 7848 0061

From zijdenbos at gmail.com  Fri Mar 23 08:48:15 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Fri, 23 Mar 2012 08:48:15 -0400
Subject: [MINC-users] Best plane (axial or coronal) for CIVET processing?
In-Reply-To: <194921E98A6CEC41B0C14C804A56CC90CFF300@DBXPRD0310MB382.eurprd03.prod.outlook.com>
References: <194921E98A6CEC41B0C14C804A56CC90CFF141@DBXPRD0310MB382.eurprd03.prod.outlook.com>
	<CABEEk14Avb=A-dKmoD884hAPcu8TR56noyC6_Ju-Ny8C-MH7Bw@mail.gmail.com>
	<194921E98A6CEC41B0C14C804A56CC90CFF237@DBXPRD0310MB382.eurprd03.prod.outlook.com>
	<CAG0CB236vyF+1DRNbKsKtq3E-S_Q_5jvaD9+hZC5Z9Rw5GXJWQ@mail.gmail.com>
	<194921E98A6CEC41B0C14C804A56CC90CFF300@DBXPRD0310MB382.eurprd03.prod.outlook.com>
Message-ID: <CABEEk17nxNDD8Ai4zYvcBVFShkRtT3ujvbj_2NxWAhKwf7+VNw@mail.gmail.com>

I can take a stab at this - Andrew can correct me if I am wrong somewhere.

>From the 'register' screenshot I would say that the image on the left
(I assume that is the 'axial') is converted correctly (barring a
left-right inversion that wouldn't be visible); and the second one is
incorrectly converted.

I suspect that nii2mnc (or ana2mnc) has no way of knowing that you
flipped the axes around, so it converts the image the same way for
both images. You can probably fix this by providing ni2mnc with one of
the spatial dimension ordering options, such as -coronal, to tell it
what the ordering of the dimensions in your image is.

Be aware though of left-right inversions; I have seen many cases where
the left and right sides are inverted in converting from "unaware"
image formats to an "aware" format such as MINC. If you can you should
always double check the sidedness; most brains are asymmetric enough
to allow you to verify the sides. All MINC tools display data in
neurological convention (left=left).

-- A

On Thu, Mar 22, 2012 at 2:35 PM, Nam, Kie Woo <kie_woo.nam at kcl.ac.uk> wrote:
> Dear Dr Andrew Janke,
>
> Thank you very much for this precious information. The reason why I've been
> using "ana2mnc" was just that it came up on top of the google search results
> list.
>
> Anyway, I've now used "nii2mnc", and have further questions. So, I would
> very much appreciate your further advice.
>
>
>
>
> I've checked that the axial and coronal MINC images do not align when loaded
> using "register" (shown in attached the image) even though both the coronal
> and axial images have the same (1) messages displayed on terminal during
> nii2mnc conversion, (2) "mincheader" outputs and (3) "mincstats" outputs
> (shown in attached the Excel sheet).
>
>
>
>
> So, could you please tell me whether the nii2mnc conversion has been done
> properly? If not, I would be grateful if you would advise me on how to fix
> this. Please be reminded that my interest is not in having both axial and
> coronal MINC images, but just making sure the UNC-to-Analyze-to-MNC has been
> done successfully whether it's is in axial or coronal plane.
>
> Many thanks,
>
> Kie Woo
>
>
> ________________________________________
> From: minc-users-bounces at bic.mni.mcgill.ca
> [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Andrew Janke
> [a.janke at gmail.com]
> Sent: 21 March 2012 20:09
>
> To: MINC users mailing list
> Cc: Simmons, Andy
>
> Subject: Re: [MINC-users] Best plane (axial or coronal) for CIVET
> processing?
>
> Hi all,
>
> On 22 March 2012 04:07, Nam, Kie Woo <kie_woo.nam at kcl.ac.uk> wrote:
>> ana2mnc: No x origin info found, guessing..
>> ana2mnc: No y origin info found, guessing..
>> ana2mnc: No z origin info found, guessing..
>>
>> Anyway, thanks to your clarification, my concern is not about whether to
>> use axial or coronal images any more. Instead, I now wish to check whether
>> the "ana2mnc" worked correctly.
>
> I'm curious as to why you are using ana2mnc and not nii2mnc? nii2mnc
> is part of MINC itself and can handle both ANALYZE and Nifti-1 data.
> nii2mnc was written as a replacement to ana2mnc a while back.
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From a.janke at gmail.com  Fri Mar 23 10:00:17 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Sat, 24 Mar 2012 00:00:17 +1000
Subject: [MINC-users] Best plane (axial or coronal) for CIVET processing?
In-Reply-To: <CABEEk17nxNDD8Ai4zYvcBVFShkRtT3ujvbj_2NxWAhKwf7+VNw@mail.gmail.com>
References: <194921E98A6CEC41B0C14C804A56CC90CFF141@DBXPRD0310MB382.eurprd03.prod.outlook.com>
	<CABEEk14Avb=A-dKmoD884hAPcu8TR56noyC6_Ju-Ny8C-MH7Bw@mail.gmail.com>
	<194921E98A6CEC41B0C14C804A56CC90CFF237@DBXPRD0310MB382.eurprd03.prod.outlook.com>
	<CAG0CB236vyF+1DRNbKsKtq3E-S_Q_5jvaD9+hZC5Z9Rw5GXJWQ@mail.gmail.com>
	<194921E98A6CEC41B0C14C804A56CC90CFF300@DBXPRD0310MB382.eurprd03.prod.outlook.com>
	<CABEEk17nxNDD8Ai4zYvcBVFShkRtT3ujvbj_2NxWAhKwf7+VNw@mail.gmail.com>
Message-ID: <CAG0CB207_YQxjtiC2vCcJDTbSyJ=cakj2AvbsTZY3oqO6bUAnQ@mail.gmail.com>

On 23 March 2012 22:48, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> I can take a stab at this - Andrew can correct me if I am wrong somewhere.

Seems pretty good to me.

> From the 'register' screenshot I would say that the image on the left
> (I assume that is the 'axial') is converted correctly (barring a
> left-right inversion that wouldn't be visible); and the second one is
> incorrectly converted.

Correct.

> I suspect that nii2mnc (or ana2mnc) has no way of knowing that you
> flipped the axes around

Correct.  I have seen instances of ANALYZE where files are stored in
the order they came of the scanner. Of course if your data starts off
being wrong. ie: you've lost the co-ordinate information when you
converted from DICOM? to UNC to ANALYZE7.5, no amount of automated
conversion fiddling
is going to save you.

> You can probably fix this by providing ni2mnc with one of
> the spatial dimension ordering options, such as -coronal, to tell it
> what the ordering of the dimensions in your image is.

Correct. But again, while this will result in a conversion that
"looks" good you still have no way of knowing if a left-right flip has
been done as part of the conversion to ANALYZE some time ago. There is
no way to solve this problem as you would have to know exactly which
path the original file took through SPM/ANALYZE/FSL/etc and know the
defaults that were set in each of these in order to figure it out.

> All MINC tools display data in neurological convention (left=left).

Again, correct. This I can't stress enough is only a viewing
convention. For an axial slice, radiological means you are viewing the
axial slice from the patients foot and neurological means you are
viewing from the top of the patients head. The way a radiological department
used to "swap" between the viewing conventions was to flip the X-ray over
on the viewing desk! The same principle applies
for coronal and sagittal. The data itself should never be flipped L-R
but unfortunately some other tools do this.

>> So, could you please tell me whether the nii2mnc conversion has been done
>> properly?

Well yes, the conversion from nii2mnc very likely was correct for both
images. The problem is the input ANALYZE or UNC file is poorly or more
likely not defined WRT co-ordinate systems.

>> Please be reminded that my interest is not in having both axial and
>> coronal MINC images, but just making sure the UNC-to-Analyze-to-MNC has been
>> done successfully whether it's is in axial or coronal plane.

>From what I have seen, this will not be possible with your data. You
will need to manually inspect each ANALYZE dataset and use the
appropriate conversion depending on if it is a "axial" or a "coronal"
ANALYZE file.

If you get stuck, and only as a last resort, use the attached scripts.
These are my swiss-army-chainsaw-botched-file-fixer-upperers, and should be
used with a great deal of caution! It looks to me as if your "coronal"
file needs to first have the Z and Y axes swapped and then be flipped
in Y. This is a fix I have seen a few times before:

   $ volmash -swap yz coronal.mnc tmp.mnc
   $ volflip -y tmp.mnc fixed.mnc


a

From zijdenbos at gmail.com  Fri Mar 23 11:15:30 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Fri, 23 Mar 2012 11:15:30 -0400
Subject: [MINC-users] mincaverage -avgdim result header
Message-ID: <CABEEk17E_NDnuW2XZ94=O3AznBE8Q3yxkXAUGiN-TWm2h5z2oQ@mail.gmail.com>

Hello all,

I just noticed that 'mincaverage -avgdim' leaves lots of header
information in the resulting average for the dimension it averaged
out; which then causes trouble with mincinfo and the like. To me this
looks like a bug in mincaverage, in that when using -avgdim <dim> it
doesn't properly clean up the <dim>-related header attributes.

Specifically:

$ mincaverage -avgdim time test_pet.mnc test_pet_avg.mnc
$ mincinfo test_pet.mnc test_pet_avg.mnc
file: test_pet.mnc
image: signed__ short -32768 to 32767
image dimensions: time zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    time                        4        227.5          150
    zspace                     90            2            0
    yspace                    128           -2         -128
    xspace                    128           -2          128


file: test_pet_avg.mnc
image: signed__ short -32768 to 32767
image dimensions: zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    zspace                     90            2            0
    yspace                    128           -2         -128
    xspace                    128           -2          128

So that looks right; we seem to have lost the time dimension. However,
using this mincinfo call:

$ mincinfo -dimnames -dimlength time test_pet_avg.mnc
time xspace yspace zspace
4

Suddenly revives the time dimension. Using mincheader:

$ mincheader test_pet_avg.mnc | grep time
        time = 4 ;
        int time ;
                time:length = 4 ;
                acquisition:start_time = "20110207 154039" ;
                study:start_time = "154039" ;
        double time-width(time) ;
                time-width:dimorder = "time" ;
                time-width:varid = "MINC standard variable" ;
                time-width:vartype = "dim-width____" ;
                time-width:version = "MINC Version    1.0" ;
                time-width:spacing = "irregular" ;
                time-width:filtertype = "square____" ;
                        "Fri Mar 23 11:07:54 2012>>> mincaverage
-clobber -avgdim time test_pet.mnc test_pet_avg.mnc\n",
 time = 0 ;
 time-width = 300, 300, 300, 300 ;

I would say that most (if not all) of these time-dimension attributes
should have been removed?

-- Alex

From kie_woo.nam at kcl.ac.uk  Fri Mar 23 11:27:32 2012
From: kie_woo.nam at kcl.ac.uk (Nam, Kie Woo)
Date: Fri, 23 Mar 2012 15:27:32 +0000
Subject: [MINC-users] Best plane (axial or coronal) for CIVET processing?
In-Reply-To: <CAG0CB207_YQxjtiC2vCcJDTbSyJ=cakj2AvbsTZY3oqO6bUAnQ@mail.gmail.com>
References: <194921E98A6CEC41B0C14C804A56CC90CFF141@DBXPRD0310MB382.eurprd03.prod.outlook.com>
	<CABEEk14Avb=A-dKmoD884hAPcu8TR56noyC6_Ju-Ny8C-MH7Bw@mail.gmail.com>
	<194921E98A6CEC41B0C14C804A56CC90CFF237@DBXPRD0310MB382.eurprd03.prod.outlook.com>
	<CAG0CB236vyF+1DRNbKsKtq3E-S_Q_5jvaD9+hZC5Z9Rw5GXJWQ@mail.gmail.com>
	<194921E98A6CEC41B0C14C804A56CC90CFF300@DBXPRD0310MB382.eurprd03.prod.outlook.com>
	<CABEEk17nxNDD8Ai4zYvcBVFShkRtT3ujvbj_2NxWAhKwf7+VNw@mail.gmail.com>,
	<CAG0CB207_YQxjtiC2vCcJDTbSyJ=cakj2AvbsTZY3oqO6bUAnQ@mail.gmail.com>
Message-ID: <194921E98A6CEC41B0C14C804A56CC90CFF3D9@DBXPRD0310MB382.eurprd03.prod.outlook.com>

Dear Andrew and Alex,

This is great! Both "nii2mnc -coronal" and "volmash -swap yz" (without volflip) worked. However, I see why you told me to use volmash "only as a last resort" because "mincstats" yield (very slightly) different values for the "volmash -swap yz" output compared those from "nii2mnc -coronal" and correctly converted axial images.

Anyway, I'm finally ready to process the images. Thank you both very much for your great patience and expert help!

Best wishes,

Kie Woo


________________________________________
From: Andrew Janke [a.janke at gmail.com]
Sent: 23 March 2012 14:00
To: Alex Zijdenbos
Cc: Nam, Kie Woo; MINC users mailing list; Simmons, Andy
Subject: Re: [MINC-users] Best plane (axial or coronal) for CIVET processing?

On 23 March 2012 22:48, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> I can take a stab at this - Andrew can correct me if I am wrong somewhere.

Seems pretty good to me.

> From the 'register' screenshot I would say that the image on the left
> (I assume that is the 'axial') is converted correctly (barring a
> left-right inversion that wouldn't be visible); and the second one is
> incorrectly converted.

Correct.

> I suspect that nii2mnc (or ana2mnc) has no way of knowing that you
> flipped the axes around

Correct.  I have seen instances of ANALYZE where files are stored in
the order they came of the scanner. Of course if your data starts off
being wrong. ie: you've lost the co-ordinate information when you
converted from DICOM? to UNC to ANALYZE7.5, no amount of automated
conversion fiddling
is going to save you.

> You can probably fix this by providing ni2mnc with one of
> the spatial dimension ordering options, such as -coronal, to tell it
> what the ordering of the dimensions in your image is.

Correct. But again, while this will result in a conversion that
"looks" good you still have no way of knowing if a left-right flip has
been done as part of the conversion to ANALYZE some time ago. There is
no way to solve this problem as you would have to know exactly which
path the original file took through SPM/ANALYZE/FSL/etc and know the
defaults that were set in each of these in order to figure it out.

> All MINC tools display data in neurological convention (left=left).

Again, correct. This I can't stress enough is only a viewing
convention. For an axial slice, radiological means you are viewing the
axial slice from the patients foot and neurological means you are
viewing from the top of the patients head. The way a radiological department
used to "swap" between the viewing conventions was to flip the X-ray over
on the viewing desk! The same principle applies
for coronal and sagittal. The data itself should never be flipped L-R
but unfortunately some other tools do this.

>> So, could you please tell me whether the nii2mnc conversion has been done
>> properly?

Well yes, the conversion from nii2mnc very likely was correct for both
images. The problem is the input ANALYZE or UNC file is poorly or more
likely not defined WRT co-ordinate systems.

>> Please be reminded that my interest is not in having both axial and
>> coronal MINC images, but just making sure the UNC-to-Analyze-to-MNC has been
>> done successfully whether it's is in axial or coronal plane.

>From what I have seen, this will not be possible with your data. You
will need to manually inspect each ANALYZE dataset and use the
appropriate conversion depending on if it is a "axial" or a "coronal"
ANALYZE file.

If you get stuck, and only as a last resort, use the attached scripts.
These are my swiss-army-chainsaw-botched-file-fixer-upperers, and should be
used with a great deal of caution! It looks to me as if your "coronal"
file needs to first have the Z and Y axes swapped and then be flipped
in Y. This is a fix I have seen a few times before:

   $ volmash -swap yz coronal.mnc tmp.mnc
   $ volflip -y tmp.mnc fixed.mnc


a


From peter.neelin at gmail.com  Sat Mar 24 00:35:42 2012
From: peter.neelin at gmail.com (Peter Neelin)
Date: Sat, 24 Mar 2012 00:35:42 -0400
Subject: [MINC-users] mincaverage -avgdim result header
In-Reply-To: <CABEEk17E_NDnuW2XZ94=O3AznBE8Q3yxkXAUGiN-TWm2h5z2oQ@mail.gmail.com>
References: <CABEEk17E_NDnuW2XZ94=O3AznBE8Q3yxkXAUGiN-TWm2h5z2oQ@mail.gmail.com>
Message-ID: <CANcjyda13aN7ivx8We=B_6hDTJzXSx9w7zAidABJembYWVwR9w@mail.gmail.com>

Hi Alex,

On Mar 23, 2012 11:16 AM, "Alex Zijdenbos" <zijdenbos at gmail.com> wrote:
> I just noticed that 'mincaverage -avgdim' leaves lots of header
> information in the resulting average for the dimension it averaged
> out; which then causes trouble with mincinfo and the like. To me this
> looks like a bug in mincaverage, in that when using -avgdim <dim> it
> doesn't properly clean up the <dim>-related header attributes.

Minc and netcdf allow for any number of dimensions to exist in the file.
They are only relevant to the image data if they index the "image" variable
in minc. mincaverage is removing the time dimension from the image
variable, but it leaves the dimension itself alone. If other variables
exist in the file, then they may be indexed by the time dimension. It might
be argued that mincaverage should do something magical to all variables
indexed by one of the dimensions (time in this case), but it would be
rather arbitrary to average any variable in the file along that dimension.
The contract of mincaverage is simply to average image data. Other data is
left untouched.

> So that looks right; we seem to have lost the time dimension. However,
> using this mincinfo call:
>
> $ mincinfo -dimnames -dimlength time test_pet_avg.mnc
> time xspace yspace zspace

I don't think that this is what you want - this asks for all the dimensions
in the file, which is what you are given. You should be using the -vardims
option with "image" as the argument instead. This will tell you which
dimensions are indexing the image variable. This is what mincinfo
-image_info does.

So bottom-line: I don't think that it is a bug - I think that it is doing
the most appropriate thing. (Of course, I wrote it, so I would think that -
you are free to disagree and change the contract/requirements if it suits
you, but please bear in mind that minc is designed around a general file
format and is intended to be extensible - I think that general-purpose
tools like mincaverage should honour that intent and not mess up non-image
data in the file.)

Hope this helps.

Peter
--
Peter Neelin
peter.neelin at gmail.com

From zijdenbos at gmail.com  Sat Mar 24 14:36:53 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Sat, 24 Mar 2012 14:36:53 -0400
Subject: [MINC-users] mincaverage -avgdim result header
In-Reply-To: <CANcjyda13aN7ivx8We=B_6hDTJzXSx9w7zAidABJembYWVwR9w@mail.gmail.com>
References: <CABEEk17E_NDnuW2XZ94=O3AznBE8Q3yxkXAUGiN-TWm2h5z2oQ@mail.gmail.com>
	<CANcjyda13aN7ivx8We=B_6hDTJzXSx9w7zAidABJembYWVwR9w@mail.gmail.com>
Message-ID: <CABEEk17ZVSFi-BpXcwLFO5iyVFfUMXueWu9M5M2HC_DzLmq=7w@mail.gmail.com>

Hi Peter,

Thanks - I think I understand the reasoning, but do have some issues
with it :) I understand the point that an "image" operation should not
mess up non-image variables; but what would be the meaning of a
"dimension" variable that is not related to (or indexes) an "image"?
Case in point, I doubt that there are many MINC users out there who
would realize that 'mincinfo -dimlength' or 'mincinfo -dimnames' does
not actually say anything about the number of "image" dimensions, and
I suspect there are many perl/python/other scripts out there (I
certainly have dozens) that use these exactly these mincinfo calls to
figure out what/how many dimensions the MINC "image" has - and so from
what you are saying, those scripts are actually all broken.

At the very least I think this needs clarification in the
documentation because the distinction you draw between "image" and
"dimension" I don't think is intuitive or clear. For instance, the
mincinfo man page says:

-image_info
              Print  out  the default general information about the file. This
              information includes the type, sign and range of the pixel data,
              the  order  of  the  dimensions, and a list of dimensions giving
              name, length, start and step for each one.

which implies it refers to "the file", not "the image variable"; while
it actually reports on the latter (only). I also looked through the
MINC2 reference manual, and I couldn't find anywhere where it
indicates that you may have a "dimension" that is not a dimension of
the actual image data (it does define "A dimension is simply an axis
or index along which the data is stored").

In practice, I would suggest that if there is a valid reason why a
"dimension" should/could exist independent from the "image" variable
(I still can't think of one), that some of the documentation should be
improved to make this distinction very clear; but if not, that the
tool(s) should be modified to consider "dimension" as always tied to
the "image" (in which case I would argue that the case I described
consititutes an inconsistent header, because it carries information
about a dimension that the actual image data doesn't have).

-- Alex

On Sat, Mar 24, 2012 at 12:35 AM, Peter Neelin <peter.neelin at gmail.com> wrote:
> Hi Alex,
>
> On Mar 23, 2012 11:16 AM, "Alex Zijdenbos" <zijdenbos at gmail.com> wrote:
>> I just noticed that 'mincaverage -avgdim' leaves lots of header
>> information in the resulting average for the dimension it averaged
>> out; which then causes trouble with mincinfo and the like. To me this
>> looks like a bug in mincaverage, in that when using -avgdim <dim> it
>> doesn't properly clean up the <dim>-related header attributes.
>
> Minc and netcdf allow for any number of dimensions to exist in the file.
> They are only relevant to the image data if they index the "image" variable
> in minc. mincaverage is removing the time dimension from the image
> variable, but it leaves the dimension itself alone. If other variables
> exist in the file, then they may be indexed by the time dimension. It might
> be argued that mincaverage should do something magical to all variables
> indexed by one of the dimensions (time in this case), but it would be
> rather arbitrary to average any variable in the file along that dimension.
> The contract of mincaverage is simply to average image data. Other data is
> left untouched.
>
>> So that looks right; we seem to have lost the time dimension. However,
>> using this mincinfo call:
>>
>> $ mincinfo -dimnames -dimlength time test_pet_avg.mnc
>> time xspace yspace zspace
>
> I don't think that this is what you want - this asks for all the dimensions
> in the file, which is what you are given. You should be using the -vardims
> option with "image" as the argument instead. This will tell you which
> dimensions are indexing the image variable. This is what mincinfo
> -image_info does.
>
> So bottom-line: I don't think that it is a bug - I think that it is doing
> the most appropriate thing. (Of course, I wrote it, so I would think that -
> you are free to disagree and change the contract/requirements if it suits
> you, but please bear in mind that minc is designed around a general file
> format and is intended to be extensible - I think that general-purpose
> tools like mincaverage should honour that intent and not mess up non-image
> data in the file.)
>
> Hope this helps.
>
> Peter
> --
> Peter Neelin
> peter.neelin at gmail.com
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From peter.neelin at gmail.com  Sun Mar 25 13:47:03 2012
From: peter.neelin at gmail.com (Peter Neelin)
Date: Sun, 25 Mar 2012 13:47:03 -0400
Subject: [MINC-users] mincaverage -avgdim result header
In-Reply-To: <CABEEk17ZVSFi-BpXcwLFO5iyVFfUMXueWu9M5M2HC_DzLmq=7w@mail.gmail.com>
References: <CABEEk17E_NDnuW2XZ94=O3AznBE8Q3yxkXAUGiN-TWm2h5z2oQ@mail.gmail.com>
	<CANcjyda13aN7ivx8We=B_6hDTJzXSx9w7zAidABJembYWVwR9w@mail.gmail.com>
	<CABEEk17ZVSFi-BpXcwLFO5iyVFfUMXueWu9M5M2HC_DzLmq=7w@mail.gmail.com>
Message-ID: <CANcjydb5JKfQONfnkHVzT7QHmtefPqzG75Jw_HGjipTw2U1bhA@mail.gmail.com>

Hi Alex,

On Mar 24, 2012 2:37 PM, "Alex Zijdenbos" <zijdenbos at gmail.com> wrote:

> but what would be the meaning of a
> "dimension" variable that is not related to (or indexes) an "image"?

Well, I can imagine having acquired non-image data along with the scan that
is also indexed by time. Blood activity for PET scans, for example
(although it is unlikely to have the same original sampling in the time
dimension, so it's not the best example since someone would have to
resample the blood data and merge it in); or stimulation-related data for
fMRI (on-off, maybe?). When running minaverage, what should be done with
this kind of data? Delete it, just because it is indexed by time? Average
it? That's rather arbitrary and not what the tool is intended to do.
Another option would be to remove the time dimension if there are no
variables referencing it (excluding the time variable). However, that just
leads to scripts that work sometimes.

> Case in point, I doubt that there are many MINC users out there who
> would realize that 'mincinfo -dimlength' or 'mincinfo -dimnames' does
> not actually say anything about the number of "image" dimensions, and
> I suspect there are many perl/python/other scripts out there (I
> certainly have dozens) that use these exactly these mincinfo calls to
> figure out what/how many dimensions the MINC "image" has - and so from
> what you are saying, those scripts are actually all broken.

Yes, they are. The idea of building on a generalized data format was that
it could be extended. Minc is really just a convention for using netcdf
along with libraries for imaging stuff and utility programs. Minc is not an
abstraction layer that hides netcdf. The expectation is that if you are
going to code at the netcdf level (core minc libraries and anything that
talks about dimensions and variables, like mincinfo) you should understand
basic netcdf. It's not really documented in minc because it's documented in
netcdf.

> At the very least I think this needs clarification in the
> documentation because the distinction you draw between "image" and
> "dimension" I don't think is intuitive or clear.

Yes. It is probably worth making clear that the netcf basics should be
understood, and maybe even re-iterating them somewhere.

> it actually reports on the latter (only). I also looked through the
> MINC2 reference manual, and I couldn't find anywhere where it
> indicates that you may have a "dimension" that is not a dimension of
> the actual image data (it does define "A dimension is simply an axis
> or index along which the data is stored").

That goes along with the general data format thing. I assume that the
netcdf concepts and interface are still documented somewhere.

> In practice, I would suggest that if there is a valid reason why a
> "dimension" should/could exist independent from the "image" variable
> (I still can't think of one), that some of the documentation should be
> improved to make this distinction very clear; but if not, that the
> tool(s) should be modified to consider "dimension" as always tied to
> the "image" (in which case I would argue that the case I described
> consititutes an inconsistent header, because it carries information
> about a dimension that the actual image data doesn't have).

Well, it is up to you guys to decide what you want minc to be. The original
conception was that it was good to allow arbitrary extension as a general
data format, with imaging conventions overlaid. But that generality may be
more annoying that useful, in which case it can be changed to be just an
image format. Then it makes sense to treat all dimensions and variables in
the context of  images. Not sure if that would mess with any existing users
of minc, though.

Peter
--
Peter Neelin
peter.neelin at gmail.com

From vladimir.fonov at gmail.com  Mon Mar 26 09:26:04 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Mon, 26 Mar 2012 09:26:04 -0400
Subject: [MINC-users] mincaverage -avgdim result header
In-Reply-To: <CANcjydb5JKfQONfnkHVzT7QHmtefPqzG75Jw_HGjipTw2U1bhA@mail.gmail.com>
References: <CABEEk17E_NDnuW2XZ94=O3AznBE8Q3yxkXAUGiN-TWm2h5z2oQ@mail.gmail.com>
	<CANcjyda13aN7ivx8We=B_6hDTJzXSx9w7zAidABJembYWVwR9w@mail.gmail.com>
	<CABEEk17ZVSFi-BpXcwLFO5iyVFfUMXueWu9M5M2HC_DzLmq=7w@mail.gmail.com>
	<CANcjydb5JKfQONfnkHVzT7QHmtefPqzG75Jw_HGjipTw2U1bhA@mail.gmail.com>
Message-ID: <CAMCwi7OGegEYQPCNAqcxV4qrU4UjTGfiG5YV21z0SNr4Hu60Mw@mail.gmail.com>

Hello,

On Sun, Mar 25, 2012 at 1:47 PM, Peter Neelin <peter.neelin at gmail.com> wrote:
> Yes, they are. The idea of building on a generalized data format was that
> it could be extended. Minc is really just a convention for using netcdf
> along with libraries for imaging stuff and utility programs. Minc is not an
> abstraction layer that hides netcdf. The expectation is that if you are
> going to code at the netcdf level (core minc libraries and anything that
> talks about dimensions and variables, like mincinfo) you should understand
> basic netcdf. It's not really documented in minc because it's documented in
> netcdf.

This just blew my brain...

1. what about minc2 - does one have to use HDF5 calls to work with it ?

2. practical observation - most minc users don't  care/read minc API
documentation. For them it is just another file format, like nifti or
nrrd. Most of the high-level perl code that I've seen uses system
calls to minc tools to work with the files. Does it mean that this is
incorrect approach?


-- 
Best regards,

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

From zijdenbos at gmail.com  Mon Mar 26 10:17:22 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Mon, 26 Mar 2012 10:17:22 -0400
Subject: [MINC-users] mincaverage -avgdim result header
In-Reply-To: <CAMCwi7OGegEYQPCNAqcxV4qrU4UjTGfiG5YV21z0SNr4Hu60Mw@mail.gmail.com>
References: <CABEEk17E_NDnuW2XZ94=O3AznBE8Q3yxkXAUGiN-TWm2h5z2oQ@mail.gmail.com>
	<CANcjyda13aN7ivx8We=B_6hDTJzXSx9w7zAidABJembYWVwR9w@mail.gmail.com>
	<CABEEk17ZVSFi-BpXcwLFO5iyVFfUMXueWu9M5M2HC_DzLmq=7w@mail.gmail.com>
	<CANcjydb5JKfQONfnkHVzT7QHmtefPqzG75Jw_HGjipTw2U1bhA@mail.gmail.com>
	<CAMCwi7OGegEYQPCNAqcxV4qrU4UjTGfiG5YV21z0SNr4Hu60Mw@mail.gmail.com>
Message-ID: <CABEEk16akeL=tDJrWrh0-m8Sr8U=bk_WKLXbaMTRLkqXa3e+XA@mail.gmail.com>

On Mon, Mar 26, 2012 at 9:26 AM, Vladimir S. FONOV
<vladimir.fonov at gmail.com> wrote:
> Hello,
>
> On Sun, Mar 25, 2012 at 1:47 PM, Peter Neelin <peter.neelin at gmail.com> wrote:
>> Yes, they are. The idea of building on a generalized data format was that
>> it could be extended. Minc is really just a convention for using netcdf
>> along with libraries for imaging stuff and utility programs. Minc is not an
>> abstraction layer that hides netcdf. The expectation is that if you are
>> going to code at the netcdf level (core minc libraries and anything that
>> talks about dimensions and variables, like mincinfo) you should understand
>> basic netcdf. It's not really documented in minc because it's documented in
>> netcdf.
>
> This just blew my brain...
>
> 1. what about minc2 - does one have to use HDF5 calls to work with it ?

This was one of my questions as well. We were discussing the
"dimension" variable; in my mind that was actually a MINC extension to
NetCDF, like the 'xspace' or 'acquisition' variables. But from what
Peter describes, and what the NetCDF documentation states, "dimension"
is actually a (pre-existing) NetCDF variable. In that context I can
see how we may want to retain the NetCDF concept behind that. But I
was also wondering how this works in HDF5 - does the same still apply?

> 2. practical observation - most minc users don't ?care/read minc API
> documentation. For them it is just another file format, like nifti or
> nrrd. Most of the high-level perl code that I've seen uses system
> calls to minc tools to work with the files. Does it mean that this is
> incorrect approach?

I hope not - I for one would have to throw out around 200,000 lines of
perl code if it were:-] From the beginning of this discussion I was
also thinking about the larger community of MINC users. Like you say
the vast majority of those only use the library of MINC tools and
don't actually code using the MINC API; so to them MINC really is a
file format like NIFTI (hopefully better). And from that perspective,
the fact that a core MINC tool like mincinfo with '-dimlength' or
'-dimnames' may not return what the user expects, is a problem. The
learning curve for MINC is already quite steep, and this type of
confusion doesn't help MINC in any popularity contest.

Now in practice I do think that this could be addressed by clarifying
things in the documentation; and/or adding perhaps some convenience
options to tools like mincinfo (e.g., mincinfo -image_dimnames). I
would be curious to know if there is anybody out there who may have
used 'mincinfo -dimnames' with the express purpose of finding
non-image dimensions?

At the more philosophical level, I have been wondering about MINC as
only adding functionality to NetCDF (which is the way Peter developed
it), or as a stand-alone file format encapsulating it; and whether
there is any difference in these philosophies between MINC1 and MINC2
in this respect. Is MINC2 more encapsulating to HDF5, as MINC1 is to
NetCDF? That's probably more a minc-dev discussion btw.

-- A

From peter.neelin at gmail.com  Mon Mar 26 23:02:26 2012
From: peter.neelin at gmail.com (Peter Neelin)
Date: Mon, 26 Mar 2012 23:02:26 -0400
Subject: [MINC-users] mincaverage -avgdim result header
In-Reply-To: <CAMCwi7OGegEYQPCNAqcxV4qrU4UjTGfiG5YV21z0SNr4Hu60Mw@mail.gmail.com>
References: <CABEEk17E_NDnuW2XZ94=O3AznBE8Q3yxkXAUGiN-TWm2h5z2oQ@mail.gmail.com>
	<CANcjyda13aN7ivx8We=B_6hDTJzXSx9w7zAidABJembYWVwR9w@mail.gmail.com>
	<CABEEk17ZVSFi-BpXcwLFO5iyVFfUMXueWu9M5M2HC_DzLmq=7w@mail.gmail.com>
	<CANcjydb5JKfQONfnkHVzT7QHmtefPqzG75Jw_HGjipTw2U1bhA@mail.gmail.com>
	<CAMCwi7OGegEYQPCNAqcxV4qrU4UjTGfiG5YV21z0SNr4Hu60Mw@mail.gmail.com>
Message-ID: <CANcjydYAeV+MV_qjb6LieG19AG64m4zYNYhn1TKWDm=6OEwHAA@mail.gmail.com>

On Mar 26, 2012 9:27 AM, "Vladimir S. FONOV" <vladimir.fonov at gmail.com>
wrote:
> > The expectation is that if you are
> > going to code at the netcdf level (core minc libraries and anything that
> > talks about dimensions and variables, like mincinfo) you should
understand
> > basic netcdf. It's not really documented in minc because it's
documented in
> > netcdf.
>
> This just blew my brain...
>
> 1. what about minc2 - does one have to use HDF5 calls to work with it?

As I understand it, HDF5 provides a netcdf interface. That's how minc works
with it. Remember, I'm talking about writing code that uses the lowest
level minc. Plus using mincinfo since I took the shortcut of just exposing
a bunch of netcdf calls through it, since netcdf did not provide any
command-line tool. I foolishly exposed low-level stuff to the command-line
through mincreshape as well. Back when I didn't think so much about
encapsulation and abstraction.

> 2. practical observation - most minc users don't  care/read minc API
> documentation. For them it is just another file format, like nifti or
> nrrd. Most of the high-level perl code that I've seen uses system
> calls to minc tools to work with the files. Does it mean that this is
> incorrect approach?

Not at all. It is in fact the right thing to do. Most minc programs are
abstractions on top of low-level minc and netcdf. Mincinfo isn't really.
But I would still suggest that it's worth learning something about the
basic file format if you are going to do anything fancy that tries to grok
the file format. It's sort of like playing with DICOM using dcmtk without
understanding anything about groups, elements, VRs, etc. These are the
basic concepts of the format.

On the other hand, using mincresample or mincaverage or minccalc, you
should mostly be able to ignore a lot of the lower-level stuff.
(Unfortunately, the abstraction is still rather leaky, so you are still
exposed to a lot of the low-level stuff like typing and dimension ordering)

Peter
--
Peter Neelin
peter.neelin at gmail.com

From a.janke at gmail.com  Mon Mar 26 23:14:02 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 27 Mar 2012 13:14:02 +1000
Subject: [MINC-users] mincaverage -avgdim result header
In-Reply-To: <CANcjydYAeV+MV_qjb6LieG19AG64m4zYNYhn1TKWDm=6OEwHAA@mail.gmail.com>
References: <CABEEk17E_NDnuW2XZ94=O3AznBE8Q3yxkXAUGiN-TWm2h5z2oQ@mail.gmail.com>
	<CANcjyda13aN7ivx8We=B_6hDTJzXSx9w7zAidABJembYWVwR9w@mail.gmail.com>
	<CABEEk17ZVSFi-BpXcwLFO5iyVFfUMXueWu9M5M2HC_DzLmq=7w@mail.gmail.com>
	<CANcjydb5JKfQONfnkHVzT7QHmtefPqzG75Jw_HGjipTw2U1bhA@mail.gmail.com>
	<CAMCwi7OGegEYQPCNAqcxV4qrU4UjTGfiG5YV21z0SNr4Hu60Mw@mail.gmail.com>
	<CANcjydYAeV+MV_qjb6LieG19AG64m4zYNYhn1TKWDm=6OEwHAA@mail.gmail.com>
Message-ID: <CAG0CB20zQ17OiUCXFaTaSiYT+bt65Ny4tTfAxbMAzFiH1ide7w@mail.gmail.com>

> I foolishly exposed low-level stuff to the command-line
> through mincreshape as well. Back when I didn't think so much about
> encapsulation and abstraction.

Don't forget mincview with ncdump! :)  Although Bert fixed this up
with mincdump and mincgen so all good now. And then I rewrote all of
mincview with sh, and then...  but I digress.

> Not at all. It is in fact the right thing to do. Most minc programs are
> abstractions on top of low-level minc and netcdf. Mincinfo isn't really.
> But I would still suggest that it's worth learning something about the
> basic file format if you are going to do anything fancy that tries to grok
> the file format. It's sort of like playing with DICOM using dcmtk without
> understanding anything about groups, elements, VRs, etc. These are the
> basic concepts of the format.

Agree whole-heartedly. I'm with Peter on this one, as it is right now
I see no reason to change anything. One of the beauties of MINC is how
flexible it can be. I have used it to store multi-channel EEG data
with a nice history of processing and am currently using it to store
multi-focal Histology data with included absorption data. I see no
reason as to why we should dumb down this flexibility to the point
that MINC can only handle 3D/4D images. Granted this is its main use
but it's not the only use.

I know I'm being elitist, but if all you want is a quick and dirty
format that can handle images there are others around. But by all
means I'm more than happy to review and possibly include any push to
the develop branch of MINC on github!


a

From peter.neelin at gmail.com  Mon Mar 26 23:22:15 2012
From: peter.neelin at gmail.com (Peter Neelin)
Date: Mon, 26 Mar 2012 23:22:15 -0400
Subject: [MINC-users] mincaverage -avgdim result header
In-Reply-To: <CABEEk16akeL=tDJrWrh0-m8Sr8U=bk_WKLXbaMTRLkqXa3e+XA@mail.gmail.com>
References: <CABEEk17E_NDnuW2XZ94=O3AznBE8Q3yxkXAUGiN-TWm2h5z2oQ@mail.gmail.com>
	<CANcjyda13aN7ivx8We=B_6hDTJzXSx9w7zAidABJembYWVwR9w@mail.gmail.com>
	<CABEEk17ZVSFi-BpXcwLFO5iyVFfUMXueWu9M5M2HC_DzLmq=7w@mail.gmail.com>
	<CANcjydb5JKfQONfnkHVzT7QHmtefPqzG75Jw_HGjipTw2U1bhA@mail.gmail.com>
	<CAMCwi7OGegEYQPCNAqcxV4qrU4UjTGfiG5YV21z0SNr4Hu60Mw@mail.gmail.com>
	<CABEEk16akeL=tDJrWrh0-m8Sr8U=bk_WKLXbaMTRLkqXa3e+XA@mail.gmail.com>
Message-ID: <CANcjyda3Z5qbLNLUaPcdPaAPxdejAZdeD9g-fE3mcivwEdxvpw@mail.gmail.com>

On Mar 26, 2012 10:18 AM, "Alex Zijdenbos" <zijdenbos at gmail.com> wrote:
>
> On Mon, Mar 26, 2012 at 9:26 AM, Vladimir S. FONOV
> <vladimir.fonov at gmail.com> wrote:
> > 1. what about minc2 - does one have to use HDF5 calls to work with it ?
>
> This was one of my questions as well. We were discussing the
> "dimension" variable; in my mind that was actually a MINC extension to
> NetCDF, like the 'xspace' or 'acquisition' variables. But from what
> Peter describes, and what the NetCDF documentation states, "dimension"
> is actually a (pre-existing) NetCDF variable.

In netcdf, you have variables that are indexed by dimensions. So any
multi-dimensional data is indexed by a set of dimensions which clearly
defines the relationship between variables. Variables also have attributes.
Minc uses a variable with the same name as a dimension to describe the
sampling of the dimension (actually, that might be a netcdf convention -
I've forgotten - but minc uses the shorthand of start and step for regular
dimensions).

If you only have image dimensions in a file, then you cannot represent any
other multi-dimensional data in that file.

> In that context I can
> see how we may want to retain the NetCDF concept behind that. But I
> was also wondering how this works in HDF5 - does the same still apply?

It's been years since I looked at HDF, but they originally just lifted the
netcdf interface because their own was far too complicated to use in real
life (I'm guessing at their motivation). They layered the netcdf concepts
on top of their own data format. I assume that HDF5 carries this forward.

> the vast majority of those only use the library of MINC tools and
> don't actually code using the MINC API; so to them MINC really is a
> file format like NIFTI (hopefully better). And from that perspective,
> the fact that a core MINC tool like mincinfo with '-dimlength' or
> '-dimnames' may not return what the user expects, is a problem. The
> learning curve for MINC is already quite steep, and this type of
> confusion doesn't help MINC in any popularity contest.

My apologies  for putting this functionality into mincinfo and mincreshape.
Mincinfo exposes low-level netcdf and mincreshape exposes low-level minc
"image conversion variables". I should have hidden that in some other
command-line tools to avoid causing confusion. Don't use mincinfo with
options unless you understand netcdf (look at the netcdf library, I believe
the mincinfo options are just plain wrappers to the netcdf functions). And
watch out for using mincreshape's auto-magical properties for flipping,
etc. (I've watch Andrew try to explain those a few time.) Many apologies
for those. It just seemed so damn convenient to expose library routines
that I wrote to make it easy for Alan to use minc in ROI and other PET
analysis tools of the early 90's. I should have left them hidden.

Information hiding. I should have read Parnas twenty years ago. Sigh.

(Hey - minc is 20 years old this summer, I think - Alan went on a 5-week
canoe trip in the Yukon and minc was born. Wow, we're all getting old!)

> At the more philosophical level, I have been wondering about MINC as
> only adding functionality to NetCDF (which is the way Peter developed
> it), or as a stand-alone file format encapsulating it; and whether
> there is any difference in these philosophies between MINC1 and MINC2
> in this respect. Is MINC2 more encapsulating to HDF5, as MINC1 is to
> NetCDF? That's probably more a minc-dev discussion btw.

I'll leave you folks to that discussion.

Peter
--
Peter Neelin
peter.neelin at gmail.com

From peter.neelin at gmail.com  Tue Mar 27 00:45:25 2012
From: peter.neelin at gmail.com (Peter Neelin)
Date: Tue, 27 Mar 2012 00:45:25 -0400
Subject: [MINC-users] mincaverage -avgdim result header
In-Reply-To: <CANcjydYAeV+MV_qjb6LieG19AG64m4zYNYhn1TKWDm=6OEwHAA@mail.gmail.com>
References: <CABEEk17E_NDnuW2XZ94=O3AznBE8Q3yxkXAUGiN-TWm2h5z2oQ@mail.gmail.com>
	<CANcjyda13aN7ivx8We=B_6hDTJzXSx9w7zAidABJembYWVwR9w@mail.gmail.com>
	<CABEEk17ZVSFi-BpXcwLFO5iyVFfUMXueWu9M5M2HC_DzLmq=7w@mail.gmail.com>
	<CANcjydb5JKfQONfnkHVzT7QHmtefPqzG75Jw_HGjipTw2U1bhA@mail.gmail.com>
	<CAMCwi7OGegEYQPCNAqcxV4qrU4UjTGfiG5YV21z0SNr4Hu60Mw@mail.gmail.com>
	<CANcjydYAeV+MV_qjb6LieG19AG64m4zYNYhn1TKWDm=6OEwHAA@mail.gmail.com>
Message-ID: <CANcjydagz_vfym1Gf1xYYcT4Jyvd-3yVJk5-VOQ5t65wYH_5hA@mail.gmail.com>

On Mar 26, 2012 11:02 PM, "Peter Neelin" <peter.neelin at gmail.com> wrote:
> As I understand it, HDF5 provides a netcdf interface. That's how minc
works with it.

Looks like I got that wrong. HDF3 provided a netcdf interface. Looks like
they took it out in HDF4 and HDF5 and some kindly soul (Leila?) wrote a
complete wrapper layer. Perhaps someone with some knowledge can provide
details. So I don't know if the netcdf concepts are reflected in the HDF5
format or only in the wrapper layer... Is there any documentation for this
stuff now?

Peter
--
Peter Neelin
peter.neelin at gmail.com

From baghdadi at phenogenomics.ca  Tue Mar 27 12:20:44 2012
From: baghdadi at phenogenomics.ca (Leila Baghdadi)
Date: Tue, 27 Mar 2012 12:20:44 -0400
Subject: [MINC-users] mincaverage -avgdim result header
Message-ID: <3048999.16071332865244698.JavaMail.root@mail2.phenogenomics.ca>

Hi guys,

To my knowledge there is no need to make HDF5 calls to "use" minc2, as the minc2 API functions will take care of that for you. I have written different software that uses minc2 and never had to go down to hdf5 layer, however, I have added more functionality to minc2 (HDF5 calls) if I discovered there was a need for a functionality which was not accounted for but this was one or two cases.
I would say that we certainly meant to keep the level of encapsulation of minc2 to be very similar to minc1.
 If you are referring to backward compatibility, last I recall, it is provided by a module which emulates a restricted subset of NETCDF calls.

and finally, I am sorry to say that documentation is nowhere near what it should be!
perhaps one day :)

one of the minc2 souls

----- Original Message -----
From: Peter Neelin <peter.neelin at gmail.com>
Sent: Tue, 3/27/2012 12:45am
To: MINC users mailing list <minc-users at bic.mni.mcgill.ca>
Subject: Re: [MINC-users] mincaverage -avgdim result header

On Mar 26, 2012 11:02 PM, "Peter Neelin" <peter.neelin at gmail.com> wrote:
> As I understand it, HDF5 provides a netcdf interface. That's how minc
works with it.

Looks like I got that wrong. HDF3 provided a netcdf interface. Looks like
they took it out in HDF4 and HDF5 and some kindly soul (Leila?) wrote a
complete wrapper layer. Perhaps someone with some knowledge can provide
details. So I don't know if the netcdf concepts are reflected in the HDF5
format or only in the wrapper layer... Is there any documentation for this
stuff now?

Peter
--
Peter Neelin
peter.neelin at gmail.com
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From peter.neelin at gmail.com  Tue Mar 27 19:42:34 2012
From: peter.neelin at gmail.com (Peter Neelin)
Date: Tue, 27 Mar 2012 19:42:34 -0400
Subject: [MINC-users] mincaverage -avgdim result header
In-Reply-To: <3048999.16071332865244698.JavaMail.root@mail2.phenogenomics.ca>
References: <3048999.16071332865244698.JavaMail.root@mail2.phenogenomics.ca>
Message-ID: <CANcjydaa46yDLymPWLPyE+jqrAR5xXob9WuY47S6dFmDRDBqgA@mail.gmail.com>

On Mar 27, 2012 12:21 PM, "Leila Baghdadi" <baghdadi at phenogenomics.ca>
wrote:

> I would say that we certainly meant to keep the level of encapsulation of
minc2 to be very similar to minc1.
>  If you are referring to backward compatibility, last I recall, it is
provided by a module which emulates a restricted subset of NETCDF calls.

So basically it still looks like netcdf to the low-level applications and
the exposed concepts are all the same.

> and finally, I am sorry to say that documentation is nowhere near what it
should be!

It sounds like the old netcdf documentation still applies, in large
measure. It might be nice for someone to add a basic netcdf concepts
section to the minc documentation so that users and script writers can get
a simple overview of how things work. (There's not that much to it, really,
which is why it is nice. Named dimensions that have length, named variables
that have type and are indexed by dimensions, named attributes associated
with variables that have type and length, plus global attributes. That's
about it, or at least all that's left in my head after ten years.)

> perhaps one day :)

Oh, I know that sentiment!

Peter
--
Peter Neelin
peter.neelin at gmail.com

From kie_woo.nam at kcl.ac.uk  Wed Mar 28 05:50:41 2012
From: kie_woo.nam at kcl.ac.uk (Nam, Kie Woo)
Date: Wed, 28 Mar 2012 09:50:41 +0000
Subject: [MINC-users] Best way to convert UNC to MINC
Message-ID: <194921E98A6CEC41B0C14C804A56CC90D023D2@DBXPRD0310MB382.eurprd03.prod.outlook.com>

Dear MINC experts,

I'm sorry to keep asking similar questions recently, but could someone please tell me the best way to convert UNC images into MINC format?





Just for your information, I'm thinking of converting my original images (in coronal plane and UNC format) as shown below.

  1.  UNC --> Analyze (using "unc2analyze")
  2.  Analyze --> MINC (using "nii2mnc")

*I've tried converting UNC directly into MINC using "unc2mnc", but these MINC image was not properly displayed using "register".





So, my questions are shown below.

  1.  Is this the best way to convert UNC images into MINC format?
     *   If "no", could you please recommend the "best" way?
     *   If "yes", would you be able to also confirm whether "nii2mnc" works better than "rawtominc" (just as "nii2mnc" works better than "ana2mnc")?




I would be grateful for the answers.


Many thanks,

Kie Woo




Kie Woo Nam
Postgraduate Research Student
Division of Psychological Medicine
Department of Psychosis Studies
Institute of Psychiatry, King?s College London
De Crespigny Park, Denmark Hill
London SE5 8AF, UK
Tel: +44 (0)20 7848 0061

From a.janke at gmail.com  Wed Mar 28 07:52:38 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 28 Mar 2012 21:52:38 +1000
Subject: [MINC-users] Best way to convert UNC to MINC
In-Reply-To: <194921E98A6CEC41B0C14C804A56CC90D023D2@DBXPRD0310MB382.eurprd03.prod.outlook.com>
References: <194921E98A6CEC41B0C14C804A56CC90D023D2@DBXPRD0310MB382.eurprd03.prod.outlook.com>
Message-ID: <CAG0CB20HiX59rCZKxgEauFBY2qwoegFyVuKa=huyUmg8-dpueg@mail.gmail.com>

> I'm sorry to keep asking similar questions recently, but could someone please tell me the best way to
> convert UNC images into MINC format?  I've tried converting UNC directly into MINC using "unc2mnc", > but these MINC image was not properly displayed using "register".

> ?1. ?Is this the best way to convert UNC images into MINC format?

Probably by using unc2mnc, having yet another format in the middle is
never a good idea. I wrote unc2mnc as a quick hack a long time ago but
as far as I am aware the format hasn't changed much.

As discussed already, there is no way you are going to get around the
"coronal" conversion problems as from what I know despite the images
being stored in UNC in "coronal" orientation there is no way to deduce
this from the UNC file. As such unc2mnc presumes all UNC images are
transverse. At least this is how I remember things!


a

From kie_woo.nam at kcl.ac.uk  Wed Mar 28 08:20:24 2012
From: kie_woo.nam at kcl.ac.uk (Nam, Kie Woo)
Date: Wed, 28 Mar 2012 12:20:24 +0000
Subject: [MINC-users] Best way to convert UNC to MINC
In-Reply-To: <CAG0CB20HiX59rCZKxgEauFBY2qwoegFyVuKa=huyUmg8-dpueg@mail.gmail.com>
References: <194921E98A6CEC41B0C14C804A56CC90D023D2@DBXPRD0310MB382.eurprd03.prod.outlook.com>,
	<CAG0CB20HiX59rCZKxgEauFBY2qwoegFyVuKa=huyUmg8-dpueg@mail.gmail.com>
Message-ID: <194921E98A6CEC41B0C14C804A56CC90D0253E@DBXPRD0310MB382.eurprd03.prod.outlook.com>

Dear Dr Andrew Janke,

Thank you very much for the answer. I understand that I can convert a coronal UNC image into MINC format either by using (1) "coronal2axial" and "unc2mnc" or (2) "unc2analyze" and "nii2mnc" or "rawtominc".

So, I'm very sorry to bother you again, but would you be able to recommend which one to use between "nii2mnc" and "rawtominc" if I try option (2)? I wish to try both options because I'm equally worried about the risk from coronal-to-axial conversion as much as that from the UNC-to-Analyze one.

Many thanks,

Kie Woo



Kie Woo Nam
Postgraduate Research Student
Division of Psychological Medicine
Department of Psychosis Studies
Institute of Psychiatry, King?s College London
De Crespigny Park, Denmark Hill
London SE5 8AF, UK
Tel: +44 (0)20 7848 0061

________________________________________
From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Andrew Janke [a.janke at gmail.com]
Sent: 28 March 2012 12:52
To: MINC users mailing list
Cc: Simmons, Andy
Subject: Re: [MINC-users] Best way to convert UNC to MINC

> I'm sorry to keep asking similar questions recently, but could someone please tell me the best way to
> convert UNC images into MINC format?  I've tried converting UNC directly into MINC using "unc2mnc", > but these MINC image was not properly displayed using "register".

>  1.  Is this the best way to convert UNC images into MINC format?

Probably by using unc2mnc, having yet another format in the middle is
never a good idea. I wrote unc2mnc as a quick hack a long time ago but
as far as I am aware the format hasn't changed much.

As discussed already, there is no way you are going to get around the
"coronal" conversion problems as from what I know despite the images
being stored in UNC in "coronal" orientation there is no way to deduce
this from the UNC file. As such unc2mnc presumes all UNC images are
transverse. At least this is how I remember things!


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



From a.janke at gmail.com  Wed Mar 28 08:24:37 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 28 Mar 2012 22:24:37 +1000
Subject: [MINC-users] Best way to convert UNC to MINC
In-Reply-To: <194921E98A6CEC41B0C14C804A56CC90D0253E@DBXPRD0310MB382.eurprd03.prod.outlook.com>
References: <194921E98A6CEC41B0C14C804A56CC90D023D2@DBXPRD0310MB382.eurprd03.prod.outlook.com>
	<CAG0CB20HiX59rCZKxgEauFBY2qwoegFyVuKa=huyUmg8-dpueg@mail.gmail.com>
	<194921E98A6CEC41B0C14C804A56CC90D0253E@DBXPRD0310MB382.eurprd03.prod.outlook.com>
Message-ID: <CAG0CB22Mh1ZTtQT3qrJgv4LfoqXPW7J3zsoPOfJJEdoCKPRE=Q@mail.gmail.com>

On 28 March 2012 22:20, Nam, Kie Woo <kie_woo.nam at kcl.ac.uk> wrote:
> Thank you very much for the answer. I understand that I can convert a coronal UNC image into MINC format either by using (1) "coronal2axial" and "unc2mnc" or (2) "unc2analyze" and "nii2mnc" or "rawtominc".

And I'd be sticking with #1.

> So, I'm very sorry to bother you again, but would you be able to recommend which one to use between "nii2mnc" and "rawtominc" if I try option (2)? I wish to try both options because I'm equally worried about the risk from coronal-to-axial conversion as much as that from the UNC-to-Analyze one.

Well the obvious choice is nii2mnc as then you won't have to figure
out orientations, image sizes, image ranges, direction cosines etc and
pass them all in to rawtominc as parameters manually.  If you meant
nii2mnc or ana2mnc then the answer is nii2mnc.


a

From kie_woo.nam at kcl.ac.uk  Wed Mar 28 09:06:30 2012
From: kie_woo.nam at kcl.ac.uk (Nam, Kie Woo)
Date: Wed, 28 Mar 2012 13:06:30 +0000
Subject: [MINC-users] Best way to convert UNC to MINC
In-Reply-To: <CAG0CB22Mh1ZTtQT3qrJgv4LfoqXPW7J3zsoPOfJJEdoCKPRE=Q@mail.gmail.com>
References: <194921E98A6CEC41B0C14C804A56CC90D023D2@DBXPRD0310MB382.eurprd03.prod.outlook.com>
	<CAG0CB20HiX59rCZKxgEauFBY2qwoegFyVuKa=huyUmg8-dpueg@mail.gmail.com>
	<194921E98A6CEC41B0C14C804A56CC90D0253E@DBXPRD0310MB382.eurprd03.prod.outlook.com>,
	<CAG0CB22Mh1ZTtQT3qrJgv4LfoqXPW7J3zsoPOfJJEdoCKPRE=Q@mail.gmail.com>
Message-ID: <194921E98A6CEC41B0C14C804A56CC90D0255B@DBXPRD0310MB382.eurprd03.prod.outlook.com>

Dear Andrew Janke,

Thank you very much for your further answers. I very much appreciate your patience.

Best wishes,

Kie Woo



Kie Woo Nam
Postgraduate Research Student
Division of Psychological Medicine
Department of Psychosis Studies
Institute of Psychiatry, King?s College London
De Crespigny Park, Denmark Hill
London SE5 8AF, UK
Tel: +44 (0)20 7848 0061

________________________________________
From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Andrew Janke [a.janke at gmail.com]
Sent: 28 March 2012 13:24
To: MINC users mailing list
Cc: Simmons, Andy
Subject: Re: [MINC-users] Best way to convert UNC to MINC

On 28 March 2012 22:20, Nam, Kie Woo <kie_woo.nam at kcl.ac.uk> wrote:
> Thank you very much for the answer. I understand that I can convert a coronal UNC image into MINC format either by using (1) "coronal2axial" and "unc2mnc" or (2) "unc2analyze" and "nii2mnc" or "rawtominc".

And I'd be sticking with #1.

> So, I'm very sorry to bother you again, but would you be able to recommend which one to use between "nii2mnc" and "rawtominc" if I try option (2)? I wish to try both options because I'm equally worried about the risk from coronal-to-axial conversion as much as that from the UNC-to-Analyze one.

Well the obvious choice is nii2mnc as then you won't have to figure
out orientations, image sizes, image ranges, direction cosines etc and
pass them all in to rawtominc as parameters manually.  If you meant
nii2mnc or ana2mnc then the answer is nii2mnc.


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