[Rtk-users] Issue report regarding the recorder of Time elapsed
Guangming Zang
guangming.zang at kaust.edu.sa
Mon Jul 27 17:12:16 CEST 2015
Thanks Simon, now it work fine when using projections generated by RTK
itself (command rtkprojectshepploganphantom ).
for 1 iteration of SART to reconstruct 128^3 size volume, it took only 19s,
which gives nice results as well.
Thanks again.
Guangming
*Guangming Zang (Alex)*
*King Abdullah University of Science and Technology(KAUST)*
*University of Chinese Academy of Sciences(UCAS)*
2015-07-27 17:20 GMT+03:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
> Obviously I hadn't looked at the result and/or checked the command line
> options, sorry. This is an example from the same simulated dataset that
> gives me a good results:
>
> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f
> Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n
> 3 --time 1
> Recording elapsed time...
> SARTConeBeamReconstructionFilter timing:
> Extraction of projection sub-stacks: 0.567773 s
> Multiplication by zero: 0.303715 s
> Forward projection: 142.305 s
> Subtraction: 0.445842 s
> Multiplication by lambda: 0.2663 s
> Ray box intersection: 5.40366 s
> Division: 0.535618 s
> Multiplication by the gating weights: 0 s
> Displaced detector: 0.415431 s
> Back projection: 21.3689 s
> Volume update: 0 s
> It took... 177.059 s
>
> but this doesn't change the content of my previous message. What takes
> time is probably in your own software, be sure that you update SART inputs
> before timing it.
> Simon
>
> On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang <
> guangming.zang at kaust.edu.sa> wrote:
>
>> Hi Simon,
>> it cost 1200s for SART algorithm at first, and the command are:
>> rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=
>> 725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128"
>>
>> rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha
>> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension
>> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1
>>
>> in which, the projections data(360pro_SL_Vol128_512.mha) is not
>> generated from rtkprojectshepploganphantom , but from my application.
>> though it took long time, but i can got a nice result,
>>
>>
>> And i just tried the command you used, i.e. generated the projections
>> data by rtkprojectshepploganphantom :
>>
>> rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729
>> --sid=500.0
>> rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512
>> rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b
>> VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128
>> --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1
>> yes, it takes about 56s.
>> but the reconstructed result is weird, the voxel values range from
>> [-142186, 208146] and can not see anything when visualizing it.
>> i believe you got the similar results, which maybe explain why it
>> computes much faster.
>>
>> if i wanna use the projections generated by rtkprojectshepploganphantom
>> , can you give me an example to get a nice results?
>>
>> Best regards
>> Guangming
>>
>>
>>
>>
>>
>>
>>
>>
>> *Guangming Zang (Alex)*
>> *King Abdullah University of Science and Technology(KAUST)*
>> *University of Chinese Academy of Sciences(UCAS)*
>>
>>
>>
>>
>> 2015-07-27 16:02 GMT+03:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>>
>>> No I expect forward projection to be longer than backprojection
>>> although with optimal implementations, it should take about the same
>>> time since they have the same complexity.
>>> I have 4 cores on my laptop. I don't see how it explains it, try to
>>> find out where does SART spend the time.
>>> Simon
>>>
>>> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang
>>> <guangming.zang at kaust.edu.sa> wrote:
>>> > Hi Simon,
>>> > sorry for the mistake, not"the backprojection should take much longer
>>> time
>>> > than
>>> > sart algorithm" , but "the backprojection should take much longer time
>>> than
>>> > forward projection in sart algorithm".
>>> >
>>> > BTW, how many cores does your computer have?? Mine is 24 cores.
>>> > is it can explain the reason why it takes much longer time on my
>>> computer
>>> > than yours?
>>> > Regards
>>> > Guangming
>>> >
>>> > Guangming Zang (Alex)
>>> > King Abdullah University of Science and Technology(KAUST)
>>> > University of Chinese Academy of Sciences(UCAS)
>>> >
>>> >
>>> >
>>> >
>>> > 2015-07-27 15:28 GMT+03:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>>> >>
>>> >> I can try. Forward and back projection have the same algorithmic
>>> >> complexity but voxel based backprojection benefits from several
>>> >> optimizations in terms of memory management and computations that
>>> >> makes it faster. The best is to look at the code for further
>>> >> details... although both have far from being optimal. And I did not
>>> >> get the sentence "the backprojection should take much longer time than
>>> >> sart algorithm." because SART contains a backprojection and other
>>> >> steps so SART is obviously longer than the bp alone.
>>> >> Your log is strange and I don't see what steps are not timed that
>>> >> would take most of the time. I did the same test on my computer and
>>> >> here is my result:
>>> >>
>>> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo
>>> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha
>>> >> --dimension 512
>>> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha
>>> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension
>>> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time
>>> >> 1
>>> >> Recording elapsed time...
>>> >> SARTConeBeamReconstructionFilter timing:
>>> >> Extraction of projection sub-stacks: 0.288571 s
>>> >> Multiplication by zero: 0.131672 s
>>> >> Forward projection: 34.3612 s
>>> >> Subtraction: 0.203409 s
>>> >> Multiplication by lambda: 0.146459 s
>>> >> Ray box intersection: 1.30755 s
>>> >> Division: 0.187294 s
>>> >> Multiplication by the gating weights: 0 s
>>> >> Displaced detector: 0.278408 s
>>> >> Back projection: 11.8456 s
>>> >> Volume update: 0 s
>>> >> It took... 53.2765 s
>>> >>
>>> >> Simon
>>> >>
>>> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang
>>> >> <guangming.zang at kaust.edu.sa> wrote:
>>> >> > Hi Simon,
>>> >> > Thanks for your reply.
>>> >> > would you pls help and explain why backprojection is expected to
>>> take
>>> >> > shorter time than forward projection?? because i was thinking if no
>>> >> > caching
>>> >> > step, the backprojection should take much longer time than sart
>>> >> > algorithm.
>>> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the
>>> time
>>> >> > consumed of 3 times's sart, which much slower than my own
>>> application.
>>> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are
>>> 360
>>> >> > shapp-logan projections(512*512 resolution each)
>>> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o
>>> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection
>>> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin
>>> >> > -64,-64,-64 -l 0.5 -n 3 --time 1
>>> >> >
>>> >> > and i will try reader->Update() like what you said.
>>> >> > Thanks
>>> >> > Guangming
>>> >> >
>>> >> >
>>> >> >
>>> >> > Guangming Zang (Alex)
>>> >> > King Abdullah University of Science and Technology(KAUST)
>>> >> > University of Chinese Academy of Sciences(UCAS)
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit <simon.rit at creatis.insa-lyon.fr
>>> >:
>>> >> >>
>>> >> >> Hi Guangming,
>>> >> >> It's not surprising to me that the backprojection is faster than
>>> the
>>> >> >> forward projection, that's what I expect. If the total time is
>>> longer,
>>> >> >> that's probably that some individual steps are not included in the
>>> >> >> total
>>> >> >> time. Can you try to add
>>> >> >> reader->Update();
>>> >> >> before the line
>>> >> >>
>>> >> >> itk::TimeProbe totalTimeProbe;
>>> >> >>
>>> >> >> in rtksart.cxx? It may be that all the reading operations are done
>>> but
>>> >> >> not
>>> >> >> timed in the sart->Update(). Why they are so long, I don't know, is
>>> >> >> your D:
>>> >> >> drive a network drive? Do you observe the same behavior if you do
>>> >> >> rtksart 2
>>> >> >> times in a row?
>>> >> >>
>>> >> >> Simon
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang
>>> >> >> <guangming.zang at kaust.edu.sa> wrote:
>>> >> >>>
>>> >> >>> Hi RTK community,
>>> >> >>> i am using SART algorithm to reconstruct an object.
>>> >> >>> But in this new RTK version, the time recording seems a little
>>> weird:
>>> >> >>> the total time is 1219.12s , but adding the time cost in
>>> different
>>> >> >>> stages is not 1291.12 s. especially for "backprojection" part,
>>> only
>>> >> >>> 16.6051s
>>> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward
>>> projection
>>> >> >>> part.
>>> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection,
>>> >> >>> respectively,
>>> >> >>> both multi-threading i think.
>>> >> >>> Can anyone tell me what's going on?
>>> >> >>> Thanks
>>> >> >>> Regards
>>> >> >>> Guangming
>>> >> >>>
>>> >> >>>
>>> >> >>> Guangming Zang (Alex)
>>> >> >>> King Abdullah University of Science and Technology(KAUST)
>>> >> >>> University of Chinese Academy of Sciences(UCAS)
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>> ________________________________
>>> >> >>> This message and its contents, including attachments are intended
>>> >> >>> solely
>>> >> >>> for the original recipient. If you are not the intended recipient
>>> or
>>> >> >>> have
>>> >> >>> received this message in error, please notify me immediately and
>>> >> >>> delete this
>>> >> >>> message from your computer system. Any unauthorized use or
>>> >> >>> distribution is
>>> >> >>> prohibited. Please consider the environment before printing this
>>> >> >>> email.
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >> > ________________________________
>>> >> > This message and its contents, including attachments are intended
>>> solely
>>> >> > for
>>> >> > the original recipient. If you are not the intended recipient or
>>> have
>>> >> > received this message in error, please notify me immediately and
>>> delete
>>> >> > this
>>> >> > message from your computer system. Any unauthorized use or
>>> distribution
>>> >> > is
>>> >> > prohibited. Please consider the environment before printing this
>>> email.
>>> >
>>> >
>>> >
>>> > ________________________________
>>> > This message and its contents, including attachments are intended
>>> solely for
>>> > the original recipient. If you are not the intended recipient or have
>>> > received this message in error, please notify me immediately and
>>> delete this
>>> > message from your computer system. Any unauthorized use or
>>> distribution is
>>> > prohibited. Please consider the environment before printing this email.
>>>
>>
>>
>> ------------------------------
>> This message and its contents, including attachments are intended solely
>> for the original recipient. If you are not the intended recipient or have
>> received this message in error, please notify me immediately and delete
>> this message from your computer system. Any unauthorized use or
>> distribution is prohibited. Please consider the environment before printing
>> this email.
>>
>
>
--
------------------------------
This message and its contents, including attachments are intended solely
for the original recipient. If you are not the intended recipient or have
received this message in error, please notify me immediately and delete
this message from your computer system. Any unauthorized use or
distribution is prohibited. Please consider the environment before printing
this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.creatis.insa-lyon.fr/pipermail/rtk-users/attachments/20150727/245be368/attachment.htm>
More information about the Rtk-users
mailing list