<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Chao,</p>
<p>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 ?</p>
<p>Kind regards,</p>
<p>Vincent<br>
</p>
<div class="moz-cite-prefix">On 12.02.20 13:20, Chao Wu wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAH+sHrWrsw6hNiSepAosDOK_ndhDOTxajoUTDicgKORAni4TiQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">But streamerBP uses CPUOutputImageType so the 30Go
is allocated on RAM instead of GRAM, so shouldn't be a
problem...
<div><br>
</div>
<div>Regards, Chao</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Simon Rit <<a
href="mailto:simon.rit@creatis.insa-lyon.fr"
moz-do-not-send="true">simon.rit@creatis.insa-lyon.fr</a>>
于2020年2月12日周三 上午9:28写道：<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>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.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Feb 11, 2020 at
8:46 PM vincent <<a href="mailto:vl@xris.eu"
target="_blank" moz-do-not-send="true">vl@xris.eu</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Hi Simon,</p>
<p>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.</p>
<p>I'll investigate further tomorrow.</p>
<p>Thank you again for your help,</p>
<p>Vincent<br>
</p>
<div>On 2020-02-11 8:08 p.m., Simon Rit wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>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).</div>
<div>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).</div>
<div>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?<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Feb 11,
2020 at 7:31 PM vincent <<a
href="mailto:vl@xris.eu" target="_blank"
moz-do-not-send="true">vl@xris.eu</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Hi Simon, <br>
</p>
<p>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.</p>
<p>kind regards,</p>
<p>Vincent<br>
</p>
<div>On 11.02.20 17:36, Simon Rit wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi Vincent,</div>
<div>There is a way to do such a thing in
rtkfdk with the --divisions option, see
code <a
href="https://github.com/SimonRit/RTK/blob/master/applications/rtkfdk/rtkfdk.cxx#L190-L196"
target="_blank" moz-do-not-send="true">here</a>.
<br>
</div>
<div>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?</div>
<div>Simon</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue,
Feb 11, 2020 at 4:21 PM vincent <<a
href="mailto:vl@xris.eu" target="_blank"
moz-do-not-send="true">vl@xris.eu</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Hello
RTK community,<br>
<br>
I am afraid that my question might not be
directly related to the <br>
excellent implementation we are all using,
but it might still be <br>
interesting for some of you.<br>
<br>
I have a stack of 1500 projections of size
2048*2048. I obviously can't <br>
reconstruct the full resolution volume on
my graphics card, as it is too <br>
big. So my solution was to split the
sinogram into N parts, for which <br>
each reconstructed volume would fit in my
GPU memory and then reassemble <br>
them. I did a test with a 700*820*900
sinogram, that I cut in two parts <br>
of 700*410(+a small overlap)*900.<br>
<br>
While the reconstruction of the whole
volume was acceptable, I got a <br>
weird issue with the split ones: the one
corresponding to the top of the <br>
image is also ok, but the bottom one is
very blurry. The three images <br>
can be found at the following links:<br>
<br>
<a href="https://ibb.co/vLk9ZhQ"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://ibb.co/vLk9ZhQ</a><br>
<a href="https://ibb.co/m4pm0LT"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://ibb.co/m4pm0LT</a><br>
<a href="https://ibb.co/Jyf1yKM"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://ibb.co/Jyf1yKM</a><br>
<br>
I used the same calibration parameters for
the three reconstruction. I <br>
visually checked the split sinograms and
they looked fine.<br>
<br>
<br>
Any insight will be much appreciated !<br>
<br>
<br>
Thanks in advance,<br>
<br>
kindest regards,<br>
<br>
Vincent<br>
<br>
_______________________________________________<br>
Rtk-users mailing list<br>
<a
href="mailto:Rtk-users@public.kitware.com"
target="_blank" moz-do-not-send="true">Rtk-users@public.kitware.com</a><br>
<a
href="https://public.kitware.com/mailman/listinfo/rtk-users"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://public.kitware.com/mailman/listinfo/rtk-users</a><br>
<br>
</blockquote>
</div>
</blockquote>
</div>
_______________________________________________<br>
Rtk-users mailing list<br>
<a href="mailto:Rtk-users@public.kitware.com"
target="_blank" moz-do-not-send="true">Rtk-users@public.kitware.com</a><br>
<a
href="https://public.kitware.com/mailman/listinfo/rtk-users"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://public.kitware.com/mailman/listinfo/rtk-users</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
_______________________________________________<br>
Rtk-users mailing list<br>
<a href="mailto:Rtk-users@public.kitware.com" target="_blank"
moz-do-not-send="true">Rtk-users@public.kitware.com</a><br>
<a
href="https://public.kitware.com/mailman/listinfo/rtk-users"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://public.kitware.com/mailman/listinfo/rtk-users</a><br>
</blockquote>
</div>
</blockquote>
</body>
</html>