[MINC-users] mincaverage -avgdim result header

[Peter Neelin]

Hi Alex,

On Mar 24, 2012 2:37 PM, "Alex Zijdenbos" <zijdenbos at gmail.com> wrote:

> but what would be the meaning of a
> "dimension" variable that is not related to (or indexes) an "image"?

Well, I can imagine having acquired non-image data along with the scan that
is also indexed by time. Blood activity for PET scans, for example
(although it is unlikely to have the same original sampling in the time
dimension, so it's not the best example since someone would have to
resample the blood data and merge it in); or stimulation-related data for
fMRI (on-off, maybe?). When running minaverage, what should be done with
this kind of data? Delete it, just because it is indexed by time? Average
it? That's rather arbitrary and not what the tool is intended to do.
Another option would be to remove the time dimension if there are no
variables referencing it (excluding the time variable). However, that just
leads to scripts that work sometimes.

> Case in point, I doubt that there are many MINC users out there who
> would realize that 'mincinfo -dimlength' or 'mincinfo -dimnames' does
> not actually say anything about the number of "image" dimensions, and
> I suspect there are many perl/python/other scripts out there (I
> certainly have dozens) that use these exactly these mincinfo calls to
> figure out what/how many dimensions the MINC "image" has - and so from
> what you are saying, those scripts are actually all broken.

Yes, they are. The idea of building on a generalized data format was that
it could be extended. Minc is really just a convention for using netcdf
along with libraries for imaging stuff and utility programs. Minc is not an
abstraction layer that hides netcdf. The expectation is that if you are
going to code at the netcdf level (core minc libraries and anything that
talks about dimensions and variables, like mincinfo) you should understand
basic netcdf. It's not really documented in minc because it's documented in
netcdf.

> At the very least I think this needs clarification in the
> documentation because the distinction you draw between "image" and
> "dimension" I don't think is intuitive or clear.

Yes. It is probably worth making clear that the netcf basics should be
understood, and maybe even re-iterating them somewhere.

> it actually reports on the latter (only). I also looked through the
> MINC2 reference manual, and I couldn't find anywhere where it
> indicates that you may have a "dimension" that is not a dimension of
> the actual image data (it does define "A dimension is simply an axis
> or index along which the data is stored").

That goes along with the general data format thing. I assume that the
netcdf concepts and interface are still documented somewhere.

> In practice, I would suggest that if there is a valid reason why a
> "dimension" should/could exist independent from the "image" variable
> (I still can't think of one), that some of the documentation should be
> improved to make this distinction very clear; but if not, that the
> tool(s) should be modified to consider "dimension" as always tied to
> the "image" (in which case I would argue that the case I described
> consititutes an inconsistent header, because it carries information
> about a dimension that the actual image data doesn't have).

Well, it is up to you guys to decide what you want minc to be. The original
conception was that it was good to allow arbitrary extension as a general
data format, with imaging conventions overlaid. But that generality may be
more annoying that useful, in which case it can be changed to be just an
image format. Then it makes sense to treat all dimensions and variables in
the context of  images. Not sure if that would mess with any existing users
of minc, though.

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