[Rtk-users] Problem with itk 4.8.1 when using rtk::FDKConeBeamReconstructionFilter
Notargiacomo Thibault
gnthibault at gmail.com
Thu Oct 15 07:55:17 EDT 2015
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/f685ac7f/attachment-0010.html>
More information about the Rtk-users
mailing list