[MINC-users] minctoraw

[Peter NEELIN]

On Wed, 28 Aug 2002, Stephen Smith wrote:

> hello - I've just found a gotcha in "minctoraw -normalise" (which I use to
> convert to analyze). It seems to me that without the -normalise option you
> get the "arbitrary" scaling of each slice's intensity, which you clearly
> don't want in the final raw image - right? So my conversion program has
> always used the -normalise flag. However I have just discovered that there
> is still some overall intensity scaling that gets lost this way, because
> when I compare two MINC files their subtraction makes sense - but when
> comparing two converted analyze files, they are somehow scaled relative to
> eachother, so the subtraction is not now sensible

Yes. I am afraid that I never got around to replacing minctoraw (the
original, rather primitive program with the helpful name) with mincextract
(the later, more featureful program with a less obvious name). Between
being afraid of breaking things and general inertia, I never fixed
that problem and so people still end up using the rather limited
minctoraw.

mincextract has the option -image_range that allows you to specify the
normalization of the output data (combined with the valid_range, one can
calculate a scale from real values to the dumped voxel values). Note also
that mincextract has -normalize turned on by default. You will need to
specify the output type, however (probably something like
"-short -signed -range 0 4095" for analyze files). If your original data
was integer data and that scaling was preserved in the conversion to minc,
then you can get the original integer values back with something like

   mincextract -short -signed -range 0 4095 -image_range 0 4095 file.mnc

(completely untested - just working from memory). The important point is
that using the same -range and -image_range will give a scaling of 1 and
offset of 0 when converting real values back to voxel values.

'Hope this helps.

            Peter
----
            Peter Neelin (neelin@bic.mni.mcgill.ca)