[MINC-users] minc2dicom ?

[Simon Fristed Eskildsen]

Ok, this demanded a bit of research. I wrote my own c-code for 
extracting raw slices from minc so I was completely certain about the 
number channels and the number of bits pr channel. With the code I 
generated three different raw files (slice 0 from a t1):
t1_1ch1b000.raw (1 channel 1 byte pr channel)
t1_1ch2b000.raw (1 channel 2 bytes pr channel)
t1_3ch1b000.raw (3 channels 1 byte pr channel)
Then I used dicom2 to convert to dicom and back to png:
dicom2 -d --modality=MRI --size=181:217 t1_1ch1b000.raw
dicom2 -p --size=181:217 t1_1ch1b000.raw.dcm

Results:
t1_1ch1b000.raw.dcm.png looks good
t1_1ch2b000.raw.dcm.png is black (with one white pixel ?)
The 3 channel image produces a warning when converted to dicom:
"bits allocated 24 > 16 are not fully supported... (email me)"
...and an error when the conversion to png is tried:
"missing pixel data (58916 words at least expected, 58915 found)!"

Now, running the dcm2v on the three produced dicom images result in 
black images for the two first and an image where the highest 
intensities are messed up of the 3 channel image. It looks like it 
expects a signed 8 bit image.
convert -size 181x217 -depth 8 RGB:t1_3ch1b000.raw t1_3ch1b000.png
produces a nice image, which shows that the 3 channel raw image is 
generated ok.

Any suggestions to how I trick dicom2 into producing the right format 
(signed 8bit)?

Sorry for the verbosity!

Simon


Andrew Janke wrote:
>> for i in `seq 0 $slices`; do
>>     mincpik -scale 1 $infile tmp.rgb
>>     mv tmp.rgb tmp.raw
>>     dicom2 -d --size=$cols:$rows tmp.raw
>>     dcm2v tmp.raw.dcm -o $prefix\_$i.v
>> done
>>     
>
> Looks good, although I suspect you will want to add a
>
>    -slice $i
>
> to the mincpik line.  Also I think you can do this with Imagemagick:
>
>    mincpik -slice $1 -scale 1 $infile RGB:tmp.raw
>
> and do away with the mv command.  'man ImageMagick' will tell more.
>
>
>