<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><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]--></head><body lang=EN-GB link=blue vlink=purple><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 lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> William Pence [mailto:wdpence2000@yahoo.com] <br><b>Sent:</b> 27 February 2020 16:56<br><b>To:</b> CCFITS Help Desk<br><b>Cc:</b> david.partridge@perdrix.co.uk; fitsbits@listmgr.nrao.edu<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 ccfits@heasarc.gsfc.nasa.gov. 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" <fitsbits@listmgr.nrao.edu><br><b>Date:</b> February 27, 2020 at 6:56:03 AM EST<br><b>To:</b> fitsbits@nrao.edu<br><b>Subject:</b> <b>[fitsbits] Possible bug in CFITSIO</b><br><b>Reply-To:</b> "David C. Partridge" <david.partridge@perdrix.co.uk><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>fitsbits@listmgr.nrao.edu<br>https://listmgr.nrao.edu/mailman/listinfo/fitsbits<o:p></o:p></p></div></blockquote></div></div></div></div></body></html>