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

[Peter Neelin]

On Wed, Mar 20, 2013 at 6:40 PM, Andrew Janke <a.janke at gmail.com> wrote:
> OK, well from your comment and Vlad's I suspect this is a feature of
> voxel_loop, this is the code that is used in mincmath, minccalc,
> minclookup, .... (pretty much anything in which you can do things
> voxel by voxel across the volumes).

Yup. voxel_loop is designed to be memory efficient (back in the days
when 32 MB was a lot of memory, or something - it's a bit hazy now).

> So if you are keen I'd look into modifying the guts of voxel_loop.
> This will not be easy though as you will have to pretty much destroy
> how voxel loop works (opening a sliding window of a series of files).

I believe that voxel_loop is designed to do no more than an image at a
time. Perhaps it could be modified to slurp up more data in one shot -
not sure how hard that would be.

> You would have to first run through, find your resulting min/max from
> the calculation and then re-run through the data....

You would end up discretizing the data a second time - that's not ideal.

Also, anything like mincresample that does not use voxel_loop would
have to have a custom fix.

Unfortunately for you, all of the minc primitives were designed with
memory limitation in mind and so slice scaling is pretty deeply
entrenched.

I do have a question though - why do you need to keep renormalizing?
It would surprise me if you really cared about the discretization of
continuous data. Is it because minc does not support integer, boolean
or label data? For years, I have felt that this is the big gap in minc
and should really be addressed. If you know that the data is integer
or labels (IDs for which proximity in value means nothing, so
interpolating between 10 and 12 to get 11 is nonsense), don't do nasty
things to it like scale it to real values or interpolate it.

If this is the real issue, then perhaps it would be more useful to
invest energy into a better handling of this data. The advantage is
that reformulating the problem this way allows data representation
decisions to be made on local data and does not require access to the
whole volume - I suspect that the code changes would be easier and
would also benefit the big data people (like Andrew showing off with
his monster volumes :)).

Peter
-- 
Peter Neelin
(peter.neelin at gmail.com)