[MINC-development] Unexpected value scaling with miget_real_value_hyperslab

[Andrew Janke]

Hi Rick,

>> I get the series as expected, however the unsigned shorts in the buffer appear to have been scaled so that the minimum and maximum values correspond respectively to 0 and USHRT_MAX.  I know the values in the file should be within the range 0 to 4095 since it comes from 12-bit DICOM - this is in fact the 'valid range' reported for the MINC2 file by mincinfo.  The true range of data values in my example file is actually 0 to 1006.
>
> I've been exploring the ICV functions some more, but honestly I couldn't find *any* way to recover the original maximum data value (1006 in my example) from the MINC2 file I generated using dcm2mnc in the reference at
>
> http://en.wikibooks.org/wiki/MINC/Reference/MINC2.0_Application_Programmers_Interface
>
> Finally I found the function miget_volume_real_range(), which does return the actual min and max values.  However this is not really documented anywhere...

Ah good to see you found one of the functions you (might) need.  I
think you are still being bitten by slice scaling though. In order to
make sure that this is or isn't the case perhaps run the output file
through something like mincreshape -signed -short (and then back
again) to check this?

Jason gives a nice example of how to deal with slice scaling here:

   http://en.wikibooks.org/wiki/MINC/Tutorials/Programming04

> Playing around with ICV's the only other thing I've been able to do is to get the data values mapped into the 12-bit range 0 to 4095, which is still not the actual data range.

Again, I'll punt this is slice scaling biting you here.

> I realize that in some cases there can be an advantage to using the whole dynamic range of a given data type, but surely there is a way to preserve the original values?

In MINC1 there was never any magic to do this, you'd just do something
like this (in the output file) to take a crack at it:

         /* set the range to something sensible (if possible) */
         if(dtype == NC_BYTE && is_signed == FALSE){
            if(min >= 0 && max < 255){
               fprintf(stdout, "BYTE data, setting 1:1 mapping (0-256)\n");
               min = 0;
               max = 255;
               }
            }
         set_volume_real_range(*volume, min, max);

The above is nicked from mincmorph and is an attempt to make 0-255 in
the real range line up with 0-255 in the voxel range.

If you _really_ want to preserve values in a MINC file your best bet
is to use something like a float. Yes, it takes more space but then
that's somewhat cheap now.

MINC2 really needed a "integer" type or flag of some description to
define a label volume but introducing it would have meant a world of
pain adding special code to deal with this in all the other tools. In
some cases the behavior would have been fairly arbitrary in any case.

Hope that helps.


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