<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<p>Dear Fits mailing list members,</p>
<p>We (CDS and more precisely myself) ave encountered a few
difficulties in implementing in java the RICE decompression codes
described in the <a
href="https://fits.gsfc.nasa.gov/standard40/fits_standard40aa-le.pdf">latest
version of the FITS standard</a> in the context of updating our
Hierarchical Progressive Survey (<a
href="https://www.ivoa.net/documents/HiPS/">IVOA Standard HiPS
1.0</a>) generation tools, and in particular <a
href="https://aladin.u-strasbg.fr/hips/#tools">Hipsgen</a>. <br>
</p>
<p>We realised that the images we were decompressing were not
strictly identical to those decompressed by cfitsio-based tools.
After investigation, it seems that the discrepancy was due to a
variation in the way the <span class="pl-c1"> ZERO_VALUE </span>value
was taken into account. In the Fits 4.0 document, the value used
to encode the zero in the SUBTRACTIVE DITHER 2 method is 214748364<b>7</b>
(page 47 "... <i>pixels in the floating-point image that are
exactly equal to 0.0 are represented by the reserved value
-2147483647 in the quantized integer array...</i>"). Except if
I'm wrong, in the cfitsio library code, the value used is
-214748364<b>6</b> (<a
href="https://heasarc.gsfc.nasa.gov/FTP/software/fitsio/c/imcompress.c">imcompress.c</a>
line 10 & 7679). <span class="pl-c1">One of the consequences
of this divergence is the shift in the application of the random
function (inhibited for the value ZERO_VALUE). And indeed,
having adopted the constant used by cfitsio, we obtain the same
results.<br>
</span></p>
<p>During this exercise, we also noted that the <span style="left:
7.08%; top: 42.57%; font-size:
calc(var(--scale-factor)*10.36px); font-family: sans-serif;
transform: scaleX(1.07716);" role="presentation" dir="ltr">random
function required for compression and decompression in the
SUBTRACTIVE_DITHER method (1 and 2) and provided in Appendix I
of the Fits 4.0 document is expressly stated as "not normative"
("<i>This appendix is not part of the FITS Standard, but is
included for informational purposes</i>"). This point may mean
that some FITS compressors could use another random function.
And If this is the case, we wondered how such a variation could
be detected.<br>
</span></p>
<p>At this stage, we decided to strictly follow the choices of the
latest version of cfitsio (4.2.0) (214748364<b>6 </b>and
assuming the unique random function).</p>
<p>If this feedback is indeed relevant, perhaps the Fits 4.0
document could be clarified on these two points to avoid any
potential divergence.<br>
</p>
<p>Best regards<br>
Pierre Fernique<br>
Centre de Données astronomiques de Strasbourg</p>
</body>
</html>