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....@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 <v...@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 <v...@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 <v...@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@public.kitware.com >>>> https://public.kitware.com/mailman/listinfo/rtk-users >>>> >>>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users@public.kitware.com >>> https://public.kitware.com/mailman/listinfo/rtk-users >>> >> _______________________________________________ > Rtk-users mailing list > Rtk-users@public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users >
_______________________________________________ Rtk-users mailing list Rtk-users@public.kitware.com https://public.kitware.com/mailman/listinfo/rtk-users
