[Rtk-users] Artefacts with GPU-based iterative reconstruction with RTK

[Simon Rit]

Dear Mathé,
Good news! I'm glad it helped.
I'm not sure about the memory issue. Can you indicate the size of the
reconstructed volume and projections? To reduce GPU memory consumption, you
can try --nocudacg which avoid computnig the CG step on the GPU but still
does the forward and backprojections on the GPU. You can also monitor the
memory consumption if you activate RTK_PROBE_EACH_FILTER to track which
filter eats up all the memory (display the report with --verbose).
Cheers,
Simon

On Mon, Aug 24, 2026 at 10:54 AM Mathé Zeegers <M.Zeegers at milabs.com> wrote:

> Dear Simon and other RTK developers,
>
>
>
> Thank you for replying so fast! And also for the suggestion to CC the RTK
> user mailing list.
>
>
>
> Your suggestion of changing the step size was exactly the solution that I
> needed: the reconstructions now look as they should.
>
> Setting the step value equal to the voxel size made the conjugate gradient
> reconstructions initially take very long, until I set the backprojector
> from CudaRayCast to CudaVoxelBased. Now I am very pleased with the
> conjugate gradient performance.
>
>
>
> The only issue that is coming up now, though, is that I get issues with
> GPU memory when I load too many projections (720 to be specific, which in
> our case amounts to 4.00 GB). I get the following error:
>
>
>
> itk::ExceptionObject (0000000408EFE618)
>
> Location: "unknown"
>
> File: ..\include\itkCudaDataManager.h
>
> Line: 54
>
> Description: Cuda Error : an illegal memory access was encountered
>
>
>
> I am working with a GPU that has 20 GB of memory, so I am a bit surprised
> that I get this problem. Also, I do not have this issue with the
> SART/OSSART/SIRT script, and neither do I have it when I use the CPU-only
> option. Are you familiar with this issue? Do I perhaps need to set a
> certain (large-memory) option that I might have missed? The usage of the
> binning option solves the problem, but I would like to use the full
> resolution of the projections. I also tried reducing the reconstruction
> volume size, but this does not change anything. Any pointers on this would
> be very helpful.
>
>
>
> Regarding the discontinuation of the config option: it is not optimal for
> us, but we can work around it by putting back the code for the config
> option in in our local versions or by writing a small wrapper for it.
>
>
>
> Kind regards,
>
> Mathé
>
>
>
>
>
> *Mathé Zeegers*
>
> Preclinical X-ray CT Specialist
>
> m.zeegers at milabs.com
>
>
>
> This message may contain confidential information and is intended
> exclusively for the addressee. If you receive this message unintentionally,
> please do not use the contents but notify the sender immediately by return
> e-mail. MILabs B.V. is a legal person by public law and is registered at
> the Chamber of Commerce for Midden-Nederland under no. 302.075.15.
>
>
>
> *From:* Simon Rit <simon.rit at creatis.insa-lyon.fr>
> *Sent:* Monday, August 17, 2026 2:57 PM
> *To:* Mathé Zeegers <M.Zeegers at milabs.com>
> *Cc:* rtk-users <rtk-users at openrtk.org>
> *Subject:* Re: Artefacts with GPU-based iterative reconstruction with RTK
>
>
>
> Hi Mathé,
>
> Nice to hear that RTK is useful. I have CCed the RTK user mailing list,
> you'll probably have faster answers with it in the future. Luckily this
> time, I'm back from my annual leave today!
>
> I bet the problem is the hard coded step length in the GPU ray casting.
> There's been an update since v2.7.0 to fix this issue
>
>
> https://github.com/RTKConsortium/RTK/commit/990ae96992529ca8f54abe4c1ab48e40950a8092
>
> See
> https://docs.openrtk.org/en/latest/documentation/docs/rtk_3_migration_guide.html#cuda-forward-ray-cast-step-size-default
> .
>
> Can you try setting the --step option to 0.08 to see if it helps? This
> would be the new default of the new version.
>
> I hope it helps,
>
> Simon
>
>
>
> PS: sorry about the --config, it's already been merged
> https://github.com/RTKConsortium/RTK/commit/d0f15386cbc1c89376753469eea23debcdf78a3f.
> The goal was to uniformize the Python and C++ applications. Will that be a
> big issue for you? If yes, please open an issue to trigger a conversation.
>
>
>
> On Mon, Aug 17, 2026 at 1:51 PM Mathé Zeegers <M.Zeegers at milabs.com>
> wrote:
>
> Dear Simon Rit and/or other RTK developers,
>
>
>
> I am writing you to ask for your suggestions as I am stuck with an
> RTK-related problem for a long time now. I am not sure if I have used the
> right e-mail address, so my apologies if I have not.
>
>
>
> Since more than a year, I am working for MILabs as the X-ray CT developer.
>
> For a long time, we have used RTK for GPU-based FDK reconstructions, and
> we have only used an SART in its CPU-based version. We are now looking into
> integrating (more) GPU-based iterative methods.
>
>
>
> I have implemented a GPU-based version of CGLS using the templates from
> the RTK github repository (version 2.7.0, commit eb3fd5b). I use this in
> combination with ITK 5.7.0 and ITKCudaCommon 2.1.0. The problem that keeps
> coming up is that my reconstructions do not look at all like what they are
> supposed to look like with the GPU-based reconstruction. I have attached an
> image to this mail to clarify this.
>
>
>
> In my reconstruction, I use 720 images with the default settings from the
> rtkprojectors_section.ggo file. The number of CGLS iterations is set to 30
> and the voxel size is set to 0.08.
>
> When I run CGLS with forward projector CudaRayCast and backprojector
> CudaRayCast, the result is very grainy and unsharp.
>
> When I change the backprojector to CudaVoxelBased, the result initially
> looks better with a very low number of iterations, but with more iterations
> the reconstruction volume rapidly becomes very stripy and the details
> disappear as well. As a reference, I also ran the CPU reconstruction and
> the results look totally fine in this case.
>
>
>
> I have tried to switch to the RTK implementation of SART/OSSART/SIRT, but
> I encounter the same problem there as well.
>
>
>
> To double check, I have also used the ASTRA and TIGRE GPU-reconstructions
> and these give correct results. Still, I would like to get this
> GPU-reconstruction to run with RTK since in my opinion it is a more
> comprehensive toolbox, and the GPU reconstruction is much faster than the
> CPU reconstruction.
>
>
>
> Do you know what the problem is here and how this can be resolved?
>
>
>
> Please let me know if something is unclear or if additional information is
> required.
>
>
>
> Thank you in advance.
>
>
>
> Kind regards,
>
> Mathé Zeegers
>
>
>
> PS: In the RTK v3 migration guide it is stated that the -config
> command-line option will be removed because it was not known to be used in
> practice. I would like to let you know that we actually use that feature
> very frequently.
>
>
>
>
>
> *Mathé Zeegers*
>
> Preclinical X-ray CT Specialist
>
> m.zeegers at milabs.com
>
>
>
> This message may contain confidential information and is intended
> exclusively for the addressee. If you receive this message unintentionally,
> please do not use the contents but notify the sender immediately by return
> e-mail. MILabs B.V. is a legal person by public law and is registered at
> the Chamber of Commerce for Midden-Nederland under no. 302.075.15.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.creatis.insa-lyon.fr/pipermail/rtk-users/attachments/20260826/ccc8fc5f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 21780 bytes
Desc: not available
URL: <http://www.creatis.insa-lyon.fr/pipermail/rtk-users/attachments/20260826/ccc8fc5f/attachment-0001.png>