[fitsbits] Output array type when BZERO is an integer {External}

[Barrett, Paul]

I'm not sure I understand what you mean about UInt16 and UInt32 remaining
integers. Do you mean for the special case? If yes, then they will remain
integers.

I'm sorry, but I am not writing an interface to CFITSIO. If you want such
an interface, then use the wrapped version.

 -- Paul

On Mon, Mar 11, 2024 at 12:55 PM Seaman, Robert Lewis - (rseaman) <
rseaman at arizona.edu> wrote:

> Hi Paul,
>
>
>
> Just to be clear, the UInt16 and UInt32 would remain integers, right?
>
>
>
> Whether or not you review CFITSIO code, applications layered on your code
> versus on CFITSIO should interoperate. This is particularly true for tile
> compression (which your package should support).
>
>
>
> Rob
>
>
>
>
>
>
>
> On 3/11/24, 9:01 AM, "Barrett, Paul" wrote:
>
>
>
> If the input array is a UInt8, then a Float64 output array is overkill. A
> Float32 array should work just fine. This provides sufficient precision
> while saving memory. So using this line of thought, I would think these
> mappings from integer input arrays to floating point output arrays would be
> reasonable.
>
>
>
> UInt8 => Float32
>
> Int16 => Float32
>
> Int32 => Float64
>
> Int64 => Float64
>
>
>
> By explicitly specifying this in the documentation, you would save future
> developers some time. They would not have to decipher how best to implement
> the code as I have done. Note that Julia does type inference, like Python,
> unless the developer specifies otherwise. If BSCALE looks like an integer,
> because there is no decimal point, then Julia will interpret this as an
> integer, unless I coerce it to a float. I'm just confirming that this is
> what I should do using the above mappings.
>
>
>
> I'm trying to support whatever the standard specifies. Being explicit
> would make this easier for me. I would prefer not to have to wade into the
> CFITSIO code to do so and I don't think other developers should have to do
> so too.
>
>
>
>  -- Paul
>
>
>
> On Sun, Mar 10, 2024 at 12:17 PM Seaman, Robert Lewis - (rseaman) <
> rseaman at arizona.edu> wrote:
>
> Hi Paul,
>
>
>
> *I'm writing a FITS package for the Julia programming language. I have a
> question about the output type of the image when BZERO is an integer value.
> The documentation implies that the output image should be a floating point
> type because the BSCALE value is a float. Is this correct? If yes, then I
> recommend stating this explicitly in the FITS standard documentation. I
> also recommend suggesting the appropriate output type depending on the
> input type, e.g., UInt8 => Float32, Int16 => Float32, etc.*
>
>
>
> Yes, that is the ancient implication of BSCALE. This carries over to lossy
> tile compression, too, which is a very fancy BSCALE operation if you look
> at it sideways.
>
>
>
> Undoubtedly there are other pending tweaks to the docs. This is hard to
> avoid with esoteric standards, especially perhaps if they survive through
> multiple generations of other contingent computer technologies.
>
>
>
> I’m not sure I understand your last sentence. Could you provide a table of
> the mappings you think should apply?
>
>
>
> To first order, other languages and libraries should start with the
> CFITSIO source for appropriate usage (or to suggest differently). One
> recommendation is that all FITS packages support tile compression.
>
>
>
> Rob Seaman
>
> Lunar and Planetary Laboratory
>
> University of Arizona
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/fitsbits/attachments/20240311/2d6917d9/attachment-0001.html>