From se at hst.aau.dk  Thu Oct  2 10:03:06 2008
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Thu, 2 Oct 2008 16:03:06 +0200 (CEST)
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
Message-ID: <87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>

Hi all,

Yes, I know this has been an issue previously discussed. Did anyone ever solve the conversion?
I tried the LONI Debabeler which claims to be able convert to dicom. However, selecting the right mapping I get

* Target Writing Error
...[ Unable to write data to the files. ]...
...[ Unable to recognize the image type. ]...
* Unable to write translated data for "dicom_source".
* Group Translation Error
...[ Unable to write all the target data. ]...
* Unable to translate (minc_source) to (dicom_source) involving the files:

and this is for a minc file downloaded from LONI.
I also tried doing mnc2nii with and without the -analyze option and debabeling the outputs. But no luck.
So does anyone have suggestions on how to obtain dicom images from minc? Maybe mincextract combined with some obscure conversion tool will do the trick?

Best regards,

Simon Fristed Eskildsen
Assistant Professor
Dept. of Health Science and Technology
Aalborg University, Denmark

From a.janke at gmail.com  Thu Oct  2 10:10:01 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 3 Oct 2008 00:10:01 +1000
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
Message-ID: <d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>

Hi Simon,

On Fri, Oct 3, 2008 at 12:03 AM, Simon Fristed Eskildsen <se at hst.aau.dk> wrote:
> Yes, I know this has been an issue previously discussed. Did anyone ever solve the conversion?

Well for myself I am still sticking well away from such heinous
conversions. I would suggest that you take a look at david clunies
dc3tools software. I seem to remember that they can read a RAW/Tiff
file which you can certainly make with the MINC tools.

Failing that surely ITK can write a DICOM file?  it can read MINC via
leila's extensions so that might be your saviour.

-- 
Andrew Janke - andrew.janke at anu.edu.au
Department of Geriatric Medicine, ANU
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From mishkind at gmail.com  Thu Oct  2 21:22:51 2008
From: mishkind at gmail.com (Mishkin Derakhshan)
Date: Thu, 2 Oct 2008 21:22:51 -0400
Subject: [MINC-users] brain-view
Message-ID: <9c5abb60810021822s784caf25ld0b659fe07f03190@mail.gmail.com>

Hi,
I am getting an error trying to load brain-view with a stats file, namely
the color scheme won't load:

Coin warning in SbImage::readFile(): The simage library is not available,
can not import any images from disk.
Coin warning in SoTexture2::filenameSensorCB(): Image file
'//usr/local/mni/share/brain-view//spectral.rgb' could not be read

I checked and the file spectral.rgb does indeed exist. It is owned by root
and has permission 644 (changing to 777 did nothing).

I suspect this has something to do with simage and coin, but i really don't
know what either of those are.

I am running ubuntu 8.04 64bit with a 2.6.24-18 kernel. I think I installed
brain-view from packages.bic.mni.mcgill.ca/ubuntu-hardy

Here is all the debug information I can think of:

opus[~]$ brain-view rh.white.obj rh.thickness.txt
Using environment file: /usr/local/mni/share/brain-view/brain-view-config
inside td.isReadable
Initialisation variables:
   Texturedir: //usr/local/mni/share/brain-view//
   Texturefile: //usr/local/mni/share/brain-view//spectral.rgb
before signals
in constructor
initialising
adding cameras
end of colourbar
after signals
Coin warning in SbImage::readFile(): The simage library is not available,
can not import any images from disk.
Coin warning in SoTexture2::filenameSensorCB(): Image file
'//usr/local/mni/share/brain-view//spectral.rgb' could not be read

opus[~]$ brain-view -version
program: 2.0.14
libminc: 2.0.14
netcdf : 3.6.1 of Mar  6 2007 10:20:46 $
HDF5   : 1.6.5

opus[~]$ ldd `which brain-view`
    linux-vdso.so.1 =>  (0x00007fff77bfe000)
    libCoin.so.40 => /usr/lib/libCoin.so.40 (0x00007f476ef56000)
    libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f476f917000)
    libSM.so.6 => /usr/lib/libSM.so.6 (0x00007f476ed4e000)
    libICE.so.6 => /usr/lib/libICE.so.6 (0x00007f476eb33000)
    libXmu.so.6 => /usr/lib/libXmu.so.6 (0x00007f476e91a000)
    libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f476e709000)
    libXi.so.6 => /usr/lib/libXi.so.6 (0x00007f476e500000)
    libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f476e1fd000)
    libpcre++.so.0 => /usr/lib/libpcre++.so.0 (0x00007f476dff4000)
    libpcre.so.3 => /usr/lib/libpcre.so.3 (0x00007f476ddce000)
    libhdf5-1.6.5.so.0 => /usr/lib/libhdf5-1.6.5.so.0 (0x00007f476dab7000)
    libz.so.1 => /usr/lib/libz.so.1 (0x00007f476d8a0000)
    libnetcdf.so.3 => /usr/lib/libnetcdf.so.3 (0x00007f476d662000)
    libSoQt.so.20 => /usr/lib/libSoQt.so.20 (0x00007f476d38e000)
    libqt-mt.so.3 => /usr/lib/libqt-mt.so.3 (0x00007f476c721000)
    libdl.so.2 => /lib/libdl.so.2 (0x00007f476c51d000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x00007f476c301000)
    libm.so.6 => /lib/libm.so.6 (0x00007f476c080000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f476bd75000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f476bb67000)
    libc.so.6 => /lib/libc.so.6 (0x00007f476b805000)
    libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x00007f476ac4e000)
    libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1
(0x00007f476ab4d000)
    libXt.so.6 => /usr/lib/libXt.so.6 (0x00007f476a8e9000)
    libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f476a6e7000)
    libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x00007f476a4e6000)
    libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f476a2cb000)
    libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f476a09a000)
    libaudio.so.2 => /usr/lib/libaudio.so.2 (0x00007f4769e81000)
    libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00007f4769c5e000)
    libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007f4769a39000)
    libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f4769830000)
    libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007f4769629000)
    libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00007f476941f000)
    libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007f476921d000)
    libXft.so.2 => /usr/lib/libXft.so.2 (0x00007f4769009000)
    libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f4768d8a000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f476f8e6000)
    libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f4768b85000)
    libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f4768961000)
    libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f476875c000)

From a.janke at gmail.com  Thu Oct  2 21:36:07 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 3 Oct 2008 11:36:07 +1000
Subject: [MINC-users] brain-view
In-Reply-To: <9c5abb60810021822s784caf25ld0b659fe07f03190@mail.gmail.com>
References: <9c5abb60810021822s784caf25ld0b659fe07f03190@mail.gmail.com>
Message-ID: <d747ed50810021836u5c84cf4aj57492030f134cede@mail.gmail.com>

Hi Miskin,


On Fri, Oct 3, 2008 at 11:22 AM, Mishkin Derakhshan <mishkind at gmail.com> wrote:
> I am getting an error trying to load brain-view with a stats file, namely
> the color scheme won't load:
>
> Coin warning in SbImage::readFile(): The simage library is not available,
> can not import any images from disk.
> Coin warning in SoTexture2::filenameSensorCB(): Image file
> '//usr/local/mni/share/brain-view//spectral.rgb' could not be read

Yes we are having trouble with the way that brain-view does library
files. Are you sure that the file in question is in /usr/local/mni or
in /usr/local/bic ?

The ubuntu-hardy packages will default to the latter and perhaps the
code is hard-coded to the former.


a

From mishkind at gmail.com  Thu Oct  2 22:03:14 2008
From: mishkind at gmail.com (Mishkin Derakhshan)
Date: Thu, 2 Oct 2008 22:03:14 -0400
Subject: [MINC-users] brain-view
In-Reply-To: <d747ed50810021836u5c84cf4aj57492030f134cede@mail.gmail.com>
References: <9c5abb60810021822s784caf25ld0b659fe07f03190@mail.gmail.com>
	<d747ed50810021836u5c84cf4aj57492030f134cede@mail.gmail.com>
Message-ID: <9c5abb60810021903t7c84236nc97d683c7bc6e0dc@mail.gmail.com>

Things were all installed in /usr/local/bic by default but I've set up
symbolic links everywhere:

/usr/local/mni -> /usr/local/bic
and
/usr/local/mni/data -> /usr/local/mni/share

so when it looks for the file it should be able to find it, no?



On Thu, Oct 2, 2008 at 9:36 PM, Andrew Janke <a.janke at gmail.com> wrote:

> Hi Miskin,
>
>
> On Fri, Oct 3, 2008 at 11:22 AM, Mishkin Derakhshan <mishkind at gmail.com>
> wrote:
> > I am getting an error trying to load brain-view with a stats file, namely
> > the color scheme won't load:
> >
> > Coin warning in SbImage::readFile(): The simage library is not available,
> > can not import any images from disk.
> > Coin warning in SoTexture2::filenameSensorCB(): Image file
> > '//usr/local/mni/share/brain-view//spectral.rgb' could not be read
>
> Yes we are having trouble with the way that brain-view does library
> files. Are you sure that the file in question is in /usr/local/mni or
> in /usr/local/bic ?
>
> The ubuntu-hardy packages will default to the latter and perhaps the
> code is hard-coded to the former.
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From a.janke at gmail.com  Thu Oct  2 22:07:39 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 3 Oct 2008 12:07:39 +1000
Subject: [MINC-users] brain-view
In-Reply-To: <9c5abb60810021903t7c84236nc97d683c7bc6e0dc@mail.gmail.com>
References: <9c5abb60810021822s784caf25ld0b659fe07f03190@mail.gmail.com>
	<d747ed50810021836u5c84cf4aj57492030f134cede@mail.gmail.com>
	<9c5abb60810021903t7c84236nc97d683c7bc6e0dc@mail.gmail.com>
Message-ID: <d747ed50810021907p71f71293uf92180e5a0671f6e@mail.gmail.com>

On Fri, Oct 3, 2008 at 12:03 PM, Mishkin Derakhshan <mishkind at gmail.com> wrote:
> Things were all installed in /usr/local/bic by default but I've set up
> symbolic links everywhere:
>
> /usr/local/mni -> /usr/local/bic
> and
> /usr/local/mni/data -> /usr/local/mni/share
>
> so when it looks for the file it should be able to find it, no?

Should. :)  Is this /usr/local NFS mounted per-chance?


a

From mishkind at gmail.com  Thu Oct  2 22:25:49 2008
From: mishkind at gmail.com (Mishkin Derakhshan)
Date: Thu, 2 Oct 2008 22:25:49 -0400
Subject: [MINC-users] brain-view
In-Reply-To: <d747ed50810021907p71f71293uf92180e5a0671f6e@mail.gmail.com>
References: <9c5abb60810021822s784caf25ld0b659fe07f03190@mail.gmail.com>
	<d747ed50810021836u5c84cf4aj57492030f134cede@mail.gmail.com>
	<9c5abb60810021903t7c84236nc97d683c7bc6e0dc@mail.gmail.com>
	<d747ed50810021907p71f71293uf92180e5a0671f6e@mail.gmail.com>
Message-ID: <9c5abb60810021925t4be4a95erb85b13f10cec15f7@mail.gmail.com>

I found the solution:

sudo apt-get install libsimage-dev

(libsimage20 didn't work)



On Thu, Oct 2, 2008 at 10:07 PM, Andrew Janke <a.janke at gmail.com> wrote:

> On Fri, Oct 3, 2008 at 12:03 PM, Mishkin Derakhshan <mishkind at gmail.com>
> wrote:
> > Things were all installed in /usr/local/bic by default but I've set up
> > symbolic links everywhere:
> >
> > /usr/local/mni -> /usr/local/bic
> > and
> > /usr/local/mni/data -> /usr/local/mni/share
> >
> > so when it looks for the file it should be able to find it, no?
>
> Should. :)  Is this /usr/local NFS mounted per-chance?
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From a.janke at gmail.com  Thu Oct  2 22:30:28 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 3 Oct 2008 12:30:28 +1000
Subject: [MINC-users] brain-view
In-Reply-To: <9c5abb60810021925t4be4a95erb85b13f10cec15f7@mail.gmail.com>
References: <9c5abb60810021822s784caf25ld0b659fe07f03190@mail.gmail.com>
	<d747ed50810021836u5c84cf4aj57492030f134cede@mail.gmail.com>
	<9c5abb60810021903t7c84236nc97d683c7bc6e0dc@mail.gmail.com>
	<d747ed50810021907p71f71293uf92180e5a0671f6e@mail.gmail.com>
	<9c5abb60810021925t4be4a95erb85b13f10cec15f7@mail.gmail.com>
Message-ID: <d747ed50810021930t5a4f34f3r450ce96d2dea55fe@mail.gmail.com>

> sudo apt-get install libsimage-dev

Thanks, I will add this to mincbundle


a

From alex at bic.mni.mcgill.ca  Thu Oct  2 22:50:25 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Thu, 2 Oct 2008 22:50:25 -0400
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
Message-ID: <e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>

<soapbox>
While I understand Andrew's reluctance towards a minc-to-dicom
converter and I also understand some of the technical issues
surrounding that type of conversion, it is undeniably a need that
exists and if we (the minc community) are somewhat serious about
wanting people to use minc, I think we have little choice but to
provide such a converter sooner or later. I myself get requests for
this on a weekly basis (twice just today in fact).

There are a few efforts out there that claim to be able to do this
(MIPAV, LONI debabeler, ...), but as far as I know they are all flawed
in some way or another - and mostly in that they are obviously not
part of minc 'proper'. IMHO, a minc-to-dicom converter *should* really
come from the makers of minc; and as a community, at some point we
should get off our high horse and accept that - well - perhaps we
should actually make it easy for people to interact with minc...

Just my $0.02... and yes, I know that does not answer the most
important question: "who?" ... Any takers to do it (or fund it)?
</soapbox>

-- A

On Thu, Oct 2, 2008 at 10:10 AM, Andrew Janke <a.janke at gmail.com> wrote:
> Hi Simon,
>
> On Fri, Oct 3, 2008 at 12:03 AM, Simon Fristed Eskildsen <se at hst.aau.dk> wrote:
>> Yes, I know this has been an issue previously discussed. Did anyone ever solve the conversion?
>
> Well for myself I am still sticking well away from such heinous
> conversions. I would suggest that you take a look at david clunies
> dc3tools software. I seem to remember that they can read a RAW/Tiff
> file which you can certainly make with the MINC tools.
>
> Failing that surely ITK can write a DICOM file?  it can read MINC via
> leila's extensions so that might be your saviour.
>
> --
> Andrew Janke - andrew.janke at anu.edu.au
> Department of Geriatric Medicine, ANU
> (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia    +61 (402) 700 883
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From alex at bic.mni.mcgill.ca  Thu Oct  2 22:58:01 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Thu, 2 Oct 2008 22:58:01 -0400
Subject: [MINC-users] minc 2.0.16?
Message-ID: <e758a6650810021958k70e408adnb39f9afe757fc1b8@mail.gmail.com>

While on the topic of conversions: are there any plans to release minc
2.0.16 anytime soon?

It appears that (at least) the 64-bit build of dcm2mnc from
minc-2.0.15 is not able to convert (or even recognize) quite a bit of
dicom data; but I built the version currently in CVS and that seems to
work flawlessly. Could be due to the fixes that Claude put in for
64-bit compatibility, I don't know, but either way, it would be good
to get a working dcm2mnc out there (plus other fixes/additions).

-- A

From jharlap at bic.mni.mcgill.ca  Thu Oct  2 23:10:26 2008
From: jharlap at bic.mni.mcgill.ca (Jonathan Harlap)
Date: Thu, 2 Oct 2008 23:10:26 -0400
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
Message-ID: <115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>

<reposted from the right account - sorry if it shows up twice>

While this has been talked about many times, I have yet to see someone
do it reliably.  I've had this discussion a few times too many by now,
and so I think it's time to summarize my experiences here, where
future seekers of such info might find it, with the caveat that all of
this should be considered my subjective truth rather than a universal
truth.

The root of the issue seems to be one of expectation: If all you
expect is a set of DICOM files each containing one slice with the
header containing only the most basic of coordinate space definition
info, then this conversion is relatively simple and you can hack it
together with a combination of minctoraw and your DICOM package of
choice (dicom3tools, dcmtk, etc...).  However, in my experience people
seem to have this interesting notion that they should be able to take
some DICOM data off a scanner, run it through dcm2mnc and then back
through a fictional mnc2dcm and that the resultant files will be
identical to the input files, or that they can take a minc file
produced by some processing pipeline and convert them to DICOM while
retaining all the information that was in the source minc.  As the
header structures of the two formats are entirely different,
specifically where the minc header can store fairly arbitrary data
with user-defined keys while DICOM has a much more regimented [and
restricted] header structure, it is fairly obvious to anyone who looks
at this problem in detail that the fictitious ideal mnc2dcm cannot
exist.  If that is agreed upon, noting that I have yet to meet the
DICOM user who is willing to agree to this, then the question of what
DICOM header info to populate given the very flexible minc header can
be discussed and, in my experience, is unlikely to be resolved - at
least not in a manner that would allow for one tool to satisfy the
needs of the larger set of possible users.  The most often outcome
seems to be that a group who only uses minc in one particular way
defines their own way of mapping the minc header attributes that they
care about into DICOM private elements and consequently writes a
conversion script that other groups will find of little use.

Sorry to have to paint such a dark picture of this process - but this
is simply my observation of the issue.  If you want to give another
group's bad hack converter a try (where LONI Debabeler was your first
bad hack converter attempt), you can try NIH's MIPAV, but I'm guessing
you'll find it differently unsuccessful.  I'm not well informed about
NIFTI-1 tools out there, but I'd guess that there are also hack
nii2dcm-type tools out there which you could chain onto mnc2nii.

Cheers,
J

On Thu, Oct 2, 2008 at 10:50 PM, Alex Zijdenbos <alex at bic.mni.mcgill.ca> wrote:
> <soapbox>
> While I understand Andrew's reluctance towards a minc-to-dicom
> converter and I also understand some of the technical issues
> surrounding that type of conversion, it is undeniably a need that
> exists and if we (the minc community) are somewhat serious about
> wanting people to use minc, I think we have little choice but to
> provide such a converter sooner or later. I myself get requests for
> this on a weekly basis (twice just today in fact).
>
> There are a few efforts out there that claim to be able to do this
> (MIPAV, LONI debabeler, ...), but as far as I know they are all flawed
> in some way or another - and mostly in that they are obviously not
> part of minc 'proper'. IMHO, a minc-to-dicom converter *should* really
> come from the makers of minc; and as a community, at some point we
> should get off our high horse and accept that - well - perhaps we
> should actually make it easy for people to interact with minc...
>
> Just my $0.02... and yes, I know that does not answer the most
> important question: "who?" ... Any takers to do it (or fund it)?
> </soapbox>
>
> -- A
>
> On Thu, Oct 2, 2008 at 10:10 AM, Andrew Janke <a.janke at gmail.com> wrote:
>> Hi Simon,
>>
>> On Fri, Oct 3, 2008 at 12:03 AM, Simon Fristed Eskildsen <se at hst.aau.dk> wrote:
>>> Yes, I know this has been an issue previously discussed. Did anyone ever solve the conversion?
>>
>> Well for myself I am still sticking well away from such heinous
>> conversions. I would suggest that you take a look at david clunies
>> dc3tools software. I seem to remember that they can read a RAW/Tiff
>> file which you can certainly make with the MINC tools.
>>
>> Failing that surely ITK can write a DICOM file?  it can read MINC via
>> leila's extensions so that might be your saviour.
>>
>> --
>> Andrew Janke - andrew.janke at anu.edu.au
>> Department of Geriatric Medicine, ANU
>> (a.janke at gmail.com || http://a.janke.googlepages.com/)
>> Canberra->Australia    +61 (402) 700 883
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From alex at bic.mni.mcgill.ca  Fri Oct  3 00:21:26 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Fri, 3 Oct 2008 00:21:26 -0400
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
	<115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
Message-ID: <e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>

:) well my subjective truth is more of a half-full nature: the vast
majority of users that ask me about a minc-to-dicom conversion, simply
want to be able to load a minc volume in their favorite dicom viewer
(and don't want to bother with building and learning Display - who
could blame them?). As such, 90% of these would be perfectly happy
with having a way to turn a minc volume into valid dicom.

I think we can all agree that expecting

   <dicom> == mnc2dcm( dcm2mnc( <dicom> ) )

is simply not realistic. However, I suspect that a mnc2dcm that would attain

  <minc> == dcm2mnc( mnc2dcm( <minc> ) )

is much more feasible (by the way, I don't believe that you can do the
back-and-forth conversion with nii2mnc/mnc2nii and expect to get the
same result either - but I could be wrong).

In any event, I agree completely that the root of the problem is
expectation, but I don't think that should be a reason for not
providing a relatively simple tool, provided with sufficient
disclaimers, that I think a fairly large number of people would find
very useful. Essentially, a 'proper' minc implementation of the hacks
that Andrew and you are suggesting.

But if nobody is interested or has done it already; I hope to find
time or $$ to take care of this, because in my mind it is one of the
largest 'holes' in minc (this and the fact that the minc2 internal
compression isn't working as well as one might hope).

-- A

On Thu, Oct 2, 2008 at 11:10 PM, Jonathan Harlap
<jharlap at bic.mni.mcgill.ca> wrote:
> <reposted from the right account - sorry if it shows up twice>
>
> While this has been talked about many times, I have yet to see someone
> do it reliably.  I've had this discussion a few times too many by now,
> and so I think it's time to summarize my experiences here, where
> future seekers of such info might find it, with the caveat that all of
> this should be considered my subjective truth rather than a universal
> truth.
>
> The root of the issue seems to be one of expectation: If all you
> expect is a set of DICOM files each containing one slice with the
> header containing only the most basic of coordinate space definition
> info, then this conversion is relatively simple and you can hack it
> together with a combination of minctoraw and your DICOM package of
> choice (dicom3tools, dcmtk, etc...).  However, in my experience people
> seem to have this interesting notion that they should be able to take
> some DICOM data off a scanner, run it through dcm2mnc and then back
> through a fictional mnc2dcm and that the resultant files will be
> identical to the input files, or that they can take a minc file
> produced by some processing pipeline and convert them to DICOM while
> retaining all the information that was in the source minc.  As the
> header structures of the two formats are entirely different,
> specifically where the minc header can store fairly arbitrary data
> with user-defined keys while DICOM has a much more regimented [and
> restricted] header structure, it is fairly obvious to anyone who looks
> at this problem in detail that the fictitious ideal mnc2dcm cannot
> exist.  If that is agreed upon, noting that I have yet to meet the
> DICOM user who is willing to agree to this, then the question of what
> DICOM header info to populate given the very flexible minc header can
> be discussed and, in my experience, is unlikely to be resolved - at
> least not in a manner that would allow for one tool to satisfy the
> needs of the larger set of possible users.  The most often outcome
> seems to be that a group who only uses minc in one particular way
> defines their own way of mapping the minc header attributes that they
> care about into DICOM private elements and consequently writes a
> conversion script that other groups will find of little use.
>
> Sorry to have to paint such a dark picture of this process - but this
> is simply my observation of the issue.  If you want to give another
> group's bad hack converter a try (where LONI Debabeler was your first
> bad hack converter attempt), you can try NIH's MIPAV, but I'm guessing
> you'll find it differently unsuccessful.  I'm not well informed about
> NIFTI-1 tools out there, but I'd guess that there are also hack
> nii2dcm-type tools out there which you could chain onto mnc2nii.
>
> Cheers,
> J
>
> On Thu, Oct 2, 2008 at 10:50 PM, Alex Zijdenbos <alex at bic.mni.mcgill.ca> wrote:
>> <soapbox>
>> While I understand Andrew's reluctance towards a minc-to-dicom
>> converter and I also understand some of the technical issues
>> surrounding that type of conversion, it is undeniably a need that
>> exists and if we (the minc community) are somewhat serious about
>> wanting people to use minc, I think we have little choice but to
>> provide such a converter sooner or later. I myself get requests for
>> this on a weekly basis (twice just today in fact).
>>
>> There are a few efforts out there that claim to be able to do this
>> (MIPAV, LONI debabeler, ...), but as far as I know they are all flawed
>> in some way or another - and mostly in that they are obviously not
>> part of minc 'proper'. IMHO, a minc-to-dicom converter *should* really
>> come from the makers of minc; and as a community, at some point we
>> should get off our high horse and accept that - well - perhaps we
>> should actually make it easy for people to interact with minc...
>>
>> Just my $0.02... and yes, I know that does not answer the most
>> important question: "who?" ... Any takers to do it (or fund it)?
>> </soapbox>
>>
>> -- A
>>
>> On Thu, Oct 2, 2008 at 10:10 AM, Andrew Janke <a.janke at gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Fri, Oct 3, 2008 at 12:03 AM, Simon Fristed Eskildsen <se at hst.aau.dk> wrote:
>>>> Yes, I know this has been an issue previously discussed. Did anyone ever solve the conversion?
>>>
>>> Well for myself I am still sticking well away from such heinous
>>> conversions. I would suggest that you take a look at david clunies
>>> dc3tools software. I seem to remember that they can read a RAW/Tiff
>>> file which you can certainly make with the MINC tools.
>>>
>>> Failing that surely ITK can write a DICOM file?  it can read MINC via
>>> leila's extensions so that might be your saviour.
>>>
>>> --
>>> Andrew Janke - andrew.janke at anu.edu.au
>>> Department of Geriatric Medicine, ANU
>>> (a.janke at gmail.com || http://a.janke.googlepages.com/)
>>> Canberra->Australia    +61 (402) 700 883
>>> _______________________________________________
>>> MINC-users at bic.mni.mcgill.ca
>>> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>>
>>>
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From a.janke at gmail.com  Fri Oct  3 00:33:35 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 3 Oct 2008 14:33:35 +1000
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
	<115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
Message-ID: <d747ed50810022133o2ce0ae31o917544f72e2ae52e@mail.gmail.com>

> The root of the issue seems to be one of expectation: If all you
> expect is a set of DICOM files each containing one slice with the
> header containing only the most basic of coordinate space definition
> info, then this conversion is relatively simple and you can hack it
> together with a combination of minctoraw and your DICOM package of
> choice (dicom3tools, dcmtk, etc...).  However, in my experience people
> seem to have this interesting notion that they should be able to take
> some DICOM data off a scanner, run it through dcm2mnc and then back
> through a fictional mnc2dcm and that the resultant files will be
> identical to the input files

Amen brother Jon.

And it is quite simply a pandoras box that I am not all that
interested in for the reasons pointed out above. Just by simply
writing mcn2ana (the logical reverse of ana2mnc) I increased my
workload significantly a while back. :)  As such I am very
trepidatious to do it again.


a

From a.janke at gmail.com  Fri Oct  3 01:11:21 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 3 Oct 2008 15:11:21 +1000
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
	<115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
	<e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>
Message-ID: <d747ed50810022211q66136b29ka9aa4911f89ffa18@mail.gmail.com>

> :) well my subjective truth is more of a half-full nature: the vast
> majority of users that ask me about a minc-to-dicom conversion, simply
> want to be able to load a minc volume in their favorite dicom viewer

Certainly not in my world.  The tend to come from the "I want to do
some processing and put it back in our PACS" type people or more scary
"I want to do motion correction pre-processing on DTI mosaic images in
MINC put it back in DICOM, read it into FSL and run TBSS" types.

> (and don't want to bother with building and learning Display - who
> could blame them?). As such, 90% of these would be perfectly happy
> with having a way to turn a minc volume into valid dicom.

define "valid dicom". It is a very very loose spec. For example to be
a tad facetious you could do this (on most ubuntu machines).

   mincpik fred.mnc out.pdf
   pdf2dcm out.pdf out.dcm

and it is "valid" dicom

You can also do the same for a JPEG2000 DICOM file (just an
encapsulated JPEG as per the above) using jpg2dcm. They will both load
into most dicom viewers and are certainly valid and would allow users
to view data.


> is simply not realistic. However, I suspect that a mnc2dcm that would attain
>
>  <minc> == dcm2mnc( mnc2dcm( <minc> ) )

I doubt it.  Header info will certainly be lost unless we add our own
custom dicom tags for history patient name, acquisition, etc. This
might be true for image orientation/cosines _if_ you guarantee me that
nothing is going to be done with the dicom file once converted. ie:
none of this:

   $ mnc2dcm out.mnc out.dcm
   $ dcmtk -strip out.dcm new.dcm

   ...

Why? Different manufacturers define origin/start/etc differently, then
there is the thorn issue of "mosaics".

> I don't believe that you can do the
> back-and-forth conversion with nii2mnc/mnc2nii and expect to get the
> same result either - but I could be wrong).

Wrong.  (Well at least for Nifti-1 if you use it correctly and the
programs you use on the Nifti-1 file conform to the Nifti-1 spec).

> But if nobody is interested or has done it already; I hope to find
> time or $$ to take care of this, because in my mind it is one of the
> largest 'holes' in minc.

How many $$?  :)

For the meantime if you really really really really promise with sugar
on top to only, only ever ever want to view images in dicom viewers
and not do anything more with them, just view them and only view them
and promise to not try to use this for other things that "we could
just extend this a bit for" here is "mnc2dcm" :)

pnmtodc is part of dicom2tools from david clunies (an Ozzie!) site,
the package is very easy to compile.

   http://www.dclunie.com/dicom3tools.html

---
#! /bin/sh


infile=$1
outfile=$2

slices=`mincinfo -dimlength zspace $infile`

for i in `seq 0 $slices`;
do
   echo "Doing slice $i"
   mincpik -clobber $infile /tmp/tmp-mnc2dcm-$i.pnm
   pnmtodc /tmp/tmp-mnc2dcm-$i.pnm ${outfile}-$i.dcm
done

---


a

From a.janke at gmail.com  Fri Oct  3 01:21:05 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 3 Oct 2008 15:21:05 +1000
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <d747ed50810022211q66136b29ka9aa4911f89ffa18@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
	<115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
	<e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>
	<d747ed50810022211q66136b29ka9aa4911f89ffa18@mail.gmail.com>
Message-ID: <d747ed50810022221k22f09221xd6ebc048d2cd5f53@mail.gmail.com>

PS: on the topic of "simple" viewers, here is what use for those who
do processing on "my" machines and want to view things from time to
time (often remotely).

   http://mavis.anu.edu.au/ANDI/AJAX-minimal/

(Please be gentle, mavis is a lowly 600Mhz Pentium III with but a
frazzle of RAM)

Currently viewing the ICBM 152.   This is a combination of some simple
php, about 500 lines of commented and indented javascript and a
skerrick of css and html.

ie: will run anwhere.  BUT given that the IE people still refuse to
support data UID's it will only work in pretty much anything bar IE.

   http://en.wikipedia.org/wiki/Data:_URI_scheme


a

From a.janke at gmail.com  Fri Oct  3 02:20:23 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 3 Oct 2008 16:20:23 +1000
Subject: [MINC-users] minc 2.0.16?
In-Reply-To: <e758a6650810021958k70e408adnb39f9afe757fc1b8@mail.gmail.com>
References: <e758a6650810021958k70e408adnb39f9afe757fc1b8@mail.gmail.com>
Message-ID: <d747ed50810022320r4060e48dl3ba5d6ca0277e4a3@mail.gmail.com>

The answer to this is "soon". :(  I had been working on changes such
that the "2.0.16' release was actually going to be 2.1.0 in which the
default output type is a MINC2 file. This means that there are  a lot
of small changes needed to a lot of files. (adding a -1 option for
example!).

I could always release 2.0.16 without all these changes.  I will add
this to tonights list of jobs.


a

On Fri, Oct 3, 2008 at 12:58 PM, Alex Zijdenbos <alex at bic.mni.mcgill.ca> wrote:
> While on the topic of conversions: are there any plans to release minc
> 2.0.16 anytime soon?
>
> It appears that (at least) the 64-bit build of dcm2mnc from
> minc-2.0.15 is not able to convert (or even recognize) quite a bit of
> dicom data; but I built the version currently in CVS and that seems to
> work flawlessly. Could be due to the fixes that Claude put in for
> 64-bit compatibility, I don't know, but either way, it would be good
> to get a working dcm2mnc out there (plus other fixes/additions).
>
> -- A
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
Andrew Janke - andrew.janke at anu.edu.au
Department of Geriatric Medicine, ANU
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From alex at bic.mni.mcgill.ca  Fri Oct  3 09:07:23 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Fri, 3 Oct 2008 09:07:23 -0400
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <d747ed50810022211q66136b29ka9aa4911f89ffa18@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
	<115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
	<e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>
	<d747ed50810022211q66136b29ka9aa4911f89ffa18@mail.gmail.com>
Message-ID: <e758a6650810030607y1cf63d3j1609c5c983a1dce8@mail.gmail.com>

>>  <minc> == dcm2mnc( mnc2dcm( <minc> ) )
>
> I doubt it.  Header info will certainly be lost unless we add our own
> custom dicom tags for history patient name, acquisition, etc.

What does MINC add to a header that wasn't in original dicom? Other
than the history (added) and the explicit slice #/position information
(lost), everything else once came from source dicom data, so why would
it be difficult to put things like patient name back where they came
from, in pretty standard dicom fields?

>> I don't believe that you can do the
>> back-and-forth conversion with nii2mnc/mnc2nii and expect to get the
>> same result either - but I could be wrong).
>
> Wrong.  (Well at least for Nifti-1 if you use it correctly and the
> programs you use on the Nifti-1 file conform to the Nifti-1 spec).

Are you talking about producing an output file in format X and that
output being valid following the spec of X; or of being able to run a
forward conversion followed by a backward conversion and getting the
same result you started with? I was talking about the latter, which
the minc<-> nifti converters definitely don't do. For the fun of it,
try

$ mnc2nii /usr/local/bic/share/mni_autoreg/icbm_avg_152_t1_tal_lin.mnc test.nii
$ nii2mnc test.nii
$ mincdiff  /usr/local/bic/share/mni_autoreg/icbm_avg_152_t1_tal_lin.mnc
test.mnc

and see how identical they are :) And what is worse, on my box (with a
fresh install of mincbundle of this morning), register doesn't even
want to load 'test,mnc'....

Anyways, I don't want to beat a dead (high?) horse but (a) I am still
not convinced that - with some reasonable assumptions - it is really
so untractable, and (b) we are already providing converters that don't
live up to the forward/backward conversion (what's the work -
idempotent? bijective?) expectation.

Yes, I know the answer is "if it is so easy, why don't you do it".
Touche' on that one :)

-- A

From jharlap at bic.mni.mcgill.ca  Fri Oct  3 09:12:45 2008
From: jharlap at bic.mni.mcgill.ca (Jonathan Harlap)
Date: Fri, 3 Oct 2008 09:12:45 -0400
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
	<115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
	<e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>
Message-ID: <115a643d0810030612g665d8f60i65755177dfa296d4@mail.gmail.com>

On Fri, Oct 3, 2008 at 12:21 AM, Alex Zijdenbos <alex at bic.mni.mcgill.ca> wrote:

> I think we can all agree that expecting
>
>   <dicom> == mnc2dcm( dcm2mnc( <dicom> ) )
>
> is simply not realistic. However, I suspect that a mnc2dcm that would attain
>
>  <minc> == dcm2mnc( mnc2dcm( <minc> ) )
>
> is much more feasible (by the way, I don't believe that you can do the

Not as feasible as you seem to think, IMO:

Givens:
(A) A minc file can store as attributes virtually any user-defined
data with the attribute name (the datum's key) being entirely up to
the user.
(B) DICOM files are actually just a stream of elements recorded on
disk, where each element is identified with a group and element
number, each 16 bits.
(C) DICOM group numbers that are even are publicly defined and so
cannot be used for arbitrary data whereas odd group numbers are
private and so can be used for anything but only the creator
application can be expected to use such data.

Now consider the statement "<minc> == dcm2mnc (mnc2dcm( <minc> ) )".
We have two approaches:
(1) Designate a single private element to contain a very long string
which contains some serialization of the minc header in its entirety,
and modify dcm2mnc to look for this private element, confirm that the
creator application was mnc2dcm, and then use that single value to
populate the entire header.
(2) Create a mapping function such that each minc attribute is
assigned to a unique private element in the output DICOM file.  This
must be a consistent and reliable mapping in order for dcm2mnc to know
about it and be able to reconstruct the original attributes without
additional user input.

I think we can trivially agree that approach (1) is completely
useless, as it doesn't produce useful DICOM files, it only produces a
hack by which a hacked dcm2mnc could satisfy the stated requirement.
In other words, your test case will pass but the unstated test case
that demonstrates that the produced DICOM is useful would fail.

Approach (2) seems, at first blush, more interesting, and certainly
would support both your test and the usefulness test.  However, if we
combine givens (B) and (C), we can show that only 2^15 private
elements can be defined in the universal mapping function before we
run out of elements in which to store the attribute values.  As we
have to deal with given (A), which implies that there is no limit on
the number of possible minc attributes in use over the universe of
minc files, it becomes clear that approach (2) will fail.  This is, of
course, putting aside issues about how you are going to add new
elements to the universal mapping function in such a way that no
private element is given to two different attributes, which could
technically be solved with distributed transactions, but is fairly
complicated and really doesn't belong in a simple file format
converter.

So, now we know that you cannot take an arbitrary DICOM or minc
dataset and circularly convert it via the other back to itself,
regardless of which one you start with.  We are back to my original
statement that it all has to do with expectation, and that while
complete conversion is impossible (as just demonstrated, I think) a
partial conversion is possible.  The worst case, as originally stated,
retains only slice position info.  Obviously an intermediate case
exists, and it is only a question of defining which elements and
attributes are used in the mapping - but this "only" is an ugly job
fraught with disagreement - as was also my original statement.


Defense rests ;)

Cheers,
J

From alex at bic.mni.mcgill.ca  Fri Oct  3 09:33:52 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Fri, 3 Oct 2008 09:33:52 -0400
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <115a643d0810030612g665d8f60i65755177dfa296d4@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
	<115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
	<e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>
	<115a643d0810030612g665d8f60i65755177dfa296d4@mail.gmail.com>
Message-ID: <e758a6650810030633r7eae3c47tde217a8f119d4264@mail.gmail.com>

>> is simply not realistic. However, I suspect that a mnc2dcm that would attain
>>
>>  <minc> == dcm2mnc( mnc2dcm( <minc> ) )
>>
>> is much more feasible (by the way, I don't believe that you can do the
>
> Not as feasible as you seem to think, IMO:

Should I mention that you were the one that suggested this to me some
time ago? :)

> Obviously an intermediate case
> exists, and it is only a question of defining which elements and
> attributes are used in the mapping - but this "only" is an ugly job
> fraught with disagreement - as was also my original statement.

Well - this is exactly the way dcm2mnc, nii2mnc, mnc2nii, and probably
other existing converters already work, and people seem to be pretty
happy with them in general...

> Defense rests ;)

Indeed

-- A

From a.janke at gmail.com  Fri Oct  3 09:42:37 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 3 Oct 2008 23:42:37 +1000
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <e758a6650810030607y1cf63d3j1609c5c983a1dce8@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
	<115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
	<e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>
	<d747ed50810022211q66136b29ka9aa4911f89ffa18@mail.gmail.com>
	<e758a6650810030607y1cf63d3j1609c5c983a1dce8@mail.gmail.com>
Message-ID: <d747ed50810030642h2b5296bqa75a4bd976ffe88d@mail.gmail.com>

On Fri, Oct 3, 2008 at 11:07 PM, Alex Zijdenbos <alex at bic.mni.mcgill.ca> wrote:
>>>  <minc> == dcm2mnc( mnc2dcm( <minc> ) )
>>
>> I doubt it.  Header info will certainly be lost unless we add our own
>> custom dicom tags for history patient name, acquisition, etc.
>
> What does MINC add to a header that wasn't in original dicom?

History, provenance (MINC unique ID), unified slice scaling
(sometimes), real to voxel intensity mapping, real valid ranges, slice
intensity ranges. That's what I could come up with just now without
vast amounts of whacking neuron together, I am sure there are more.

> so why would
> it be difficult to put things like patient name back where they came
> from, in pretty standard dicom fields?

Jon used bigger words than I did on this one so I will defer to him.

> Are you talking about producing an output file in format X and that
> output being valid following the spec of X; or of being able to run a
> forward conversion followed by a backward conversion and getting the
> same result you started with? I was talking about the latter, which
> the minc<-> nifti converters definitely don't do. For the fun of it,
> try
>
> $ mnc2nii /usr/local/bic/share/mni_autoreg/icbm_avg_152_t1_tal_lin.mnc test.nii
> $ nii2mnc test.nii
> $ mincdiff  /usr/local/bic/share/mni_autoreg/icbm_avg_152_t1_tal_lin.mnc
> test.mnc
>
> and see how identical they are :)

If you look down, I reckon your toes are smoking....  You my friend
just got bitten by one of the shortcomings of NifTI (slice by slice
scaling). This is somewhat important if you want to do things like
voxel loop or averaging thousands of files with something less than a
PetaByte of RAM.

What you have done above is pretty much just dumbed down the MINC file
to Nifti-1/Analyze level by removing slice scaling. And therein lies
the folly of expecting this to work all the time as the assumption is
that both file formats can hold the same amount/quality of information
when usually they dont.

> And what is worse, on my box (with a
> fresh install of mincbundle of this morning), register doesn't even
> want to load 'test,mnc'....

Lost me there, works for me I think the range thing is biting you.
-scanrange or a bit of post-processing with mincmath -clamp should do
the trick.  The problem again being that Nifti does not support
something like valid-range that I know of. The old ANALYZE/SPM style
calmax and calmin are not used in Nifti

> (b) we are already providing converters that don't
> live up to the forward/backward conversion expectation.

Correct. They do not live up to incorrect expectations. :)

> Yes, I know the answer is "if it is so easy, why don't you do it".
> Touche' on that one :)

Hey! I just wrote you a mnc2dcm.


a

From burt.crepeault at crulrg.ulaval.ca  Fri Oct  3 09:46:48 2008
From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=)
Date: Fri, 3 Oct 2008 09:46:48 -0400
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <d747ed50810022221k22f09221xd6ebc048d2cd5f53@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
	<115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
	<e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>
	<d747ed50810022211q66136b29ka9aa4911f89ffa18@mail.gmail.com>
	<d747ed50810022221k22f09221xd6ebc048d2cd5f53@mail.gmail.com>
Message-ID: <ac2a7d1f0810030646v47dc9165j9ee566613931fbe4@mail.gmail.com>

Here's how I see this particular issue.

I don't think that anybody will ever ask for a magical mnc2dcm that figures
out all the proper DICOM headers to include in the files, other than the
spatial data. However, a much more realistic and useful feature for
successful dcm2mnc and mnc2dcm conversions could look like this:

dcm2mnc (<dicom>) => <minc> + <headers>

(the original DICOM headers are extracted and saved in a standard file
format -- a carefully crafted XML schema comes to mind)

mnc2dcm (<minc> [, <headers>]) => <dicom>

(the mnc2dcm function requires an external header file to reproduce the
original dicoms, otherwise the header info is simply lost)

That way, whatever transformations happen to the MINC file are independent
to those happening at the header level. In other words, it entirely up to
your application logic to track, transform and reinject the headers at
reconversion time.

Burt.

From jharlap at bic.mni.mcgill.ca  Fri Oct  3 09:55:40 2008
From: jharlap at bic.mni.mcgill.ca (Jonathan Harlap)
Date: Fri, 3 Oct 2008 09:55:40 -0400
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <ac2a7d1f0810030646v47dc9165j9ee566613931fbe4@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
	<115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
	<e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>
	<d747ed50810022211q66136b29ka9aa4911f89ffa18@mail.gmail.com>
	<d747ed50810022221k22f09221xd6ebc048d2cd5f53@mail.gmail.com>
	<ac2a7d1f0810030646v47dc9165j9ee566613931fbe4@mail.gmail.com>
Message-ID: <115a643d0810030655v63c36ddbj2aab81777d3aa5e5@mail.gmail.com>

Your view seems to coincide with Alex's, where you assume that what
you're trying to do is take a minc produced by dcm2mnc and then run it
straight back through mnc2dcm, whereas almost every user I've
interacted with who wanted mnc2dcm actually wanted to convert some
processed result so they could load those results into a non-minc
software package (which may be a PACS system).  In that case, using
the original DICOM headers from something further up the processing
chain doesn't make sense.

As an aside, if you want a dcm2X (dicom) => image + headers, your X =
analyze.  One of the selling points of minc is that you keep all this
info together in one file that's easy to manage, and that its header
structure is very freely extensible to store arbitrary (user-defined)
attributes.

J


On Fri, Oct 3, 2008 at 9:46 AM, Burt Cr?peault
<burt.crepeault at crulrg.ulaval.ca> wrote:
> Here's how I see this particular issue.
>
> I don't think that anybody will ever ask for a magical mnc2dcm that figures
> out all the proper DICOM headers to include in the files, other than the
> spatial data. However, a much more realistic and useful feature for
> successful dcm2mnc and mnc2dcm conversions could look like this:
>
> dcm2mnc (<dicom>) => <minc> + <headers>
>
> (the original DICOM headers are extracted and saved in a standard file
> format -- a carefully crafted XML schema comes to mind)
>
> mnc2dcm (<minc> [, <headers>]) => <dicom>
>
> (the mnc2dcm function requires an external header file to reproduce the
> original dicoms, otherwise the header info is simply lost)
>
> That way, whatever transformations happen to the MINC file are independent
> to those happening at the header level. In other words, it entirely up to
> your application logic to track, transform and reinject the headers at
> reconversion time.
>
> Burt.
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


From jharlap at bic.mni.mcgill.ca  Fri Oct  3 10:02:37 2008
From: jharlap at bic.mni.mcgill.ca (Jonathan Harlap)
Date: Fri, 3 Oct 2008 10:02:37 -0400
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <e758a6650810030633r7eae3c47tde217a8f119d4264@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
	<115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
	<e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>
	<115a643d0810030612g665d8f60i65755177dfa296d4@mail.gmail.com>
	<e758a6650810030633r7eae3c47tde217a8f119d4264@mail.gmail.com>
Message-ID: <115a643d0810030702w473bf783w1ff0bf0461b2628e@mail.gmail.com>

On Fri, Oct 3, 2008 at 9:33 AM, Alex Zijdenbos <alex at bic.mni.mcgill.ca> wrote:
>>> is simply not realistic. However, I suspect that a mnc2dcm that would attain
>>>
>>>  <minc> == dcm2mnc( mnc2dcm( <minc> ) )
>>>
>>> is much more feasible (by the way, I don't believe that you can do the
>>
>> Not as feasible as you seem to think, IMO:
>
> Should I mention that you were the one that suggested this to me some
> time ago? :)

That I described what a user group wanted doesn't mean that I agreed
that their desire was reasonable or feasible...  And if you are
instead referring to my counterarguments when discussing a particular
US-gov't-employed Italian's insanity, then you'll recall that what I
said might be feasible would be:

minc = dcm2mnc (dicom1)
dicom2 = mnc2dcm (minc)
minc2 = dcm2mnc (dicom2)

dicom2 = mnc2dcm ( dcm2mnc( dicom2 ) )
and
minc2 = dcm2mnc ( mnc2dcm ( minc2 ) )

The distinction is pretty important - it states that the first
conversion you do is lossy, but that afterwards you could back and
forth happily, given properly written converters.

J

From acveilleux at mrs.mni.mcgill.ca  Fri Oct  3 10:23:35 2008
From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX)
Date: Fri, 3 Oct 2008 10:23:35 -0400
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <115a643d0810030702w473bf783w1ff0bf0461b2628e@mail.gmail.com>;
	from jharlap@bic.mni.mcgill.ca on Fri, Oct 03, 2008 at 10:02:37AM
	-0400
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
	<115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
	<e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>
	<115a643d0810030612g665d8f60i65755177dfa296d4@mail.gmail.com>
	<e758a6650810030633r7eae3c47tde217a8f119d4264@mail.gmail.com>
	<115a643d0810030702w473bf783w1ff0bf0461b2628e@mail.gmail.com>
Message-ID: <20081003102335.A4837@mrs.mni.mcgill.ca>

On Fri, Oct 03, 2008 at 10:02:37AM -0400, Jonathan Harlap wrote:
> 
> That I described what a user group wanted doesn't mean that I agreed
> that their desire was reasonable or feasible...  And if you are
> instead referring to my counterarguments when discussing a particular
> US-gov't-employed Italian's insanity, then you'll recall that what I
> said might be feasible would be:
> 
> minc = dcm2mnc (dicom1)
> dicom2 = mnc2dcm (minc)
> minc2 = dcm2mnc (dicom2)
> 
> dicom2 = mnc2dcm ( dcm2mnc( dicom2 ) )
> and
> minc2 = dcm2mnc ( mnc2dcm ( minc2 ) )
> 
> The distinction is pretty important - it states that the first
> conversion you do is lossy, but that afterwards you could back and
> forth happily, given properly written converters.

This is not necessarily so. MINC can be used to encode all group/element pairs
in the original DICOM files (some converters already do this) and given that
information, it is possible to essentially spit out dicom1.

Now, given any amount of processing whatsoever, the value of the original
DICOM headers decreases rapidly, but using them as baseline and then using
the more standard MINC properties (that probably refelect the processing)
to override some of the DICOM header, you could end up with an acceptable
DICOM image for processed data... To a point.

Couple of extra thoughts:

1) After some processing has been done to an image, there's no valid reason
to keep any odd-numbered DICOM groups. We can't tell what they mean so we can't
ascertain in any way their validity.

2) Most minc (1.x) tools don't seem to preserve headers consistently. No idea how
this applies to MINC 2.x. I haven't looked at this much in the last 3 years however
so this point isn't so valid, but if someone actually makes that mnc2dcm, that person
will have to think about that.

3) Most DICOM code I've seen in converters was awfully crude and fails on at least
some input files (we've converted DICOMS from hundreds of sites and many many thousand
scans). Usual culprit being either PixelData encoding or variable sized DICOM elements
(i.e.: anything with a length attribute of -1).

Rather funny to see the amount of activity this mnc2dcm thread generates seeing as
no-one actually wants to do it (for good reason).

Alex

From burt.crepeault at crulrg.ulaval.ca  Fri Oct  3 10:42:05 2008
From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=)
Date: Fri, 3 Oct 2008 10:42:05 -0400
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <115a643d0810030655v63c36ddbj2aab81777d3aa5e5@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
	<115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
	<e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>
	<d747ed50810022211q66136b29ka9aa4911f89ffa18@mail.gmail.com>
	<d747ed50810022221k22f09221xd6ebc048d2cd5f53@mail.gmail.com>
	<ac2a7d1f0810030646v47dc9165j9ee566613931fbe4@mail.gmail.com>
	<115a643d0810030655v63c36ddbj2aab81777d3aa5e5@mail.gmail.com>
Message-ID: <ac2a7d1f0810030742j20ee41a7w456f70003487ae6b@mail.gmail.com>

On Fri, Oct 3, 2008 at 9:55 AM, Jonathan Harlap
<jharlap at bic.mni.mcgill.ca>wrote:

> Your view seems to coincide with Alex's, where you assume that what
> you're trying to do is take a minc produced by dcm2mnc and then run it
> straight back through mnc2dcm,


Of course! In a research environment, the requirements for the back
conversion are perhaps a little less important, but if you are ever going to
write a minc-based application that re-inserts images in a PACS, you cannot
afford to lose any information. No matter where the header information comes
from, it's gotta find its way back into the DICOM series.


> whereas almost every user I've
> interacted with who wanted mnc2dcm actually wanted to convert some
> processed result so they could load those results into a non-minc
> software package (which may be a PACS system).  In that case, using
> the original DICOM headers from something further up the processing
> chain doesn't make sense.


Some of the DICOM headers are not going to change (patient, study headers),
others will change according to image transformations (such as you describe
above), the rest may be calculated by your application logic (I'm thinking
about UIDs for instance). In the end, everything must converge back into
DICOM.

>
>
> As an aside, if you want a dcm2X (dicom) => image + headers, your X =
> analyze.  One of the selling points of minc is that you keep all this
> info together in one file that's easy to manage, and that its header
> structure is very freely extensible to store arbitrary (user-defined)
> attributes.


I can't argue with that. The important point is, if a mnc2dcm utility is
ever to be written, it has to allow re-insertion of some external header
content. I agree this would break the symmetry of the dcm2mnc/mnc2dcm
diptych but in my view, it's a must-have feature.

As an interesting side-effect to this model, it would allow the calculation
of header content to be outside the mnc2dcm tool. The difficult ones could
be omitted from mnc2dcm altogether while still be possible for those wanting
to dig in to the problem. Eventually, some of those would find their way
into future iterations of mnc2dcm.

my 2?

Burt.

From alex at bic.mni.mcgill.ca  Fri Oct  3 11:21:54 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Fri, 3 Oct 2008 11:21:54 -0400
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <115a643d0810030702w473bf783w1ff0bf0461b2628e@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
	<115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
	<e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>
	<115a643d0810030612g665d8f60i65755177dfa296d4@mail.gmail.com>
	<e758a6650810030633r7eae3c47tde217a8f119d4264@mail.gmail.com>
	<115a643d0810030702w473bf783w1ff0bf0461b2628e@mail.gmail.com>
Message-ID: <e758a6650810030821r3156d4b4h44ad976ceb94c130@mail.gmail.com>

> it states that the first
> conversion you do is lossy, but that afterwards you could back and
> forth happily, given properly written converters.

Well this is exactly what I meant - I had implicitly assumed you would
have done a dicom to minc conversion to get the first minc. Indeed
that does not cover what a MINC could technically store in a header;
but mind you processed minc typically has even less information in the
headers than 'native' minc, so I think it just gets easier.

My point is simple: (a) there is a undeniable (and growing) need/want
for a minc to dicom converter; and (b) by accepting that the
conversion may/can not be lossless and/or invertible (as different
file formats store different things in different ways), we probably
*can* come up with a converter that works for most people in most
situations and does retain most 'standard' header fields.

This is exactly the case at the moment for the nii<->mnc converters
which by and large seem to work for people. I don't think nifti-1 is
fundamentally different from dicom in this respect - in fact, one
could argue that nifti-1 is actually 'dumber' than dicom.

I guess I will use the mnc2dcm Andrew provided in this thread (thanks
Andrew!) until somebody writes a better one :)

-- Alex (Z)

From laurence at bic.mni.mcgill.ca  Fri Oct  3 13:48:27 2008
From: laurence at bic.mni.mcgill.ca (Laurence MERCIER)
Date: Fri, 3 Oct 2008 13:48:27 -0400
Subject: [MINC-users] MINC to DICOM
In-Reply-To: <e758a6650810030821r3156d4b4h44ad976ceb94c130@mail.gmail.com>
References: <1422613522.14871222956046185.JavaMail.root@zimbra-store01.hst.aau.dk>
	<87166116.14891222956186230.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810020710m29b24527v352e3f94bd64ca10@mail.gmail.com>
	<e758a6650810021950o1996dd11k65888db5fdf4acfc@mail.gmail.com>
	<115a643d0810022010t6f4319ccs4f55dd6660d5bc67@mail.gmail.com>
	<e758a6650810022121s50975e4cg25d72141772080cf@mail.gmail.com>
	<115a643d0810030612g665d8f60i65755177dfa296d4@mail.gmail.com>
	<e758a6650810030633r7eae3c47tde217a8f119d4264@mail.gmail.com>
	<115a643d0810030702w473bf783w1ff0bf0461b2628e@mail.gmail.com>
	<e758a6650810030821r3156d4b4h44ad976ceb94c130@mail.gmail.com>
Message-ID: <Pine.SGI.4.58.0810031342540.230603@yorick.bic.mni.mcgill.ca>

Hello,

I follow your discussions with great interest as I would certainly be one
of the many users of a mnc2dcm script (well when I get back from my
mat leave!). And so as many have already said, I do think it would be very
useful even if it is not a perfect converter! ;-)

Laurence


__________________________________
Laurence Mercier, PhD student

McConnell Brain Imaging Center
Montreal Neurological Institute
3801 University St, room: WB-320
Montreal (QC), H3A 2B4
CANADA

tel: +1 514.398.1573
fax: +1 514.398.2975
__________________________________



On Fri, 3 Oct 2008, Alex Zijdenbos wrote:

> > it states that the first
> > conversion you do is lossy, but that afterwards you could back and
> > forth happily, given properly written converters.
>
> Well this is exactly what I meant - I had implicitly assumed you would
> have done a dicom to minc conversion to get the first minc. Indeed
> that does not cover what a MINC could technically store in a header;
> but mind you processed minc typically has even less information in the
> headers than 'native' minc, so I think it just gets easier.
>
> My point is simple: (a) there is a undeniable (and growing) need/want
> for a minc to dicom converter; and (b) by accepting that the
> conversion may/can not be lossless and/or invertible (as different
> file formats store different things in different ways), we probably
> *can* come up with a converter that works for most people in most
> situations and does retain most 'standard' header fields.
>
> This is exactly the case at the moment for the nii<->mnc converters
> which by and large seem to work for people. I don't think nifti-1 is
> fundamentally different from dicom in this respect - in fact, one
> could argue that nifti-1 is actually 'dumber' than dicom.
>
> I guess I will use the mnc2dcm Andrew provided in this thread (thanks
> Andrew!) until somebody writes a better one :)
>
> -- Alex (Z)
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From a.janke at gmail.com  Mon Oct  6 08:02:24 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 6 Oct 2008 23:02:24 +1100
Subject: [MINC-users] problem with nu_estimate_np_and_em
In-Reply-To: <d747ed50809301727h10b0d357o2770b7b3b48d3ded@mail.gmail.com>
References: <6ec808c10809251401o65ef869bsf84e14c4fcccb8d@mail.gmail.com>
	<200809262021.m8QKLDRk600346@yorick.bic.mni.mcgill.ca>
	<6ec808c10809301241j1a5cd156qb1a4d5d157de933@mail.gmail.com>
	<d747ed50809301727h10b0d357o2770b7b3b48d3ded@mail.gmail.com>
Message-ID: <d747ed50810060502t6d64e527ha45af1afc7d533ff@mail.gmail.com>

> On Wed, Oct 1, 2008 at 5:41 AM, Tejaswini Ganapathi
> <tejasvinee at gmail.com> wrote:
>> All of my installed files (exe files) are in /usr/bin. Infact nu_correct,
>> nu_estimate and nu_evaluate work fine. I'm having this problem only with
>> nu_estimate_np_and_em
>>
>> Ive tried the following on the shell command line,
>> $ nu_estimate_np_and_em -normalize_field -save_fields -mask
>> mask.mnc breast.mnc fields_time.mnc
>>
>> nu_estimate_np_and_em: couldn't find program "class_statistics"
>> nu_estimate_np_and_em: couldn't find program "estimate"
>
> I reckon you have hit on a bug.  And amusingly I cannot find these two
> executables that you are talking about on my system (or yorick!)
> either. I suspect that you are using a little used part of the N3
> package that has escaped inspection/execution for a long time.

An update on this one, I have been in contact with the original Author
of N3 (John Sled) and he tells me that these errors are due to the
script in question trying to use another version of intensity
correction that is based upon the EM algorithm. nu_estimate_np_and_em
was written to compare the two methods.  He tells me that it is likely
not worth resurrecting the EM method (although I did find the code
hidden deep in an archive -- Thanks Mike and Sylvain). So the "fix"
for now is to not use the -mean or -tag options and be sure to use a
-sharpen x y option.

The default option for sharpen is:

   -sharpen 100 0.01

Mind you this he tells me is why nu_correct and nu_estimate were
written as they are simply wrappers for the bits of code in question
that make sure that only the NP method (or N3) is used.

There is now a "fix" in CVS for this that should make the next release
that will warn users of this.


-- 
Andrew Janke - andrew.janke at anu.edu.au
Department of Geriatric Medicine, ANU
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From mishkind at gmail.com  Mon Oct  6 19:15:31 2008
From: mishkind at gmail.com (Mishkin Derakhshan)
Date: Mon, 6 Oct 2008 19:15:31 -0400
Subject: [MINC-users] Display - Scan object to volume
Message-ID: <9c5abb60810061615g3b612090j3f71330987c37904@mail.gmail.com>

Hi,

I have a question regarding this:

Display input.mnc.gz object.obj
(R - Objects)
(W - Scan object to volume)

Let's say my object is a simple sphere, but the co-ordinates have sub-voxel
accuracy. If i do the above, then the resulting label that gets loaded onto
the image will indeed be a sphere, but, for every vertex in my object, the
entire corresponding voxel is colored on the volume. Is there a way to just
paint the points/coordinates of the object onto the volume, or connect the
points via a thin line, instead of just lighting up the entire voxel?

The best solution I have thus far is to resample my input volume to 0.1 mm
isotropic voxels for example, and then the resulting label is much thinner,
but this creates a huge file and is a waste of space and time.

thanks,
mishkin

From claude at bic.mni.mcgill.ca  Mon Oct  6 22:14:57 2008
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Mon, 6 Oct 2008 22:14:57 -0400 (EDT)
Subject: [MINC-users] Display - Scan object to volume
Message-ID: <200810070214.m972Ev89519624@yorick.bic.mni.mcgill.ca>

Hi Mishkin,

> Let's say my object is a simple sphere, but the co-ordinates have sub-voxel
> accuracy. If i do the above, then the resulting label that gets loaded onto
> the image will indeed be a sphere, but, for every vertex in my object, the
> entire corresponding voxel is colored on the volume. Is there a way to just
> paint the points/coordinates of the object onto the volume, or connect the
> points via a thin line, instead of just lighting up the entire voxel?

I'm not sure if this helps, but you can try polygons_to_lines
to get only lines. Nonetheless, a vertex will still be the size
of a voxel (1mm) and the lines will be 1mm too. It would have 
been nice if Display had the ability to draw at the screen's
resolution (in pixels). Today's graphics cards would support
it. :-)

Claude

From se at hst.aau.dk  Tue Oct  7 06:06:26 2008
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Tue, 7 Oct 2008 12:06:26 +0200 (CEST)
Subject: [MINC-users] problem with nu_estimate_np_and_em
In-Reply-To: <d747ed50810060502t6d64e527ha45af1afc7d533ff@mail.gmail.com>
Message-ID: <2046436230.26871223373986359.JavaMail.root@zimbra-store01.hst.aau.dk>

Now that we are on the subject of nu_correct. I just compiled the latest of everything from packages/tgz on ubuntu 64bit --with-minc2, and nu_correct rewarded me with the following.

> nu_correct native/t1_native.mnc test.mnc
Bad buffer size 0 in set_loop_buffer_size
Bad buffer size 0 in set_loop_buffer_size
Bad buffer size 0 in set_loop_buffer_size
Transforming slices:..............................................Done
Bad buffer size 0 in set_loop_buffer_size
Bad buffer size 0 in set_loop_buffer_size
Bad buffer size 0 in set_loop_buffer_size
Bad buffer size 0 in set_loop_buffer_size
Must have one or bins per histogram
sharpen_volume: crashed while running volume_hist (termination status=256)
nu_estimate_np_and_em: crashed while running sharpen_volume (termination status=256)
nu_correct: crashed while running nu_estimate_np_and_em (termination status=256)

Am I missing something?

Regards,
Simon
----- "Andrew Janke" <a.janke at gmail.com> wrote:

> > On Wed, Oct 1, 2008 at 5:41 AM, Tejaswini Ganapathi
> > <tejasvinee at gmail.com> wrote:
> >> All of my installed files (exe files) are in /usr/bin. Infact
> nu_correct,
> >> nu_estimate and nu_evaluate work fine. I'm having this problem only
> with
> >> nu_estimate_np_and_em
> >>
> >> Ive tried the following on the shell command line,
> >> $ nu_estimate_np_and_em -normalize_field -save_fields -mask
> >> mask.mnc breast.mnc fields_time.mnc
> >>
> >> nu_estimate_np_and_em: couldn't find program "class_statistics"
> >> nu_estimate_np_and_em: couldn't find program "estimate"
> >
> > I reckon you have hit on a bug.  And amusingly I cannot find these
> two
> > executables that you are talking about on my system (or yorick!)
> > either. I suspect that you are using a little used part of the N3
> > package that has escaped inspection/execution for a long time.
> 
> An update on this one, I have been in contact with the original
> Author
> of N3 (John Sled) and he tells me that these errors are due to the
> script in question trying to use another version of intensity
> correction that is based upon the EM algorithm. nu_estimate_np_and_em
> was written to compare the two methods.  He tells me that it is
> likely
> not worth resurrecting the EM method (although I did find the code
> hidden deep in an archive -- Thanks Mike and Sylvain). So the "fix"
> for now is to not use the -mean or -tag options and be sure to use a
> -sharpen x y option.
> 
> The default option for sharpen is:
> 
>    -sharpen 100 0.01
> 
> Mind you this he tells me is why nu_correct and nu_estimate were
> written as they are simply wrappers for the bits of code in question
> that make sure that only the NP method (or N3) is used.
> 
> There is now a "fix" in CVS for this that should make the next
> release
> that will warn users of this.
> 
> 
> -- 
> Andrew Janke - andrew.janke at anu.edu.au
> Department of Geriatric Medicine, ANU
> (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia    +61 (402) 700 883
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From jasonc at bic.mni.mcgill.ca  Tue Oct  7 11:26:48 2008
From: jasonc at bic.mni.mcgill.ca (Jason Cakiroglu)
Date: Tue, 7 Oct 2008 11:26:48 -0400
Subject: [MINC-users] converting amira to minc
Message-ID: <fa3646d0810070826r2705125dw7ba15d628d65024a@mail.gmail.com>

Hello All,

Is there a way to convert from Amira files (.am) to minc (.mnc)?

Thanks,

Jason

From a.janke at gmail.com  Tue Oct  7 11:34:26 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 8 Oct 2008 02:34:26 +1100
Subject: [MINC-users] converting amira to minc
In-Reply-To: <fa3646d0810070826r2705125dw7ba15d628d65024a@mail.gmail.com>
References: <fa3646d0810070826r2705125dw7ba15d628d65024a@mail.gmail.com>
Message-ID: <d747ed50810070834p65185811j76b3192b907d32c4@mail.gmail.com>

Hi Jason,


On Wed, Oct 8, 2008 at 2:26 AM, Jason Cakiroglu
<jasonc at bic.mni.mcgill.ca> wrote:

> Is there a way to convert from Amira files (.am) to minc (.mnc)?

I am not aware of a converter (but that does not preclude such a
things existence!) I note from:

   http://www.amiravis.com/documentation/50/amira/usersguide/HxIndexFileFormat.html

That you can write out NifTI images so that may be an option. With a
quick bit of searching I couldn't find any docco on the .am files
format itself though so writing a converter may prove "fun".


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

From mishkind at gmail.com  Tue Oct  7 18:16:44 2008
From: mishkind at gmail.com (Mishkin Derakhshan)
Date: Tue, 7 Oct 2008 18:16:44 -0400
Subject: [MINC-users] colour_object vs. brain-view
Message-ID: <9c5abb60810071516k4c5da2f1i8b47e3bedeffdd08@mail.gmail.com>

Hi,
Usually, if I do:

brain-view object.obj stats.txt

or if i do

colour_object object.obj stats.txt coloured_object.obj spectral 0 5
brain-view coloured_object.obj

then, visually I get the same results.

I preface this with usually cause I am getting cases where they do not.

Screenshot here:
http://www.bic.mni.mcgill.ca/users/mishkin/good_bad.png

Data here:
http://www.bic.mni.mcgill.ca/users/mishkin/object.obj.gz
http://www.bic.mni.mcgill.ca/users/mishkin/stats.txt
http://www.bic.mni.mcgill.ca/users/mishkin/coloured_object.obj.gz

Is this a bug or what?

thanks,
mishkin

From mok at bic.mni.mcgill.ca  Tue Oct  7 22:53:42 2008
From: mok at bic.mni.mcgill.ca (Kelvin Mok)
Date: Tue, 07 Oct 2008 22:53:42 -0400
Subject: [MINC-users] colour_object vs. brain-view
In-Reply-To: <9c5abb60810071516k4c5da2f1i8b47e3bedeffdd08@mail.gmail.com>
References: <9c5abb60810071516k4c5da2f1i8b47e3bedeffdd08@mail.gmail.com>
Message-ID: <48EC20B6.9090004@bic.mni.mcgill.ca>

Isn't the latter (in the good vs bad) just the addition of the wireframe 
mesh (vertices)?

Or are you referring to the blackout stuff around the lateral 
ventricles? In that case, there are supposed to be no vertices in this 
area (I believe), so it is likely that brain view performs that 
interpolation in this area, while colour_object does not do such.

Kelvin

Mishkin Derakhshan wrote:
> Hi,
> Usually, if I do:
>
> brain-view object.obj stats.txt
>
> or if i do
>
> colour_object object.obj stats.txt coloured_object.obj spectral 0 5
> brain-view coloured_object.obj
>
> then, visually I get the same results.
>
> I preface this with usually cause I am getting cases where they do not.
>
> Screenshot here:
> http://www.bic.mni.mcgill.ca/users/mishkin/good_bad.png
>
> Data here:
> http://www.bic.mni.mcgill.ca/users/mishkin/object.obj.gz
> http://www.bic.mni.mcgill.ca/users/mishkin/stats.txt
> http://www.bic.mni.mcgill.ca/users/mishkin/coloured_object.obj.gz
>
> Is this a bug or what?
>
> thanks,
> mishkin
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>   

From a.janke at gmail.com  Wed Oct  8 09:21:52 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 9 Oct 2008 00:21:52 +1100
Subject: [MINC-users] problem with nu_estimate_np_and_em
In-Reply-To: <2046436230.26871223373986359.JavaMail.root@zimbra-store01.hst.aau.dk>
References: <d747ed50810060502t6d64e527ha45af1afc7d533ff@mail.gmail.com>
	<2046436230.26871223373986359.JavaMail.root@zimbra-store01.hst.aau.dk>
Message-ID: <d747ed50810080621j50530c8o2893709d7a9e3434@mail.gmail.com>

Hi Simon,

No idea if you are missing anything but I just tried this same game
(although in truth I built packages and installed them) and it works
for me.

Is there something amiss with the histogram of t1_native.mnc ?  The
error output would seem to indicate a dud histogram.

a

On Tue, Oct 7, 2008 at 9:06 PM, Simon Fristed Eskildsen <se at hst.aau.dk> wrote:
> Now that we are on the subject of nu_correct. I just compiled the latest of everything from packages/tgz on ubuntu 64bit --with-minc2, and nu_correct rewarded me with the following.
>
>> nu_correct native/t1_native.mnc test.mnc
> Bad buffer size 0 in set_loop_buffer_size
> Bad buffer size 0 in set_loop_buffer_size
> Bad buffer size 0 in set_loop_buffer_size
> Transforming slices:..............................................Done
> Bad buffer size 0 in set_loop_buffer_size
> Bad buffer size 0 in set_loop_buffer_size
> Bad buffer size 0 in set_loop_buffer_size
> Bad buffer size 0 in set_loop_buffer_size
> Must have one or bins per histogram
> sharpen_volume: crashed while running volume_hist (termination status=256)
> nu_estimate_np_and_em: crashed while running sharpen_volume (termination status=256)
> nu_correct: crashed while running nu_estimate_np_and_em (termination status=256)
>
> Am I missing something?
>
> Regards,
> Simon
> ----- "Andrew Janke" <a.janke at gmail.com> wrote:
>
>> > On Wed, Oct 1, 2008 at 5:41 AM, Tejaswini Ganapathi
>> > <tejasvinee at gmail.com> wrote:
>> >> All of my installed files (exe files) are in /usr/bin. Infact
>> nu_correct,
>> >> nu_estimate and nu_evaluate work fine. I'm having this problem only
>> with
>> >> nu_estimate_np_and_em
>> >>
>> >> Ive tried the following on the shell command line,
>> >> $ nu_estimate_np_and_em -normalize_field -save_fields -mask
>> >> mask.mnc breast.mnc fields_time.mnc
>> >>
>> >> nu_estimate_np_and_em: couldn't find program "class_statistics"
>> >> nu_estimate_np_and_em: couldn't find program "estimate"
>> >
>> > I reckon you have hit on a bug.  And amusingly I cannot find these
>> two
>> > executables that you are talking about on my system (or yorick!)
>> > either. I suspect that you are using a little used part of the N3
>> > package that has escaped inspection/execution for a long time.
>>
>> An update on this one, I have been in contact with the original
>> Author
>> of N3 (John Sled) and he tells me that these errors are due to the
>> script in question trying to use another version of intensity
>> correction that is based upon the EM algorithm. nu_estimate_np_and_em
>> was written to compare the two methods.  He tells me that it is
>> likely
>> not worth resurrecting the EM method (although I did find the code
>> hidden deep in an archive -- Thanks Mike and Sylvain). So the "fix"
>> for now is to not use the -mean or -tag options and be sure to use a
>> -sharpen x y option.
>>
>> The default option for sharpen is:
>>
>>    -sharpen 100 0.01
>>
>> Mind you this he tells me is why nu_correct and nu_estimate were
>> written as they are simply wrappers for the bits of code in question
>> that make sure that only the NP method (or N3) is used.
>>
>> There is now a "fix" in CVS for this that should make the next
>> release
>> that will warn users of this.
>>
>>
>> --
>> Andrew Janke - andrew.janke at anu.edu.au
>> Department of Geriatric Medicine, ANU
>> (a.janke at gmail.com || http://a.janke.googlepages.com/)
>> Canberra->Australia    +61 (402) 700 883
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
Andrew Janke - andrew.janke at anu.edu.au
Department of Geriatric Medicine, ANU
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From jason at bic.mni.mcgill.ca  Wed Oct  8 16:55:11 2008
From: jason at bic.mni.mcgill.ca (Jason Lerch)
Date: Wed, 8 Oct 2008 16:55:11 -0400
Subject: [MINC-users] converting amira to minc
In-Reply-To: <d747ed50810070834p65185811j76b3192b907d32c4@mail.gmail.com>
References: <fa3646d0810070826r2705125dw7ba15d628d65024a@mail.gmail.com>
Message-ID: <48ED1E2F.5090707@bic.mni.mcgill.ca>

Hi all,

we've got a  MINC reader and writer for Amira which we're happy to give 
to whoever wants it - just send me an email.

Cheers,

Jason

Andrew Janke wrote:
> Hi Jason,
>
>
> On Wed, Oct 8, 2008 at 2:26 AM, Jason Cakiroglu
> <jasonc at bic.mni.mcgill.ca> wrote:
>
>   
>> Is there a way to convert from Amira files (.am) to minc (.mnc)?
>>     
>
> I am not aware of a converter (but that does not preclude such a
> things existence!) I note from:
>
>    http://www.amiravis.com/documentation/50/amira/usersguide/HxIndexFileFormat.html
>
> That you can write out NifTI images so that may be an option. With a
> quick bit of searching I couldn't find any docco on the .am files
> format itself though so writing a converter may prove "fun".
>
>
>   


From mishkind at gmail.com  Wed Oct  8 17:26:51 2008
From: mishkind at gmail.com (Mishkin Derakhshan)
Date: Wed, 8 Oct 2008 17:26:51 -0400
Subject: [MINC-users] colour_object vs. brain-view
In-Reply-To: <48EC20B6.9090004@bic.mni.mcgill.ca>
References: <9c5abb60810071516k4c5da2f1i8b47e3bedeffdd08@mail.gmail.com>
	<48EC20B6.9090004@bic.mni.mcgill.ca>
Message-ID: <9c5abb60810081426x23f306d9m2c30e60f3bc47778@mail.gmail.com>

Hi,

So with some help from Claude we figured out that the culprit was the
stats.txt file.
It seems the file has a trailing space at the end of every line,
something which it seems brain-view has troubles reading.
If you just eliminate the space at the end of every line then it works
fine. Perhaps this can be incorporated into the next version of
brain-view.

mishkin


On Tue, Oct 7, 2008 at 10:53 PM, Kelvin Mok <mok at bic.mni.mcgill.ca> wrote:
> Isn't the latter (in the good vs bad) just the addition of the wireframe
> mesh (vertices)?
>
> Or are you referring to the blackout stuff around the lateral
> ventricles? In that case, there are supposed to be no vertices in this
> area (I believe), so it is likely that brain view performs that
> interpolation in this area, while colour_object does not do such.
>
> Kelvin
>
> Mishkin Derakhshan wrote:
>> Hi,
>> Usually, if I do:
>>
>> brain-view object.obj stats.txt
>>
>> or if i do
>>
>> colour_object object.obj stats.txt coloured_object.obj spectral 0 5
>> brain-view coloured_object.obj
>>
>> then, visually I get the same results.
>>
>> I preface this with usually cause I am getting cases where they do not.
>>
>> Screenshot here:
>> http://www.bic.mni.mcgill.ca/users/mishkin/good_bad.png
>>
>> Data here:
>> http://www.bic.mni.mcgill.ca/users/mishkin/object.obj.gz
>> http://www.bic.mni.mcgill.ca/users/mishkin/stats.txt
>> http://www.bic.mni.mcgill.ca/users/mishkin/coloured_object.obj.gz
>>
>> Is this a bug or what?
>>
>> thanks,
>> mishkin
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From Michel.Audette at medizin.uni-leipzig.de  Wed Oct 15 11:39:52 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Wed, 15 Oct 2008 17:39:52 +0200
Subject: [MINC-users] mincconcat error
References: <d747ed50810060502t6d64e527ha45af1afc7d533ff@mail.gmail.com><2046436230.26871223373986359.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810080621j50530c8o2893709d7a9e3434@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E69020205D2@MRZS152229.medizin.uni-leipzig.de>

Hi all, 

I'm trying to use mincconcat with a large number of tissue slice, high-res minc files, and getting the following error. 

mincconcat -clobber -filelist files.tmp -sequential korean_full_gray.mnc
Processing:.mincconcat: ncx.c:1716: ncx_put_size_t: Assertion `*ulp <= 4294967295U' failed.
Aborted

The directory represented by files.tmp is as follows: 

-rwxr-xr-x  1 maudette users 3474264 2007-10-26 18:48 full_gray/0000.mnc
-rwxr-xr-x  1 maudette users 3474264 2007-10-26 18:48 full_gray/0001.mnc
...
-rwxr-xr-x  1 maudette users 3474264 2007-10-26 20:38 full_gray/1327.mnc
-rwxr-xr-x  1 maudette users 3474264 2007-10-26 20:38 full_gray/1328.mnc

Can anyone suggest a course of action? 

Best wishes, 

Michel

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


From claude at bic.mni.mcgill.ca  Wed Oct 15 11:53:31 2008
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Wed, 15 Oct 2008 11:53:31 -0400 (EDT)
Subject: [MINC-users] mincconcat error
References: <d747ed50810060502t6d64e527ha45af1afc7d533ff@mail.gmail.com><2046436230.26871223373986359.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810080621j50530c8o2893709d7a9e3434@mail.gmail.com>
Message-ID: <200810151553.m9FFrVkJ1096352@yorick.bic.mni.mcgill.ca>

Hi Michel,

I'm using mincconcat for 7400 slices and it works. In minc2, of course.
Here is my command:

mincconcat -clobber -filetype -filelist files.tmp -concat_dimension yspace -sequential full.mnc

You may need to change the concat_dimension (may not be yspace for you). 
You should also disable internal file compression if concatenation is too
slow (setenv MINC_COMPRESS 0).

Try this and let me know. It could also be some bug.

Claude


> I'm trying to use mincconcat with a large number of tissue slice, =
> high-res minc files, and getting the following error.=20
> 
> mincconcat -clobber -filelist files.tmp -sequential korean_full_gray.mnc
> Processing:.mincconcat: ncx.c:1716: ncx_put_size_t: Assertion `*ulp <=3D =
> 4294967295U' failed.
> Aborted
> 
> The directory represented by files.tmp is as follows:=20
> 
> -rwxr-xr-x  1 maudette users 3474264 2007-10-26 18:48 full_gray/0000.mnc
> -rwxr-xr-x  1 maudette users 3474264 2007-10-26 18:48 full_gray/0001.mnc
> ...
> -rwxr-xr-x  1 maudette users 3474264 2007-10-26 20:38 full_gray/1327.mnc
> -rwxr-xr-x  1 maudette users 3474264 2007-10-26 20:38 full_gray/1328.mnc
> 
> Can anyone suggest a course of action?=20
> 
> Best wishes,=20
> 
> Michel

From Michel.Audette at medizin.uni-leipzig.de  Thu Oct 16 04:46:42 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Thu, 16 Oct 2008 10:46:42 +0200
Subject: [MINC-users] mincconcat error
References: <d747ed50810060502t6d64e527ha45af1afc7d533ff@mail.gmail.com><2046436230.26871223373986359.JavaMail.root@zimbra-store01.hst.aau.dk><d747ed50810080621j50530c8o2893709d7a9e3434@mail.gmail.com>
	<200810151553.m9FFrVkJ1096352@yorick.bic.mni.mcgill.ca>
Message-ID: <160E3DD4FB702C4CB860C65186686E69020205DA@MRZS152229.medizin.uni-leipzig.de>

Hi Claude, 

as you suggested, I played around with the files.tmp file, to ascertain the effect of deleting some entries, and it does turn out that mincconcat is sensitive to the number of entries. With 1000 mnc files 

full_gray/0999.mnc
...
full_gray/0001.mnc
full_gray/0000.mnc


I get: 

maudette at icaw164059:/data/KoreanVisible> mincconcat -clobber -filetype -filelist files.tmp -concat_dimension zspace -sequential full.mnc
Processing:.. 
...(skipping...)
..Done

With slightly more than that...
full_gray/1328.mnc
full_gray/1327.mnc
...
full_gray/0001.mnc
full_gray/0000.mnc

I hit a size limit somewhere: 

maudette at icaw164059:/data/KoreanVisible> mincconcat -clobber -filetype -filelist files.tmp -concat_dimension zspace -sequential full.mnc
Processing:.mincconcat: ncx.c:1716: ncx_put_size_t: Assertion `*ulp <= 4294967295U' failed.
Aborted

I should emphasize that I am working with 64-bit Suse 10 Linux. 

Cheers, 

Michel

-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Claude LEPAGE
Sent: Wed 10/15/2008 5:53 PM
To: MINC users mailing list
Subject: Re: [MINC-users] mincconcat error
 
Hi Michel,

I'm using mincconcat for 7400 slices and it works. In minc2, of course.
Here is my command:

mincconcat -clobber -filetype -filelist files.tmp -concat_dimension yspace -sequential full.mnc

You may need to change the concat_dimension (may not be yspace for you). 
You should also disable internal file compression if concatenation is too
slow (setenv MINC_COMPRESS 0).

Try this and let me know. It could also be some bug.

Claude


> I'm trying to use mincconcat with a large number of tissue slice, =
> high-res minc files, and getting the following error.=20
> 
> mincconcat -clobber -filelist files.tmp -sequential korean_full_gray.mnc
> Processing:.mincconcat: ncx.c:1716: ncx_put_size_t: Assertion `*ulp <=3D =
> 4294967295U' failed.
> Aborted
> 
> The directory represented by files.tmp is as follows:=20
> 
> -rwxr-xr-x  1 maudette users 3474264 2007-10-26 18:48 full_gray/0000.mnc
> -rwxr-xr-x  1 maudette users 3474264 2007-10-26 18:48 full_gray/0001.mnc
> ...
> -rwxr-xr-x  1 maudette users 3474264 2007-10-26 20:38 full_gray/1327.mnc
> -rwxr-xr-x  1 maudette users 3474264 2007-10-26 20:38 full_gray/1328.mnc
> 
> Can anyone suggest a course of action?=20
> 
> Best wishes,=20
> 
> Michel
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users



From a.janke at gmail.com  Thu Oct 16 05:05:47 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 16 Oct 2008 20:05:47 +1100
Subject: [MINC-users] mincconcat error
In-Reply-To: <160E3DD4FB702C4CB860C65186686E69020205DA@MRZS152229.medizin.uni-leipzig.de>
References: <d747ed50810060502t6d64e527ha45af1afc7d533ff@mail.gmail.com>
	<2046436230.26871223373986359.JavaMail.root@zimbra-store01.hst.aau.dk>
	<d747ed50810080621j50530c8o2893709d7a9e3434@mail.gmail.com>
	<200810151553.m9FFrVkJ1096352@yorick.bic.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E69020205DA@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <d747ed50810160205r42165b40r7174bab88d9a753@mail.gmail.com>

> I hit a size limit somewhere:
>
> maudette at icaw164059:/data/KoreanVisible> mincconcat -clobber -filetype -filelist files.tmp -concat_dimension zspace -sequential full.mnc
> Processing:.mincconcat: ncx.c:1716: ncx_put_size_t: Assertion `*ulp <= 4294967295U' failed.
> Aborted
>
> I should emphasize that I am working with 64-bit Suse 10 Linux.

Hi Michel,

Claude eluded to this but I dont think asked directly. Are these MINC1
or MINC2 files?  ie: what does:

   $ file fred.mnc

return?  the ncx_....  calls would insinuate to me that these are
netcdf (MINC 1) files. In that case I am not surprised that you are
hitting limits.


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

From Michel.Audette at medizin.uni-leipzig.de  Thu Oct 16 05:11:14 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Thu, 16 Oct 2008 11:11:14 +0200
Subject: [MINC-users] mincconcat error
References: <d747ed50810060502t6d64e527ha45af1afc7d533ff@mail.gmail.com><2046436230.26871223373986359.JavaMail.root@zimbra-store01.hst.aau.dk><d747ed50810080621j50530c8o2893709d7a9e3434@mail.gmail.com><200810151553.m9FFrVkJ1096352@yorick.bic.mni.mcgill.ca><160E3DD4FB702C4CB860C65186686E69020205DA@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50810160205r42165b40r7174bab88d9a753@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E69020205DC@MRZS152229.medizin.uni-leipzig.de>

Hi Andrew, 

that makes sense. Thanks for the explanation. I should mincconvert the tissue slices files and then mincconcat, or will mincconcat do the conversion? 

On another note, I seem to be hitting this limit with Display as well. If I mincconcat 400 or so slices into 1 minc volume, I'm able to Display it, but not if I mincconcat 1000 of them. 

Let me look into this conversion. 

Best wishes, 

Michel


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Andrew Janke
Sent: Thu 10/16/2008 11:05 AM
To: MINC users mailing list
Subject: Re: [MINC-users] mincconcat error
 
> I hit a size limit somewhere:
>
> maudette at icaw164059:/data/KoreanVisible> mincconcat -clobber -filetype -filelist files.tmp -concat_dimension zspace -sequential full.mnc
> Processing:.mincconcat: ncx.c:1716: ncx_put_size_t: Assertion `*ulp <= 4294967295U' failed.
> Aborted
>
> I should emphasize that I am working with 64-bit Suse 10 Linux.

Hi Michel,

Claude eluded to this but I dont think asked directly. Are these MINC1
or MINC2 files?  ie: what does:

   $ file fred.mnc

return?  the ncx_....  calls would insinuate to me that these are
netcdf (MINC 1) files. In that case I am not surprised that you are
hitting limits.


-- 
Andrew Janke
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users




From Michel.Audette at medizin.uni-leipzig.de  Thu Oct 16 10:04:06 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Thu, 16 Oct 2008 16:04:06 +0200
Subject: [MINC-users] mincconvert error
References: <d747ed50810060502t6d64e527ha45af1afc7d533ff@mail.gmail.com><2046436230.26871223373986359.JavaMail.root@zimbra-store01.hst.aau.dk><d747ed50810080621j50530c8o2893709d7a9e3434@mail.gmail.com><200810151553.m9FFrVkJ1096352@yorick.bic.mni.mcgill.ca><160E3DD4FB702C4CB860C65186686E69020205DA@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50810160205r42165b40r7174bab88d9a753@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E69020205E1@MRZS152229.medizin.uni-leipzig.de>

Hi folks, 

my mincconcat error has now morphed into a mincconvert error (it's apparent that memory consumption was an issue with my minc-1 attempts). 

maudette at icaw164059:/data> mincconvert -2 -clob KoreanVisible/full_gray/0000.mnc KoreanVisible/full_gray/0000_2.mnc
HDF5-DIAG: Error detected in HDF5 library version: 1.6.1 thread 0.  Back trace follows.
  #000: H5F.c line 3191 in H5Fclose(): decrementing file ID failed
    major(07): Atom layer
    minor(16): Unable to close file
  #001: H5F.c line 3119 in H5F_close(): unable to flush cache
    major(08): Meta data cache layer
    minor(36): Unable to flush data from cache
  #002: H5F.c line 2881 in H5F_flush(): low level flush failed
    major(05): Low-level I/O layer
    minor(23): Write failed
  #003: H5FD.c line 3265 in H5FD_flush(): driver flush request failed
    major(22): Virtual File Layer
    minor(27): Unable to initialize object
  #004: H5FDsec2.c line 822 in H5FD_sec2_flush(): unable to extend file properly
    major(05): Low-level I/O layer
    minor(21): Seek failed

Is this an environment variable that I neglected to set in my .bashrc file? 

Best wishes, 

Michel
-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Andrew Janke
Sent: Thu 10/16/2008 11:05 AM
To: MINC users mailing list
Subject: Re: [MINC-users] mincconcat error
 
> I hit a size limit somewhere:
>
> maudette at icaw164059:/data/KoreanVisible> mincconcat -clobber -filetype -filelist files.tmp -concat_dimension zspace -sequential full.mnc
> Processing:.mincconcat: ncx.c:1716: ncx_put_size_t: Assertion `*ulp <= 4294967295U' failed.
> Aborted
>
> I should emphasize that I am working with 64-bit Suse 10 Linux.

Hi Michel,

Claude eluded to this but I dont think asked directly. Are these MINC1
or MINC2 files?  ie: what does:

   $ file fred.mnc

return?  the ncx_....  calls would insinuate to me that these are
netcdf (MINC 1) files. In that case I am not surprised that you are
hitting limits.


-- 
Andrew Janke
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users



From Michel.Audette at medizin.uni-leipzig.de  Thu Oct 16 10:14:02 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Thu, 16 Oct 2008 16:14:02 +0200
Subject: [MINC-users] mincconvert error
References: <d747ed50810060502t6d64e527ha45af1afc7d533ff@mail.gmail.com><2046436230.26871223373986359.JavaMail.root@zimbra-store01.hst.aau.dk><d747ed50810080621j50530c8o2893709d7a9e3434@mail.gmail.com><200810151553.m9FFrVkJ1096352@yorick.bic.mni.mcgill.ca><160E3DD4FB702C4CB860C65186686E69020205DA@MRZS152229.medizin.uni-leipzig.de><d747ed50810160205r42165b40r7174bab88d9a753@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E69020205E1@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <160E3DD4FB702C4CB860C65186686E69020205E2@MRZS152229.medizin.uni-leipzig.de>

Hi again, 

turns out that both I and other Minc-users have seen this error before, and it is resolved with a newer version of hdf5 (1.6.7) than I currently have on the machine where I am playing with this tissue data (not my usual machine). 

Please disregard the previous message. 

Best wishes, 

Michel

-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Audette, Michel
Sent: Thu 10/16/2008 4:04 PM
To: MINC users mailing list
Subject: [MINC-users] mincconvert error
 
Hi folks, 

my mincconcat error has now morphed into a mincconvert error (it's apparent that memory consumption was an issue with my minc-1 attempts). 

maudette at icaw164059:/data> mincconvert -2 -clob KoreanVisible/full_gray/0000.mnc KoreanVisible/full_gray/0000_2.mnc
HDF5-DIAG: Error detected in HDF5 library version: 1.6.1 thread 0.  Back trace follows.
  #000: H5F.c line 3191 in H5Fclose(): decrementing file ID failed
    major(07): Atom layer
    minor(16): Unable to close file
  #001: H5F.c line 3119 in H5F_close(): unable to flush cache
    major(08): Meta data cache layer
    minor(36): Unable to flush data from cache
  #002: H5F.c line 2881 in H5F_flush(): low level flush failed
    major(05): Low-level I/O layer
    minor(23): Write failed
  #003: H5FD.c line 3265 in H5FD_flush(): driver flush request failed
    major(22): Virtual File Layer
    minor(27): Unable to initialize object
  #004: H5FDsec2.c line 822 in H5FD_sec2_flush(): unable to extend file properly
    major(05): Low-level I/O layer
    minor(21): Seek failed

Is this an environment variable that I neglected to set in my .bashrc file? 

Best wishes, 

Michel
-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Andrew Janke
Sent: Thu 10/16/2008 11:05 AM
To: MINC users mailing list
Subject: Re: [MINC-users] mincconcat error
 
> I hit a size limit somewhere:
>
> maudette at icaw164059:/data/KoreanVisible> mincconcat -clobber -filetype -filelist files.tmp -concat_dimension zspace -sequential full.mnc
> Processing:.mincconcat: ncx.c:1716: ncx_put_size_t: Assertion `*ulp <= 4294967295U' failed.
> Aborted
>
> I should emphasize that I am working with 64-bit Suse 10 Linux.

Hi Michel,

Claude eluded to this but I dont think asked directly. Are these MINC1
or MINC2 files?  ie: what does:

   $ file fred.mnc

return?  the ncx_....  calls would insinuate to me that these are
netcdf (MINC 1) files. In that case I am not surprised that you are
hitting limits.


-- 
Andrew Janke
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users





From Michel.Audette at medizin.uni-leipzig.de  Thu Oct 16 11:26:16 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Thu, 16 Oct 2008 17:26:16 +0200
Subject: [MINC-users] mincconvert error
References: <200810161429.m9GETHfT1213730@yorick.bic.mni.mcgill.ca>
Message-ID: <160E3DD4FB702C4CB860C65186686E69020205E5@MRZS152229.medizin.uni-leipzig.de>

Hi again, 

making progress with mincconcat, but now I have a really large minc2 file that mincinfo and Display don't seem to like


maudette at icaw164059:/data> mincinfo  full.mnc
(from miopen): Unable to open file 'full.mnc'
mincinfo: Error opening file "full.mnc"
maudette at icaw164059:/data> ls -l full.mnc
-rwxr-xr-x  1 maudette users 4294967295 2008-10-16 17:21 full.mnc

maudette at icaw164059:/data> Display full.mnc
Inputting full.mnc.
(from miopen): Unable to open file 'full.mnc'
Error: opening MINC file "full.mnc".
Error loading full.mnc

I just recompiled my minc tools as well as Display software with hdf5 1.6.6... 

Also, my student had implemented a perl script in the past that did this:
  system("minc_modify_header -dinsert zspace:step=0.2 -dinsert yspace:step=0.2 -dinsert xspace:step=0.2 $output");

and minc_modify_header apparently does not deal with minc2. 
maudette at icaw164059:/data> minc_modify_header -dinsert zspace:step=0.2 -dinsert yspace:step=0.2 -dinsert xspace:step=0.2 full.mnc
(from miopen): Can't write compressed file
ncredef: ncid -1: Not a netCDF id
micreate_group_variable: MINC package entry point
...
ncclose: ncid -1: Not a netCDF id
Or does it? (It won't take -2 as an option).

Best wishes, 

Michel

-----Original Message-----
From: Claude LEPAGE [mailto:claude at bic.mni.mcgill.ca]
Sent: Thu 10/16/2008 4:29 PM
To: Audette, Michel
Subject: [MINC-users] mincconvert error
 

Hi Michel,

We are using hdf5-1.6.6 and hdf5-1.6.7 here without problems. It's possible
that 1.6.1 was buggy. Good for you if you could resolve your problem. 

Claude



From ed.gronenschild at mi.unimaas.nl  Fri Oct 17 08:25:30 2008
From: ed.gronenschild at mi.unimaas.nl (Ed Gronenschild)
Date: Fri, 17 Oct 2008 14:25:30 +0200
Subject: [MINC-users] How to register T1 onto T2/PD?
In-Reply-To: <mailman.3.1222099202.25275.minc-users@bic.mni.mcgill.ca>
References: <mailman.3.1222099202.25275.minc-users@bic.mni.mcgill.ca>
Message-ID: <5AAAC096-DD55-457D-907B-7583B6865B3D@mi.unimaas.nl>

Hi,

I need to register a coronal T1 stack onto an axial T2 stack
of the same subject. Details of the stacks are:
T1:
176 slices of 384 * 384 pixels, pixel size = 0.67 mm * 0.67 mm,
slice thickness = 1.34 mm.

T2:
50 slices of 256 * 256 pixels, pixel size = 1.0 mm * 1.0 mm,
slice thickness = 2.00 mm

The T2 slices are positioned such that they cover only the brain
tissue (in the Z direction), whereas the T1 slices cover a much
larger area, fully including the head and part of the neck.

I tried the following two commands:

mritoself T1.mnc T2.mnc T1_to_T2.xfm
mincresample -transformation T1_to_T2.xfm -like T2.mnc \
	T1.mnc T1_to_T2.mnc

That produced a stack that is incorrect in that it is shifted
along the Z-axis.

The same is true if I use a PD stack with the same size and
orientation as T2.

It looks as if the problem is mainly caused by the difference
in extent of both stacks (mainly in the Z-direction).
Is there another command to register a T1 onto a T2 or PD?

Ed


From sorench at gmail.com  Fri Oct 17 08:32:14 2008
From: sorench at gmail.com (Soren Christensen)
Date: Fri, 17 Oct 2008 23:32:14 +1100
Subject: [MINC-users] How to register T1 onto T2/PD?
In-Reply-To: <5AAAC096-DD55-457D-907B-7583B6865B3D@mi.unimaas.nl>
References: <mailman.3.1222099202.25275.minc-users@bic.mni.mcgill.ca>
	<5AAAC096-DD55-457D-907B-7583B6865B3D@mi.unimaas.nl>
Message-ID: <d6e2d6550810170532x4cd3876dq3648a731d6480f93@mail.gmail.com>

hi ed,
 Did you try nothreshold and/or far options?

On 10/17/08, Ed Gronenschild <ed.gronenschild at mi.unimaas.nl> wrote:
> Hi,
>
> I need to register a coronal T1 stack onto an axial T2 stack
> of the same subject. Details of the stacks are:
> T1:
> 176 slices of 384 * 384 pixels, pixel size = 0.67 mm * 0.67 mm,
> slice thickness = 1.34 mm.
>
> T2:
> 50 slices of 256 * 256 pixels, pixel size = 1.0 mm * 1.0 mm,
> slice thickness = 2.00 mm
>
> The T2 slices are positioned such that they cover only the brain
> tissue (in the Z direction), whereas the T1 slices cover a much
> larger area, fully including the head and part of the neck.
>
> I tried the following two commands:
>
> mritoself T1.mnc T2.mnc T1_to_T2.xfm
> mincresample -transformation T1_to_T2.xfm -like T2.mnc \
> 	T1.mnc T1_to_T2.mnc
>
> That produced a stack that is incorrect in that it is shifted
> along the Z-axis.
>
> The same is true if I use a PD stack with the same size and
> orientation as T2.
>
> It looks as if the problem is mainly caused by the difference
> in extent of both stacks (mainly in the Z-direction).
> Is there another command to register a T1 onto a T2 or PD?
>
> Ed
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From louis.collins at mcgill.ca  Fri Oct 17 09:29:04 2008
From: louis.collins at mcgill.ca (D. Louis Collins)
Date: Fri, 17 Oct 2008 09:29:04 -0400
Subject: [MINC-users] How to register T1 onto T2/PD?
In-Reply-To: <5AAAC096-DD55-457D-907B-7583B6865B3D@mi.unimaas.nl>
References: <mailman.3.1222099202.25275.minc-users@bic.mni.mcgill.ca>
	<5AAAC096-DD55-457D-907B-7583B6865B3D@mi.unimaas.nl>
Message-ID: <B2593B0A-965E-4CA2-AD06-5D1A736B473B@mcgill.ca>

Ed,

mritoself uses mutual information as an objective function to  
establish the mapping between the two scans to be registered.  This  
works well when you have a decent estimate of the initial  
transformation to ensure that you are in the local minima of the  
objective function.  mritoself will fail in the way you describe if  
the initial estimate (either given by the use, or estimated by the  
procedure) is not good.

If your datasets were acquired during the same session, and the  
subject did not move much during the session, then try
	mritoself -close T1.mnc T2.mnc T1_to_T2.xfm

If the datasets were acquired during different sessions, then the two  
datasets will be reasonably far from one another.  if so, try
	 mritoself -far T1.mnc T2.mnc T1_to_T2.xfm	

If neither of these work, then you'll have to estimate the initial  
transformation by hand. do the following
	register T2.mnc T1.mnc
	identify homologous tag points in each data set
	save the transformation as initial_t1-to-t2.xfm

then
	mritotal -transform initial_t1-to-t2.xfm T1.mnc T2.mnc T1_to_T2.xfm

hope this helps.

-Louis

On Oct 17, 2008, at 8:25 AM, Ed Gronenschild wrote:

> Hi,
>
> I need to register a coronal T1 stack onto an axial T2 stack
> of the same subject. Details of the stacks are:
> T1:
> 176 slices of 384 * 384 pixels, pixel size = 0.67 mm * 0.67 mm,
> slice thickness = 1.34 mm.
>
> T2:
> 50 slices of 256 * 256 pixels, pixel size = 1.0 mm * 1.0 mm,
> slice thickness = 2.00 mm
>
> The T2 slices are positioned such that they cover only the brain
> tissue (in the Z direction), whereas the T1 slices cover a much
> larger area, fully including the head and part of the neck.
>
> I tried the following two commands:
>
> mritoself T1.mnc T2.mnc T1_to_T2.xfm
> mincresample -transformation T1_to_T2.xfm -like T2.mnc \
> 	T1.mnc T1_to_T2.mnc
>
> That produced a stack that is incorrect in that it is shifted
> along the Z-axis.
>
> The same is true if I use a PD stack with the same size and
> orientation as T2.
>
> It looks as if the problem is mainly caused by the difference
> in extent of both stacks (mainly in the Z-direction).
> Is there another command to register a T1 onto a T2 or PD?
>
> Ed
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From claude at bic.mni.mcgill.ca  Fri Oct 17 11:13:56 2008
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Fri, 17 Oct 2008 11:13:56 -0400 (EDT)
Subject: [MINC-users] How to register T1 onto T2/PD?
References: <mailman.3.1222099202.25275.minc-users@bic.mni.mcgill.ca>
	<5AAAC096-DD55-457D-907B-7583B6865B3D@mi.unimaas.nl>
Message-ID: <200810171513.m9HFDuQG1323149@yorick.bic.mni.mcgill.ca>

Hi,

The way it is done in the cortical surface extraction pipeline is to
first correct t1 and t2 for non-uniformities using N3 in native space, 
then to use mritoself like this:

mritoself -nothreshold -mi -lsq6 t2.mnc t1.mnc t2_to_t1.xfm

No brain mask is used. I have yet to see a failed case with this
approach, but I'm sure it can fail. Easy to try.

Claude


> I need to register a coronal T1 stack onto an axial T2 stack
> of the same subject. Details of the stacks are:
> T1:
> 176 slices of 384 * 384 pixels, pixel size = 0.67 mm * 0.67 mm,
> slice thickness = 1.34 mm.
> 
> T2:
> 50 slices of 256 * 256 pixels, pixel size = 1.0 mm * 1.0 mm,
> slice thickness = 2.00 mm
> 
> The T2 slices are positioned such that they cover only the brain
> tissue (in the Z direction), whereas the T1 slices cover a much
> larger area, fully including the head and part of the neck.
> 
> I tried the following two commands:
> 
> mritoself T1.mnc T2.mnc T1_to_T2.xfm
> mincresample -transformation T1_to_T2.xfm -like T2.mnc \
> 	T1.mnc T1_to_T2.mnc
> 
> That produced a stack that is incorrect in that it is shifted
> along the Z-axis.
> 
> The same is true if I use a PD stack with the same size and
> orientation as T2.
> 
> It looks as if the problem is mainly caused by the difference
> in extent of both stacks (mainly in the Z-direction).
> Is there another command to register a T1 onto a T2 or PD?
> 
> Ed
> 
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> 

From ed.gronenschild at mi.unimaas.nl  Mon Oct 20 04:19:31 2008
From: ed.gronenschild at mi.unimaas.nl (Ed Gronenschild)
Date: Mon, 20 Oct 2008 10:19:31 +0200
Subject: [MINC-users] How to register T1 onto T2/PD?
In-Reply-To: <mailman.1.1224259206.4358.minc-users@bic.mni.mcgill.ca>
References: <mailman.1.1224259206.4358.minc-users@bic.mni.mcgill.ca>
Message-ID: <BC36CD55-7D6E-49E5-9A39-D9FA62D3A4A7@mi.unimaas.nl>

Thank you for your response.
The problem was solved by adding -nothreshold option

without -nothreshold I got the following transformation matrix:
-center         0.00000    0.00000    0.00000
-translation   -0.42123    0.01528   -1.36785
-rotation      -0.13077    1.24821    1.40240
-scale          1.00000    1.00000    1.00000
-shear          0.00000   -0.00000    0.00000

and with -nothreshold -close:
-center         0.00000    0.00000    0.00000
-translation   -0.08993    1.40369  -37.71188
-rotation       2.91978    5.85738    2.30537
-scale          1.00000    1.00000    1.00000
-shear         -0.00000   -0.00000    0.00000

and with -nothreshold -far:
-center         0.00000    0.00000    0.00000
-translation    0.05671    1.00988  -38.10320
-rotation       1.98986    5.50084    2.33306
-scale          1.00000    1.00000    1.00000
-shear         -0.00000   -0.00000   -0.00000

There is only a marginal difference between -close [default] and -far
options in this case. Note the effect on the Z translation by adding
-nothreshold option.

Ed

On 17 Oct 2008, at 18:00, minc-users-request at bic.mni.mcgill.ca wrote:

> Message: 4
> Date: Fri, 17 Oct 2008 11:13:56 -0400 (EDT)
> From: Claude LEPAGE <claude at bic.mni.mcgill.ca>
> Subject: Re: [MINC-users] How to register T1 onto T2/PD?
> To: MINC users mailing list <minc-users at bic.mni.mcgill.ca>
> Message-ID: <200810171513.m9HFDuQG1323149 at yorick.bic.mni.mcgill.ca>
>
> Hi,
>
> The way it is done in the cortical surface extraction pipeline is to
> first correct t1 and t2 for non-uniformities using N3 in native space,
> then to use mritoself like this:
>
> mritoself -nothreshold -mi -lsq6 t2.mnc t1.mnc t2_to_t1.xfm
>
> No brain mask is used. I have yet to see a failed case with this
> approach, but I'm sure it can fail. Easy to try.
>
> Claude
>


From alex at bic.mni.mcgill.ca  Tue Oct 21 16:03:17 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Tue, 21 Oct 2008 16:03:17 -0400
Subject: [MINC-users] bicppl on centOS (and RedHat)?
Message-ID: <e758a6650810211303n66109e15he1c611ea7bed7b32@mail.gmail.com>

Hello,

I was wondering if anybody has managed to compile bicpl on CentOS (or
RedHat)? The configure step doesn't like not being able to find
libppm. I installed the netpbm-devel package, but that doesn't provide
libppm (only libnetpbm v10).

There is a similar story for debian actually, where bicpl needs the
netpbm9-dev pkg instead of netpbm10-dev; but at least debian seems to
still provide the v9 lib, whereas I haven't been able to find that for
CentOS.

Thanks,

-- Alex

From a.janke at gmail.com  Tue Oct 21 20:28:03 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 22 Oct 2008 11:28:03 +1100
Subject: [MINC-users] bicppl on centOS (and RedHat)?
In-Reply-To: <e758a6650810211303n66109e15he1c611ea7bed7b32@mail.gmail.com>
References: <e758a6650810211303n66109e15he1c611ea7bed7b32@mail.gmail.com>
Message-ID: <d747ed50810211728n658fcc5bm578ad0c8395fa02c@mail.gmail.com>

Hi Alex,

> I was wondering if anybody has managed to compile bicpl on CentOS (or
> RedHat)? The configure step doesn't like not being able to find
> libppm. I installed the netpbm-devel package, but that doesn't provide
> libppm (only libnetpbm v10).

Yes I have made this work (RHEL5 and Fedora), I will see if I can make
some packages..  In the meantime I would do this when configuring:

   $ ./configure --with-minc2 --with-image-netpbm

a

From se at hst.aau.dk  Wed Oct 22 11:11:41 2008
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Wed, 22 Oct 2008 17:11:41 +0200 (CEST)
Subject: [MINC-users] problem with nu_estimate_np_and_em
In-Reply-To: <278262543.94121224688095330.JavaMail.root@zimbra-store01.hst.aau.dk>
Message-ID: <547897314.94141224688301719.JavaMail.root@zimbra-store01.hst.aau.dk>

Hi Andrew,
Sorry for the delay on this subject. A lot of work was pushed onto my stack. Now I have popped down to this issue again.
Nothing seems to be wrong with the input image. In fact, nu_correct is running fine on the same image on my 32bit ubuntu work station (minc deb installation).

se at rom:~$ nu_correct -version
Program nu_correct, built from:
Package MNI N3, version 1.10.1, compiled by rotor at mavis (i686-pc-linux-gnu) on 2008-05-17 at 08:01:11

The version that breaks is:

se at cerebrum01:~> nu_correct -version
Program nu_correct, built from:
Package MNI N3, version 1.10.1, compiled by se at cerebrum01 (x86_64-unknown-linux-gnu) on 2008-10-07 at 11:35:07

Are there 64bit issues with the nu_correct script?

Simon

----- "Andrew Janke" <a.janke at gmail.com> wrote:

> Hi Simon,
> 
> No idea if you are missing anything but I just tried this same game
> (although in truth I built packages and installed them) and it works
> for me.
> 
> Is there something amiss with the histogram of t1_native.mnc ?  The
> error output would seem to indicate a dud histogram.
> 
> a
> 
> On Tue, Oct 7, 2008 at 9:06 PM, Simon Fristed Eskildsen
> <se at hst.aau.dk> wrote:
> > Now that we are on the subject of nu_correct. I just compiled the
> latest of everything from packages/tgz on ubuntu 64bit --with-minc2,
> and nu_correct rewarded me with the following.
> >
> >> nu_correct native/t1_native.mnc test.mnc
> > Bad buffer size 0 in set_loop_buffer_size
> > Bad buffer size 0 in set_loop_buffer_size
> > Bad buffer size 0 in set_loop_buffer_size
> > Transforming
> slices:..............................................Done
> > Bad buffer size 0 in set_loop_buffer_size
> > Bad buffer size 0 in set_loop_buffer_size
> > Bad buffer size 0 in set_loop_buffer_size
> > Bad buffer size 0 in set_loop_buffer_size
> > Must have one or bins per histogram
> > sharpen_volume: crashed while running volume_hist (termination
> status=256)
> > nu_estimate_np_and_em: crashed while running sharpen_volume
> (termination status=256)
> > nu_correct: crashed while running nu_estimate_np_and_em (termination
> status=256)
> >
> > Am I missing something?
> >
> > Regards,
> > Simon
> > ----- "Andrew Janke" <a.janke at gmail.com> wrote:
> >
> >> > On Wed, Oct 1, 2008 at 5:41 AM, Tejaswini Ganapathi
> >> > <tejasvinee at gmail.com> wrote:
> >> >> All of my installed files (exe files) are in /usr/bin. Infact
> >> nu_correct,
> >> >> nu_estimate and nu_evaluate work fine. I'm having this problem
> only
> >> with
> >> >> nu_estimate_np_and_em
> >> >>
> >> >> Ive tried the following on the shell command line,
> >> >> $ nu_estimate_np_and_em -normalize_field -save_fields -mask
> >> >> mask.mnc breast.mnc fields_time.mnc
> >> >>
> >> >> nu_estimate_np_and_em: couldn't find program "class_statistics"
> >> >> nu_estimate_np_and_em: couldn't find program "estimate"
> >> >
> >> > I reckon you have hit on a bug.  And amusingly I cannot find
> these
> >> two
> >> > executables that you are talking about on my system (or yorick!)
> >> > either. I suspect that you are using a little used part of the
> N3
> >> > package that has escaped inspection/execution for a long time.
> >>
> >> An update on this one, I have been in contact with the original
> >> Author
> >> of N3 (John Sled) and he tells me that these errors are due to the
> >> script in question trying to use another version of intensity
> >> correction that is based upon the EM algorithm.
> nu_estimate_np_and_em
> >> was written to compare the two methods.  He tells me that it is
> >> likely
> >> not worth resurrecting the EM method (although I did find the code
> >> hidden deep in an archive -- Thanks Mike and Sylvain). So the
> "fix"
> >> for now is to not use the -mean or -tag options and be sure to use
> a
> >> -sharpen x y option.
> >>
> >> The default option for sharpen is:
> >>
> >>    -sharpen 100 0.01
> >>
> >> Mind you this he tells me is why nu_correct and nu_estimate were
> >> written as they are simply wrappers for the bits of code in
> question
> >> that make sure that only the NP method (or N3) is used.
> >>
> >> There is now a "fix" in CVS for this that should make the next
> >> release
> >> that will warn users of this.
> >>
> >>
> >> --
> >> Andrew Janke - andrew.janke at anu.edu.au
> >> Department of Geriatric Medicine, ANU
> >> (a.janke at gmail.com || http://a.janke.googlepages.com/)
> >> Canberra->Australia    +61 (402) 700 883
> >> _______________________________________________
> >> MINC-users at bic.mni.mcgill.ca
> >> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
> 
> 
> 
> -- 
> Andrew Janke - andrew.janke at anu.edu.au
> Department of Geriatric Medicine, ANU
> (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia    +61 (402) 700 883
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From a.janke at gmail.com  Wed Oct 22 18:21:49 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 23 Oct 2008 10:21:49 +1200
Subject: [MINC-users] problem with nu_estimate_np_and_em
In-Reply-To: <547897314.94141224688301719.JavaMail.root@zimbra-store01.hst.aau.dk>
References: <278262543.94121224688095330.JavaMail.root@zimbra-store01.hst.aau.dk>
	<547897314.94141224688301719.JavaMail.root@zimbra-store01.hst.aau.dk>
Message-ID: <d747ed50810221521k26f801ebia0adf8fae2dab041@mail.gmail.com>

> Sorry for the delay on this subject. A lot of work was pushed onto my stack. Now I have popped down to this issue again.

You are certainly not alone there.

> Nothing seems to be wrong with the input image. In fact, nu_correct is running fine on the same image on my 32bit ubuntu work station (minc deb installation).
>
> se at rom:~$ nu_correct -version
> Program nu_correct, built from:
> Package MNI N3, version 1.10.1, compiled by rotor at mavis (i686-pc-linux-gnu) on 2008-05-17 at 08:01:11

Hrm...

> se at cerebrum01:~> nu_correct -version
> Program nu_correct, built from:
> Package MNI N3, version 1.10.1, compiled by se at cerebrum01 (x86_64-unknown-linux-gnu) on 2008-10-07 at 11:35:07
>
> Are there 64bit issues with the nu_correct script?

certainly not that i am aware of. If this is a ubuntu machine can you
try the prebuilt amd64 binaries ala rom?


a

From se at hst.aau.dk  Thu Oct 23 04:52:29 2008
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Thu, 23 Oct 2008 10:52:29 +0200 (CEST)
Subject: [MINC-users] problem with nu_estimate_np_and_em
In-Reply-To: <1431497202.95771224751864877.JavaMail.root@zimbra-store01.hst.aau.dk>
Message-ID: <688095926.95811224751949125.JavaMail.root@zimbra-store01.hst.aau.dk>

> certainly not that i am aware of. If this is a ubuntu machine can you
> try the prebuilt amd64 binaries ala rom?

Well, no sudo or root access for this machine. I am not up to speed on how to do a local installation from deb :-/ That's why I always compile everything myself.
I tried reverting to minc1 with the necessary packages needed by N3:
N3-1.10.1
ebtks-1.6.1
minc-1.5.1
netcdf-4.0
Everything works fine with this configuration.
Recompiled the above exchanging minc-1.5.1 with minc-2.0.16 (hdf5 is already installed system wide). Back to the same problem!

Btw I found a small typo in the configure -help info of minc-2.0.16:
--disable-minc2          enable HDF5 (MINC 2) functionality
This should probably read "disable" instead of "enable" as the default is now minc2.

Simon

From se at hst.aau.dk  Thu Oct 23 06:29:25 2008
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Thu, 23 Oct 2008 12:29:25 +0200 (CEST)
Subject: [MINC-users] problem with nu_estimate_np_and_em
In-Reply-To: <688095926.95811224751949125.JavaMail.root@zimbra-store01.hst.aau.dk>
Message-ID: <494883986.96321224757764970.JavaMail.root@zimbra-store01.hst.aau.dk>

Latest development:
Reverting to minc-2.0.15 solved all my problems. All other package versions remain the same.
I'm sorry I don't have time to track down the bug in minc version 2.0.16.

Simon