Subject: On final text of IMAGE and Blocking proposals

From: [email-masked]
Date: Mon, 14 Mar 94 11:31:54 +0100

Garching, Mar. 14, 1994

Dear IAU-FWG members,
 I have the following comments on the IMAGE and Blocking proposals
(ref. NRAO FITS archive /fits/documents/proposals/ files
  94980 Jun  4  1992 X_image.ps and  
   2183 Oct  1  1991 FITS_blocking90.txt):

IMAGE extension:
  In table 1 'Mandatory FITS keywords for ... IMAGE extension' the
  values of PCOUNT,GCOUNT are explicitly given as 0,1, respectively.
  On the other hand section 3.1.5 and 3.1.6 state that they 'shall
  contain a non-negtive integer ..' and that 'A simple IMAGE extension
  will have PCOUNT=0 and GCOUNT=1' which imply possible other values
  for PCOUNT/GCOUNT in contradiction with the table. The two options
  for clarification:
   A) Only PCOUNT=0/GCOUNT=1 is allowed (as specified in Table 1).
      In this case section 3.1.5 and 3.1.6 should be reworded to
      state that these shall be the values.
   B) Any non-negative values is allowed.
      This would require the explicit value (0,1) in table 1 to be
      removed.
   I would prefer option A.

Blocking proposal:
   The sentence 'Reading an incomplete FITS logical record should be
   regarded as an end-of-file.' in section 2 is not totally clear.
   It should rather be worded as 'After detection of an end-of-file
   on reading, any incomplete logical FITS record should be disregarded.'

Please be reminded that today (Mar. 14) is the formal deadline for comments
on the explicit wording of the proposals!

Best regards,

Preben Grosbol
Chairman, IAU FITS WG

---

From: [email-masked] (William Pence)
Date: Tue, 15 Mar 94 16:06:06 EST

Regarding the value of PCOUNT and GCOUNT in IMAGE extensions, I
have no strong preference.  My FITSIO package already supports
any non-negative values for these keywords, but it would
be simple to restrict this to PCOUNT=0/GCOUNT=1 if that is
what the community wants.

-Bill Pence

---

From: [email-masked] (Doug Tody)
Date: Tue, 15 Mar 94 14:58:49 MST

Preben, I have reviewed your points (10Mar94) and the current bintable
draft, as well as the comments already posted.  I agree with the comments
already made, so it is unanimous.  None of these points represent any
changes to the proposal, rather they address ambiguities in the draft, and
they are all worthwhile.        - Doug

For reference, the four points were:

    1)	Require that NAXIS1 be the sum of the TFORMs (no implicit padding,
	explicit padding remains possible).

    2)	Extension version (EXTVER) should be 1.

    3)	Clarify use of AUTHOR keyword (this is not restricted to BINTABLE).

    4)	Values other than `T' `F' or NUL for a logical are illegal.