🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

2 total messages Started by Peter Teuben Tue, 28 Jul 1992 15:27
BSCALE/BZERO
#9
Author: Peter Teuben
Date: Tue, 28 Jul 1992 15:27
28 lines
1695 bytes
The NOST fits panel report states that for BITPIX < 0 (i.e. when
the data is stored in IEEE floating point format) the usage of
BSCALE and BZERO not recommended. We never (wanted to) forbid 
or explicitly state that it should or should not be applied
in section 6.3 (though section 5.2.2.5 does state this).

The FITS users guide (also published by NOST) does explicitly
states that BSCALE and BZERO  be applied in the BITPIX<0 case, with
the danger of producing overflows/underflows of course (hence the 
reason that BSCALE and BZERO should not be present).

I've indeed noted that the AIPS and MIRIAD readers 'correctly' apply
BSCALE and BZERO in the floating point cases, but the problem arose
when we imported a FITS file generated by IDL. The idl procedure
'WRITEFITS' seems to write images with BSCALE not 1.0, which has
caused some readers to read in the wrong datavalues.
Perhaps Wayne Landsman can comment on this.

Has anybody seen fits readers which skip BSCALE and BZERO if BITPIX < 0?

	Peter

--
Peter J. Teuben         |  INTERNET  : teuben@astro.umd.edu
Astronomy Department    |  FAX:        (301) 314-9067
University of Maryland  |  MA-BELL   : (301) 405-1540 (office)
College Park, MD 20742  |              (301) 405-1502 (secr.)
Re: BSCALE/BZERO
#10
Author: William Thompson, code 682.1, x2...
Date: Wed, 29 Jul 1992 18:36
43 lines
2864 bytes
In article <TEUBEN.92Jul28112713@lynx.astro.umd.edu>, teuben@lynx.astro.umd.edu
(Peter Teuben) writes...
> 
>The NOST fits panel report states that for BITPIX < 0 (i.e. when
>the data is stored in IEEE floating point format) the usage of
>BSCALE and BZERO not recommended. We never (wanted to) forbid 
>or explicitly state that it should or should not be applied
>in section 6.3 (though section 5.2.2.5 does state this).
> 
>The FITS users guide (also published by NOST) does explicitly
>states that BSCALE and BZERO  be applied in the BITPIX<0 case, with
>the danger of producing overflows/underflows of course (hence the 
>reason that BSCALE and BZERO should not be present).
> 
>I've indeed noted that the AIPS and MIRIAD readers 'correctly' apply
>BSCALE and BZERO in the floating point cases, but the problem arose
>when we imported a FITS file generated by IDL. The idl procedure
>'WRITEFITS' seems to write images with BSCALE not 1.0, which has
>caused some readers to read in the wrong datavalues.
>Perhaps Wayne Landsman can comment on this.
> 
>Has anybody seen fits readers which skip BSCALE and BZERO if BITPIX < 0?

I don't want to talk for Wayne Landsman as to what the IDL routines do or don't
do when writing FITS files.  I do want to address the issue inherent in the
last question, though.

I believe that there is a valid usage for BSCALE and BZERO when applied to
floating point data.  Most people probably think of these variables as just a
way of packing floating point numbers into integer arrays.  However, the FITS
documentation simply states that these parameters are used to convert array
values into scientifically useful physical values.  Thus, another possible use
of BSCALE and BZERO is to convert raw detector values into calibrated values.
Thus, both levels of information are retained, and changing the calibration at
a later date is fairly trivial.

The IDL FITS reader routines do, by default, apply the BSCALE and BZERO
parameters to the data.  This occurs for both integer and floating point
arrays.  However, this behavior can be overridden by including the /NOSCALE
keyword.  That way, the user can also access the "raw" data.  It doesn't matter
whether or not BITPIX is > 0 or < 0.

Bill Thompson
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads