[MINC-users] mincaverage -avgdim result header

[Alex Zijdenbos]

Hi Peter,

Thanks - I think I understand the reasoning, but do have some issues
with it :) I understand the point that an "image" operation should not
mess up non-image variables; but what would be the meaning of a
"dimension" variable that is not related to (or indexes) an "image"?
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.

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. For instance, the
mincinfo man page says:

-image_info
              Print  out  the default general information about the file. This
              information includes the type, sign and range of the pixel data,
              the  order  of  the  dimensions, and a list of dimensions giving
              name, length, start and step for each one.

which implies it refers to "the file", not "the image variable"; while
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").

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).

-- Alex

On Sat, Mar 24, 2012 at 12:35 AM, Peter Neelin <peter.neelin at gmail.com> wrote:
> Hi Alex,
>
> On Mar 23, 2012 11:16 AM, "Alex Zijdenbos" <zijdenbos at gmail.com> wrote:
>> I just noticed that 'mincaverage -avgdim' leaves lots of header
>> information in the resulting average for the dimension it averaged
>> out; which then causes trouble with mincinfo and the like. To me this
>> looks like a bug in mincaverage, in that when using -avgdim <dim> it
>> doesn't properly clean up the <dim>-related header attributes.
>
> Minc and netcdf allow for any number of dimensions to exist in the file.
> They are only relevant to the image data if they index the "image" variable
> in minc. mincaverage is removing the time dimension from the image
> variable, but it leaves the dimension itself alone. If other variables
> exist in the file, then they may be indexed by the time dimension. It might
> be argued that mincaverage should do something magical to all variables
> indexed by one of the dimensions (time in this case), but it would be
> rather arbitrary to average any variable in the file along that dimension.
> The contract of mincaverage is simply to average image data. Other data is
> left untouched.
>
>> So that looks right; we seem to have lost the time dimension. However,
>> using this mincinfo call:
>>
>> $ mincinfo -dimnames -dimlength time test_pet_avg.mnc
>> time xspace yspace zspace
>
> I don't think that this is what you want - this asks for all the dimensions
> in the file, which is what you are given. You should be using the -vardims
> option with "image" as the argument instead. This will tell you which
> dimensions are indexing the image variable. This is what mincinfo
> -image_info does.
>
> So bottom-line: I don't think that it is a bug - I think that it is doing
> the most appropriate thing. (Of course, I wrote it, so I would think that -
> you are free to disagree and change the contract/requirements if it suits
> you, but please bear in mind that minc is designed around a general file
> format and is intended to be extensible - I think that general-purpose
> tools like mincaverage should honour that intent and not mess up non-image
> data in the file.)
>
> Hope this helps.
>
> Peter
> --
> Peter Neelin
> peter.neelin at gmail.com
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>