[MINC-development] Welcome

[John G. Sled]

Hi Bert,

I'm back in Toronto and have had a chance to talk to my colleagues at
MICe about the MINC meeting.  We are pleased that the BIC is committed
to improving the MINC format and we are keen to collaborate with you
on this project.  As discussed at the meeting, I think this mailing
list should be a good way to collect the ideas of interested parties
so as to put together a design proposal (MINC 2.0?).  I had suggest we
meet in Montreal in December to go over the details; however, that
doesn't seem feasible at this point.  Can we set a meeting for mid
January instead?

I have a few additions to your list of MINC wishes.

#8  MINC should support a multiresolution representation of the data
that would allow one to efficiently work with data at reduced resolutions.
This has obvious implications for visualization tools, but may also
be an asset in implementing segmentation and registration schemes 
that are multiscale.  One proposal for handling this is to use a 
Harr wavelet decomposition.

#9 MINC should internally handle compression in either a lossy or lossless 
manner.

#10 An interesting suggestion that came up at the meeting is that 
the MINC API should also address our interest in remote visualization
by providing network access to data.  In a sense the problems of 
working with out of core data and working with remote data are the 
same.  In principle the API could be set up to make little distinction 
between file:/myfile.mnc and minc://myserver.ca/myfile.mnc

#11 MINC should have an expanded set of languages that it supports.
There is much enthusiasm here for a C++ API that hides some of the
complexity.  At the meeting it was also suggested that a JAVA API would
be a good strategic choice.

#12 The handling of numeric formats should be reexamined.  In the present 
scheme when using volume IO there is one number type for the original file,
another for the in memory volume and a third, either floating point or 
integer, that has meaning to the user.  If this is combined with a 
caching mechanism then it would seem more sensible to cache this
latter type rather than either of the former two.  On a related note,
perhaps it would also be helpful to distinguish between files that 
are meant to be interpreted as integers and those that are not.


A minor comment, on point #4: when MINC is compiled on a 32bit
architecture with the large file operating system flags then it does
work with files larger than 2GB.  I haven't tested this extensively,
but the minc* tools appear to work.


cheers,

John

Hospital for Sick Children
Mouse Imaging Centre
555 University Ave.
Toronto, Ontario
M5G 1X8
Canada

Phone: 416 813-7654 x1438
Fax: 416 813-2208


On Mon, Nov 11, 2002 at 02:39:04PM -0500, Robert VINCENT wrote:
> Hi everyone,
> 
> Welcome to the list.  I thought I'd start off by posting a few guesses
> about the goals for MINC development.
> 
> 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've intentionally used MINC as a blanket term for the file format,
> libraries, and dependant applications.
> 
> Claims #3, #4, and #5 are related but not necessarily completely
> overlapping.  There are probably people running on 32-bit architectures
> who need to process large files, and there are people with 64-bit systems
> that still don't have enough core to process huge files in memory.
> 
> My undertanding is that Jason is currently spending some time on #5,
> making MINC tools run in a 64 bit world on SGI.  The The MICe group seems
> to be focused on #3 and #6.  Has anyone invested much time in these other
> things?  Is anyone aware of work by the NetCDF group to address any of
> these issues?
> 
> What other major or minor tasks are obvious to people?
> 
> Thanks!
> 
> 	-bert
> 
> 
> 
> _______________________________________________
> MINC-development mailing list
> MINC-development@bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>