[Rtk-users] scanner development problems

[Simon Rit]

Ok, sorry, I erroneously mixed the size of the reconstructed volume and the
size of the projections. Then your calculation seems correct and I don't
know where does your geometry problem come from. For sure, you don't have
to shift the projections, --proj_iso_x does the same thing directly.
Regards,
Simon

On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov <nabokajeleboka at gmail.com>
wrote:

> Dear Simon, as i understand --neworigin is origin for projections. my
> projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137
>
> On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit <simon.rit at creatis.insa-lyon.fr
> > wrote:
>
>> Hi,
>> I think it's a geometry problem. I don't have a solution for you but just
>> a remark: how did you come up with the neworigin parameter? Changing this
>> has a similar effect as changing the --proj_iso_x or "offseting" the
>> projections. And it seems that the value you put (-18.137) makes no sense
>> to me wrt the total width (800*0.0296=23.68). Typically, I center the
>> projection which in your case would require as a new origin 799/-2*0.0296.
>> I hope this helps,
>> Simon
>>
>> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov <
>> nabokajeleboka at gmail.com> wrote:
>>
>>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about
>>> my problems if anyone can help me..
>>> I develop scanner. Reconstruction of parallelepiped or cube (
>>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact (
>>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan,
>>> without averaging and big rotation step.  Yea, it seems that its mainly
>>> misalignments problems, so i calibrated sourceX, sourceY, detectorX,
>>> detectorY by the following method
>>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got
>>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this
>>> information but without success.
>>>
>>> I also wrote a little program in this way
>>>     for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo;
>>> sourceXOffset_ += searchStep)
>>>     for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo;
>>> sourceYOffset_ += searchStep)
>>>     for (float projXOffset = projXFrom; projXOffset < projXTo;
>>> projXOffset += searchStep)
>>>     {
>>>         sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90
>>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f
>>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset);
>>>
>>>         int r = system(cmd);
>>>
>>>         sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r
>>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800
>>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0
>>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252");
>>>         r = system(cmd);
>>> ...
>>>
>>> to search scanner alignment but also without success.
>>>
>>> I noticed interesting thing: when i specially offset detector
>>> horizontally to the right by 4.5mm from the center, and specify it by
>>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! (
>>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on
>>> the center, reconstruct it, and here is phantom artifact, then i manually
>>> offset picture to the left on the tifs (from
>>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and
>>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment
>>> i work in this way, take scans when detector on the center, manually offset
>>> picture to the left and specify it by proj_iso_x to avoid phantom artifact,
>>> but its HUGE WORKAROUND =))
>>>
>>>
>>> What do you think about it ? If its geometry issue, why real or virtual
>>> offset of detector cleans up the phantom artifact?
>>>
>>>
>>> _______________________________________________
>>> Rtk-users mailing list
>>> Rtk-users at public.kitware.com
>>> http://public.kitware.com/mailman/listinfo/rtk-users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20160318/25262fb6/attachment-0010.html>