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

[Simon Rit]

Dear Mathé,
Thanks for the report. First note that we almost always work with 32-bit
float vlaues in RTK. In any case, you have encountered a real limitation
and Axel has kindly looked into it and believes he's found the issue. It
was indeed a 32-bit limitation. Can you please confirm whether
https://github.com/RTKConsortium/RTK/pull/989 solves the problem for you?
Thanks in advance,
Simon

On Thu, Aug 27, 2026 at 2:09 PM Mathé Zeegers <M.Zeegers at milabs.com> wrote:

> Dear Simon and other RTK developers,
>
>
>
> Thanks a lot for your suggestions. So far, I have not been able to find
> what causes the problem, but I found out a few things which may help.
>
>
>
> The size of the reconstructed volume is 400x400x1313 which with 16-bit
> values is about 400 megabytes.
>
> The size of the projections is 1285x1944x1536 (where 1285 is the number of
> projections), which with 16-bit values is 7.14 gigabytes.
>
> The maximum number of projections I can use with GPU-based conjugate
> gradient is 719, which is 3.999 GB. When I use 720 projections (4.005 GB)
> or more, I get the illegal memory access error from Cuda as in the previous
> mail.
>
>
>
> I have tried to use the nocudacg option, but the threshold remains exactly
> same. Also, resizing the reconstruction volume has no effect on it.
>
>
>
> I have also tried to run the same script on another machine with a GPU
> with 8 GB of memory instead of 20 GB, but the limit of the projections that
> I can load is still 719 (3.999 GB) on both machines. This makes me think
> the limit is somehow imposed by the RTK software (perhaps a 32-bit limit,
> since 2^32 bits is equal to 4 gigabytes).
>
>
>
> The error only happens in the GPU-based version of the conjugate gradient
> code; the GPU-based SART code works fine (with nprojpersubset=1285), which
> I think should rule out problems with my ITK setup. Could there be anything
> wrong with my RTK setup (I can include the CMakeCache file if it is
> helpful), or is it more likely that the issue is caused by a bug in the
> conjugategradient script (or its include files)?
>
>
>
> 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:* Wednesday, August 26, 2026 2:04 PM
> *To:* Mathé Zeegers <M.Zeegers at milabs.com>
> *Cc:* rtk-users at openrtk.org
> *Subject:* Re: Artefacts with GPU-based iterative reconstruction with RTK
>
>
>
> 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/20260904/3135fd5d/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/20260904/3135fd5d/attachment-0001.png>