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 <[email protected]> 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 <[email protected] > > 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 < >> [email protected]> 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 >>> [email protected] >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >>> >> >
_______________________________________________ Rtk-users mailing list [email protected] http://public.kitware.com/mailman/listinfo/rtk-users
