[MINC-users] mincaverage -avgdim result header

[Peter Neelin]

On Mar 26, 2012 10:18 AM, "Alex Zijdenbos" <zijdenbos at gmail.com> wrote:
>
> On Mon, Mar 26, 2012 at 9:26 AM, Vladimir S. FONOV
> <vladimir.fonov at gmail.com> wrote:
> > 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 netcdf, you have variables that are indexed by dimensions. So any
multi-dimensional data is indexed by a set of dimensions which clearly
defines the relationship between variables. Variables also have attributes.
Minc uses a variable with the same name as a dimension to describe the
sampling of the dimension (actually, that might be a netcdf convention -
I've forgotten - but minc uses the shorthand of start and step for regular
dimensions).

If you only have image dimensions in a file, then you cannot represent any
other multi-dimensional data in that file.

> 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?

It's been years since I looked at HDF, but they originally just lifted the
netcdf interface because their own was far too complicated to use in real
life (I'm guessing at their motivation). They layered the netcdf concepts
on top of their own data format. I assume that HDF5 carries this forward.

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

My apologies  for putting this functionality into mincinfo and mincreshape.
Mincinfo exposes low-level netcdf and mincreshape exposes low-level minc
"image conversion variables". I should have hidden that in some other
command-line tools to avoid causing confusion. Don't use mincinfo with
options unless you understand netcdf (look at the netcdf library, I believe
the mincinfo options are just plain wrappers to the netcdf functions). And
watch out for using mincreshape's auto-magical properties for flipping,
etc. (I've watch Andrew try to explain those a few time.) Many apologies
for those. It just seemed so damn convenient to expose library routines
that I wrote to make it easy for Alan to use minc in ROI and other PET
analysis tools of the early 90's. I should have left them hidden.

Information hiding. I should have read Parnas twenty years ago. Sigh.

(Hey - minc is 20 years old this summer, I think - Alan went on a 5-week
canoe trip in the Yukon and minc was born. Wow, we're all getting old!)

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

I'll leave you folks to that discussion.

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