Re: Multi image FITS file

[Leonard Sitongia]

There was a posting last year about this.

> *From:* Soo Hoo Tom K CTR AFRL/DESM <[log in to unmask]
> <https://list.nih.gov/cgi-bin/wa?LOGON=A2%3Dind0704%26L%3DIMAGEJ%26P%3DR6240%26I%3D-3>>
> *Subject:* Multi image FITS file
>
> Does ImageJ support or is there a plugin available that opens a
> multiple image FITS file, like SAOImage DS9's open 'FITS Multiple
> Extension Data Cube' capability?
>
I'm interested in implementing a plugin to handle this.  Tom McGlynn's
FITS I/O library can handle this type of data cube, so I'm looking at
using it.

The obvious approach is to create an Image Sequence from the data cube.  
Is that reasonable?  Is it consistent with how other plugins handle data
cubes (are there any)?  What about multiple headers?  My FITS data cubes
have one header extension for each image extension.

--
==Leonard E. Sitongia
   High Altitude Observatory
   National Center for Atmospheric Research
   P.O. Box 3000 Boulder CO 80307  USA
   [hidden email]  voice: [phone]  fax: [phone]

[Frederic V. Hessman]

On 19 Apr 2008, at 1:18 am, Leonard Sitongia wrote:

> There was a posting last year about this.
>
>> *From:* Soo Hoo Tom K CTR AFRL/DESM <[log in to unmask] <https://list.nih.gov/cgi-bin/wa?LOGON=A2%3Dind0704%26L%3DIMAGEJ%26P%3DR6240%26I%3D-3 
>> >> *Subject:* Multi image FITS file
>>
>> Does ImageJ support or is there a plugin available that opens a  
>> multiple image FITS file, like SAOImage DS9's open 'FITS Multiple  
>> Extension Data Cube' capability?
>>
> I'm interested in implementing a plugin to handle this.  Tom  
> McGlynn's FITS I/O library can handle this type of data cube, so I'm  
> looking at using it.
>
> The obvious approach is to create an Image Sequence from the data  
> cube.  Is that reasonable?  Is it consistent with how other plugins  
> handle data cubes (are there any)?  What about multiple headers?  My  
> FITS data cubes have one header extension for each image extension.

I've been playing with the idea of extending the standard FITS class  
in ImageJ to cover the obvious cases.   A strong constraint is the  
handling of FITS header info in ImageJ: normal ImagePlus's have a copy  
of the FITS header in the Info property and ImageStack's in the slice  
label.   This is certainly not an optimal solution, but can be made to  
work (constant checking for images versus stacks and reading and  
writing into the image info or stack label String).   For instance, my  
Astronomy plugin jar has a Fits class which will let you manipulate  
FITS headers in ImagePlus's and ImageStack's as String arrays - simple  
and crude, but effective.  However, there's no non-plugin way to write  
this info back to a file given that the default FITS writer ignores  
the present FITS header, thus

        - suggestion # 1: Make the default FITS writer at least write the  
contents of the present FITS header for a simple ImagePlus (QUICK &  
SIMPLE)

(otherwise one has to use a separate plugin).

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)

The other problem is that ImageJ still won't let you calibrate each of  
the axes individually (the microscope assumption is that the 2-D  
images have axes in the same physical space), whereas N-dimensional  
FITS images can easily have N different axes.  Taking care of this  
problem would be a great future upgrade for ImageJ, since there are  
people out there using ImageJ for things like sonograms and such.  The  
present calibration would be OK for 3-D images with one FITS header if  
each axis had it's own unit (right now there's just a single, global  
unit like "pixels") but certainly isn't prepared for multi-header FITS  
images (I have no idea what TIFF images are like in this respect).  If  
only people doing astronomy are worried about this issue, then we'll  
have to have separate plugins which read and write FITS headers and  
which may get out-of-sync with the less-general Calibration.

        - suggestion #3: Extend Calibration to handle independent axes  
instead of the present historical mix of 2-D imaging and video-stacks  
(NICE-TO-HAVE)

Rick

------------------------------------------------------------------------------------------------
Dr. Frederic V. Hessman     [hidden email]
Institut für Astrophysik          Tel.  [phone]
Friedrich-Hund-Platz 1         Fax [phone]
37077 Goettingen                 Room F04-133
http://www.Astro.physik.Uni-Goettingen.de/~hessman
-------------------------------------------------------------------------------------------------
MONET: a MOnitoring NEtwork of Telescopes
http://monet.Uni-Goettingen.de
-------------------------------------------------------------------------------------------------

[Frederic V. Hessman]

>> 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.  [phone]
Friedrich-Hund-Platz 1         Fax [phone]
37077 Goettingen                 Room F04-133
http://www.Astro.physik.Uni-Goettingen.de/~hessman
-------------------------------------------------------------------------------------------------
MONET: a MOnitoring NEtwork of Telescopes
http://monet.Uni-Goettingen.de
-------------------------------------------------------------------------------------------------

[Leonard Sitongia]

Frederic V. Hessman wrote:
>> Alas I don't drink wine --
>
> How about  a large bar of swiss chocolate..... ;-)
>
> Rick
And a box of Boulder's own Celestial Seasonings tea from me!  :-)

--
==Leonard E. Sitongia
   High Altitude Observatory
   National Center for Atmospheric Research
   P.O. Box 3000 Boulder CO 80307  USA
   [hidden email]  voice: [phone]  fax: [phone]

[Leonard Sitongia]

Frederic V. Hessman wrote:

>
> The other problem is that ImageJ still won't let you calibrate each of
> the axes individually (the microscope assumption is that the 2-D
> images have axes in the same physical space), whereas N-dimensional
> FITS images can easily have N different axes.  Taking care of this
> problem would be a great future upgrade for ImageJ, since there are
> people out there using ImageJ for things like sonograms and such.  The
> present calibration would be OK for 3-D images with one FITS header if
> each axis had it's own unit (right now there's just a single, global
> unit like "pixels") but certainly isn't prepared for multi-header FITS
> images (I have no idea what TIFF images are like in this respect).  If
> only people doing astronomy are worried about this issue, then we'll
> have to have separate plugins which read and write FITS headers and
> which may get out-of-sync with the less-general Calibration.
>
>     - suggestion #3:        Extend Calibration to handle independent
> axes instead of the present historical mix of 2-D imaging and
> video-stacks (NICE-TO-HAVE)

Wayne added some support for this in 1.39e, kindly in response to my
raising this issue.  He had said:

> In ImageJ 1.39e (attached), I added setXUnit(String),
> setYUnit(String), setZUnit(String), getXUnit(), getYUnit() and
> getZUnit() methods to the Calibration class. These methods are
> currently not used anywhere in ImageJ.
I haven't checked to see if this is in the official release.

--
==Leonard E. Sitongia
   High Altitude Observatory
   National Center for Atmospheric Research
   P.O. Box 3000 Boulder CO 80307  USA
   [hidden email]  voice: [phone]  fax: [phone]

[Leonard Sitongia]

Frederic V. Hessman wrote:
>
> I've been playing with the idea of extending the standard FITS class
> in ImageJ to cover the obvious cases.   A strong constraint is the
> handling of FITS header info in ImageJ: normal ImagePlus's have a copy
> of the FITS header in the Info property and ImageStack's in the slice
> label.
I'm writing a Plugin to read my Multiple Extension Data Cube.  I'm using
the approach of Stack slices.  However, when I put the header as a
string in the slice label, I see the lines of the header in the text
area above the image.  And, when I Show Info, I see the info that a
non-FITS file usually has.  I'm adding the header in:

                    stack.addSlice(headerString.toString(), imp);

I don't see how it is done in FITS_Reader.  I see in Info.getImageInfo
how the infoProperty is obtained from the slice label for a Stack.  I
must be putting the header into the wrong place.

Thanks for any help!

--
==Leonard E. Sitongia
   High Altitude Observatory
   National Center for Atmospheric Research
   P.O. Box 3000 Boulder CO 80307  USA
   [hidden email]  voice: [phone]  fax: [phone]

[Leonard Sitongia]

Leonard Sitongia wrote:
>
> I don't see how it is done in FITS_Reader.  I see in Info.getImageInfo
> how the infoProperty is obtained from the slice label for a Stack.  I
> must be putting the header into the wrong place.
Pilot error.  :-)  I wasn't putting a newline at the end of each line,
so I saw only the first line or so.  I have it working now.

--
==Leonard E. Sitongia
   High Altitude Observatory
   National Center for Atmospheric Research
   P.O. Box 3000 Boulder CO 80307  USA
   [hidden email]  voice: [phone]  fax: [phone]