<p dir="ltr">This is exactly my problem.</p>
<p dir="ltr">There is also a parker short scan filter after the dd filter. If I move the ddf then pssf shall also be moved. This may be too much change. </p>
<p dir="ltr">If I use the CPU version of ddf, I guess the same issue will occur at pssf, then I shall use CPU version of pssf as well. Sounds also a suboptimal solution.</p>
<p dir="ltr">Maybe adding an extract filter between reader and ddf is still the most straightforward way? Then I guess the later extract filter in the fdk will be inplace and do nothing?<br></p>
<p dir="ltr">Regards, Chao<br>
Sent from Samsung Galaxy Note 3</p>
<div class="gmail_quote">2015年6月11日 11:35 PM于 "Simon Rit" <<a href="mailto:simon.rit@creatis.insa-lyon.fr">simon.rit@creatis.insa-lyon.fr</a>>写道：<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sorry, I see what I missed: the whole stack projection is loaded by the displaced detector filter. I think the best would be to move the displaced detector filter in the FDKConeBeamReconstructionFilter, between the extract and the FDKWeightProjectionFilter or to roll back to the CPU displaced detector imagefilter.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 11, 2015 at 11:31 PM, Simon Rit <span dir="ltr"><<a href="mailto:simon.rit@creatis.insa-lyon.fr" target="_blank">simon.rit@creatis.insa-lyon.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Interesting problem. First a comment: normally with mhd files, it only reads from disk what is requested, not the whole projection. I have implemented FDK so that it only request the lines that are necessary for the piece of the volume that is being computed. However, the full projection is read with some input formats that did not implement streaming or if you use the --hannY option or the scatter glare correction. Another comment that crosses my mind: once it's been read from disk once, if you have enough ram, it will be cached and the second time it reads it should be much faster, as if it were in RAM.<br></div>For your solution, I would say that it's already what it does. The reader, the preprocessing and the streaming are encapsulated in the rtk::ProjectionsReader so if you request the full stack from the projections reader, i.e., without<br></div> the --lowmem option, it will compute the whole stack but it will do it one projection at a time since there is a streaming filter encapsulated. Is this not what you observe? Projections will still be loaded substack per substack to the gpu after since there is an extract filter in FDK. In short, don't use the --lowmem option and you should be set. If not, let me know because there is something I'm missing or not working.<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div>Simon<br></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 11, 2015 at 10:52 PM, Chao Wu <span dir="ltr"><<a href="mailto:wuchao04@gmail.com" target="_blank">wuchao04@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks Simon, it is clear.<div><br></div><div>I have an issue with rtkfdk. When using cuda, the first several (mini-) filters in rtkfdk look like this:</div><div><span style="white-space:pre-wrap">     file reader -> preprocessing filters -> streaming filter -> cuda displaced detector filter -> ...</span><br></div><div><span style="white-space:pre-wrap">When the streaming filter is updated, all preprocessed projection data will be store in RAM, which is not a problem so far.</span><br></div><div><span style="white-space:pre-wrap">However when executing the cuda displaced detector filter, RAM to GRAM copy will be triggered. </span><span style="white-space:pre-wrap">In my case the GRAM is not big enough to store the data.</span></div><div><span style="white-space:pre-wrap">I know --lowmem will work but when it combines with --division the projection files will be re-read several times from harddisk, which is quite inefficient and slow.</span></div><div><span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">My previous temporary solution is to use the streaming filter as a sort of isolator: </span></div><div><span style="white-space:pre-wrap">Instead of updating the streaming filter in the first step, I only update the last preprocessing filter.</span></div><div><span style="white-space:pre-wrap">This way, when updating the remaining part of the pipeline, the buffered region of the input of the streaming filter will be the full stack of projections, but the buffered region of the output of the streaming filter will just be the requested region by the cuda displaced detector filter (#subsetsize projections). Then there is no problem to copy this small amount of projections from RAM to GRAM during execution of the cuda displaced detector filter.</span></div><div><span style="white-space:pre-wrap">Nevertheless looking at your explanations about the purpose of the streaming filter, I found this is not an optimal solution.</span></div><div><span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">Now I am thinking to add a simple filter between the streaming filter and the cuda displace detector filter for isolation, so that its input will buffer the full stack of projections after updating the streaming filter, but its output only buffers the requested region </span><span style="white-space:pre-wrap">(#subsetsize projections)</span><span style="white-space:pre-wrap">. How do you think about this solution? Any better opinions?</span></div><div><span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">Regards,</span></div><div><span style="white-space:pre-wrap">Chao</span></div><div><span style="white-space:pre-wrap"><br></span></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-11 19:19 GMT+02:00 Simon Rit <span dir="ltr"><<a href="mailto:simon.rit@creatis.insa-lyon.fr" target="_blank">simon.rit@creatis.insa-lyon.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Not stupid at all. We have recently introduced the possibility to automatically compute the I0 (pixel value without object). This is the filter I0EstimationProjectionFilter in the ProjectionsReader, see graph in <a href="http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html" target="_blank">doc</a>. In many scanners, the exposure varies from frame-to-frame and we wanted this to be projection-specific which is why we did this. We also think that all the preprocessing is more efficient per projection but this is pure conjecture.<br></div><div>There were only pros in our opinion but do you see cons to this solution?<br></div>Simon<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Thu, Jun 11, 2015 at 7:06 PM, Chao Wu <span dir="ltr"><<a href="mailto:wuchao04@gmail.com" target="_blank">wuchao04@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><p dir="ltr">Hi all,</p>
<p dir="ltr">Maybe a stupid question... what is the purpose of the streaming filter at the end of the mini-filter pipeline inside the ProjectionsReader?<br>
Thanks.</p>
<p dir="ltr">Regards, Chao</p>
<br></div></div>_______________________________________________<br>
Rtk-users mailing list<br>
<a href="mailto:Rtk-users@public.kitware.com" target="_blank">Rtk-users@public.kitware.com</a><br>
<a href="http://public.kitware.com/mailman/listinfo/rtk-users" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/rtk-users</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</blockquote></div>