[MINC-users] 0.3 vs 1.0 scaling - clarifications

[Peter NEELIN]

On Thu, 15 May 2003, James Dessart wrote:

> It seems that what's happening when loading in my data set with 1.0 is
> that values are scaled to the image-max for the whole data set.  So
> given a data set with 256 as the global max, when a slice is read in
> with an image-max of 180, the values are scaled up to reach 256,
> resulting in inconsistent intensity over slices.
>
> This is not the behaviour I want, since 0.3 is what we've been using,
> and it doesn't do that.  What ICV variable needs to be changed to keep
> 1.0 from doing this?

MI_ICV_DO_NORM should be set to FALSE, which is the default. I don't think
that this has changed since the beginning of minc. Are you certain that
this is not being set to TRUE somewhere in your code? Can you create a
small test program to illustrate the behaviour?

As far as I can recall, no incompatibilities of this type were introduced
into the library - I am normally quite sensitive to backward compatibility
issues, so a change like this would surprise me. Although 0.3 was a
long time back - perhaps you were relying on a bug...

[...sounds of shuffling through old code and logs...]

Ah, here is something from the CVS (RCS) log that might be helpful:

   date: 2001/11/13 21:00:24;  author: neelin;  state: Exp;  lines: +43 -22
   Modified icv scaling calculations for no normalization. When the icv
   type is double, normalization is always done, regardless of the
   normalization setting. When the external type is floating point,
   normalization to the slice real range is done (essentially a valid
   range scaling, but where the valid range for a float is the slice real
   range).

So if your internal type is a floating-point type (I think that double
probably means either double or float), then normalization will always be
done. This was a rationalization of the library behaviour: floating-point
values should always have the real value, rather than a voxel value.

I apologize if this breaks your code - I had thought that very few people
were using this. Is your icv type NC_FLOAT or NC_DOUBLE? If so, then you
cannot get the file voxel values. If it is of an integer type (NC_BYTE,
NC_SHORT), then the old behaviour should still apply.

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