Posted by
Frederic V. Hessman on
Apr 23, 2008; 2:51pm
URL: http://imagej.273.s1.nabble.com/Re-Multi-image-FITS-file-tp3696394p3696399.html
>> Since Tom's nom.tam.fits package does all of this and more and
>> since he's adopted ImageJ for use by the stand-alone SkyView
>> package, we should ask Tom about adopting what he's done for use by
>> normal ImageJ users. The downside is forcing uses to insure that
>> they've got a copy of Tom's packages - since we're using ImageJ for
>> school classes, the fewer constraints we put on the use of ImageJ
>> the better, so a native ImageJ solution which is good enough for
>> most ImageJ users would be preferable.
>> - suggestion #2a: Extend the default FITS readers and
>> writers to handle the simplest multi-header-data-unit cases (DO-ABLE)
>> - suggestion #2b: Promise Tom a bottle of wine if he'll
>> adapt his nom.tam.* packages for normal ImageJ users (EASY FOR US
>> TO SAY)
> Is the concern that you want everything to go in a single class in
> the anonymous package the way that simple plugins are done?
> The first seems a bit painful -- probably the easiest way to put
> everything in a single class is to have it include set of static
> nested classes which mimic the current structure as separate classes
> in the nom.tam.fits package. If that works it's a pretty
> straightforward translation. If it really needs to be a single
> class file, then it's a lot more work.
No, I was just trying to make it easier to install for people with no
idea where their jar files are....
> Or that it's OK to have separate classes but the FITS package is too
> large?
> If the size of the package is an issue then one could trim the it by
> deleting all of the table handling which is the bulk of the FITS code.
This would be a good idea, but I admit that brutal functionality is
more important that file size or easy if installation.
> Or is it just issues of how to translate between the internal and
> FITS representations?
No, you've probably taken care of this with your SkyView port of
ImageJ, but basically I imagine...
- simple 1-D or 2-D FITS -> ImagePlus with header in the image's
"Info" property
- simple 3-D FITS -> ImageStack with one header in the ImagePlus's
"Info" property
- simple 1-D or 2-D multi-header FITS with the same dimensions->
ImageStack with multiple headers in the slice labels
- multi-header FITS with datasets of different dimensions ->
different ImagePlus's/Stack's as above.
> Finally, if we can identify where the image and header data are
> available (or are supposed to be placed) within ImageJ, the actual I/
> O is pretty straightforward.
Simple: the ImagePlus headers are in the "Info" property; the
ImageStack headers are in the individual slice labels.
Once the headers are placed in these standard storage places, the rest
is easy. Tricky is only the I/O (FITS -> ImageJ and ImageJ -> FITS)
given that FITS files can be so different.
> Alas I don't drink wine --
How about a large bar of swiss chocolate..... ;-)
Rick
------------------------------------------------------------------------------------------------
Dr. Frederic V. Hessman
[hidden email]
Institut für Astrophysik Tel. +49-551-39-5052
Friedrich-Hund-Platz 1 Fax +49-551-39-5043
37077 Goettingen Room F04-133
http://www.Astro.physik.Uni-Goettingen.de/~hessman-------------------------------------------------------------------------------------------------
MONET: a MOnitoring NEtwork of Telescopes
http://monet.Uni-Goettingen.de-------------------------------------------------------------------------------------------------