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

[Tom McGlynn (NASA/GSFC Code 660.1)]

[Responses reordered.]
> On 07/01/15 08:46, Tom McGlynn (NASA/GSFC Code 660.1) wrote:
>> Peter Weilbacher wrote:
>>> On Wed, 1 Jul 2015, THIERRY FORVEILLE wrote:
>>>
>>>> "Frank Valdes" <valdes at noao.edu> writes
>>>> ----- Original Message -----
>>>>> 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".
>>>>>
>>>> The flip side is that doing that covers the need which you
>>>> describe, and is
>>>> already fully part of the standard.
>>>>
>>>> There is a non-trivial cost (in additional code in FITS readers
>>>> that needs
>>>> writing and, more importantly, maintaining) to multiple solution to
>>>> the same
>>>> problem, which I see as enough of a reason to say no to INHERIT.
>>> On the other hand, reading and writing bintable data is less efficient
>>> than writing image data. So when /using/ it, it creates extra overhead.
>>> So depending on the use-case, writing MEF instead of bintables does
>>> make
>>> a lot of sense, and that would benefit from INHERIT. (But since for
>>> those purposes, INHERIT can be implicitly be assumed for the case at
>>> hand, so that's a similarly weak argument for INHERIT as yours is
>>> against. ;-))
>>>
>>>     Peter.
>> Since the binary encoding is the same for the actual image data, the
>> only
>> difference here is in the header information,.  For very large images
>> it won't
>> matter much because the image data will dominate. For small images it
>> won't
>> matter much because the overhead of locating and opening the files will
>> dominate....

>
> William Thompson wrote:
> One can argue about which is better, binary tables or IMAGE
> extensions, but the fact of the matter is that data providers do not
> necessarily follow your preferences.  I know of a lot of groups who
> have great resistance to using binary tables.  We shouldn't reject
> something simply because we think it should be done with binary tables
> instead.

I don't think anyone's suggesting that users not write binary tables or 
image extensions or even limiting the use of INHERIT as a convention. 
However if we add it as a standard element of FITS that is -- to my mind 
at least -- an implicit endorsement of it as a good and recommended 
technical solution.  A duplication of functionality with existing 
capabilities would certainly be something to be considered in making 
that evaluation.  If the bias against the existing capability is based 
upon a misapprehension then we should clarify that and understand what 
the real benefits are.  Peter's concerns with the efficiency of binary 
tables might arise from aspects or use cases that I've not considered. 
But if lots of people think that binary tables are inefficient and 
that's not the case, then maybe the answer is education rather than 
adding complexity to the standard. Presumably the role of this 
discussion period should be to thrash out the pluses and minuses of 
suggested changes.

I want to see some clear benefit for <any> change to the standard.  In 
this case, where it breaks the long standing decoupling of FITS HDUs so 
that the processing of FITS files needs to be significantly rethought, 
I think that benefit should be substantial before we endorse it.

     Tom