<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>My comment is a positive for its usefulness. While one argument for this convention was about minimizing space, particularly for lots of small images like a collection of 1D spectra, my appreciation has been greatest for the aspect of updating information in MEF files. By this I mean that there is only one place that needs updating. An example would be a collection of CCD images from a mosaic camera, say DECam, where the observer keyword is wrong. To remediate this just requires changing the OBSERVER keyword in the PHU rather than repeating this for all 60 extensions. I think it also encourages data format designers to think about good decomposition much along the design of databases that are well normalized.</div><div><br></div><div>I am not particularly commenting on the legalese description that would be needed in a standard or whether it should remain as a convention. But if it was codified I think it would need to be stronger about distinguishing format keywords from documentary keywords. What I mean is that it would not have occurred to me to save space with TFORM, NAXIS, CRVAL, etc. type of keywords. If it stays as a convention then I would object if words such as "deprecated" or "not recommended" were used. Clearly there is a lot of data with this convention and I would continue to use it in its intended form as a way to encapsulate descriptive metadata about collections in one place but allow application to access them as if they were part of the extension without having to decide that the keyword is missing and then go to the PHU. In other words for this last point, the joining of PHU and EHU belongs in the supporting software and not the science application.</div><div><br></div><div>Frank Valdes, NOAO</div><div><br></div><div>P.S. I really don't like the suggestion that multiple "images", say traditional CCD images, which are related should be "packed in a single binary table".</div><div class=""><div><br><blockquote type="cite" class=""><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">From: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">William Pence <<a href="mailto:William.Pence@nasa.gov" class="">William.Pence@nasa.gov</a>><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">Subject: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class=""><b class="">Re: [fitsbits] start of Public Comment Period on the INHERIT convention</b><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">Date: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">June 23, 2015 at 11:56:57 AM MST<br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">To: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">FITSBITS <<a href="mailto:fitsbits@nrao.edu" class="">fitsbits@nrao.edu</a>><br class=""></span></div><br class=""><div class="">I share many of the concerns that others have expressed here about promoting the INHERIT convention into the FITS Standard.<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">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?<br class=""><br class="">-Bill<br class=""></div></blockquote></div><br class=""></div></body></html>