<div dir="ltr"><div><div><div><div><div><div><div><div><div>No, I agree that it would be unwise to put mosaics into cubes.<br></div>I was just asking the question; it's been answered.<br><br></div>Refarding the primary header: I also agree that it is extremely<br></div>useful to have pertinent information in the header of a null primary.<br></div>We do that for our event lists, too.<br></div>But that doesn't mean it can't or shouldn't be repeated in the subsequent<br></div>headers. Our custom is to put a summary of essential keywords in the<br></div>primary header, then all the details in the subsequent extension headers.<br><br></div>Cheers,<br><br></div>  - Arnold<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>Arnold H. Rots                                          Chandra X-ray Science Center<br>Smithsonian Astrophysical Observatory                   tel:  +1 617 496 7701<br>60 Garden Street, MS 67                                      fax:  +1 617 495 7356<br>Cambridge, MA 02138                                         <a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>USA                                                   <a href="http://hea-www.harvard.edu/~arots/" target="_blank">http://hea-www.harvard.edu/~arots/</a><br>--------------------------------------------------------------------------------------------------------------<br><br></div></div></div>
<br><div class="gmail_quote">On Wed, Jul 1, 2015 at 2:30 PM, Frank Valdes <span dir="ltr"><<a href="mailto:valdes@noao.edu" target="_blank">valdes@noao.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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.<div><br></div><div>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.<span class="HOEnZb"><font color="#888888"><br><div><br></div><div>Frank</div></font></span><div><div class="h5"><div><br></div><div><br><div><div>On Jul 1, 2015, at 11:07 AM, Arnold Rots wrote:</div><br><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div><div>I am returning to Bill's sentiment - it saves me from rehashing the arguments<br></div>(hm, this might be considered a form of inheriting these comments:-)<br><br></div>I think INHERIT is a bad idea, in short, because of the complications when<br></div>interpreting, modifying, and copying HDUs. As the standard currently stands,<br></div><div>each HDU is self-contained and I think that is a good thing.<br></div><div><br></div>As an aside, I wonder how many of the multi-image FITS files could be combined<br></div>into an image cube.<br><br></div>Cheers,<br><br></div>  - Arnold<br></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>Arnold H. Rots                                          Chandra X-ray Science Center<br>Smithsonian Astrophysical Observatory                   tel:  <a href="tel:%2B1%20617%20496%207701" value="+16174967701" target="_blank">+1 617 496 7701</a><br>60 Garden Street, MS 67                                      fax:  <a href="tel:%2B1%20617%20495%207356" value="+16174957356" target="_blank">+1 617 495 7356</a><br>Cambridge, MA 02138                                         <a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>USA                                                   <a href="http://hea-www.harvard.edu/~arots/" target="_blank">http://hea-www.harvard.edu/~arots/</a><br>--------------------------------------------------------------------------------------------------------------<br><br></div></div></div>
<br><div class="gmail_quote">On Tue, Jun 23, 2015 at 2:56 PM, William Pence <span dir="ltr"><<a href="mailto:William.Pence@nasa.gov" target="_blank">William.Pence@nasa.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I share many of the concerns that others have expressed here about promoting the INHERIT convention into the FITS Standard.<br>
<br>
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>
<br>
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>
<br>
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>
<br>
-Bill<div><div><br>
<br>
_______________________________________________<br>
fitsbits mailing list<br>
<a href="mailto:fitsbits@listmgr.nrao.edu" target="_blank">fitsbits@listmgr.nrao.edu</a><br>
<a href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits" rel="noreferrer" target="_blank">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>fitsbits mailing list<br><a href="mailto:fitsbits@listmgr.nrao.edu" target="_blank">fitsbits@listmgr.nrao.edu</a><br><a href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits" target="_blank">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a><br></blockquote></div><br></div></div></div></div></div><br>_______________________________________________<br>
fitsbits mailing list<br>
<a href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a><br>
<a href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits" rel="noreferrer" target="_blank">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a><br>
<br></blockquote></div><br></div>