[Rtk-users] Streaming filter in ProjectionsReader

[Simon Rit]

The problem of an extract filter is that you need to set the extract
region, I don't think that the requested region is the default. I would
simply use an addimagefilter with a 0 constant or a multiplyimagefilter
with a 1 constant...

On Thu, Jun 11, 2015 at 11:56 PM, Chao Wu <wuchao04 at gmail.com> wrote:

> 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/20150612/92af4546/attachment-0010.html>