[MINC-development] MINC2 file with floating-point voxels and slice normalization

[Peter Neelin]

On Jan 17, 2013 6:03 PM, "Andrew Janke" <a.janke at gmail.com> wrote:

> On 18 January 2013 06:36, Vladimir S. FONOV <vladimir.fonov at gmail.com>
wrote:
> > So, the question to MINC founding fathers - should MINC2 api be
modified to
> > make sure that no inter-slice normalization happens when voxel type is
> > float, or is there any some other considerations?
>
> My understanding was that float/double MINC files don't do slice
> normalisation as it doesn't make sense. Float+Double filetypes specify
> a precision for your datatype, the range is irrelevant. So yes this
> should be removed. It was my understanding that if you convert a file

Andrew is right. Remember that in the original design of minc, there were
only real numbers (conceptually) - storing as bytes or shorts has always
just been a representational trick for fixed point. The real values are
rescaled to fit in the integer range, potentially on a slice-by-slice
basis, preserving the scaling info in the image max/min. Floating-point
representations do not need any rescaling to fit, so none is done.
Normalization on read does not make sense since the values are already
normalized.

> to float/double using MINC tools the slice max/mins are discarded.

In the float/double case the slice max/mins are preserved for informational
purposes (it is not necessary to read the whole image to know the range).

Peter
--
Peter Neelin
peter.neelin at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20130117/41e67ff9/attachment.html>