Coordinate systems

[Curtis Rueden]

Hi everyone,

One of ImageJDev's goals is to generalize the hyperstack model to support N-dimensional image organizations (see http://imagejdev.org/proposal, Aim IC). There are many domains across which image planes can be sampled: multi-spectral emission, multi-spectral excitation, polarization, lifetime decay histograms, high-content samplings (screens/plates/wells)... and surely many more in various scientific disciplines. A multidimensional data model would provide support for all of these and more without any code changes to support emerging acquisition modalities.

Frederic Hessman suggested that it might be nice for ImageJ to support other structural image metadata, such as coordinate systems and map projections. Ideally I agree, but it is a matter of effort and resources. One possibility would be some sort of integration with the VisAD numerical data visualization and analysis library (http://www.ssec.wisc.edu/~billh/visad.html). VisAD supports a variety of generalized metadata including coordinate systems, domain sets (including both gridded and unordered) and error estimates. It originally emerged from the earth and space sciences field, but was designed with a very general data model capable of supporting scientific data from any discipline.

At the least, we should be cognizant of these ideas as we work on the software architecture, so that another redesign is not necessary to include such features in the future.

-Curtis

[was: ImageJ development involvement/contributions]

On Mon, Dec 14, 2009 at 12:15 PM, Frederic V. Hessman <Hes...@astro.physik.uni-goettingen.de> wrote: 

I'm not complaining, just thinking about what would be possible if ImageJ
supported all the data models and world coordinate systems of just the
FITS standard (generalized hyperstacks, highly non-linear coordinates,
all known map-projections).

... IMHO you should not

say that a certain model is very primitive unless you have come up with a

superior model...

I'd be happy to ablidge.   These things were taken care of (literally) ages ago in astronomy - being a small, global community, we needed good standards early on:

- generalized hyperstacks (1981)
       http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1981A%26AS...44..371G&db_key=AST&high=3db47576cf05893

- generalized tables (1995)
       http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1995A%26AS..113..159C&db_key=AST&high=3db47576cf06210

- generalized coordinates (2002)
       http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=2002A%26A...395.1061G&db_key=AST&high=3db47576cf06933

- every known map-projection (2002)
       http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=2002A%26A...395.1077C&db_key=AST&high=3db47576cf06933

Of course, this is just a data-representation made for storage (that's what the FITS standard is all about), but the appropriate properties of a generalized data model are well illustrated by the constraints  placed on being able to store such data.  The FITS header mechanism is primitive but easy to use and makes the bookkeeping associated with generalized hyperstacks/tables/coordinates/world-coordinate-systems fairly manageable (and is much more powerful than that used in TIFF or JPEG).

Since most of you are interested in plain imaging (even if it is n-dimensional), it was natural that ImageJ only supported the simplest data forms, but once you get to know and love (!) ImageJ, you want to be able to do other things as well.

[Gabriel Landini]

On Thursday 24 December 2009, Curtis Rueden wrote:
> Frederic Hessman suggested that it might be nice for ImageJ to support
> other structural image metadata, such as coordinate systems and map
> projections. Ideally I agree, but it is a matter of effort and resources.

It is great idea, but we should perhaps estimate to what degree current users
would benefit from alternative coordinate systems and projections at this
stage of the ijx development. I guess that it would not be a trivial task (but
perhaps I am very wrong).

This could attract a large number of new users and contributors from the
Astronomy/Geography sciences. Is that a priority at this particular point?

If it is, it might be worth considered finding a group of additional
contributors -rather than the current team- to contribute on implementing
these additional features, so the ijx development is not sidetracked from its
main goals.

It might be a matter of contacting the right people, perhaps through Frederic,
who brought up this issue?

Merry Christmas

Gabriel

[Gabriel Landini]