[Rtk-users] Problem with itk 4.8.1 when using rtk::FDKConeBeamReconstructionFilter

Thu Oct 15 10:50:30 EDT 2015

Interesting... I never used a geometry with negative sdd and sid but that's
the issue here in my opinion. I did a quick test with positive and negative
sdd/sid and that does not work for me either.
Can you make them positive somehow? BTW, do you still use a modified
version of the reg23 and can you share it?
Thanks,
Simon

PS: the script I used for the test:
rtksimulatedgeometry \
    -o g \
    -n 360 \
    --sdd 1500 \
    --sid 1000
rtkprojectshepploganphantom \
    -g g \
    -o p.mha \
    --dimension 256,3,256 \
    --spacing 2
rtkfdk -p . -r ^p.mha$ -o pos.mha -g g

rtksimulatedgeometry \
    -o g \
    -n 360 \
    --sdd -1500 \
    --sid -1000
rtkprojectshepploganphantom \
    -g g \
    -o p.mha \
    --dimension 256,3,256 \
    --spacing 2
rtkfdk -p . -r ^p.mha$ -o neg.mha -g g

On Thu, Oct 15, 2015 at 1:55 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Thank you very much Simon for this advice, I should have read more
> carefully the recent posts about FFTWF / FFTWD.
>
> Now that Itk has been rebuilt using these flags, I no longer experience
> the previous problem.
> Unfortunately, when reconstructing with the CPU version of FDK, it seems
> that, although Ramp filtering and backprojection now do work very well, I
> still have issues with the weighting filter of FDK.
>
> As I am not familiar with analytic reconstruction methods, I don't know if
> the geometric parameters that are generated by the import method of
> Reg23ProjectionGeometry are consistant with the high variability of the
> gain factor applied to my projection by FDKWeightProjectionFilter:
>
> Just a short example:
> When using the following geometric parameters:
>
> SrcToCenter -1045.84
> SrcToDet -1261.02
> srcOffX 6.56918
> srcOffY 6.56918
> ProjOffX -151.44
> ProjOffY -151.44
>
> => FDKWeighting filter outputs an image that has a mean of -1.518 with a
> standard deviation of 2.056  with minimum value of  -6.130  and maximum
> value of  1.871
>
>
> On a frame where the source offset seems to be a little bit lower, I have
> the following gemetric parameters:
>
> SrcToCenter -1042.66
> SrcToDet -1257.4
> srcOffX 1.25469
> srcOffY 1.25469
> ProjOffX -150.321
> ProjOffY -150.321
>
> => FDKWeighting filter outputs an image that has a mean of   -4.279E-4
> with a standard deviation of  5.786E-4  with minimum value of  -0.005  and
> maximum value of  5.268E-4
>
> For comparison, our attenuation images in input of FDK have a mean of  0.8
> with a standard deviation of 1.09  with minimum value of  -1  and maximum
> value of  3.262.
>
> Here the negative values of attenuation arise from a problem while
> approximating the I0 in our images, although we should work on that
> problem, it was not that critical in SART reconstruction.
>
> I am surprised by such an important difference in gain applied to
> projection, given that, when disabling manually this weighting filter in
> RTK code, RampFiltering and BackProjection alone provided visually good
> reconstruction results.
>
> If you have any idea of what could have gone wrong in the process of
> importing geometry and/or applying weighting filter, I would be glad to
> hear it.
>
> Thank you in advance.
>
> Kind regards
>
> Thibault Notargiacomo
>
>
>
>
>
>
>
>
> 2015-10-14 18:58 GMT+02:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> Hi Thibault,
>> No, there is not really a log system that would allow you debugging at
>> run time. You can compile a debug version that would enable a lot of
>> messages related to the pipeline. For this, I think you need to use NDEBUG
>> at compilation (it's an ITK mechanism that I never use).
>> No, it's not normal that you see an error message. There are two things:
>> - the FFT of itk (compiled by default, based on vnl) is really bad IMO:
>> it only handles power of 2/3/5 dimensions and it's slow. I always advise
>> people to use FFTW by turning on ITK_USE_FFTW options during ITK's
>> compilation.
>> - I don't fully understand why vnl doesn't work either. I understand the
>> first two dimensions, for vnl (which I strongly suggest to not use), I pad
>> to the next power of 2 so
>> 780 * 2 (for zero padding) -> 2048
>> 780 -> 1024
>> but then, if you use 64 projections, why 11? Are you sure the second
>> input image to FDKConeBeamReconstructionImageFilter has the dimension you
>> want? I would try to connect input 2 to an itk::ImageFileWriter and check
>> what are the dimensions of this image. If you're absolutely sure, then I'll
>> try to reproduce and fix the issue.
>> Simon
>>
>> On Wed, Oct 14, 2015 at 11:38 AM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Dear all,
>>>
>>> I recently had troubles while trying to rewrite my code, linked with
>>> libRTK / libRTKcuda, from using rtk cuda version of SART, that worked quite
>>> well, to using fdk reconstruction method.
>>>
>>> My first question: is there a general way to enable maximum debug log
>>> level at runtime in rtk ?
>>>
>>> My second question, is more specific: is it normal that I see such error
>>> message coming from itk when using FDKConeBeamReconstructionFilter :
>>>
>>> ExceptionObject caught with fdk->Update() in file [...]
>>>
>>> itk::ExceptionObject (0x7f377c020cb0)
>>> Location: "unknown"
>>> File: [...]/itk-4.8.1/Modules/Core/Common/src/itkMultiThreader.cxx
>>> Line: 416
>>> Description: itk::ERROR: MultiThreader(0x1866340): Exception occurred
>>> during SingleMethodExecute
>>>
>>> /usr/local/include/ITK-4.8/itkVnlRealToHalfHermitianForwardFFTImageFilter.hxx:60:
>>> itk::ERROR: VnlRealToHalfHermitianForwardFFTImageFilter(0x7f377c0207d0):
>>> Cannot compute FFT of image with size [2048, 1024, 11].
>>> VnlRealToHalfHermitianForwardFFTImageFilter operates only on images whose
>>> size in each dimension has a prime factorization consisting of only 2s, 3s,
>>> or 5s.
>>>
>>> I suppose that this error arise while performing ramp filtering, but I
>>> see no relation between FFT configuration stated in the error log ( [2048,
>>> 1024, 11] ) and the size of my input image, which is 780 * 720, over 64
>>> projections.
>>>
>>> I also tried with 200 projection and I had the same problem, but with
>>> [2048, 1024, 34]
>>>
>>> Note that I set my FDKConeBeamReconstructionFilter ProjectionSubsetSize
>>> to the total number of projection in my dataset every time.
>>>
>>> The revision I am currently using:
>>> commit 4993ddfca5b3d59a2fcf71f94890036ede610a08
>>> Merge: 578cf89 09d820c
>>>
>>>
>>> Thank you in advance for your help.
>>>
>>> Regards
>>>
>>> Thibault Notargiacomo
>>>
>>> _______________________________________________
>>> 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/20151015/afb9818e/attachment-0010.html>