<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>