[Rtk-users] Blurred piece-wise reconstruction

vincent vl at xris.eu
Wed Feb 12 09:49:19 EST 2020


Hi Chao,

I agree with you as far as my particular case is concerned.  But maybe 
it could be a good option for other people to have ?

Kind regards,

Vincent

On 12.02.20 13:20, Chao Wu wrote:
> But streamerBP uses CPUOutputImageType so the 30Go is allocated on RAM 
> instead of GRAM, so shouldn't be a problem...
>
> Regards, Chao
>
> Simon Rit <simon.rit at creatis.insa-lyon.fr 
> <mailto:simon.rit at creatis.insa-lyon.fr>> 于2020年2月12日周三 
> 上午9:28写道:
>
>     Actually, the way I have implemented the streaming, it still
>     allocates the 30Go complete volume and compute it piece by piece.
>     One thing you could try is to remove the streamerBP object,
>     connect directly the reconstruction to the writer
>     "writer->SetInput(pfeldkamp->GetOutput());" and set the streaming
>     in the writer
>     "writer->SetNumberOfStreamDivisions(args_info.divisions_arg);".
>     Then it never allocates the whole volume in memory. If that works
>     for you, I think you can open a PR on github with this change,
>     that makes a lot more sense in my opinion.
>
>     On Tue, Feb 11, 2020 at 8:46 PM vincent <vl at xris.eu
>     <mailto:vl at xris.eu>> wrote:
>
>         Hi Simon,
>
>         yes, I used both in my command line.  I have 64 Go RAM on the
>         machine, so that shouldn't be the issue. For the sake of
>         completeness, I also tried the subset option in combination
>         with the divisions option, going as low as 1, but to no avail.
>
>         I'll investigate further tomorrow.
>
>         Thank you again for your help,
>
>         Vincent
>
>         On 2020-02-11 8:08 p.m., Simon Rit wrote:
>>         Have you tried the combination of both? To be clear,
>>         --divisions acts on the reconstructed volume so it should be
>>         ~7 Go with the "--divisions 4" option (instead of
>>         2000*2000*2000*4/1024/1024/1024=29.8 Go otherwise).
>>         The --lowmem option acts on the projections and you have 250
>>         Mo (instead of 2048*2048*1500*4/1024/1024/1024=23.4 Go
>>         otherwise).
>>         The message "Failed to allocate memory for image" seems to be
>>         a CPU memory issue. Are you sure you have about 10 Go
>>         available to run this reconstruction?
>>
>>         On Tue, Feb 11, 2020 at 7:31 PM vincent <vl at xris.eu
>>         <mailto:vl at xris.eu>> wrote:
>>
>>             Hi Simon,
>>
>>             I am afraid I forgot to mention something in my last
>>             email.  I tried to use the lowmem option, as you
>>             suggested a while ago in the list for the same problem,
>>             but I am afraid I am still getting the same error.
>>
>>             kind regards,
>>
>>             Vincent
>>
>>             On 11.02.20 17:36, Simon Rit wrote:
>>>             Hi Vincent,
>>>             There is a way to do such a thing in rtkfdk with the
>>>             --divisions option, see code here
>>>             <https://github.com/SimonRit/RTK/blob/master/applications/rtkfdk/rtkfdk.cxx#L190-L196>.
>>>
>>>             I also don't really understand either what's going on in
>>>             your bottom reconstruction, it seems to be a geometric
>>>             problem. Have you checked an axial slice?
>>>             Simon
>>>
>>>             On Tue, Feb 11, 2020 at 4:21 PM vincent <vl at xris.eu
>>>             <mailto:vl at xris.eu>> wrote:
>>>
>>>                 Hello RTK community,
>>>
>>>                 I am afraid that my question might not be directly
>>>                 related to the
>>>                 excellent implementation we are all using, but it
>>>                 might still be
>>>                 interesting for some of you.
>>>
>>>                 I have a stack of 1500 projections of size
>>>                 2048*2048.  I obviously can't
>>>                 reconstruct the full resolution volume on my
>>>                 graphics card, as it is too
>>>                 big.  So my solution was to split the sinogram into
>>>                 N parts, for which
>>>                 each reconstructed volume would fit in my GPU memory
>>>                 and then reassemble
>>>                 them.  I did a test with a 700*820*900 sinogram,
>>>                 that I cut in two parts
>>>                 of 700*410(+a small overlap)*900.
>>>
>>>                 While the reconstruction of the whole volume was
>>>                 acceptable, I got a
>>>                 weird issue with the split ones: the one
>>>                 corresponding to the top of the
>>>                 image is also ok, but the bottom one is very
>>>                 blurry.  The three images
>>>                 can be found at the following links:
>>>
>>>                 https://ibb.co/vLk9ZhQ
>>>                 https://ibb.co/m4pm0LT
>>>                 https://ibb.co/Jyf1yKM
>>>
>>>                 I used the same calibration parameters for the three
>>>                 reconstruction.  I
>>>                 visually checked the split sinograms and they looked
>>>                 fine.
>>>
>>>
>>>                 Any insight will be much appreciated !
>>>
>>>
>>>                 Thanks in advance,
>>>
>>>                 kindest regards,
>>>
>>>                 Vincent
>>>
>>>                 _______________________________________________
>>>                 Rtk-users mailing list
>>>                 Rtk-users at public.kitware.com
>>>                 <mailto:Rtk-users at public.kitware.com>
>>>                 https://public.kitware.com/mailman/listinfo/rtk-users
>>>
>>             _______________________________________________
>>             Rtk-users mailing list
>>             Rtk-users at public.kitware.com
>>             <mailto:Rtk-users at public.kitware.com>
>>             https://public.kitware.com/mailman/listinfo/rtk-users
>>
>     _______________________________________________
>     Rtk-users mailing list
>     Rtk-users at public.kitware.com <mailto:Rtk-users at public.kitware.com>
>     https://public.kitware.com/mailman/listinfo/rtk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200212/57387545/attachment-0001.html>


More information about the Rtk-users mailing list