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

[Seaman, Robert Lewis - (rseaman)]

Yes, don’t messed with unsigned integer support.

No, don’t muck about with CFITSIO, but files generated by CFITSIO (and other packages) should be readable using your Julia code, and vice versa.

Rob



On 3/11/24, 10:26 AM, "Barrett, Paul" wrote:

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<mailto: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<mailto: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/75637fe4/attachment-0001.html>