Question about FITS write behavior

[pllim]

From what I understand in io_fits, save_as_file() only saves the extension being displayed, not the entire HDU list associated with the displayed image. What was the original intention of this functionality? Just curious.

[ejeschke]

@pllim, that is correct. This function is not expected to be used frequently, but just to provide some means to create simple FITS files. If one wanted to do something more sophisticated it is expected that they would use astropy, etc. to create a more structured FITS file.

[pllim]

Okay. In the future, if ginga wants to support plugins that modify the buffer and write a modified image back out, it needs to support retaining all the extensions, while changing the data/header of the modified extension(s). For now, I'll write that up myself. Thanks for the clarification.

[ejeschke]

More generally, it was a deliberate decision to abstract from the FITS format in Ginga. I'm not fully aware of how well we've managed to accomplish this, but the basic idea is to support any sort of format where the pixel data can be represented in a numpy-like array. That way new formats, ad-hoc formats, etc. can be readily supported. There was a talk at the last ADASS where a guy got ginga loading his HDF5-based "FITS replacement" with only modifying a half-dozen lines of ginga.

I try to extend this as well to WCSes. So AstroImage objects just marry a numpy array with a generic WCS object and some common convenience methods. Thus the pluggable io and wcs classes.

I think you can accomplish what you want by attaching other items to the image that would follow it around. You can use the metadata set/get methods on the image to add arbitrary data.

[ejeschke]

Note that you do have to keep in mind the size (length) of the datasrc objects used to hold the images. There is one datasrc for each channel, and the size is set based on the 1) saved channel preference, 2) saved preference for generic "Image" channel, 3) program default (in that order). Once an image is ejected from the datasrc it will (should) be dereferenced and collected. The Thumbs and Contents plugins will retain a future to reload the image from the file, but that will not contain any unsaved mods.

[pllim]

Yes, I am aware, thanks. I have numImages=100 in my ~/.ginga/channel_Image.cfg and I do not expect to have more than 20 multi-extension FITS with [PRI, SCI, ERR, DQ] combo to be loaded at once. So hopefully that will take care of buffer resetting (provided the machine has enough memory). A typical use case should only involve modifying the SCI extension anyway, and not on all the 20 images.

But just in case, what is the best way to check within a plugin if its Datasrc still have something in memory or needs reloading?

[ejeschke]

To check, you need to know the image name and channel name. Something like:

chinfo = self.fv.get_channelInfo(chname)
if imname in chinfo.datasrc:
    ...

The image name is set in the metadata of the image object and can be retrieved by image.get('name'). Channel name can be retrieved by a call like:

chname = self.fv.get_channelName(self.fitsimage)

[pllim]

Okay, thanks!