[MINC-development] Welcome

[Andrew Janke]

On Mon, 11 Nov 2002, Robert VINCENT wrote:

> To test my understanding of the current state of things, I'd like to see
> if there is consensus about the following claims:
>
> 1. MINC could be better documented.
> 2. MINC would benefit from a more complete set of automated tests.
> 3. MINC requires extensions to support files larger than core.
> 4. MINC requires extensions to support files larger than 2 GB.
> 5. MINC requires extensions to run on 64-bit architectures.
> 6. Given #3, block-structuring MINC data will improve file access speed.
> 7. MINC must remain backward compatible with existing data.

I think that should at least keep you busy for a few weeks... I don't quite
follow #2 though, you mean more mincxxxxx progs? or something more specific?

Take a look in /software/source/minc_dev for a few things I am working on
currently.  However at some stage we need to stop re-inventing the wheel and use
something like PDL (which now has a working netCDF module that works with MINC!
-- well as far as I've tested it anyhow) or perish the thought 'Numeric Python'
:).

I do agree with you about digging around netCDF and seeing what is available
first before re-inventing the wheel. netCDF as far as I understand is already
network transparent. To this end, netCDF can also read many other formats like
HDF so there is also no reason as to why we need limit outselves to the netCDF
version of network transparency.

As such perhaps we need to make MINC more 'netCDF'ish' :). In order that many of
the other freeware netCDF viewers out there can read MINC files without to much
munging of the header.

ncview come to mind:
   http://meteora.ucsd.edu/~pierce/ncview_home_page.html

re: Compression: I seem to remember reading somewhere about netCDF and
compression, the consensus was that netCDF probably shouldn't do this as HDF
already does it.  (remember, netCDF can read HDF tranparently).

> What other major or minor tasks are obvious to people?

My biggest wish has been that some functionality can be added to the core MINC
libs (voxel-loop more specifically) such that MINC can take advantage of
multiple processors (bewoulf!). netCDF supports concurrent access of files (RW)
so there is no reason as to why MINC shouldn't do parallell ops when it can.
(this would mean most of the minxxxx progs could be sped up to a factor of X).

Thanks for the oportunity to get on a soap-box.


--
Andrew Janke   ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor )
Australia->University of Queensland->Centre for Magnetic Resonance
Work: +61 7 3365 4100 || Home: +61 7 3800 4042