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

[Andrew Janke]

> Could be handled by wrapper scripts; would be ugly either
> way.

Indeed and very much the exception from the norm. From how you
describe the problem it sounds like poorly "ranged" data to begin
with. I take my "mincnorm" hammer to all such data and reset ranges to
histogram pCT's. This is done in all pre-processing.

> On that note - how does voxel_loop divvy things up on >3D volumes?
> Still per 2D slice? Or per unit of the slowest-varying dimension
> (i.e., a volume)?

Per 2D slice (sort of). In essence voxel_loop takes an input buffer of
data that will end up fitting in the output as a slice. (or image as
Peter calls it).

> But I'm a bit confused about the label volume argument. Presumably if
> MINC would properly handle label volumes (and Vlad mentioned that
> support for that already exists in MINC2), the slice-based scaling
> issue would have to be dealt with?

Well no, because in the case of label volumes, the voxel value is the
real value. So slice scaling isn't "turned off" it just doesn't exist.

> But from what I gather this would (at minimum) require control over
> the size of the sliding window in voxel_loop; possibly even on a
> per-volume basis. I have no idea how feasible that would be

>From the short conversation I just had with Peter about this I'd say
doable but it'd destroy what voxel_loop originally set out to do.

> sounds daunting (and that is recalling the meeting at MNI where Peter
> first presented his new invention "voxel_loop", and very few - if any
> - of us were able to follow at the time :-) )

Hrmpfh! why wasn't I invited??  Probably was still in 1st year uni.  I
can claim that I have broken voxel_loop and caused Peter to have to
add a few extra functions for mincstats...  Hardly a claim to fame.


a