<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><tt>In your example, the FITS image contains 16-bit signed
integer values. It is not possible for the value to be less
than -32768 or greater than +32767, so there cannot be an
overflow when adding BZERO = 32768. There would be an overflow,
however, if BZERO were greater than 32768. So the question is
whether CFITSIO checks for that case and returns a float instead
of an unsigned int with an incorrect value. Have you checked
that?</tt></p>
<p><tt>Phil</tt><br>
</p>
<div class="moz-cite-prefix">On 2/28/20 4:49 AM, David C. Partridge
via fitsbits wrote:<br>
</div>
<blockquote type="cite"
cite="mid:005e01d5ee1c$72b0ebf0$5812c3d0$@perdrix.co.uk">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Times New Roman","serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div style="border:solid #9C6500 1.0pt;padding:2.0pt 2.0pt 2.0pt
2.0pt">
<center>
<p class="MsoNormal"
style="line-height:12.0pt;background:#FFEB9C"><span
style="font-size:10.0pt;color:black">External Email - Use
Caution</span></p>
</center>
</div>
<div>
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">So for
clarity:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Are you
saying that if the headers of a 16 bit FITS file say:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">
SIMPLE = T / file does conform to FITS
standard<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">
BITPIX = 16 / number of bits per data
pixel<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">
BZERO = 32768 / offset data range to that
of unsigned short<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">
BSCALE = 1 / default scaling factor<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">that I
should ignore the fact the BITPIX is telling me to use
signed short, and act as if<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">BITPIX had
a value of 20 (unsigned short).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">And
similarly 32 bit files with values of BITPX of 32 (signed)
and 40 (unsigned)??<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">That
somehow feels wrong!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">David<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US"> William Pence
[<a class="moz-txt-link-freetext" href="mailto:wdpence2000@yahoo.com">mailto:wdpence2000@yahoo.com</a>]
<br>
<b>Sent:</b> 27 February 2020 16:56<br>
<b>To:</b> CCFITS Help Desk<br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:david.partridge@perdrix.co.uk">david.partridge@perdrix.co.uk</a>;
<a class="moz-txt-link-abbreviated" href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a><br>
<b>Subject:</b> Fwd: [fitsbits] Possible bug in
CFITSIO<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span
style="font-family:"Tahoma","sans-serif""></span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span
style="font-family:"Tahoma","sans-serif""></span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span
style="font-family:"Tahoma","sans-serif""></span><o:p></o:p></p>
<div>
<p class="MsoNormal">The HEASARC at NASA/GSFC
continues to maintain the CFITSIO library. Any
issues with CFITSIO should be addressed to their
help desk at <a class="moz-txt-link-abbreviated" href="mailto:ccfits@heasarc.gsfc.nasa.gov">ccfits@heasarc.gsfc.nasa.gov</a>. I’m
forwarding this email to them for possible follow
up. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">While the topic of how CFITSIO
internally handles datatype conversion between every
possible FITS datatype and every possible C variable
datatype is too complex to go into here, the short
answer is that it is being handled correctly. This
particular code has been widely used for the past 25
years, so any serious bugs would surely have been
discovered by now. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Bill Pence<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">HEASRC, NASA/GSFC, Emeritus <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">——————————————-<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
Begin forwarded message:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b>From:</b>
"David C. Partridge via fitsbits"
<a class="moz-txt-link-rfc2396E" href="mailto:fitsbits@listmgr.nrao.edu"><fitsbits@listmgr.nrao.edu></a><br>
<b>Date:</b> February 27, 2020 at 6:56:03 AM EST<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:fitsbits@nrao.edu">fitsbits@nrao.edu</a><br>
<b>Subject:</b> <b>[fitsbits] Possible bug in
CFITSIO</b><br>
<b>Reply-To:</b> "David C. Partridge"
<a class="moz-txt-link-rfc2396E" href="mailto:david.partridge@perdrix.co.uk"><david.partridge@perdrix.co.uk></a><o:p></o:p></p>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span
style="font-family:"Tahoma","sans-serif""></span>=====
QUOTE =====<br>
Although FITS does not directly support unsigned
integers as one of its<br>
fundamental data types, FITS can still be used to
efficiently store unsigned<br>
integer data values in images and binary tables.
The convention used in FITS<br>
files is to store the unsigned integers as signed
integers with an<br>
associated offset (specified by the BZERO or
TZEROn keyword). For example,<br>
to store unsigned 16-bit integer values in a FITS
image the image would be<br>
defined as a signed 16-bit integer (with BITPIX
keyword = SHORT_IMG = 16)<br>
with the keywords BSCALE = 1.0 and BZERO = 32768.
Thus the unsigned values<br>
of 0, 32768, and 65535, for example, are
physically stored in the FITS image<br>
as -32768, 0, and 32767, respectively; CFITSIO
automatically adds the BZERO<br>
offset to these values when they are read.<br>
===== END QUOTE =====<br>
<br>
With that in mind I believe that the code in
fffi2i2 (for example) at line<br>
1054 is incorrect as it always adds the zero value
before checking for an<br>
overflow error.<br>
<br>
I think that it should check the value is in range
and ONLY then add the<br>
zero value.<br>
<br>
IOW:<br>
<br>
for (ii = 0; ii < ntodo; ii++)<br>
{<br>
dvalue = input[ii] * scale; //
don't do + zero;<br>
<br>
if (dvalue < DSHRT_MIN)<br>
{<br>
*status = OVERFLOW_ERR;<br>
dvalue = DSHRT_MIN;<br>
}<br>
else if (dvalue > DSHRT_MAX)<br>
{<br>
*status = OVERFLOW_ERR;<br>
dvalue = DSHRT_MAX;<br>
};<br>
dvalue += zero; // NOW Add the
zero offset to the validated<br>
value<br>
output[ii] = (short) dvalue;<br>
}<br>
<br>
Similar issue with handling of 32 bit values.<br>
<br>
David<br>
<br>
<br>
_______________________________________________<br>
fitsbits mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a><br>
<a class="moz-txt-link-freetext" href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a><o:p></o:p></p>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
fitsbits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a>
<a class="moz-txt-link-freetext" href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a>
</pre>
</blockquote>
</body>
</html>