[Rtk-users] Blurred piece-wise reconstruction

Chao Wu wuchao04 at gmail.com
Wed Feb 12 07:20:21 EST 2020


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> 于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> 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> 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> 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
>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>>
>>>> _______________________________________________
>>> Rtk-users mailing list
>>> Rtk-users at public.kitware.com
>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>
>> _______________________________________________
> Rtk-users mailing list
> 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/3cbccfb7/attachment-0001.html>


More information about the Rtk-users mailing list