[MINC-users] Reading minc format DTI data

[Rupert Brooks]

Hi,

I've seen a vaguely similar problem at some point in the past.  If i
remember, it was because the windows versions did not correctly do
binary writing - so some bytes actually expanded to two when written
to the disk.  Theres a similar problem with windows reading where the
file appears mysteriously truncated due to attempting to read the
CTRL-Z.   When opening files in C++ on windows, you have to be careful
to pass the binary flags exactly right or it does some kind of ascii
conversion.  I think C worked similarly.  I never remember the details
and get bitten by this problem about once a year :-P

The easiest fix would be to perform the extraction on a linux or mac
system i would guess.  Vlad - im supposing you did your experiment on
a linux box?

At some point in the distant past, i created native windows binaries
as well.   They are posted on my web site (see
www.rupertbrooks.ca/code.html).  It might be worth trying them as
well, although i kind of doubt they will work any differently than
what you tried.  If you do try them, please let me know the result,
i'll attach it to the notes about them for what its worth.

If you really cant get access to a linux system, you could try a
cygwin build instead of a native Win32 build.  It might overcome the
problem.

Good luck,
Rupert
--------------------------------------------------------------
Rupert Brooks
rupert.brooks at gmail.com




On Mon, Jun 21, 2010 at 18:46, Vladimir FONOV <vladimir.fonov at gmail.com> wrote:
> Hello,
>
> Yonas T. wrote:
>>
>> Here is what I found however:
>>
>> minctoraw -normalize dti.mnc > ImageData.raw
>> Result: ImageData.raw file with size = 227,288,499 bytes  (about 216MB)
>>
>> minctoraw -normalize -short dti.mnc > ImageData_Short.raw
>> Result: ImageData_Short.raw file with size = 227,288,499 bytes  (about
>> 216MB)
>>
>> mincextract dti.mnc > ImageDataWithExtract.raw
>> Result: ImageDataWithExtract.raw file with size = 2,141,244,230 bytes
>> (about 2GB)
>>
>> mincextract -normalize -short dti.mnc > ImageDataWithExtract_Short.raw
>> Result: ImageDataWithExtract_Short.raw file with size = 225,473,844 bytes
>> (about 215MB)
>
> my experiment:
>
>> mincinfo test_dti.mnc
> file: test_dti.mnc
> image: signed__ short 0 to 4095
> image dimensions: time zspace yspace xspace
>    dimension name         length         step        start
>    --------------         ------         ----        -----
>    time                       32            1            0
>    zspace                     40          1.2      -16.894
>    yspace                    128     -1.21875      80.1687
>    xspace                    128     -1.21875      77.9898
>
> 32*40*128*128*4=83886080
>
>> minctoraw -normalize -float test_dti.mnc > test1.raw
>> mincextract -float test_dti.mnc > test2.raw
>> ls -l test1.raw test2.raw
> -rw-r--r-- 1 vfonov pet 83886080 Jun 21 18:41 test1.raw
> -rw-r--r-- 1 vfonov pet 83886080 Jun 21 18:41 test2.raw
>
>> cmp  test1.raw test2.raw
>
> (no messages, meaning files are identical)
>
>
>> So my questions,
>>
>> 1. As you can see from the result, I am baffled by these strangely
>> different
>> results when using minctoraw versus mincextract calls. Worse, none of
>> these
>> file sizes matches what I expected. That is the file size is LARGER than
>> what I expected (mincextract -normalize -short dti.mnc >
>> ImageDataWithExtract_Short.raw gives 225,473,844 bytes although I expected
>> 225,017,856 bytes). Any idea, please?
>>
>> 2. I also found emma matlab toolbox that can read minc format images.
>> Going
>> through line by line of the reading routines, I can see that this tool
>> does
>> nothing but uses mincextract to read the minc file to a temporary file and
>> then takes the first N bytes (where N is the expected size) from the
>> temporary file and returns. That is although the temporary file is bigger,
>> what emma does is simply discard the extra bytes. My questions here is:
>> does
>> this emma knows the extra bytes are at the end of the raw file read? Is
>> there any documentation for this?
>
> As far as I know emma is unsupported now.
>
>
>>
>> 3. Does the result of mincinfo seem meaningful? I am a bit surprised by
>> "image:
>> signed__ short 0 to 4095" because I would think unsigned short would make
>> more sense to say range 0 - 4095.
>
> 2**12=4096 - so scanner have got 12bit ADC I suppose ?
>
>
>> Any ideas please? Or any better way to read minc format image to save it
>> as
>> raw file?
>
> You can try to use niak: http://code.google.com/p/niak/ , it uses
> mincextract internally as well.
>
>
> --
> Best regards,
>  Vladimir S. FONOV ~ v.s.fonov  <at> ilmarin.info
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>