<div dir="ltr"><div>Please stick to the mailing list. The DivideImageFilter is part of OSEM so that doesn't explain it. I did a quick test and that works for me:</div><div><span style="font-family:monospace">rtksimulatedgeometry -n 100 -o g</span></div><div><span style="font-family:monospace">rtkprojectshepploganphantom -g g -o proj.mha --spacing 1.5</span></div><div><span style="font-family:monospace">rtkosem -p . -r proj.mha -v -o osem.mha -n 5 -g g --nprojpersubset 100</span></div><div>and I obtain 5.7e6 in the osem.mha file and 5.9e8 in the proj.mha file.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 27, 2023 at 4:07 PM Nathan Sinsoilliez <<a href="mailto:n.sinsoilliez@gmail.com" target="_blank">n.sinsoilliez@gmail.com</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"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi,</div>I'm not using any attenuation correction currently. The total counts of the reconstructed images is still too low compared to the total average in one projection. It looks like the pixel values are divided (which can explain why they're decimals). After checking the OSEMConeBeamReconstructionFilter on the wiki, I saw that there is a DivideImageFilter, maybe it can explain why but I don't really get how it works and why it is necessary so maybe I'm speaking nonsense here. </div><div dir="ltr"><br></div><div>Sinsoilliez Nathan</div><div dir="ltr"><h3 style="margin-right:15px;color:rgb(0,0,0);font-family:Roboto,sans-serif"><br></h3><div><br></div><div><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 27 juin 2023 à 10:18, Simon Rit <<a href="mailto:simon.rit@creatis.insa-lyon.fr" target="_blank">simon.rit@creatis.insa-lyon.fr</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div>I'm not sure we actually ever checked this but it's a good check. Are you using attenuation correction? If not, I expect that the total number of counts in one projection should be equal to the integral of the SPECT image as this is the Radon transform model. So you may want to average the number of counts and not sum it (i.e., divide 8E+6 by your number of projections). Can you check this?</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 27, 2023 at 8:48 AM Nathan Sinsoilliez <<a href="mailto:n.sinsoilliez@gmail.com" target="_blank">n.sinsoilliez@gmail.com</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"><div dir="ltr">Hello everyone,<div><br></div><div>I'm currently using rtk to reconstruct SPECT images using OSEM and I have an issue after the reconstruction. The total count of the image is completely changed (like 8E+6 in the projections VS 2E+4 when reconstructed). Also most of the pixels now have decimal values. Graphically everything seems to be alright though.</div><div><br>Do you have an idea about what could cause this problem ?</div><div><br></div><div>Best Regards</div><div>Sinsoilliez Nathan</div></div>
_______________________________________________<br>
Rtk-users mailing list<br>
<a href="mailto:rtk-users@openrtk.org" target="_blank">rtk-users@openrtk.org</a><br>
<a href="https://www.creatis.insa-lyon.fr/mailman/listinfo/rtk-users" rel="noreferrer" target="_blank">https://www.creatis.insa-lyon.fr/mailman/listinfo/rtk-users</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>