[MINC-users] mincaverage -avgdim result header

[Alex Zijdenbos]

On Mon, Mar 26, 2012 at 9:26 AM, Vladimir S. FONOV
<vladimir.fonov at gmail.com> wrote:
> Hello,
>
> On Sun, Mar 25, 2012 at 1:47 PM, Peter Neelin <peter.neelin at gmail.com> wrote:
>> 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.
>
> This just blew my brain...
>
> 1. what about minc2 - does one have to use HDF5 calls to work with it ?

This was one of my questions as well. We were discussing the
"dimension" variable; in my mind that was actually a MINC extension to
NetCDF, like the 'xspace' or 'acquisition' variables. But from what
Peter describes, and what the NetCDF documentation states, "dimension"
is actually a (pre-existing) NetCDF variable. In that context I can
see how we may want to retain the NetCDF concept behind that. But I
was also wondering how this works in HDF5 - does the same still apply?

> 2. practical observation - most minc users don't  care/read minc API
> documentation. For them it is just another file format, like nifti or
> nrrd. Most of the high-level perl code that I've seen uses system
> calls to minc tools to work with the files. Does it mean that this is
> incorrect approach?

I hope not - I for one would have to throw out around 200,000 lines of
perl code if it were:-] From the beginning of this discussion I was
also thinking about the larger community of MINC users. Like you say
the vast majority of those only use the library of MINC tools and
don't actually code using the MINC API; so to them MINC really is a
file format like NIFTI (hopefully better). And from that perspective,
the fact that a core MINC tool like mincinfo with '-dimlength' or
'-dimnames' may not return what the user expects, is a problem. The
learning curve for MINC is already quite steep, and this type of
confusion doesn't help MINC in any popularity contest.

Now in practice I do think that this could be addressed by clarifying
things in the documentation; and/or adding perhaps some convenience
options to tools like mincinfo (e.g., mincinfo -image_dimnames). I
would be curious to know if there is anybody out there who may have
used 'mincinfo -dimnames' with the express purpose of finding
non-image dimensions?

At the more philosophical level, I have been wondering about MINC as
only adding functionality to NetCDF (which is the way Peter developed
it), or as a stand-alone file format encapsulating it; and whether
there is any difference in these philosophies between MINC1 and MINC2
in this respect. Is MINC2 more encapsulating to HDF5, as MINC1 is to
NetCDF? That's probably more a minc-dev discussion btw.

-- A