<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 25.04.22 09:07, Simon Rit wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAF0oig2G10xvpWYt18tHjb7Gp2FtL-EAr3badrw7-EpnyNmhTw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>Hi Vincent (and Jasper),</div>
        <div>I agree with Jasper that this is most likely due to a
          difference in geometric calibration between the two datasets.
          Do you have more information on what does B use (projection
          matrices, detailed parametrization, etc.)? I think that such a
          blur can be caused by a difference in source to detector
          distance (or, equivalently, detector pixel size).</div>
        <div>Simon<br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Tue, Apr 19, 2022 at 11:08
          AM Vincent Libertiaux <<a href="mailto:vl@xris.eu"
            moz-do-not-send="true" class="moz-txt-link-freetext">vl@xris.eu</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
          16.04.22 13:52, Jasper Albertus Nijkamp wrote:<br>
          > Hi Vincent,<br>
          ><br>
          >  From just these two images, it is a bit hard to help.
          However, I have seen similar challenges when the detector
          vertical offset is not properly set. If you could share a bit
          more data (fx projection data and the geometry), more people
          might be able to help.<br>
          ><br>
          > Jasper<br>
          ><br>
          > -----Original Message-----<br>
          > From: Rtk-users <<a
            href="mailto:rtk-users-bounces@public.kitware.com"
            target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">rtk-users-bounces@public.kitware.com</a>>
          On Behalf Of Vincent Libertiaux<br>
          > Sent: Friday, 15 April 2022 17:15<br>
          > To: rtk-users <<a
            href="mailto:rtk-users@public.kitware.com" target="_blank"
            moz-do-not-send="true" class="moz-txt-link-freetext">rtk-users@public.kitware.com</a>><br>
          > Cc: Damien Koch <<a href="mailto:dk@xris.eu"
            target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">dk@xris.eu</a>><br>
          > Subject: [Rtk-users] Lateral blur in a FDK reconstructed
          volume<br>
          ><br>
          > Hello rtk users !<br>
          ><br>
          > I am facing a problem for which I have exhausted all the
          possibilities except asking you.<br>
          > I have performed a standard FDK reconstruction of a lego
          bricks assembly.  I used a custom-made code to compute the
          detector horizontal offset and tilt angle, found to be 1.15 mm
          and 0.02° respectively.  The result of the reconstruction is
          shown in the picture<br>
          > <a href="https://ibb.co/LdMzJF2" rel="noreferrer"
            target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://ibb.co/LdMzJF2</a> . 
          The volume looks mostly sharp, except on the lateral edges,
          let's say on the last half brick.<br>
          ><br>
          > We had the opportunity to have the same volume
          reconstructed with two commercial solutions.  The first one,
          "A", produced the same results than rtk.  The second, "B",
          produced the result shown in the picture <a
            href="https://ibb.co/VwXMmRH" rel="noreferrer"
            target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://ibb.co/VwXMmRH</a><br>
          ><br>
          > In this case, the edges are sharp too.  The offset values
          found with this software were very close (1.13mm and 0.025°
          respectively) and feeding them to rtksimulatedgeometry didn't
          change my result.  No other correction was allegedly applied.<br>
          ><br>
          > I thought that the edge blurring was due to a wobbling
          artefact but it can't be the case according to the result with
          the "B" software.<br>
          ><br>
          > Do you have any idea on what could cause this blurring on
          the edges ?<br>
          ><br>
          > I thank you very much for any clue.<br>
          ><br>
          > Best regards,<br>
          ><br>
          > Vincent<br>
          ><br>
          > _______________________________________________<br>
          > Rtk-users mailing list<br>
          > <a href="mailto:Rtk-users@public.kitware.com"
            target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">Rtk-users@public.kitware.com</a><br>
          > <a
            href="https://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users"
            rel="noreferrer" target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users</a><br>
          <br>
          Hi Jasper,<br>
          <br>
          thank you for your reply. I had already tried to play with the
          vertical <br>
          offset but setting it to a value different than 0
          progressively decrease <br>
          the overall quality of the reconstruction.<br>
          Following your advice, here are the projections:<br>
          <br>
          <a href="http://share.xris.eu/d91b09673bba" rel="noreferrer"
            target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">http://share.xris.eu/d91b09673bba</a><br>
          <br>
          word of warning, the set is very large (900 projections on a
          3072x3072 <br>
          pixels detector, approx. size = 16Go)  I could try and make it
          smaller <br>
          by downsampling it but I am afraid it would mask the problem. 
          I can try <br>
          and do it on request.<br>
          The geometric parameters I used were: SDD = 810 mm, SID = 410
          mm, <br>
          proj_iso_x = 1.15mm and in_angle = 0.02°.<br>
          <br>
          <br>
          Best regards,<br>
          <br>
          Vincent<br>
          <br>
          _______________________________________________<br>
          Rtk-users mailing list<br>
          <a href="mailto:Rtk-users@public.kitware.com" target="_blank"
            moz-do-not-send="true" class="moz-txt-link-freetext">Rtk-users@public.kitware.com</a><br>
          <a
            href="https://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users"
            rel="noreferrer" target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users</a><br>
          <br>
        </blockquote>
      </div>
    </blockquote>
    <p>Hi Simon, hi Jasper.</p>
    <p>I have investigated a bit more on that issue.  I told you in my
      first message that both software we used besides rtk found the
      same set of parameters.  After playing a bit more with the
      software "B" (the one that gives the sharp edges), I found out
      that the tilt angle is found to be 0 and it is the out-of-plane
      angle around the vertical axis of the detector which is non zero
      (and very coincidentally is very close to the tilt angle we
      computed).  The value is quite low (0.025°).  I am a bit puzzled
      as, if I am not mistaken, the literature always assumes that both
      out of plane angles are negligible as long as they don't come
      close 2°.  We are two order of magnitude below this value, hence
      my surprise.</p>
    <p>I am also wondering if this angle can be introduced in the rtk
      geometry.  From the doc
      (<a class="moz-txt-link-freetext" href="http://www.openrtk.org/Doxygen/DocGeo3D.html">http://www.openrtk.org/Doxygen/DocGeo3D.html</a>), it seems that only
      the out-of-plane angle around the detector horizontal axis is
      considered.  Is that correct ?  If yes, is there a way to model
      the other one with the available parameters ?</p>
    <p>Once again, thank you for any help you can provide.</p>
    <p>Kindest regards,</p>
    <p>Vincent<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
  </body>
</html>