[fitsbits] Output array type when BZERO is an integer {External}
peter teuben
teuben at umd.edu
Tue Mar 12 14:51:44 EDT 2024
I've not understood why
/for the special case where BZERO is an integer/
would be a special case. The standard says that BZERO and BSCALE are
real, so if the fits file says BZERO 10 or 10.0 that's the same. Same
for BSCALE.
The processing software still has one option to cast the final data, and
that has nothing to do with the standard in my opinion, and that's if
they want the data to wind up being int8 vs. float64, say. I got more
the impression this is what you were thinking of.
peter
On 3/12/24 10:57, Barrett, Paul via fitsbits wrote:
> I'll ask this question one more time and then I'll let it go.
>
> I understand that the default behaviour for BZERO and BSCALE creates a
> floating point array because of the typical upconversion rules.
> However, I'm not clear about the data type for the special case where
> BZERO is an integer. In this case, it appears that BZERO is added
> first to the integer array before converting it to a floating point
> array, because BSCALE = 1.0 implies upconversion. Is this correct?
>
>
> As for your comments:
>
> * I disagree with your first comment. FITS is used because of peer
> pressure. It is mandated by NASA. That means a large sector of the
> community HAS to use it.
> * Yes, dynamic languages are dynamic enough. In the case of Julia, it
> can do everything that C/C++, FORTRAN, and Python can do. /Think of
> Julia as Python with Numba built-in./
>
> -- Paul
>
> On Tue, Mar 12, 2024 at 9:39 AM Seaman, Robert Lewis - (rseaman) via
> fitsbits <fitsbits at listmgr.nrao.edu> wrote:
>
> Howdy,
>
> It is always good to see a spirited FITS discussion! A few more
> peppy points:
>
> * There is always an assertion that it would be preferable to
> use a “modern” format
>
> o Yet projects often end up using FITS
> o This choice does not result from peer pressure
>
> * There is nothing magic about IEEE floating point or
> twos-complement integers
>
> o Efficient (compressed) data representations may not even
> be binary (Rice is unary)
> o Are dynamically typed languages dynamic enough?
>
> * A tile-compressed image is a simple binary table
>
> o My first encounter with FITS data (c. 1983) was writing a
> FITS image reader from scratch by consulting the original
> journal article(s) (possibly also my first encounter with C)
> o I am confident young Rob could have written a reader for
> tile-compressed binary data with little more effort (or
> code) just from reading the current FITS standard
>
> * FITS documentation is pretty good
>
> o (Comments about other projects’ documentation omitted)
>
> * Most FITS discussions/disagreements are about metadata
>
> o Only a small minority of FITS metadata is strictly
> required to enforce the structure of each extension
> o Science metadata (astronomical and computer science) would
> be legal (and trivial) to represent, using any schema you
> like, in a binary table structure, described in a
> convention or appendix or chapter of the standard
> o Schemata could also include language-specific pragma, for
> data-typing purposes or otherwise
>
> * It is perhaps peer pressure that pushes projects to use
> 80-char ASCII header keywords in 2880-byte records
>
> o Consider, rather, what is the optimal tiled representation
> for your project, and separately
> o How can your project’s (and community) metadata best be
> represented in a schema realized as a binary table?
>
> Rob
>
> _______________________________________________
> fitsbits mailing list
> fitsbits at listmgr.nrao.edu
> https://listmgr.nrao.edu/mailman/listinfo/fitsbits
>
>
> _______________________________________________
> fitsbits mailing list
> fitsbits at listmgr.nrao.edu
> https://listmgr.nrao.edu/mailman/listinfo/fitsbits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/fitsbits/attachments/20240312/95ac5f1a/attachment.html>
More information about the fitsbits
mailing list