<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <p>Hi all,<br>
    </p>
    <div class="moz-cite-prefix">Le 28/03/2024 à 00:43, Seaman, Robert
      Lewis - (rseaman) via fitsbits a écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:SA3PR19MB8165976B66C4594A2F94714AA7342@SA3PR19MB8165.namprd19.prod.outlook.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta name="Generator"
        content="Microsoft Word 15 (filtered medium)">
      <style>@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        mso-ligatures:none;}div.WordSection1
        {page:WordSection1;}</style>
      <div class="WordSection1">
        <p class="MsoNormal">Does Rubin have any other suggestions for
          updating the standard? By all means make a list. The standard
          is not frozen, even if the procedures may be a bit quaint.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Rob</p>
      </div>
    </blockquote>
    <p>As the standard is not frozen 😉, I'd like to take this
      opportunity to recall the following discrepancies raised one year
      ago between the current description of the RICE decompression
      method in the standard (4.0), and the actual implementation in the
      latest version of CFITSIO (see below for details).</p>
    <p>More generally, regarding the easiness / difficulty of
      implementing the new document's recommendations, it would be
      interesting to know which alternative libraries to CFITSIO have
      already partially or fully implemented the document
      compression/decompression recommendations. A new column in the
      table described here
      <a class="moz-txt-link-freetext" href="https://fits.gsfc.nasa.gov/fits_libraries.html">https://fits.gsfc.nasa.gov/fits_libraries.html</a> would be very
      valuable for evaluating this question.<br>
    </p>
    Best regards,<br>
    Pierre Fernique<br>
    <p><br>
    </p>
    <div class="moz-cite-prefix">Le 14/06/2023 à 18:42, William Pence a
      écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:304D7A32-3D57-458A-9DA2-16D9655A7712@yahoo.com">
      <div dir="ltr">Pierre,</div>
      <div dir="ltr"><br>
      </div>
      <div dir="ltr">You are correct that CFITSIO ended up using the
        value -<i>2147483646 instead of -</i><i>2147483647 </i>to
        represent zero-valued pixels in a compressed image.  This was
        because the latter value was already reserved in CFITSIO to
        represent null-valued pixels that have no assigned value. As you
        note, this change has a small ripple effect on the quantization
        of the other pixels in the image in that in a very few cases a
        pixel will end up quantized into an adjacent bin because of
        small (and insignificant) rounding errors.   Ideally, the FITS
        Standard should be corrected to reflect this change.</div>
      <div dir="ltr"><br>
      </div>
    </blockquote>
    (...)<br>
    <blockquote type="cite"
      cite="mid:304D7A32-3D57-458A-9DA2-16D9655A7712@yahoo.com">
      <div dir="ltr"><br>
      </div>
      <div dir="ltr">William Pence</div>
      <div dir="ltr">NASA, HEASARC (Emeritus)</div>
      <div dir="ltr"><br>
      </div>
      <div dir="ltr"><br>
      </div>
      <div dir="ltr"><br>
        <blockquote type="cite">On Jun 13, 2023, at 5:41 AM, Pierre
          Fernique via fitsbits <a class="moz-txt-link-rfc2396E" href="mailto:fitsbits@listmgr.nrao.edu"><fitsbits@listmgr.nrao.edu></a> wrote:<br>
          <br>
        </blockquote>
      </div>
      <blockquote type="cite">
        <div dir="ltr">
          <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><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"><br>
            </span></p>
        </div>
      </blockquote>
    </blockquote>
    (...)<br>
    <blockquote type="cite"
      cite="mid:304D7A32-3D57-458A-9DA2-16D9655A7712@yahoo.com">
      <blockquote type="cite">
        <div dir="ltr">
          <p><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"> </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>
          <span>_______________________________________________</span><br>
          <span>fitsbits mailing list</span><br>
          <span><a class="moz-txt-link-abbreviated" href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a></span><br>
          <span><a class="moz-txt-link-freetext" href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a></span><br>
        </div>
      </blockquote>
    </blockquote>
    <p><span style="white-space: pre-wrap">
</span></p>
  </body>
</html>