[Rtk-users] Streaming filter in ProjectionsReader

[Chao Wu]

This is exactly my problem.

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.

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.

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?

Regards, Chao
Sent from Samsung Galaxy Note 3
2015年6月11日 11:35 PM于 "Simon Rit" <simon.rit at creatis.insa-lyon.fr>写道：

> 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.
>
> On Thu, Jun 11, 2015 at 11:31 PM, Simon Rit <
> simon.rit at creatis.insa-lyon.fr> wrote:
>
>> 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.
>> 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
>>  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.
>> Simon
>>
>> On Thu, Jun 11, 2015 at 10:52 PM, Chao Wu <wuchao04 at gmail.com> wrote:
>>
>>> Thanks Simon, it is clear.
>>>
>>> I have an issue with rtkfdk. When using cuda, the first several (mini-)
>>> filters in rtkfdk look like this:
>>> file reader -> preprocessing filters -> streaming filter -> cuda
>>> displaced detector filter -> ...
>>> When the streaming filter is updated, all preprocessed projection data
>>> will be store in RAM, which is not a problem so far.
>>> However when executing the cuda displaced detector filter, RAM to GRAM
>>> copy will be triggered. In my case the GRAM is not big enough to store
>>> the data.
>>> 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.
>>>
>>> My previous temporary solution is to use the streaming filter as a sort
>>> of isolator:
>>> Instead of updating the streaming filter in the first step, I only
>>> update the last preprocessing filter.
>>> 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.
>>> Nevertheless looking at your explanations about the purpose of the
>>> streaming filter, I found this is not an optimal solution.
>>>
>>> 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 (#subsetsize
>>> projections). How do you think about this solution? Any better opinions?
>>>
>>> Regards,
>>> Chao
>>>
>>>
>>> 2015-06-11 19:19 GMT+02:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>>>
>>>> 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
>>>> doc <http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>.
>>>> 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.
>>>> There were only pros in our opinion but do you see cons to this
>>>> solution?
>>>> Simon
>>>>
>>>> On Thu, Jun 11, 2015 at 7:06 PM, Chao Wu <wuchao04 at gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Maybe a stupid question... what is the purpose of the streaming filter
>>>>> at the end of the mini-filter pipeline inside the ProjectionsReader?
>>>>> Thanks.
>>>>>
>>>>> Regards, Chao
>>>>>
>>>>> _______________________________________________
>>>>> Rtk-users mailing list
>>>>> Rtk-users at public.kitware.com
>>>>> http://public.kitware.com/mailman/listinfo/rtk-users
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20150611/0556fa39/attachment-0010.html>