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 <[email protected]
<mailto:[email protected]>> 于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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
https://public.kitware.com/mailman/listinfo/rtk-users
_______________________________________________
Rtk-users mailing list
[email protected]
<mailto:[email protected]>
https://public.kitware.com/mailman/listinfo/rtk-users
_______________________________________________
Rtk-users mailing list
[email protected] <mailto:[email protected]>
https://public.kitware.com/mailman/listinfo/rtk-users
_______________________________________________
Rtk-users mailing list
[email protected]
https://public.kitware.com/mailman/listinfo/rtk-users
