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

[John G. Sled]

Hi Andrew,

Thanks for investigating.   I was under the impression that Display used 
the image min/max rather than valid min/max for the initial colour range 
with float volumes.   I often encouter float MINC volumes where neither 
valid range or image range are set sensibly, which causes Display to 
quantize them to zero bit precision.   This is likely a fault of file 
converters or a python API rather than the core minc libraries.   I 
think there is value in having the correct minimum and maximum recorded 
in the header for floating point volumes.   Computing this on the fly 
when the volume is read seems wasteful given that volumes are more often 
read than written.   My preference would be to have one value for the 
whole float volume and store this as the image-min/image-max.   
Obviously, the valid-min/valid-max fields could serve the same purpose; 
however, the 'valid' part is not as intuitive a name.

Vlad's question of whether to dispense with slice scaling entirely is 
worth further discussion.   The two arguments that I am aware of that 
are in favour of per-slice scaling are: (i) that one can squeeze more 
numerical precision out of fixed point datatypes than with per-volume 
scaling; and (ii) that one can make a loss-less conversion to MINC of 
DICOM or similar data types that are inherently 2D and may not keep the 
same scaling for each slice. The arguments against per-slice scaling are 
that for out-of-core applications where one wants a section orthogonal 
to the slice direction, keeping track of slice scaling for every row of 
the section is complicated.  Also, the slice concept doesn't generalize 
elegantly to features such as block layout files that HDF5 supports.  In 
addition, given that most users of MINC are interested in 3D image 
processing of data that are presumed to have stationary image 
statistics, the benefits of (i) are often small or counterproductive.   
Point (ii) has merit but is more relevant to a radiologist's work flow 
than mine.

I have talked myself into Vlad's point of view.   I am unclear on how to 
achieve this though without breaking too many useful tools and legacy 
datasets.

cheers,

John




On 13-01-20 4:00 PM, Andrew Janke wrote:
> Hi John,
>
> I went looking for an example of this in the Register/Display code but
> it seems to use the valid min/max of a file (not the per slice values
> even if they are present). Yes, the per slice values are used while
> reading and normalised by volume_io but not in register/Display
> themselves.
>
> In our MINC2 based web viewer for large histology (TissueStack) we use
> the valid min/max as a starting guess. We also normalise during
> conversion to its own internal fast format but that's another story.
>
> Do you have an example of this behaviour? I didn't get to looking far
> into postf to see what it does, I ask as while I see this as being
> useful for discrete data types I don't see the point for float/double
> given that they are "normalised" already and thus a file min/max
> should be a decent approximation.
>
> Storing a min/max for each slice is also only going to work for
> viewing in a particular orientation.
>
> ta
>
>
> a
>
>
> On 19 January 2013 01:46, John G. Sled <jgsled at phenogenomics.ca> wrote:
>> Since we are voting ... I vote for keeping Peter's design where the slice
>> min / max is maintained for informational purposes when the underlying data
>> type is float.  This allows visualization tools to make a sensible initial
>> choice for the window and level.
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development