[fitsbits] start of Public Comment Period on the INHERIT convention

[Arnold Rots]

No, I agree that it would be unwise to put mosaics into cubes.
I was just asking the question; it's been answered.

Refarding the primary header: I also agree that it is extremely
useful to have pertinent information in the header of a null primary.
We do that for our event lists, too.
But that doesn't mean it can't or shouldn't be repeated in the subsequent
headers. Our custom is to put a summary of essential keywords in the
primary header, then all the details in the subsequent extension headers.

Cheers,

  - Arnold

-------------------------------------------------------------------------------------------------------------
Arnold H. Rots                                          Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory                   tel:  +1 617 496
7701
60 Garden Street, MS 67                                      fax:  +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------


On Wed, Jul 1, 2015 at 2:30 PM, Frank Valdes <valdes at noao.edu> wrote:

> Come on (!), talking about alternate formats is not helpful.  DECam is
> generating a huge amount of data (arguably the biggest optical data source
> in the world) on an almost daily basis.  The raw data is an MEF and uses
> INHERIT.  The calibrated data produces MEF with INHERIT.  All mosaic data
> that NOAO has in its archive, -- >10 yrs of Mosaic, > 5 yrs of NEWFIRM,
> DECAM -- is in this format.  I echo that binary tables seems more complex
> to many people and I really agree with Bill T. that people look at the
> primary header first and I've found it very useful (and used in the
> pipeline) to just check the primary header for some information.
>
> The only complications I've encountered is people that have software that
> doesn't support INHERIT.  Making an image cube for a mosaic would be a new
> convention which almost no software (e.g. DS9) would not support.
>
> Frank
>
>
> On Jul 1, 2015, at 11:07 AM, Arnold Rots wrote:
>
> I am returning to Bill's sentiment - it saves me from rehashing the
> arguments
> (hm, this might be considered a form of inheriting these comments:-)
>
> I think INHERIT is a bad idea, in short, because of the complications when
> interpreting, modifying, and copying HDUs. As the standard currently
> stands,
> each HDU is self-contained and I think that is a good thing.
>
> As an aside, I wonder how many of the multi-image FITS files could be
> combined
> into an image cube.
>
> Cheers,
>
>   - Arnold
>
>
> -------------------------------------------------------------------------------------------------------------
> Arnold H. Rots                                          Chandra X-ray
> Science Center
> Smithsonian Astrophysical Observatory                   tel:  +1 617 496
> 7701
> 60 Garden Street, MS 67                                      fax:  +1 617
> 495 7356
> Cambridge, MA 02138
> arots at cfa.harvard.edu
> USA
> http://hea-www.harvard.edu/~arots/
>
> --------------------------------------------------------------------------------------------------------------
>
>
> On Tue, Jun 23, 2015 at 2:56 PM, William Pence <William.Pence at nasa.gov>
> wrote:
>
>> I share many of the concerns that others have expressed here about
>> promoting the INHERIT convention into the FITS Standard.
>>
>> It seems to me that the motivation for using the INHERIT convention to
>> save what typically amounts to less than a few 100K bytes of disk space per
>> file is now greatly diminished from when it was first developed back in
>> 1995, since the cost of disk storage has dropped so dramatically. Also,
>> data providers are now much more comfortable with more efficient ways of
>> packing multiple data arrays into a single binary table (which were only
>> officially approved the year before in 1994), instead of writing each array
>> as a separate image extension. Thus, I think it is questionable whether
>> this convention continues to serve a useful purpose.
>>
>> Implementing this convention in FITS reading and writing software also
>> seems to me to be a rather complex and somewhat ambiguous task.  It is not
>> exactly clear what action should be taken with regard to preserving the
>> inherited keywords during complex data processing operations where the
>> values of some of the inherited keywords may be modified, or when copying
>> an HDU which uses the INHERIT convention into another FITS file.  Because
>> of these complexities, I have never attempted to support the INHERIT
>> convention in the CFITSIO library.
>>
>> So far, all the comments about the INHERIT convention have been quite
>> negative.  Does anyone want to offer any positive comments in support of
>> incorporating this convention into the FITS standard?
>>
>> -Bill
>>
>>
>> _______________________________________________
>> fitsbits mailing list
>> fitsbits at listmgr.nrao.edu
>> https://listmgr.nrao.edu/mailman/listinfo/fitsbits
>>
>
> _______________________________________________
> fitsbits mailing list
> fitsbits at listmgr.nrao.edu
> https://listmgr.nrao.edu/mailman/listinfo/fitsbits
>
>
>
> _______________________________________________
> fitsbits mailing list
> fitsbits at listmgr.nrao.edu
> https://listmgr.nrao.edu/mailman/listinfo/fitsbits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/fitsbits/attachments/20150701/c02f2bbc/attachment.html>