[Rtk-users] Blurred piece-wise reconstruction
vincent
vl at xris.eu
Thu Feb 13 16:56:14 CET 2020
Well, it worked this time....
V.
On 13.02.20 15:13, vincent wrote:
>
> Hi Chao, hi Simon,
>
> I have to admit that I heavily use the computer on multitasking mode.
>
> I'll make sure that enough RAM is available and test again under the
> same conditions.
>
> Thank you for your help,
>
> Vincent
>
> On 13.02.20 15:09, Chao Wu wrote:
>> Ah, right, I see. itk::MemoryAllocationError.
>> So maybe less than 30 GB RAM is available at that moment...
>>
>> Simon Rit <simon.rit at creatis.insa-lyon.fr
>> <mailto:simon.rit at creatis.insa-lyon.fr>> 于2020年2月13日周四
>> 下午12:26写道：
>>
>> Well, the error was a CPU memory error, not a GPU error. But that
>> should have fitted in RAM, I'm not sure why it didn't.
>>
>> On 2/12/20 1:20 PM, 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
>>>
>
> _______________________________________________
> 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: <http://www.creatis.insa-lyon.fr/pipermail/rtk-users/attachments/20200213/0142d502/attachment.htm>
More information about the Rtk-users
mailing list