From andrew at biospective.com  Tue Jun  3 16:53:46 2014
From: andrew at biospective.com (Andrew Wood)
Date: Tue, 3 Jun 2014 16:53:46 -0400
Subject: [MINC-users] Building bicpl-1.6.4 on Ubuntu 12.04
Message-ID: <CABApf9HiQNaaGZoy4yO=j5kJ=4jXRmuGYuiyPADZGteQ7isyDQ@mail.gmail.com>

Hi all,

I'm trying to build bicpl-1.6.4 on Ubuntu 12.04 and am having some trouble.

Here's my configure command:
./configure --with-minc2 --with-build-path=/usr/local/bic/ --with-image-ppm

Everything goes well until the Testing/ subdirectory, where I get this:

gcc -g -O2 -o test_rgb_io test_rgb_io.o  -L/usr/local/bic//lib
../.libs/libbicpl.a -lppm -lvolume_io2 -lminc2 /usr/lib/libhdf5.so
-lpthread -lz -lnetcdf -lm
/usr/bin/ld: ../.libs/libbicpl.a(rgb_io.o): undefined reference to symbol
'pm_freerow'
/usr/bin/ld: note: 'pm_freerow' is defined in DSO /usr/lib64/libpbm.so.9 so
try adding it to the linker command line
/usr/lib64/libpbm.so.9: could not read symbols: Invalid operation


Manually running the gcc command with "-lpbm" at the end, as suggested by
the prompt, works fine. Is there a good reason that the build system isn't
passing along the linker flags? Have I made a mistake with the configure
args?

Thanks,
Andrew

From a.janke at gmail.com  Tue Jun  3 21:12:27 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 4 Jun 2014 11:12:27 +1000
Subject: [MINC-users] Building bicpl-1.6.4 on Ubuntu 12.04
In-Reply-To: <CABApf9HiQNaaGZoy4yO=j5kJ=4jXRmuGYuiyPADZGteQ7isyDQ@mail.gmail.com>
References: <CABApf9HiQNaaGZoy4yO=j5kJ=4jXRmuGYuiyPADZGteQ7isyDQ@mail.gmail.com>
Message-ID: <CAG0CB230kMybY9M+fO7rGYizxMZgnGRaEWGJCYDh4HMxTLTP5g@mail.gmail.com>

Hi Andrew,

No you haven't made a mistake with the configure args. It's a
shortcoming of how libtool is handled in the old MINC build system for
binary packages packages.

If you build MINC from source (any release) or use any of the later
packages (mni-toolkit) you shouldn't see this problem.

In any case I'd recommend shifting to Vlad's new CMake build system
for MINC as very little of the old autoconf/make code will now be kept
up to date.

ta


a


On 4 June 2014 06:53, Andrew Wood <andrew at biospective.com> wrote:
> Hi all,
>
> I'm trying to build bicpl-1.6.4 on Ubuntu 12.04 and am having some trouble.
>
> Here's my configure command:
> ./configure --with-minc2 --with-build-path=/usr/local/bic/ --with-image-ppm
>
> Everything goes well until the Testing/ subdirectory, where I get this:
>
> gcc -g -O2 -o test_rgb_io test_rgb_io.o  -L/usr/local/bic//lib
> ../.libs/libbicpl.a -lppm -lvolume_io2 -lminc2 /usr/lib/libhdf5.so
> -lpthread -lz -lnetcdf -lm
> /usr/bin/ld: ../.libs/libbicpl.a(rgb_io.o): undefined reference to symbol
> 'pm_freerow'
> /usr/bin/ld: note: 'pm_freerow' is defined in DSO /usr/lib64/libpbm.so.9 so
> try adding it to the linker command line
> /usr/lib64/libpbm.so.9: could not read symbols: Invalid operation
>
>
> Manually running the gcc command with "-lpbm" at the end, as suggested by
> the prompt, works fine. Is there a good reason that the build system isn't
> passing along the linker flags? Have I made a mistake with the configure
> args?
>
> Thanks,
> Andrew
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From andrew at biospective.com  Wed Jun  4 09:50:06 2014
From: andrew at biospective.com (Andrew Wood)
Date: Wed, 4 Jun 2014 09:50:06 -0400
Subject: [MINC-users] Building bicpl-1.6.4 on Ubuntu 12.04
In-Reply-To: <CAG0CB230kMybY9M+fO7rGYizxMZgnGRaEWGJCYDh4HMxTLTP5g@mail.gmail.com>
References: <CABApf9HiQNaaGZoy4yO=j5kJ=4jXRmuGYuiyPADZGteQ7isyDQ@mail.gmail.com>
	<CAG0CB230kMybY9M+fO7rGYizxMZgnGRaEWGJCYDh4HMxTLTP5g@mail.gmail.com>
Message-ID: <CABApf9FA1051y_DLP9oW8gE5MBaBCE_fdCSnyDqgm8otFAtbuA@mail.gmail.com>

Hi Andrew,

I'd grabbed bicpl-1.6.4 from http://packages.bic.mni.mcgill.ca/tgz/. I've
switched over to the CMake system where possible, but the bicpl releases
all predate Vlad's CMake build system, so are we not stuck with libtool for
this?

I could grab a release from Github, but I'd just be rerunning the
autotools, no?

Thanks,
Andrew


On Tue, Jun 3, 2014 at 9:12 PM, Andrew Janke <a.janke at gmail.com> wrote:

> Hi Andrew,
>
> No you haven't made a mistake with the configure args. It's a
> shortcoming of how libtool is handled in the old MINC build system for
> binary packages packages.
>
> If you build MINC from source (any release) or use any of the later
> packages (mni-toolkit) you shouldn't see this problem.
>
> In any case I'd recommend shifting to Vlad's new CMake build system
> for MINC as very little of the old autoconf/make code will now be kept
> up to date.
>
> ta
>
>
> a
>
>
> On 4 June 2014 06:53, Andrew Wood <andrew at biospective.com> wrote:
> > Hi all,
> >
> > I'm trying to build bicpl-1.6.4 on Ubuntu 12.04 and am having some
> trouble.
> >
> > Here's my configure command:
> > ./configure --with-minc2 --with-build-path=/usr/local/bic/
> --with-image-ppm
> >
> > Everything goes well until the Testing/ subdirectory, where I get this:
> >
> > gcc -g -O2 -o test_rgb_io test_rgb_io.o  -L/usr/local/bic//lib
> > ../.libs/libbicpl.a -lppm -lvolume_io2 -lminc2 /usr/lib/libhdf5.so
> > -lpthread -lz -lnetcdf -lm
> > /usr/bin/ld: ../.libs/libbicpl.a(rgb_io.o): undefined reference to symbol
> > 'pm_freerow'
> > /usr/bin/ld: note: 'pm_freerow' is defined in DSO /usr/lib64/libpbm.so.9
> so
> > try adding it to the linker command line
> > /usr/lib64/libpbm.so.9: could not read symbols: Invalid operation
> >
> >
> > Manually running the gcc command with "-lpbm" at the end, as suggested by
> > the prompt, works fine. Is there a good reason that the build system
> isn't
> > passing along the linker flags? Have I made a mistake with the configure
> > args?
> >
> > Thanks,
> > Andrew
> > _______________________________________________
> > 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 Jun  4 09:59:49 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 4 Jun 2014 23:59:49 +1000
Subject: [MINC-users] Building bicpl-1.6.4 on Ubuntu 12.04
In-Reply-To: <CABApf9FA1051y_DLP9oW8gE5MBaBCE_fdCSnyDqgm8otFAtbuA@mail.gmail.com>
References: <CABApf9HiQNaaGZoy4yO=j5kJ=4jXRmuGYuiyPADZGteQ7isyDQ@mail.gmail.com>
	<CAG0CB230kMybY9M+fO7rGYizxMZgnGRaEWGJCYDh4HMxTLTP5g@mail.gmail.com>
	<CABApf9FA1051y_DLP9oW8gE5MBaBCE_fdCSnyDqgm8otFAtbuA@mail.gmail.com>
Message-ID: <CAG0CB20hXF1Y39JuZ791Wtv_dvU5zcpshm64df1BzmY3TJ6_Kg@mail.gmail.com>

Hi Andrew,

Sorry, I should have been more clear, you'll need to build the
dependencies using the new packaging system. Libtool then picks up the
libraries from the .la files in these for subsequent packages.

In this case my memory tells me it's EBTKS that you need to build from
scratch so that the .la files for it include the correct things. In
this case -lpbm



a

On 4 June 2014 23:50, Andrew Wood <andrew at biospective.com> wrote:
> Hi Andrew,
>
> I'd grabbed bicpl-1.6.4 from http://packages.bic.mni.mcgill.ca/tgz/. I've
> switched over to the CMake system where possible, but the bicpl releases
> all predate Vlad's CMake build system, so are we not stuck with libtool for
> this?
>
> I could grab a release from Github, but I'd just be rerunning the
> autotools, no?
>
> Thanks,
> Andrew
>
>
> On Tue, Jun 3, 2014 at 9:12 PM, Andrew Janke <a.janke at gmail.com> wrote:
>
>> Hi Andrew,
>>
>> No you haven't made a mistake with the configure args. It's a
>> shortcoming of how libtool is handled in the old MINC build system for
>> binary packages packages.
>>
>> If you build MINC from source (any release) or use any of the later
>> packages (mni-toolkit) you shouldn't see this problem.
>>
>> In any case I'd recommend shifting to Vlad's new CMake build system
>> for MINC as very little of the old autoconf/make code will now be kept
>> up to date.
>>
>> ta
>>
>>
>> a
>>
>>
>> On 4 June 2014 06:53, Andrew Wood <andrew at biospective.com> wrote:
>> > Hi all,
>> >
>> > I'm trying to build bicpl-1.6.4 on Ubuntu 12.04 and am having some
>> trouble.
>> >
>> > Here's my configure command:
>> > ./configure --with-minc2 --with-build-path=/usr/local/bic/
>> --with-image-ppm
>> >
>> > Everything goes well until the Testing/ subdirectory, where I get this:
>> >
>> > gcc -g -O2 -o test_rgb_io test_rgb_io.o  -L/usr/local/bic//lib
>> > ../.libs/libbicpl.a -lppm -lvolume_io2 -lminc2 /usr/lib/libhdf5.so
>> > -lpthread -lz -lnetcdf -lm
>> > /usr/bin/ld: ../.libs/libbicpl.a(rgb_io.o): undefined reference to symbol
>> > 'pm_freerow'
>> > /usr/bin/ld: note: 'pm_freerow' is defined in DSO /usr/lib64/libpbm.so.9
>> so
>> > try adding it to the linker command line
>> > /usr/lib64/libpbm.so.9: could not read symbols: Invalid operation
>> >
>> >
>> > Manually running the gcc command with "-lpbm" at the end, as suggested by
>> > the prompt, works fine. Is there a good reason that the build system
>> isn't
>> > passing along the linker flags? Have I made a mistake with the configure
>> > args?
>> >
>> > Thanks,
>> > Andrew
>> > _______________________________________________
>> > MINC-users at bic.mni.mcgill.ca
>> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From andrew at biospective.com  Wed Jun  4 10:28:11 2014
From: andrew at biospective.com (Andrew Wood)
Date: Wed, 4 Jun 2014 10:28:11 -0400
Subject: [MINC-users] Building bicpl-1.6.4 on Ubuntu 12.04
In-Reply-To: <CAG0CB20hXF1Y39JuZ791Wtv_dvU5zcpshm64df1BzmY3TJ6_Kg@mail.gmail.com>
References: <CABApf9HiQNaaGZoy4yO=j5kJ=4jXRmuGYuiyPADZGteQ7isyDQ@mail.gmail.com>
	<CAG0CB230kMybY9M+fO7rGYizxMZgnGRaEWGJCYDh4HMxTLTP5g@mail.gmail.com>
	<CABApf9FA1051y_DLP9oW8gE5MBaBCE_fdCSnyDqgm8otFAtbuA@mail.gmail.com>
	<CAG0CB20hXF1Y39JuZ791Wtv_dvU5zcpshm64df1BzmY3TJ6_Kg@mail.gmail.com>
Message-ID: <CABApf9HYefvhXPAQ=0g9_4LxT=s+yR2fw8kbeQ1=FhzTzX2ccg@mail.gmail.com>

Hi Andrew,

I'm actually building all of the BIC/MNI stuff from scratch (tarball
releases).

So my configure command was really this:
./configure --with-minc2 --prefix=/my/build/ --with-build-path=/my/build/
--with-image-ppm

It may be worth noting that the script I use to build this stuff used to
work on Ubuntu 10.04.

I'm looking at an old build log, and the gcc command which is currently
failing actually worked on 10.04 (i.e. it didn't have -lpbm either). So
something must have changed in the ppm/pbm libraries? Or perhaps I had
statically linked a library before which is currently trying to link
dynamically?

I'm stumped..

Thanks,
Andrew





On Wed, Jun 4, 2014 at 9:59 AM, Andrew Janke <a.janke at gmail.com> wrote:

> Hi Andrew,
>
> Sorry, I should have been more clear, you'll need to build the
> dependencies using the new packaging system. Libtool then picks up the
> libraries from the .la files in these for subsequent packages.
>
> In this case my memory tells me it's EBTKS that you need to build from
> scratch so that the .la files for it include the correct things. In
> this case -lpbm
>
>
>
> a
>
> On 4 June 2014 23:50, Andrew Wood <andrew at biospective.com> wrote:
> > Hi Andrew,
> >
> > I'd grabbed bicpl-1.6.4 from http://packages.bic.mni.mcgill.ca/tgz/.
> I've
> > switched over to the CMake system where possible, but the bicpl releases
> > all predate Vlad's CMake build system, so are we not stuck with libtool
> for
> > this?
> >
> > I could grab a release from Github, but I'd just be rerunning the
> > autotools, no?
> >
> > Thanks,
> > Andrew
> >
> >
> > On Tue, Jun 3, 2014 at 9:12 PM, Andrew Janke <a.janke at gmail.com> wrote:
> >
> >> Hi Andrew,
> >>
> >> No you haven't made a mistake with the configure args. It's a
> >> shortcoming of how libtool is handled in the old MINC build system for
> >> binary packages packages.
> >>
> >> If you build MINC from source (any release) or use any of the later
> >> packages (mni-toolkit) you shouldn't see this problem.
> >>
> >> In any case I'd recommend shifting to Vlad's new CMake build system
> >> for MINC as very little of the old autoconf/make code will now be kept
> >> up to date.
> >>
> >> ta
> >>
> >>
> >> a
> >>
> >>
> >> On 4 June 2014 06:53, Andrew Wood <andrew at biospective.com> wrote:
> >> > Hi all,
> >> >
> >> > I'm trying to build bicpl-1.6.4 on Ubuntu 12.04 and am having some
> >> trouble.
> >> >
> >> > Here's my configure command:
> >> > ./configure --with-minc2 --with-build-path=/usr/local/bic/
> >> --with-image-ppm
> >> >
> >> > Everything goes well until the Testing/ subdirectory, where I get
> this:
> >> >
> >> > gcc -g -O2 -o test_rgb_io test_rgb_io.o  -L/usr/local/bic//lib
> >> > ../.libs/libbicpl.a -lppm -lvolume_io2 -lminc2 /usr/lib/libhdf5.so
> >> > -lpthread -lz -lnetcdf -lm
> >> > /usr/bin/ld: ../.libs/libbicpl.a(rgb_io.o): undefined reference to
> symbol
> >> > 'pm_freerow'
> >> > /usr/bin/ld: note: 'pm_freerow' is defined in DSO
> /usr/lib64/libpbm.so.9
> >> so
> >> > try adding it to the linker command line
> >> > /usr/lib64/libpbm.so.9: could not read symbols: Invalid operation
> >> >
> >> >
> >> > Manually running the gcc command with "-lpbm" at the end, as
> suggested by
> >> > the prompt, works fine. Is there a good reason that the build system
> >> isn't
> >> > passing along the linker flags? Have I made a mistake with the
> configure
> >> > args?
> >> >
> >> > Thanks,
> >> > Andrew
> >> > _______________________________________________
> >> > 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
>

From a.janke at gmail.com  Wed Jun  4 10:53:51 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 5 Jun 2014 00:53:51 +1000
Subject: [MINC-users] Building bicpl-1.6.4 on Ubuntu 12.04
In-Reply-To: <CABApf9HYefvhXPAQ=0g9_4LxT=s+yR2fw8kbeQ1=FhzTzX2ccg@mail.gmail.com>
References: <CABApf9HiQNaaGZoy4yO=j5kJ=4jXRmuGYuiyPADZGteQ7isyDQ@mail.gmail.com>
	<CAG0CB230kMybY9M+fO7rGYizxMZgnGRaEWGJCYDh4HMxTLTP5g@mail.gmail.com>
	<CABApf9FA1051y_DLP9oW8gE5MBaBCE_fdCSnyDqgm8otFAtbuA@mail.gmail.com>
	<CAG0CB20hXF1Y39JuZ791Wtv_dvU5zcpshm64df1BzmY3TJ6_Kg@mail.gmail.com>
	<CABApf9HYefvhXPAQ=0g9_4LxT=s+yR2fw8kbeQ1=FhzTzX2ccg@mail.gmail.com>
Message-ID: <CAG0CB20Ho+D=F2WUzNVxWGZ-t7SArEOXM3kJ6iOX3oT6MycxAQ@mail.gmail.com>

On 5 June 2014 00:28, Andrew Wood <andrew at biospective.com> wrote:
> So my configure command was really this:
> ./configure --with-minc2 --prefix=/my/build/ --with-build-path=/my/build/
> --with-image-ppm
>
> It may be worth noting that the script I use to build this stuff used to
> work on Ubuntu 10.04.
>
> I'm looking at an old build log, and the gcc command which is currently
> failing actually worked on 10.04 (i.e. it didn't have -lpbm either). So
> something must have changed in the ppm/pbm libraries? Or perhaps I had
> statically linked a library before which is currently trying to link
> dynamically?

Interesting. You are using --with-image-ppm with EBTKS and it builds
correctly? With some combinations I have seen it build but fail
silently and just not include the ppm part in EBTKS at which point you
only notice something has broken with bicpl.

I have just dug out my old prereq file. Seems there was a change.

ubuntu-maverick: libnetcdf-dev libhdf5-serial-dev libnetpbm9-dev
fftw-dev libgsl0-dev libgetopt-tabular-perl libmni-perllib-perl
libxext-dev glutg3-dev imagemagick libtext-format-perl

ubuntu-precise: libnetcdf-dev libhdf5-serial-dev libnetpbm10-dev
fftw-dev libgsl0-dev libgetopt-tabular-perl libmni-perllib-perl
libxext-dev imagemagick libtext-format-perl freeglut3-dev

Note the change libnetpbm9-dev to libnetpbm10-dev.



a

From andrew at biospective.com  Wed Jun  4 12:17:14 2014
From: andrew at biospective.com (Andrew Wood)
Date: Wed, 4 Jun 2014 12:17:14 -0400
Subject: [MINC-users] Building bicpl-1.6.4 on Ubuntu 12.04
In-Reply-To: <CAG0CB20Ho+D=F2WUzNVxWGZ-t7SArEOXM3kJ6iOX3oT6MycxAQ@mail.gmail.com>
References: <CABApf9HiQNaaGZoy4yO=j5kJ=4jXRmuGYuiyPADZGteQ7isyDQ@mail.gmail.com>
	<CAG0CB230kMybY9M+fO7rGYizxMZgnGRaEWGJCYDh4HMxTLTP5g@mail.gmail.com>
	<CABApf9FA1051y_DLP9oW8gE5MBaBCE_fdCSnyDqgm8otFAtbuA@mail.gmail.com>
	<CAG0CB20hXF1Y39JuZ791Wtv_dvU5zcpshm64df1BzmY3TJ6_Kg@mail.gmail.com>
	<CABApf9HYefvhXPAQ=0g9_4LxT=s+yR2fw8kbeQ1=FhzTzX2ccg@mail.gmail.com>
	<CAG0CB20Ho+D=F2WUzNVxWGZ-t7SArEOXM3kJ6iOX3oT6MycxAQ@mail.gmail.com>
Message-ID: <CABApf9EbLU3j09V9U0oz4D_v1yUiBa02ZZAwKKHCyJyRgC9kNA@mail.gmail.com>

Got it! Initially I had libnetpbm9, libnetpbm9-dev and libnetpbm10
installed. Now I've just got libnetpbm10 and libnetpbm10-dev.

I had to switch the configure flag from --with-image-ppm
to --with-image-netpbm; it compiles, and will hopefully still work like it
used to.

As for EBTKS, are you sure it's a prereq of bicpl?

Here is the order that my script builds the packages:
1. netcdf
2. hdf5
3. minc
4. bicpl
...

Thanks,
Andrew





On Wed, Jun 4, 2014 at 10:53 AM, Andrew Janke <a.janke at gmail.com> wrote:

> On 5 June 2014 00:28, Andrew Wood <andrew at biospective.com> wrote:
> > So my configure command was really this:
> > ./configure --with-minc2 --prefix=/my/build/ --with-build-path=/my/build/
> > --with-image-ppm
> >
> > It may be worth noting that the script I use to build this stuff used to
> > work on Ubuntu 10.04.
> >
> > I'm looking at an old build log, and the gcc command which is currently
> > failing actually worked on 10.04 (i.e. it didn't have -lpbm either). So
> > something must have changed in the ppm/pbm libraries? Or perhaps I had
> > statically linked a library before which is currently trying to link
> > dynamically?
>
> Interesting. You are using --with-image-ppm with EBTKS and it builds
> correctly? With some combinations I have seen it build but fail
> silently and just not include the ppm part in EBTKS at which point you
> only notice something has broken with bicpl.
>
> I have just dug out my old prereq file. Seems there was a change.
>
> ubuntu-maverick: libnetcdf-dev libhdf5-serial-dev libnetpbm9-dev
> fftw-dev libgsl0-dev libgetopt-tabular-perl libmni-perllib-perl
> libxext-dev glutg3-dev imagemagick libtext-format-perl
>
> ubuntu-precise: libnetcdf-dev libhdf5-serial-dev libnetpbm10-dev
> fftw-dev libgsl0-dev libgetopt-tabular-perl libmni-perllib-perl
> libxext-dev imagemagick libtext-format-perl freeglut3-dev
>
> Note the change libnetpbm9-dev to libnetpbm10-dev.
>
>
>
> 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 Jun  4 12:26:38 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 5 Jun 2014 02:26:38 +1000
Subject: [MINC-users] Building bicpl-1.6.4 on Ubuntu 12.04
In-Reply-To: <CABApf9EbLU3j09V9U0oz4D_v1yUiBa02ZZAwKKHCyJyRgC9kNA@mail.gmail.com>
References: <CABApf9HiQNaaGZoy4yO=j5kJ=4jXRmuGYuiyPADZGteQ7isyDQ@mail.gmail.com>
	<CAG0CB230kMybY9M+fO7rGYizxMZgnGRaEWGJCYDh4HMxTLTP5g@mail.gmail.com>
	<CABApf9FA1051y_DLP9oW8gE5MBaBCE_fdCSnyDqgm8otFAtbuA@mail.gmail.com>
	<CAG0CB20hXF1Y39JuZ791Wtv_dvU5zcpshm64df1BzmY3TJ6_Kg@mail.gmail.com>
	<CABApf9HYefvhXPAQ=0g9_4LxT=s+yR2fw8kbeQ1=FhzTzX2ccg@mail.gmail.com>
	<CAG0CB20Ho+D=F2WUzNVxWGZ-t7SArEOXM3kJ6iOX3oT6MycxAQ@mail.gmail.com>
	<CABApf9EbLU3j09V9U0oz4D_v1yUiBa02ZZAwKKHCyJyRgC9kNA@mail.gmail.com>
Message-ID: <CAG0CB213mSsVHL7Rm217JBL1Qa4bi+QMr=SJRjHK=VSi27kQ9w@mail.gmail.com>

On 5 June 2014 02:17, Andrew Wood <andrew at biospective.com> wrote:
> Got it! Initially I had libnetpbm9, libnetpbm9-dev and libnetpbm10
> installed. Now I've just got libnetpbm10 and libnetpbm10-dev.

This is ringing a bell somewhere.

> As for EBTKS, are you sure it's a prereq of bicpl?

You're right it's not. It's only for classify, N3 and normalize.

> Here is the order that my script builds the packages:
> 1. netcdf
> 2. hdf5
> 3. minc
> 4. bicpl

>From a quick look at my old perl build scripts this matches.


a

From trash001 at odu.edu  Thu Jun 12 14:11:14 2014
From: trash001 at odu.edu (Tanweer Rashid)
Date: Thu, 12 Jun 2014 14:11:14 -0400
Subject: [MINC-users] Build error
Message-ID: <CAE1j2uiubM5qORn0VGWZvqhQ9ofPZ=rG2Sk3qjcm19QUNSHvYw@mail.gmail.com>

Hi all,

I am trying to build minc 2.2.00 from source on 64-bit Ubuntu 14.04. I keep
getting the following error message


/bin/bash ./libtool --tag=CC   --mode=link gcc  -g -O2   -o vff2mnc
conversion/vff2mnc/vff2mnc.o libvolume_io2.la libminc2.la -lhdf5 -lz
-lnetcdf -lm
libtool: link: gcc -g -O2 -o .libs/vff2mnc conversion/vff2mnc/vff2mnc.o
 ./.libs/libvolume_io2.so ./.libs/libminc2.so -lhdf5 -lz -lnetcdf -lm
depbase=`echo progs/mincexample/mincexample1.o | sed
's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -DHAVE_CONFIG_H -I. -I./libsrc -I./volume_io/Include
-I./volume_io/Include -I./progs/Proglib -I./conversion/Acr_nema -I./libsrc2
   -g -O2 -MT progs/mincexample/mincexample1.o -MD -MP -MF $depbase.Tpo -c
-o progs/mincexample/mincexample1.o progs/mincexample/mincexample1.c &&\
mv -f $depbase.Tpo $depbase.Po
/bin/bash ./libtool --tag=CC   --mode=link gcc  -g -O2   -o mincexample1
progs/mincexample/mincexample1.o libvolume_io2.la libminc2.la -lhdf5 -lz
-lnetcdf -lm
libtool: link: gcc -g -O2 -o .libs/mincexample1
progs/mincexample/mincexample1.o  ./.libs/libvolume_io2.so
./.libs/libminc2.so -lhdf5 -lz -lnetcdf -lm
depbase=`echo progs/mincexample/mincexample2.o | sed
's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -DHAVE_CONFIG_H -I. -I./libsrc -I./volume_io/Include
-I./volume_io/Include -I./progs/Proglib -I./conversion/Acr_nema -I./libsrc2
   -g -O2 -MT progs/mincexample/mincexample2.o -MD -MP -MF $depbase.Tpo -c
-o progs/mincexample/mincexample2.o progs/mincexample/mincexample2.c &&\
mv -f $depbase.Tpo $depbase.Po
/bin/bash ./libtool --tag=CC   --mode=link gcc  -g -O2   -o mincexample2
progs/mincexample/mincexample2.o libvolume_io2.la libminc2.la -lhdf5 -lz
-lnetcdf -lm
libtool: link: gcc -g -O2 -o .libs/mincexample2
progs/mincexample/mincexample2.o  ./.libs/libvolume_io2.so
./.libs/libminc2.so -lhdf5 -lz -lnetcdf -lm
/usr/bin/pod2man --section=1 progs/minccomplete/minccomplete >
progs/minccomplete/minccomplete.man1
/usr/bin/pod2man --section=1 progs/minchistory/minchistory >
progs/minchistory/minchistory.man1
/usr/bin/pod2man --section=1 progs/mincpik/mincpik >
progs/mincpik/mincpik.man1
progs/mincpik/mincpik around line 580: You forgot a '=back' before '=head3'
progs/mincpik/mincpik around line 582: '=item' outside of any '=over'
progs/mincpik/mincpik around line 599: You forgot a '=back' before '=head3'
progs/mincpik/mincpik around line 601: '=item' outside of any '=over'
progs/mincpik/mincpik around line 618: You forgot a '=back' before '=head3'
progs/mincpik/mincpik around line 620: '=item' outside of any '=over'
POD document had syntax errors at /usr/bin/pod2man line 71.
make[2]: *** [progs/mincpik/mincpik.man1] Error 255
make[2]: Leaving directory `/home/trash001/Downloads/minc-2.2.00'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/trash001/Downloads/minc-2.2.00'
make: *** [all] Error 2



Any help is appreciated.

Thanks and regards,
-- 
Tanweer Rashid
MSVE Dept.
Old Dominion University

From elizabethw at msmri.medicine.ubc.ca  Thu Jun 12 14:51:30 2014
From: elizabethw at msmri.medicine.ubc.ca (Elizabeth Wicks)
Date: Thu, 12 Jun 2014 11:51:30 -0700
Subject: [MINC-users] Registration of Binary Images
Message-ID: <5399F6B2.2020708@msmri.medicine.ubc.ca>

Hi all,

I was wondering if minctracc provides any options to help optimize 
registration of two binary images? In particular, the registration of 
two skull images (with pixel intensities of either 1000 or 0) . 
Currently, there doesn't seem to be enough information in the images to 
do a consistent reliable -lsq12 minctracc registration.

Thank you in advance!

Elizabeth

From a.janke at gmail.com  Thu Jun 12 16:34:12 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 13 Jun 2014 06:34:12 +1000
Subject: [MINC-users] Registration of Binary Images
In-Reply-To: <5399F6B2.2020708@msmri.medicine.ubc.ca>
References: <5399F6B2.2020708@msmri.medicine.ubc.ca>
Message-ID: <CAG0CB20uYQCFNej53bzy+buZqka9PJC8GhKUrHeDrS8Zy3JQ1Q@mail.gmail.com>

Hi Elizabeth,

Have you tried to blur them with a FWHM kernel of about 5mm before registration?


a


On 13 June 2014 04:51, Elizabeth Wicks <elizabethw at msmri.medicine.ubc.ca> wrote:
> Hi all,
>
> I was wondering if minctracc provides any options to help optimize
> registration of two binary images? In particular, the registration of two
> skull images (with pixel intensities of either 1000 or 0) . Currently, there
> doesn't seem to be enough information in the images to do a consistent
> reliable -lsq12 minctracc registration.
>
> Thank you in advance!
>
> Elizabeth
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From a.janke at gmail.com  Thu Jun 12 16:47:11 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 13 Jun 2014 06:47:11 +1000
Subject: [MINC-users] Build error
In-Reply-To: <CAE1j2uiubM5qORn0VGWZvqhQ9ofPZ=rG2Sk3qjcm19QUNSHvYw@mail.gmail.com>
References: <CAE1j2uiubM5qORn0VGWZvqhQ9ofPZ=rG2Sk3qjcm19QUNSHvYw@mail.gmail.com>
Message-ID: <CAG0CB23Y5pVOcWbqyjbgL8cULbEH0JMXWg4pR8L6HOA+sO1QpQ@mail.gmail.com>

Hi Tanweer

This looks to be an error in the POD documentation of the perl script
mincpik, I had thought this was fixed in later version of MINC. Are
you building from a git download or from packages.bic.mni.mcgill.ca?


a



On 13 June 2014 04:11, Tanweer Rashid <trash001 at odu.edu> wrote:
> Hi all,
>
> I am trying to build minc 2.2.00 from source on 64-bit Ubuntu 14.04. I keep
> getting the following error message
>
>
> /bin/bash ./libtool --tag=CC   --mode=link gcc  -g -O2   -o vff2mnc
> conversion/vff2mnc/vff2mnc.o libvolume_io2.la libminc2.la -lhdf5 -lz
> -lnetcdf -lm
> libtool: link: gcc -g -O2 -o .libs/vff2mnc conversion/vff2mnc/vff2mnc.o
>  ./.libs/libvolume_io2.so ./.libs/libminc2.so -lhdf5 -lz -lnetcdf -lm
> depbase=`echo progs/mincexample/mincexample1.o | sed
> 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> gcc -DHAVE_CONFIG_H -I. -I./libsrc -I./volume_io/Include
> -I./volume_io/Include -I./progs/Proglib -I./conversion/Acr_nema -I./libsrc2
>    -g -O2 -MT progs/mincexample/mincexample1.o -MD -MP -MF $depbase.Tpo -c
> -o progs/mincexample/mincexample1.o progs/mincexample/mincexample1.c &&\
> mv -f $depbase.Tpo $depbase.Po
> /bin/bash ./libtool --tag=CC   --mode=link gcc  -g -O2   -o mincexample1
> progs/mincexample/mincexample1.o libvolume_io2.la libminc2.la -lhdf5 -lz
> -lnetcdf -lm
> libtool: link: gcc -g -O2 -o .libs/mincexample1
> progs/mincexample/mincexample1.o  ./.libs/libvolume_io2.so
> ./.libs/libminc2.so -lhdf5 -lz -lnetcdf -lm
> depbase=`echo progs/mincexample/mincexample2.o | sed
> 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> gcc -DHAVE_CONFIG_H -I. -I./libsrc -I./volume_io/Include
> -I./volume_io/Include -I./progs/Proglib -I./conversion/Acr_nema -I./libsrc2
>    -g -O2 -MT progs/mincexample/mincexample2.o -MD -MP -MF $depbase.Tpo -c
> -o progs/mincexample/mincexample2.o progs/mincexample/mincexample2.c &&\
> mv -f $depbase.Tpo $depbase.Po
> /bin/bash ./libtool --tag=CC   --mode=link gcc  -g -O2   -o mincexample2
> progs/mincexample/mincexample2.o libvolume_io2.la libminc2.la -lhdf5 -lz
> -lnetcdf -lm
> libtool: link: gcc -g -O2 -o .libs/mincexample2
> progs/mincexample/mincexample2.o  ./.libs/libvolume_io2.so
> ./.libs/libminc2.so -lhdf5 -lz -lnetcdf -lm
> /usr/bin/pod2man --section=1 progs/minccomplete/minccomplete >
> progs/minccomplete/minccomplete.man1
> /usr/bin/pod2man --section=1 progs/minchistory/minchistory >
> progs/minchistory/minchistory.man1
> /usr/bin/pod2man --section=1 progs/mincpik/mincpik >
> progs/mincpik/mincpik.man1
> progs/mincpik/mincpik around line 580: You forgot a '=back' before '=head3'
> progs/mincpik/mincpik around line 582: '=item' outside of any '=over'
> progs/mincpik/mincpik around line 599: You forgot a '=back' before '=head3'
> progs/mincpik/mincpik around line 601: '=item' outside of any '=over'
> progs/mincpik/mincpik around line 618: You forgot a '=back' before '=head3'
> progs/mincpik/mincpik around line 620: '=item' outside of any '=over'
> POD document had syntax errors at /usr/bin/pod2man line 71.
> make[2]: *** [progs/mincpik/mincpik.man1] Error 255
> make[2]: Leaving directory `/home/trash001/Downloads/minc-2.2.00'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/trash001/Downloads/minc-2.2.00'
> make: *** [all] Error 2
>
>
>
> Any help is appreciated.
>
> Thanks and regards,
> --
> Tanweer Rashid
> MSVE Dept.
> Old Dominion University
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From trash001 at odu.edu  Thu Jun 12 20:05:43 2014
From: trash001 at odu.edu (Tanweer Rashid)
Date: Thu, 12 Jun 2014 20:05:43 -0400
Subject: [MINC-users] Build error
Message-ID: <CAE1j2ujVeu3TUnwxwVpeCbFntUcKKzKf+Ygqc+7NH2UWAhqm-Q@mail.gmail.com>

Hi Andrew,

I used the downloads available from packages.bic.mni.mcgill.ca.

-- 
Tanweer Rashid
MSVE Dept.
Old Dominion University

From a.janke at gmail.com  Thu Jun 12 22:12:52 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 13 Jun 2014 12:12:52 +1000
Subject: [MINC-users] Diffusion smoothing
Message-ID: <CAG0CB20849YpoRV2aQ3H52R6p_rcjM4_sF9AJfvJeJ-C56BgaQ@mail.gmail.com>

Hi all,

As I recall there is some diffusion smoothing code for MINC somewhere,
as I recall Simon Fristed wrote it? Anyone have a git link for it?

ta

a

From zijdenbos at gmail.com  Thu Jun 12 22:28:53 2014
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Thu, 12 Jun 2014 22:28:53 -0400
Subject: [MINC-users] Diffusion smoothing
In-Reply-To: <CAG0CB20849YpoRV2aQ3H52R6p_rcjM4_sF9AJfvJeJ-C56BgaQ@mail.gmail.com>
References: <CAG0CB20849YpoRV2aQ3H52R6p_rcjM4_sF9AJfvJeJ-C56BgaQ@mail.gmail.com>
Message-ID: <CABEEk17SZ=R8=beApTQ7vj0Oui=bG=NLPJ6haGNVo7uou=K43Q@mail.gmail.com>

I wrote 'diffuse' way back when, but it never made it out the door really
(and then Claude appropriated the name for something else :-) ). I still
have the source code that you are welcome to have, but getting it to build
now may prove challenging (it uses EBTKS from before it was EBTKS). My
guess is that somebody else may have something more current.

-- A


On Thu, Jun 12, 2014 at 10:12 PM, Andrew Janke <a.janke at gmail.com> wrote:

> Hi all,
>
> As I recall there is some diffusion smoothing code for MINC somewhere,
> as I recall Simon Fristed wrote it? Anyone have a git link for it?
>
> ta
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From a.janke at gmail.com  Thu Jun 12 22:33:51 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 13 Jun 2014 12:33:51 +1000
Subject: [MINC-users] Diffusion smoothing
In-Reply-To: <CABEEk17SZ=R8=beApTQ7vj0Oui=bG=NLPJ6haGNVo7uou=K43Q@mail.gmail.com>
References: <CAG0CB20849YpoRV2aQ3H52R6p_rcjM4_sF9AJfvJeJ-C56BgaQ@mail.gmail.com>
	<CABEEk17SZ=R8=beApTQ7vj0Oui=bG=NLPJ6haGNVo7uou=K43Q@mail.gmail.com>
Message-ID: <CAG0CB20K3Qn88EFDKmt_V1inJhJ_gWQ9j455AV2TGuX5Frq6OQ@mail.gmail.com>

I think I have just found it, it was Vlad who has reimplemented
something of Pierrick Coupe's volume_denoise.pl in minc-toolkit.


a


On 13 June 2014 12:28, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> I wrote 'diffuse' way back when, but it never made it out the door really
> (and then Claude appropriated the name for something else :-) ). I still
> have the source code that you are welcome to have, but getting it to build
> now may prove challenging (it uses EBTKS from before it was EBTKS). My
> guess is that somebody else may have something more current.
>
> -- A
>
>
> On Thu, Jun 12, 2014 at 10:12 PM, Andrew Janke <a.janke at gmail.com> wrote:
>
>> Hi all,
>>
>> As I recall there is some diffusion smoothing code for MINC somewhere,
>> as I recall Simon Fristed wrote it? Anyone have a git link for it?
>>
>> 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

From claude at bic.mni.mcgill.ca  Thu Jun 12 22:41:08 2014
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Thu, 12 Jun 2014 22:41:08 -0400
Subject: [MINC-users] Diffusion smoothing
In-Reply-To: <CAG0CB20K3Qn88EFDKmt_V1inJhJ_gWQ9j455AV2TGuX5Frq6OQ@mail.gmail.com>
Message-ID: <201406130241.s5D2f89g022966@agrippa.bic.mni.mcgill.ca>

Hi,

What I recall being named "diffusion smoothing" was a surface blurring
code by Moo Chung that works on .obj surfaces. The code was initially
in Matlab and I rewrote it in C. It was indeed difficult to compile
with links to blas and other such libs. However, I think Andrew means
a different code here.

Claude


>
> I think I have just found it, it was Vlad who has reimplemented
> something of Pierrick Coupe's volume_denoise.pl in minc-toolkit.
>
>
> a
>
>
> On 13 June 2014 12:28, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> > I wrote 'diffuse' way back when, but it never made it out the door really
> > (and then Claude appropriated the name for something else :-) ). I still
> > have the source code that you are welcome to have, but getting it to build
> > now may prove challenging (it uses EBTKS from before it was EBTKS). My
> > guess is that somebody else may have something more current.
> >
> > -- A
> >
> >
> > On Thu, Jun 12, 2014 at 10:12 PM, Andrew Janke <a.janke at gmail.com> wrote:
> >
> >> Hi all,
> >>
> >> As I recall there is some diffusion smoothing code for MINC somewhere,
> >> as I recall Simon Fristed wrote it? Anyone have a git link for it?
> >>
> >> ta
> >>
> >> a
> >> _______________________________________________

From zijdenbos at gmail.com  Thu Jun 12 22:58:39 2014
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Thu, 12 Jun 2014 22:58:39 -0400
Subject: [MINC-users] Diffusion smoothing
In-Reply-To: <201406130241.s5D2f89g022966@agrippa.bic.mni.mcgill.ca>
References: <CAG0CB20K3Qn88EFDKmt_V1inJhJ_gWQ9j455AV2TGuX5Frq6OQ@mail.gmail.com>
	<201406130241.s5D2f89g022966@agrippa.bic.mni.mcgill.ca>
Message-ID: <CABEEk14TyG5e-88rpM__evVOLe1zTcqsd1WqJFJeybZKfixR0w@mail.gmail.com>

I imagined that Andrew was referring to anisotropic diffusion like the one
from Guido Gerig's 1992 paper:

   http://poseidon.tel.uva.es/~carlos/ltif10001/gerig.pdf

which is the one that I implemented at the time. I'm sure there are now
other implementations out there.

-- A


On Thu, Jun 12, 2014 at 10:41 PM, Claude LEPAGE <claude at bic.mni.mcgill.ca>
wrote:

> Hi,
>
> What I recall being named "diffusion smoothing" was a surface blurring
> code by Moo Chung that works on .obj surfaces. The code was initially
> in Matlab and I rewrote it in C. It was indeed difficult to compile
> with links to blas and other such libs. However, I think Andrew means
> a different code here.
>
> Claude
>
>
> >
> > I think I have just found it, it was Vlad who has reimplemented
> > something of Pierrick Coupe's volume_denoise.pl in minc-toolkit.
> >
> >
> > a
> >
> >
> > On 13 June 2014 12:28, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> > > I wrote 'diffuse' way back when, but it never made it out the door
> really
> > > (and then Claude appropriated the name for something else :-) ). I
> still
> > > have the source code that you are welcome to have, but getting it to
> build
> > > now may prove challenging (it uses EBTKS from before it was EBTKS). My
> > > guess is that somebody else may have something more current.
> > >
> > > -- A
> > >
> > >
> > > On Thu, Jun 12, 2014 at 10:12 PM, Andrew Janke <a.janke at gmail.com>
> wrote:
> > >
> > >> Hi all,
> > >>
> > >> As I recall there is some diffusion smoothing code for MINC somewhere,
> > >> as I recall Simon Fristed wrote it? Anyone have a git link for it?
> > >>
> > >> ta
> > >>
> > >> 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 Jun 13 00:31:52 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 13 Jun 2014 14:31:52 +1000
Subject: [MINC-users] Build error
In-Reply-To: <CAE1j2ujVeu3TUnwxwVpeCbFntUcKKzKf+Ygqc+7NH2UWAhqm-Q@mail.gmail.com>
References: <CAE1j2ujVeu3TUnwxwVpeCbFntUcKKzKf+Ygqc+7NH2UWAhqm-Q@mail.gmail.com>
Message-ID: <CAG0CB21+K8N6hAeH4GkNVF+QTCsoz7rBRE37rF5_nXdzkBzzOg@mail.gmail.com>

If building from source, I recommend you use the current releases on
github here:

   https://github.com/BIC-MNI/minc-toolkit

Look for the libminc and minctools subpackages.


a




On 13 June 2014 10:05, Tanweer Rashid <trash001 at odu.edu> wrote:
> Hi Andrew,
>
> I used the downloads available from packages.bic.mni.mcgill.ca.
>
> --
> Tanweer Rashid
> MSVE Dept.
> Old Dominion University

From francois.hebert007 at gmail.com  Fri Jun 13 07:04:24 2014
From: francois.hebert007 at gmail.com (Francois Hebert)
Date: Fri, 13 Jun 2014 07:04:24 -0400
Subject: [MINC-users] Diffusion smoothing
In-Reply-To: <CABEEk14TyG5e-88rpM__evVOLe1zTcqsd1WqJFJeybZKfixR0w@mail.gmail.com>
References: <CAG0CB20K3Qn88EFDKmt_V1inJhJ_gWQ9j455AV2TGuX5Frq6OQ@mail.gmail.com>
	<201406130241.s5D2f89g022966@agrippa.bic.mni.mcgill.ca>
	<CABEEk14TyG5e-88rpM__evVOLe1zTcqsd1WqJFJeybZKfixR0w@mail.gmail.com>
Message-ID: <CACGPbDy1-0nyHRgmT-+uqbVRfHXgTvW7FwucSwPO6PP7Db+bFg@mail.gmail.com>

Hi Andrew,

I wrote the code for an anisotropic diffusin filter and a bilateral filter
it's in C++ and using minc2, .
If you want I can give you the code.

Francois
(Alex Padawan :) )


2014-06-12 22:58 GMT-04:00 Alex Zijdenbos <zijdenbos at gmail.com>:

> I imagined that Andrew was referring to anisotropic diffusion like the one
> from Guido Gerig's 1992 paper:
>
>    http://poseidon.tel.uva.es/~carlos/ltif10001/gerig.pdf
>
> which is the one that I implemented at the time. I'm sure there are now
> other implementations out there.
>
> -- A
>
>
> On Thu, Jun 12, 2014 at 10:41 PM, Claude LEPAGE <claude at bic.mni.mcgill.ca>
> wrote:
>
> > Hi,
> >
> > What I recall being named "diffusion smoothing" was a surface blurring
> > code by Moo Chung that works on .obj surfaces. The code was initially
> > in Matlab and I rewrote it in C. It was indeed difficult to compile
> > with links to blas and other such libs. However, I think Andrew means
> > a different code here.
> >
> > Claude
> >
> >
> > >
> > > I think I have just found it, it was Vlad who has reimplemented
> > > something of Pierrick Coupe's volume_denoise.pl in minc-toolkit.
> > >
> > >
> > > a
> > >
> > >
> > > On 13 June 2014 12:28, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> > > > I wrote 'diffuse' way back when, but it never made it out the door
> > really
> > > > (and then Claude appropriated the name for something else :-) ). I
> > still
> > > > have the source code that you are welcome to have, but getting it to
> > build
> > > > now may prove challenging (it uses EBTKS from before it was EBTKS).
> My
> > > > guess is that somebody else may have something more current.
> > > >
> > > > -- A
> > > >
> > > >
> > > > On Thu, Jun 12, 2014 at 10:12 PM, Andrew Janke <a.janke at gmail.com>
> > wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> As I recall there is some diffusion smoothing code for MINC
> somewhere,
> > > >> as I recall Simon Fristed wrote it? Anyone have a git link for it?
> > > >>
> > > >> 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
>

From mallar.chak at gmail.com  Fri Jun 13 10:17:18 2014
From: mallar.chak at gmail.com (Mallar Chakravarty)
Date: Fri, 13 Jun 2014 10:17:18 -0400
Subject: [MINC-users] Registration of Binary Images
In-Reply-To: <CAG0CB20uYQCFNej53bzy+buZqka9PJC8GhKUrHeDrS8Zy3JQ1Q@mail.gmail.com>
References: <5399F6B2.2020708@msmri.medicine.ubc.ca>
	<CAG0CB20uYQCFNej53bzy+buZqka9PJC8GhKUrHeDrS8Zy3JQ1Q@mail.gmail.com>
Message-ID: <CAMrG8rPCMcOSt8r7VFwNogPHYH-t-fW18ks7CQ41X-VAz5qTkA@mail.gmail.com>

Hi Elizabeth,

Another neat trick that I find often works is to manufacture some contrast
be estimating a distance map using either mincchamfer or mincmorph.

mallar


On Thu, Jun 12, 2014 at 4:34 PM, Andrew Janke <a.janke at gmail.com> wrote:

> Hi Elizabeth,
>
> Have you tried to blur them with a FWHM kernel of about 5mm before
> registration?
>
>
> a
>
>
> On 13 June 2014 04:51, Elizabeth Wicks <elizabethw at msmri.medicine.ubc.ca>
> wrote:
> > Hi all,
> >
> > I was wondering if minctracc provides any options to help optimize
> > registration of two binary images? In particular, the registration of two
> > skull images (with pixel intensities of either 1000 or 0) . Currently,
> there
> > doesn't seem to be enough information in the images to do a consistent
> > reliable -lsq12 minctracc registration.
> >
> > Thank you in advance!
> >
> > Elizabeth
> > _______________________________________________
> > 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 tarek.sherif at mcgill.ca  Fri Jun 13 12:02:05 2014
From: tarek.sherif at mcgill.ca (Tarek Sherif)
Date: Fri, 13 Jun 2014 12:02:05 -0400
Subject: [MINC-users] Contradictory MINC coordinate conversion documentation
Message-ID: <539B207D.4050803@mcgill.ca>

Hi all,

I've been trying to figure out how handle conversions between
voxel and world coordinatesin MINC files, and I've come
across two pieces of documentation that seem to contradict
each other:
http://en.wikibooks.org/wiki/MINC/Reference/MINC2.0_File_Format_Reference#MINC_2.0_coordinate_system
http://www.bic.mni.mcgill.ca/software/minc/minc2_format/node4.html

The latter is more recent, but the matrix notation is incorrect.
I assume the two vectors are meant to be transposed. The
latter is older, but doesn't have the same notation issues. The
most important point, though, is that they give different
results for the transformation. For example, in calculating the
world x coordinate, the former resource gives:

      wx = cxx * stepx * vx + cxy * stepx * vy + cxz * stepx * vz + ox

while the latter gives:

wx = cxx * stepx * vx + cyx * stepy * vy + czx * stepz * vz + ox

Does anyone know which is the correction transformation? Also,
once we figure out which doc is incorrect, does anyone know
whom I should contact to get it removed/updated?

Thank you,

Tarek

From tarek.sherif at mcgill.ca  Sat Jun 14 05:47:34 2014
From: tarek.sherif at mcgill.ca (Tarek Sherif)
Date: Sat, 14 Jun 2014 05:47:34 -0400
Subject: [MINC-users] Wikibook coordinate conversion documentation fixed
Message-ID: <539C1A36.1090109@mcgill.ca>

Hello all,

After some discussion with Bert Vincent, it became clear
that the conversion equations in the Wikibook
documentation were completely wrong. I've fixed them
and added some other information that I thought might
be useful to people: 
https://en.wikibooks.org/wiki/MINC/Reference/MINC2.0_File_Format_Reference#MINC_2.0_coordinate_system

The information added includes:
1. The decomposition of the voxel-to-world transformation
into scaling, rotation and translation components.
2. The inverse, world-to-voxel transformation.

If people could verify the correctness of the new
equations, that would be great.

Tarek

From zijdenbos at gmail.com  Sat Jun 14 12:59:44 2014
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Sat, 14 Jun 2014 12:59:44 -0400
Subject: [MINC-users] Wikibook coordinate conversion documentation fixed
In-Reply-To: <539C1A36.1090109@mcgill.ca>
References: <539C1A36.1090109@mcgill.ca>
Message-ID: <CABEEk16=Z+ghxKnDkMpn4+cG2x26aXx5xof4MxnL+3bueM+LXQ@mail.gmail.com>

Hi Tarek,

Nice work! It's good to have this coordinate business straightened out once
and for all, as it is invariably problematic, especially for new MINC users
- and in fact, I am not sure I'd ever wrapped my head completely around the
direction cosines bit :-)

I do however have a few suggestions:

1) to add a diagram that illustrates the coordinate systems. I'm pretty
sure that exists somewhere, but right now I don't remember exactly where I
saw that. If somebody knows where it is I would suggest to add it to this
section.

2) what is not clear/missing is how one goes from real (as in, floating
point) voxel coordinates to integer array indices. I believe that is a
rounding operation (as opposed to a truncation for example).

3) Related to 2), we may want to clarify explicitly here that a MINC image
is a lattice of point samples, which I think is often not obvious to
people. In this context, the statement: "The voxel coordinate values are
nonnegative integers ranging from zero to one less than the number of data
points along the axis, with the origin fixed at one corner of the image"
may be confusing to some: if you consider the step size as the "width" of a
voxel (which I think most people would do), then the voxel coordinate
origin is actually half a voxel into the image, or conversely, what people
might consider the "corner" of a standard MNI 1.00mm image, actually has
voxel coordinates (-0.5, -0.5, -0.5), which is also _not_ the start
coordinate.

-- A


On Sat, Jun 14, 2014 at 5:47 AM, Tarek Sherif <tarek.sherif at mcgill.ca>
wrote:

> Hello all,
>
> After some discussion with Bert Vincent, it became clear
> that the conversion equations in the Wikibook
> documentation were completely wrong. I've fixed them
> and added some other information that I thought might
> be useful to people: https://en.wikibooks.org/wiki/
> MINC/Reference/MINC2.0_File_Format_Reference#MINC_2.0_coordinate_system
>
> The information added includes:
> 1. The decomposition of the voxel-to-world transformation
> into scaling, rotation and translation components.
> 2. The inverse, world-to-voxel transformation.
>
> If people could verify the correctness of the new
> equations, that would be great.
>
> Tarek
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From a.janke at gmail.com  Sat Jun 14 19:23:24 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 15 Jun 2014 09:23:24 +1000
Subject: [MINC-users] Wikibook coordinate conversion documentation fixed
In-Reply-To: <539C1A36.1090109@mcgill.ca>
References: <539C1A36.1090109@mcgill.ca>
Message-ID: <CAG0CB21iUoL1hMrF2==8DxQFPQFEv+c1A3L9R4OV10411_=AgQ@mail.gmail.com>

Thanks Tarek,

I made that page originally by transcribing (largely manually) the
.tex sources to wikibooks format, perhaps there was something in this
conversion that went awry.  By all means edit away as you see fit.

Thanks again,


a


On 14 June 2014 19:47, Tarek Sherif <tarek.sherif at mcgill.ca> wrote:
> Hello all,
>
> After some discussion with Bert Vincent, it became clear
> that the conversion equations in the Wikibook
> documentation were completely wrong. I've fixed them
> and added some other information that I thought might
> be useful to people:
> https://en.wikibooks.org/wiki/MINC/Reference/MINC2.0_File_Format_Reference#MINC_2.0_coordinate_system
>
> The information added includes:
> 1. The decomposition of the voxel-to-world transformation
> into scaling, rotation and translation components.
> 2. The inverse, world-to-voxel transformation.
>
> If people could verify the correctness of the new
> equations, that would be great.
>
> Tarek
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From a.janke at gmail.com  Sat Jun 14 19:50:05 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 15 Jun 2014 09:50:05 +1000
Subject: [MINC-users] Diffusion smoothing
In-Reply-To: <CACGPbDy1-0nyHRgmT-+uqbVRfHXgTvW7FwucSwPO6PP7Db+bFg@mail.gmail.com>
References: <CAG0CB20K3Qn88EFDKmt_V1inJhJ_gWQ9j455AV2TGuX5Frq6OQ@mail.gmail.com>
	<201406130241.s5D2f89g022966@agrippa.bic.mni.mcgill.ca>
	<CABEEk14TyG5e-88rpM__evVOLe1zTcqsd1WqJFJeybZKfixR0w@mail.gmail.com>
	<CACGPbDy1-0nyHRgmT-+uqbVRfHXgTvW7FwucSwPO6PP7Db+bFg@mail.gmail.com>
Message-ID: <CAG0CB20M+yq58EECym1sx1VYmj6eh1s32f=Dchy_j=9Adc5=xg@mail.gmail.com>

Hi Francois,

By all means, the best way to do this would be to put the code up on
github in your account at which stage it can be incorporated into
minc-toolkit if others have a need for it.

Thanks

a



On 13 June 2014 21:04, Francois Hebert <francois.hebert007 at gmail.com> wrote:
> Hi Andrew,
>
> I wrote the code for an anisotropic diffusin filter and a bilateral filter
> it's in C++ and using minc2, .
> If you want I can give you the code.
>
> Francois
> (Alex Padawan :) )

From eskild at gmail.com  Sun Jun 15 00:17:37 2014
From: eskild at gmail.com (Simon Eskildsen)
Date: Sun, 15 Jun 2014 06:17:37 +0200
Subject: [MINC-users] Diffusion smoothing
In-Reply-To: <CAG0CB20849YpoRV2aQ3H52R6p_rcjM4_sF9AJfvJeJ-C56BgaQ@mail.gmail.com>
References: <CAG0CB20849YpoRV2aQ3H52R6p_rcjM4_sF9AJfvJeJ-C56BgaQ@mail.gmail.com>
Message-ID: <CAD3v436D2V9+WDtGJSepmFnw1AcopE1VALt8ftJFzemZYMcD6A@mail.gmail.com>

Hi Andrew,

I wrote diffusion smoothing for surfaces a long time ago. I guess this is
not what you're looking for.

S


On Fri, Jun 13, 2014 at 4:12 AM, Andrew Janke <a.janke at gmail.com> wrote:

> Hi all,
>
> As I recall there is some diffusion smoothing code for MINC somewhere,
> as I recall Simon Fristed wrote it? Anyone have a git link for it?
>
> ta
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From a.janke at gmail.com  Sun Jun 15 06:47:57 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 15 Jun 2014 20:47:57 +1000
Subject: [MINC-users] Diffusion smoothing
In-Reply-To: <CAD3v436D2V9+WDtGJSepmFnw1AcopE1VALt8ftJFzemZYMcD6A@mail.gmail.com>
References: <CAG0CB20849YpoRV2aQ3H52R6p_rcjM4_sF9AJfvJeJ-C56BgaQ@mail.gmail.com>
	<CAD3v436D2V9+WDtGJSepmFnw1AcopE1VALt8ftJFzemZYMcD6A@mail.gmail.com>
Message-ID: <CAG0CB23x8ton=cqKSiAive=N=pUHcL0yh4sRfKw0JpwSPu-1cA@mail.gmail.com>

On 15 June 2014 14:17, Simon Eskildsen <eskild at gmail.com> wrote:
> I wrote diffusion smoothing for surfaces a long time ago. I guess this is
> not what you're looking for.

Nope, I was after something for voxel data.

Thanks


a

From vladimir.fonov at gmail.com  Sun Jun 15 15:18:27 2014
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Sun, 15 Jun 2014 21:18:27 +0200
Subject: [MINC-users] Diffusion smoothing
In-Reply-To: <CAG0CB23x8ton=cqKSiAive=N=pUHcL0yh4sRfKw0JpwSPu-1cA@mail.gmail.com>
References: <CAG0CB20849YpoRV2aQ3H52R6p_rcjM4_sF9AJfvJeJ-C56BgaQ@mail.gmail.com>
	<CAD3v436D2V9+WDtGJSepmFnw1AcopE1VALt8ftJFzemZYMcD6A@mail.gmail.com>
	<CAG0CB23x8ton=cqKSiAive=N=pUHcL0yh4sRfKw0JpwSPu-1cA@mail.gmail.com>
Message-ID: <2822E598-BCA8-4B34-98F3-6B0EFAF36E4B@gmail.com>

Hello,


I have got (a pretty trivial) program calling 
http://www.itk.org/Doxygen/html/classitk_1_1GradientAnisotropicDiffusionImageFilter.html
or
http://www.itk.org/Doxygen/html/classitk_1_1CurvatureAnisotropicDiffusionImageFilter.html



On Jun 15, 2014, at 12:47 PM, Andrew Janke <a.janke at gmail.com> wrote:

> On 15 June 2014 14:17, Simon Eskildsen <eskild at gmail.com> wrote:
>> I wrote diffusion smoothing for surfaces a long time ago. I guess this is
>> not what you're looking for.
> 
> Nope, I was after something for voxel data.
> 
> Thanks
> 
> 
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

---
Best regards,

Vladimir S. FONOV ~ v.s.fonov <at> ilmarin.info






From a.janke at gmail.com  Mon Jun 16 02:07:05 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 16 Jun 2014 16:07:05 +1000
Subject: [MINC-users] Diffusion smoothing
In-Reply-To: <2822E598-BCA8-4B34-98F3-6B0EFAF36E4B@gmail.com>
References: <CAG0CB20849YpoRV2aQ3H52R6p_rcjM4_sF9AJfvJeJ-C56BgaQ@mail.gmail.com>
	<CAD3v436D2V9+WDtGJSepmFnw1AcopE1VALt8ftJFzemZYMcD6A@mail.gmail.com>
	<CAG0CB23x8ton=cqKSiAive=N=pUHcL0yh4sRfKw0JpwSPu-1cA@mail.gmail.com>
	<2822E598-BCA8-4B34-98F3-6B0EFAF36E4B@gmail.com>
Message-ID: <CAG0CB21+wfz0TphKi6xCfn1c2YR8YJYNJgZCesw4dKNcnLsoXw@mail.gmail.com>

Thanks Vlad,

Is this too part of minc-toolkit yet?


a


On 16 June 2014 05:18, Vladimir S. FONOV <vladimir.fonov at gmail.com> wrote:
> Hello,
>
>
> I have got (a pretty trivial) program calling
> http://www.itk.org/Doxygen/html/classitk_1_1GradientAnisotropicDiffusionImageFilter.html
> or
> http://www.itk.org/Doxygen/html/classitk_1_1CurvatureAnisotropicDiffusionImageFilter.html
>
>
>
> On Jun 15, 2014, at 12:47 PM, Andrew Janke <a.janke at gmail.com> wrote:
>
>> On 15 June 2014 14:17, Simon Eskildsen <eskild at gmail.com> wrote:
>>> I wrote diffusion smoothing for surfaces a long time ago. I guess this is
>>> not what you're looking for.
>>
>> Nope, I was after something for voxel data.
>>
>> Thanks
>>
>>
>> a
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
> ---
> Best regards,
>
> Vladimir S. FONOV ~ v.s.fonov <at> ilmarin.info
>
>
>
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From peter.neelin at gmail.com  Mon Jun 16 09:57:56 2014
From: peter.neelin at gmail.com (Peter Neelin)
Date: Mon, 16 Jun 2014 09:57:56 -0400
Subject: [MINC-users] Wikibook coordinate conversion documentation fixed
In-Reply-To: <CABEEk16=Z+ghxKnDkMpn4+cG2x26aXx5xof4MxnL+3bueM+LXQ@mail.gmail.com>
References: <539C1A36.1090109@mcgill.ca>
	<CABEEk16=Z+ghxKnDkMpn4+cG2x26aXx5xof4MxnL+3bueM+LXQ@mail.gmail.com>
Message-ID: <CANcjydYF2uuSS0M_29S_2gpHEFOL1MmSiLTmw7+EearQkL=-kw@mail.gmail.com>

Hi Alex and Tarek,

On Sat, Jun 14, 2014 at 12:59 PM, Alex Zijdenbos <zijdenbos at gmail.com>
wrote:


> Nice work! It's good to have this coordinate business straightened out once
>

Yes, thanks Tarek for finding this error and fixing it. If you are using
column vectors, then each axis unit vector (direction cosines) becomes a
column of the transformation matrix.


> and for all, as it is invariably problematic, especially for new MINC users
> - and in fact, I am not sure I'd ever wrapped my head completely around the
> direction cosines bit :-)
>

Apart from the name, the direction cosines are really not that hard. They
are just the unit vector along the axis in the positive direction. The
language is borrowed from the ACR-NEMA 1.0 standard ("Direction cosines of
the R axis of the image system with respect to the patient coordinate axes
x,y,z") which has been carried over into DICOM 3.0 ("The direction cosines
of the first row and the first column with respect to the patient"). For
the record, minc attributes are largely borrowed/inspired/generalized from
the ACR-NEMA 1.0 standard of which I had a copy in early 1992 when minc was
created (coincidentally, DICOM appeared at around the same time).

The tricky bit is the start attribute. Conceptually it is simple - an
offset along the axis (parallel to the axis). I chose this because one
could then ignore the rotation (direction cosines) and properly handle
translation. This was based on the assumption that broken (naive)
implementations would handle scaling and translation but ignore rotation of
the sampling grid. Unfortunately, it makes it a bit more complicated to
calculate the full transformation matrix. ACR-NEMA/DICOM chose to use the
position of the first pixel in the patient frame, which makes calculating
the full transformation matrix easy. Basically, they assume that naive
implementations will do the scaling, but will not worry about rotation or
translation.

In some sense, we were guessing as to what a naive/limited implementation
would choose to honour. In retrospect, I think that they may have made the
better choice because it is easier to understand and most software now
handles the full transformation matrix correctly (although the lack of
invariance under rotation still bothers me, as does the fact that it does
not generalize well to independent axes).

Regardless, the minc community is pretty much stuck with my choice from 22
years ago, since change something as fundamental as coordinate system
definition is a hard thing to do.


>
> 3) Related to 2), we may want to clarify explicitly here that a MINC image
> is a lattice of point samples, which I think is often not obvious to
> people. In this context, the statement: "The voxel coordinate values are
> nonnegative integers ranging from zero to one less than the number of data
> points along the axis, with the origin fixed at one corner of the image"
> may be confusing to some: if you consider the step size as the "width" of a
> voxel (which I think most people would do), then the voxel coordinate
> origin is actually half a voxel into the image, or conversely, what people
> might consider the "corner" of a standard MNI 1.00mm image, actually has
> voxel coordinates (-0.5, -0.5, -0.5), which is also _not_ the start
> coordinate.
>

I am not alone in this choice. This is consistent with ACR-NEMA/DICOM -
from the DICOM standard: "The Image Position (0020,0032) specifies the x,
y, and z coordinates of the upper left hand corner of the image; it is the
center of the first voxel transmitted". I think that it reflects the
physicist/engineering perspective that medical imaging data is a sampling
with both sampling frequency (voxel separation) and resolution (voxel
width). Computer scientists tend to like to think about images as blocks -
this has annoyed me for years.

Anyway, I just want to be clear that the matrices presented in those
documents are not defining of the coordinate system. The definition is
pretty simple (pulled from my head right now, so perhaps not expressed as
clearly as possible):

For each axis (spatial dimension) there is a start, step and set of
direction cosines.
The direction cosines are the unit vector of the axis in the patient frame,
oriented in the positive direction (largest component must be positive).
The start is the real-world (millimetres) signed offset of the centre of
the first sample along (parallel to) the axis.
The step is the real-world (millimetres) sample separation, with a sign
chosen to indicate positive or negative direction.

The patient frame is defined as it is in DICOM, except that left-to-right
is positive (Alan Evans bias) and posterior-to-anterior is positive (my
bias towards human-oriented screen coordinates, a la Iris GL library rather
than X and others, plus the desire for a right-handed coordinate system).

Hope that this helps to clarify. Tarek, please confirm that everything is
consistent.

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

From vladimir.fonov at gmail.com  Sun Jun 22 22:04:54 2014
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Sun, 22 Jun 2014 22:04:54 -0400
Subject: [MINC-users] Diffusion smoothing
In-Reply-To: <CAG0CB21+wfz0TphKi6xCfn1c2YR8YJYNJgZCesw4dKNcnLsoXw@mail.gmail.com>
References: <CAG0CB20849YpoRV2aQ3H52R6p_rcjM4_sF9AJfvJeJ-C56BgaQ@mail.gmail.com>
	<CAD3v436D2V9+WDtGJSepmFnw1AcopE1VALt8ftJFzemZYMcD6A@mail.gmail.com>
	<CAG0CB23x8ton=cqKSiAive=N=pUHcL0yh4sRfKw0JpwSPu-1cA@mail.gmail.com>
	<2822E598-BCA8-4B34-98F3-6B0EFAF36E4B@gmail.com>
	<CAG0CB21+wfz0TphKi6xCfn1c2YR8YJYNJgZCesw4dKNcnLsoXw@mail.gmail.com>
Message-ID: <CAMCwi7PQtqo7uPHT=0FKv3MCyg22p5f0RZk5SNq6UjOrV4OH9A@mail.gmail.com>

Hello,

sorry for the delay, i just added the program (and several others) to
minc-toolkit ( https://github.com/BIC-MNI/EZminc/blob/ITK4/tools/itk_diffusion.cpp
), right now it only compiles in ITK4 branch.

On Mon, Jun 16, 2014 at 2:07 AM, Andrew Janke <a.janke at gmail.com> wrote:
> Thanks Vlad,
>
> Is this too part of minc-toolkit yet?
>
>
> a
>
>
> On 16 June 2014 05:18, Vladimir S. FONOV <vladimir.fonov at gmail.com> wrote:
>> Hello,
>>
>>
>> I have got (a pretty trivial) program calling
>> http://www.itk.org/Doxygen/html/classitk_1_1GradientAnisotropicDiffusionImageFilter.html
>> or
>> http://www.itk.org/Doxygen/html/classitk_1_1CurvatureAnisotropicDiffusionImageFilter.html
>>
>>
>>
>> On Jun 15, 2014, at 12:47 PM, Andrew Janke <a.janke at gmail.com> wrote:
>>
>>> On 15 June 2014 14:17, Simon Eskildsen <eskild at gmail.com> wrote:
>>>> I wrote diffusion smoothing for surfaces a long time ago. I guess this is
>>>> not what you're looking for.
>>>
>>> Nope, I was after something for voxel data.
>>>
>>> Thanks
>>>
>>>
>>> a
>>> _______________________________________________
>>> MINC-users at bic.mni.mcgill.ca
>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>> ---
>> Best regards,
>>
>> Vladimir S. FONOV ~ v.s.fonov <at> ilmarin.info
>>
>>
>>
>>
>>
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users



-- 
Best regards,

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

From a.janke at gmail.com  Mon Jun 23 09:09:41 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 23 Jun 2014 23:09:41 +1000
Subject: [MINC-users] Diffusion smoothing
In-Reply-To: <CAMCwi7PQtqo7uPHT=0FKv3MCyg22p5f0RZk5SNq6UjOrV4OH9A@mail.gmail.com>
References: <CAG0CB20849YpoRV2aQ3H52R6p_rcjM4_sF9AJfvJeJ-C56BgaQ@mail.gmail.com>
	<CAD3v436D2V9+WDtGJSepmFnw1AcopE1VALt8ftJFzemZYMcD6A@mail.gmail.com>
	<CAG0CB23x8ton=cqKSiAive=N=pUHcL0yh4sRfKw0JpwSPu-1cA@mail.gmail.com>
	<2822E598-BCA8-4B34-98F3-6B0EFAF36E4B@gmail.com>
	<CAG0CB21+wfz0TphKi6xCfn1c2YR8YJYNJgZCesw4dKNcnLsoXw@mail.gmail.com>
	<CAMCwi7PQtqo7uPHT=0FKv3MCyg22p5f0RZk5SNq6UjOrV4OH9A@mail.gmail.com>
Message-ID: <CAG0CB21dUp=dCnK4xF2c5DQ6RuJDL0jC=QE3OAkzFv7E8stEYw@mail.gmail.com>

On 23 June 2014 12:04, Vladimir S. FONOV <vladimir.fonov at gmail.com> wrote:
> sorry for the delay, i just added the program (and several others) to
> minc-toolkit ( https://github.com/BIC-MNI/EZminc/blob/ITK4/tools/itk_diffusion.cpp
> ), right now it only compiles in ITK4 branch.

No trouble, thanks for adding it.


a

From zijdenbos at gmail.com  Mon Jun 23 19:14:54 2014
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Mon, 23 Jun 2014 19:14:54 -0400
Subject: [MINC-users] mincdefrag arguments
Message-ID: <CABEEk16T=mR6-Y9vChW9KRJNG8=Tc9iwRODjPQaMnxWPDAwgzg@mail.gmail.com>

This one is mostly for Claude, but just in case it has affected anybody I
figured I'd raise it here.

The mincdefrag help text states that the allowable values for this "number
of neighbors" value are (6, 19, 27), which is inconsistent (19 and 27
include the center voxel, 6 does not).

Where this matters is that I just realized that mincdefrag actually doesn't
check these values, and *silently (ack) falls back to '6' for anything that
is not 19 or 27*.

I for one have used (by force of habit or logic or consistency with
mincmorph) '26' in quite a number of mincdefrag calls, and I am now
realizing that those were all silently using a 6-neighbor kernel :(

I suggest we change the help text to read (1, 18, 26); and, for backward
compatibility, change the bit where it checks this value to accept both 18
and 19 for stencil=2; 26 and 27 for stencil=3, and throws an error for
anything that is not (6, 18, 19, 26, 27);

-- A

From a.janke at gmail.com  Mon Jun 23 20:10:39 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 24 Jun 2014 10:10:39 +1000
Subject: [MINC-users] mincdefrag arguments
In-Reply-To: <CABEEk16T=mR6-Y9vChW9KRJNG8=Tc9iwRODjPQaMnxWPDAwgzg@mail.gmail.com>
References: <CABEEk16T=mR6-Y9vChW9KRJNG8=Tc9iwRODjPQaMnxWPDAwgzg@mail.gmail.com>
Message-ID: <CAG0CB20RasbMvO1Lesew3MSnnpsjb3w4qWt2C9nBUNsu8jUZTA@mail.gmail.com>

IIRC, there was at one stage an effort to include the logic of
mincdefrag into mincmorph. (it would be just another kernel
operation). This would be one way to resolve differences and allow
mincdefrag to be more flexible.

Claude, do you remember what happened here?


a

On 24 June 2014 09:14, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> This one is mostly for Claude, but just in case it has affected anybody I
> figured I'd raise it here.
>
> The mincdefrag help text states that the allowable values for this "number
> of neighbors" value are (6, 19, 27), which is inconsistent (19 and 27
> include the center voxel, 6 does not).
>
> Where this matters is that I just realized that mincdefrag actually doesn't
> check these values, and *silently (ack) falls back to '6' for anything that
> is not 19 or 27*.
>
> I for one have used (by force of habit or logic or consistency with
> mincmorph) '26' in quite a number of mincdefrag calls, and I am now
> realizing that those were all silently using a 6-neighbor kernel :(
>
> I suggest we change the help text to read (1, 18, 26); and, for backward
> compatibility, change the bit where it checks this value to accept both 18
> and 19 for stencil=2; 26 and 27 for stencil=3, and throws an error for
> anything that is not (6, 18, 19, 26, 27);
>
> -- A
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From claude at bic.mni.mcgill.ca  Mon Jun 23 23:37:10 2014
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Mon, 23 Jun 2014 23:37:10 -0400
Subject: [MINC-users] mincdefrag arguments
In-Reply-To: <CAG0CB20RasbMvO1Lesew3MSnnpsjb3w4qWt2C9nBUNsu8jUZTA@mail.gmail.com>
Message-ID: <201406240337.s5O3bAQd022761@agrippa.bic.mni.mcgill.ca>


hi,

Somehow, mincdefrag survived over the years after I implemented it quickly.

I have no objection if someone wants to include it in mincmorph. That's fine,
as long as that someone is not me.

I agree that the specification of the arguments is not consistent with other
minctools. Maybe 6 should be 7 instead. But it's all the same. The center 
voxel is always included. The "silent" mode is perhaps not desirable. It would
not take much effort to make it "idiot-proof". 

Claude

PS: It's nice to see that mincdefrag is being used out there. :-)


> IIRC, there was at one stage an effort to include the logic of
> mincdefrag into mincmorph. (it would be just another kernel
> operation). This would be one way to resolve differences and allow
> mincdefrag to be more flexible.
>
> Claude, do you remember what happened here?
>
>
> a
>
> On 24 June 2014 09:14, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> > This one is mostly for Claude, but just in case it has affected anybody I
> > figured I'd raise it here.
> >
> > The mincdefrag help text states that the allowable values for this "number
> > of neighbors" value are (6, 19, 27), which is inconsistent (19 and 27
> > include the center voxel, 6 does not).
> >
> > Where this matters is that I just realized that mincdefrag actually doesn't
> > check these values, and *silently (ack) falls back to '6' for anything that
> > is not 19 or 27*.
> >
> > I for one have used (by force of habit or logic or consistency with
> > mincmorph) '26' in quite a number of mincdefrag calls, and I am now
> > realizing that those were all silently using a 6-neighbor kernel :(
> >
> > I suggest we change the help text to read (1, 18, 26); and, for backward
> > compatibility, change the bit where it checks this value to accept both 18
> > and 19 for stencil=2; 26 and 27 for stencil=3, and throws an error for
> > anything that is not (6, 18, 19, 26, 27);
> >
> > -- 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 zijdenbos at gmail.com  Tue Jun 24 15:44:13 2014
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Tue, 24 Jun 2014 15:44:13 -0400
Subject: [MINC-users] mincdefrag arguments
In-Reply-To: <201406240337.s5O3bAQd022761@agrippa.bic.mni.mcgill.ca>
References: <CAG0CB20RasbMvO1Lesew3MSnnpsjb3w4qWt2C9nBUNsu8jUZTA@mail.gmail.com>
	<201406240337.s5O3bAQd022761@agrippa.bic.mni.mcgill.ca>
Message-ID: <CABEEk15FkVHfEEHHcQZGQSrDaYVjdYRYm1imUD4ki4xUPAOa6g@mail.gmail.com>

OK - I may be able to get mincdefrag functionality incorporated into
mincmorph (may take a little while).

For the short term, I'll fix the mincdefrag help text and command-line
checking this week; will keep it backward compatible as I suggested. I
prefer (6, 18, 26), since we are talking about #neighbors.

Silently doing something else is not just undesirable, it's wrong :)

-- A


On Mon, Jun 23, 2014 at 11:37 PM, Claude LEPAGE <claude at bic.mni.mcgill.ca>
wrote:

>
> hi,
>
> Somehow, mincdefrag survived over the years after I implemented it quickly.
>
> I have no objection if someone wants to include it in mincmorph. That's
> fine,
> as long as that someone is not me.
>
> I agree that the specification of the arguments is not consistent with
> other
> minctools. Maybe 6 should be 7 instead. But it's all the same. The center
> voxel is always included. The "silent" mode is perhaps not desirable. It
> would
> not take much effort to make it "idiot-proof".
>
> Claude
>
> PS: It's nice to see that mincdefrag is being used out there. :-)
>
>
> > IIRC, there was at one stage an effort to include the logic of
> > mincdefrag into mincmorph. (it would be just another kernel
> > operation). This would be one way to resolve differences and allow
> > mincdefrag to be more flexible.
> >
> > Claude, do you remember what happened here?
> >
> >
> > a
> >
> > On 24 June 2014 09:14, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> > > This one is mostly for Claude, but just in case it has affected
> anybody I
> > > figured I'd raise it here.
> > >
> > > The mincdefrag help text states that the allowable values for this
> "number
> > > of neighbors" value are (6, 19, 27), which is inconsistent (19 and 27
> > > include the center voxel, 6 does not).
> > >
> > > Where this matters is that I just realized that mincdefrag actually
> doesn't
> > > check these values, and *silently (ack) falls back to '6' for anything
> that
> > > is not 19 or 27*.
> > >
> > > I for one have used (by force of habit or logic or consistency with
> > > mincmorph) '26' in quite a number of mincdefrag calls, and I am now
> > > realizing that those were all silently using a 6-neighbor kernel :(
> > >
> > > I suggest we change the help text to read (1, 18, 26); and, for
> backward
> > > compatibility, change the bit where it checks this value to accept
> both 18
> > > and 19 for stencil=2; 26 and 27 for stencil=3, and throws an error for
> > > anything that is not (6, 18, 19, 26, 27);
> > >
> > > -- 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
>
>

From elizabethw at msmri.medicine.ubc.ca  Tue Jun 24 18:24:23 2014
From: elizabethw at msmri.medicine.ubc.ca (Elizabeth Wicks)
Date: Tue, 24 Jun 2014 15:24:23 -0700
Subject: [MINC-users] MNI152 Standard Brain
Message-ID: <53A9FA97.4040306@msmri.medicine.ubc.ca>

Hi all,

I am wondering if anyone knows how the skull image is produced in the 
MNI152 2mm standard set of images? I am hoping to find out what method 
was used to extract the skull in order to reproduce similar skull 
outputs with other brain images.

Thanks in advance!

Elizabeth

From a.janke at gmail.com  Wed Jun 25 19:05:31 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 26 Jun 2014 09:05:31 +1000
Subject: [MINC-users] MNI152 Standard Brain
In-Reply-To: <53A9FA97.4040306@msmri.medicine.ubc.ca>
References: <53A9FA97.4040306@msmri.medicine.ubc.ca>
Message-ID: <CAG0CB22DtUPNuNAHo_-7b3kazQ9yuK1rt4bfPc7XX7evWcoWKw@mail.gmail.com>

Hi Elizabeth,

Can you elaborate a bit more on what you mean by skull image? MRI will
only show bone as the absence of signal (unless you are using
ultra-short Z-TE imaging which the ICBM protocol didn't).

If you are talking about the latest nonlinear models I was of the
understanding that the high-resolution non-linear fitting was done on
the cortical structures only and anything else external was linear
only. Vladimir will be able to confirm this.


ta


a


On 25 June 2014 08:24, Elizabeth Wicks <elizabethw at msmri.medicine.ubc.ca> wrote:
> Hi all,
>
> I am wondering if anyone knows how the skull image is produced in the MNI152
> 2mm standard set of images? I am hoping to find out what method was used to
> extract the skull in order to reproduce similar skull outputs with other
> brain images.
>
> Thanks in advance!
>
> Elizabeth
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users