Subject: Can BSCALE have a physical meaning?

From: landsman at stars.gsfc.nasa.gov (Wayne Landsman (301)-286-3625)
Date: 4 Dec 91 02:35:00 GMT

I am working with a group that making FITS files of linearized,
digitized, (ultraviolet), photographic images.    The dynamic range of these 
images is well-represented by INTEGER*2 data, and we encourage users to work 
with this form of the data so that they can easily assess the uncertainties
in the data, i.e. where they are in the photographic characteristic curve.
(The savings in CPU and disk space for 2048 x 2048 images is also non-trivial.)
However, we also include a BSCALE keyword containing an absolute calibration
value in ergs/cm**2/s/A/pixel.

     The problem is that some FITS readers apply the BSCALE factor to the
data, and then set BSCALE = 1.    The original value of BSCALE is lost
and the user cannot recover the original INTEGER*2 intensities and ultimately
the photographic densities.   So my question is as follows:

    Is BSCALE always simply a numeric scale factor for representing REAL*4 data
using INTEGER*2 numbers?    Or can it have a physical meaning for converting
between two representations of the data?    Should we move or copy the 
absolute calibration value into another keyword besides BSCALE to make sure 
that it is always available to the user?

    Thanks for any suggestions and I apologize for the somewhat anachronistic
flavor of the question...

Wayne Landsman                    landsman at stars.gsfc.nasa.gov
Hughes/STX
(301)-286-3625

---

From: hanisch at stsci.edu (Bob Hanisch,N406,4910)
Date: 4 Dec 91 22:49:44 GMT

>From article <3DEC199122350724 at stars.gsfc.nasa.gov>, by landsman at stars.gsfc.nasa.gov (Wayne Landsman (301)-286-3625):
> 
I have not encountered any usage of BSCALE to represent anything other than
the scale factor for converting integer FITS values back to floating point,
and this is the only real significance attached to the keyword in the FITS 
standard.  I would suggest storing the absolute calibration value using a
separate keyword.

-- Bob Hanisch

---

From: warnock at nssdca.gsfc.nasa.gov (Archie Warnock)
Date: 5 Dec 91 13:57:00 GMT

In article <1991Dec4.224944.7525 at stsci.edu>, hanisch at stsci.edu (Bob Hanisch,N406,4910) writes...
>standard.  I would suggest storing the absolute calibration value using a

I wonder if, perhaps, there ought to be some agreement on what those 
keywords ought to be.  Seems like a common thing to want to store in a 
header.  Certainly those of us who develop image display programs would 
like to have the physical conversion factors available, so that pixel 
values can be displayed in those units, rather than raw DN values.

----------------------------------------------------------------------------
-- Archie Warnock                     Internet:  warnock at nssdc.gsfc.nasa.gov
-- Hughes STX                         SPAN:      NSSDC::WARNOCK
-- NASA/GSFC                          "Unix - JCL for the 90s"

---

From: hanisch at stsci.edu (Bob Hanisch,N406,4910)
Date: 5 Dec 91 15:29:05 GMT

>From article <5DEC199108575533 at nssdca.gsfc.nasa.gov>, by warnock at nssdca.gsfc.nasa.gov (Archie Warnock):
Well, there is BUNIT, which defines the physical units of the scaled data
values.  ST has a set of keywords which are used to define the flux units
of spectral data (which depend on whether the flux is per unit wavelength
interval or unit frequency interval, for example).  However, BUNIT has 
served adequately in this regard for image data.

Bob Hanisch

---

From: bhill at stars.gsfc.nasa.gov (Robert S. Hill)
Date: 5 Dec 91 19:44:00 GMT

In article <1991Dec5.152905.19132 at stsci.edu>, 
hanisch at stsci.edu (Bob Hanisch,N406,4910) writes...
>values. [...]

The whole tenor of this thread suggests that section 5.2.2.5 of the
standards document (NOST 100-0.2g) has been ignored.  There, the
envisioned use of BZERO, BSCALE, and BUNIT is -- pretty clearly -- to
provide a physical calibration in physicist's units (especially since we
are referred to the IAU style guide).

\begin{tantrum}
What are the FITS readers that can't handle this?  The original FITS
papers also reflect this same intent.  E.g., see p. 369 of A.&A. Suppl.
Vol. 44.  Didn't anyone else read this stuff?  Am I the only one who
obeyed instructions?  Shame on everybody!   at #%$*!(  Wack wack wack!
\end{tantrum}

If BSCALE and BZERO are used solely for stuffing floating-point numbers
into integer variables, then IMHO for consistency, you have to make
BUNIT = 'ADU' or (in Landsman's and my case) 'E UNITS'.  You can't use
BSCALE and BZERO to define your arbitrary scaling, then use BUNIT for
your physical units.

How about something like PHYSCALE, PHYZERO, and PHYUNIT, to be used
on the result of applying BSCALE, BZERO, and BUNIT?  

 - Bob Hill

---

From: bhill at stars.gsfc.nasa.gov (Robert S. Hill)
Date: 5 Dec 91 21:19:00 GMT

Actually, I think I threw my tantrum a little too soon in that last
posting. Yes, I know, this is very mealy-mouthed, on Usenet one should
stand by one's flames.  ;-)

I think I had the question backwards.  The problem isn't that FITS
readers fail to apply BZERO, BSCALE, and BUNIT properly; it's that the
stored numbers in the file are regarded as being, per se, meaningless
*unless* BZERO, BSCALE, and BUNIT are applied.  But for Wayne's and
my project, the stored numbers will always be meaningful as
instrumental units.

It still seems apparent that for our purposes we need a couple of layers
of conversion, since we don't want users to lose track of instrumental
units, which have implications for saturation and for error analysis.

 - Bob Hill

--------------------------------------------------------------------------------
Robert S. Hill                        Internet:  BHILL at STARS.GSFC.NASA.GOV
Hughes STX Corp.                      SPAN:      STARS::BHILL
Code 680                              Phone:     301/286-3624
NASA/Goddard Space Flight Center
Greenbelt, MD 20771
-------------------------------------------------------------------------------

---

From: hanisch at stsci.edu (Bob Hanisch,N406,4910)
Date: 6 Dec 91 22:07:41 GMT

>From article <5DEC199116190859 at stars.gsfc.nasa.gov>, by bhill at stars.gsfc.nasa.gov (Robert S. Hill):

Thanks, Bob, for clarifying your position on this.  I couldn't quite
believe the first posting you wrote.

The FITS i/o packages I'm familiar with treat the data, after application
of BSCALE and BZERO, to be in the appropriate physical units (i.e., units
of BUNIT).  If this is not the case, then I agree with Chris Flatters'
previous posting (in response to a different message) that the writer of 
the data has made an error.

In the UIT case it seems that you are trying to kill two birds with one
stone, which is laudable in the sense of economizing on data storage, but
potentially confusing in terms of the subsequent interpretation.  For
example, for HST we deliver to observers both the raw data and calibrated
data.  The calibration is more than just a scaling, so we cannot avail
ourselves of the situation apparently available for UIT images.  However,
my recommedation for UIT would be to export your integer data using
BSCALE = 1., BZERO = 0., and BUNIT = 'DN' or whatever is appropriate.
You can provide a scaling factor elsewhere in the header that allows users
to convert to flux units, but I think it would be unwise to have this
applied automatically like BSCALE.  I expect that in most data analysis
systems it would be pretty straightforward for users to write a procedure
that extracts the flux scale value from the header and multiplies the
data to produce a new image.

Bob Hanisch