<div dir="ltr">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.<div><div><br></div><div>UInt8 => Float32</div><div>Int16 => Float32</div><div>Int32 => Float64</div><div>Int64 => Float64</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> -- Paul</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 10, 2024 at 12:17 PM Seaman, Robert Lewis - (rseaman) <<a href="mailto:rseaman@arizona.edu" target="_blank">rseaman@arizona.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>





<div lang="EN-US">
<div>
<p class="MsoNormal">Hi Paul,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div id="m_-8264937793714063958m_2825591748467855562mail-editor-reference-message-container">
<div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><i>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.<u></u><u></u></i></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><i><u></u> <u></u></i></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I’m not sure I understand your last sentence. Could you provide a table of the mappings you think should apply?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Rob Seaman<u></u><u></u></p>
<p class="MsoNormal">Lunar and Planetary Laboratory<u></u><u></u></p>
<p class="MsoNormal">University of Arizona<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>

</div></blockquote></div>