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

Thu Aug 27 14:09:17 CEST 2026

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é

[cid:image001.png at 01DD362D.26DF2790]

Mathé Zeegers
Preclinical X-ray CT Specialist
m.zeegers at milabs.com<mailto: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<mailto: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é

[cid:image001.png at 01DD362D.26DF2790]

Mathé Zeegers
Preclinical X-ray CT Specialist
m.zeegers at milabs.com<mailto: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<mailto:simon.rit at creatis.insa-lyon.fr>>
Sent: Monday, August 17, 2026 2:57 PM
To: Mathé Zeegers <M.Zeegers at milabs.com<mailto:M.Zeegers at milabs.com>>
Cc: rtk-users <rtk-users at openrtk.org<mailto: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<mailto: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.

[cid:image001.png at 01DD362D.26DF2790]

Mathé Zeegers

Preclinical X-ray CT Specialist

m.zeegers at milabs.com<mailto: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/20260827/7b1a3522/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 21780 bytes
Desc: image001.png
URL: <http://www.creatis.insa-lyon.fr/pipermail/rtk-users/attachments/20260827/7b1a3522/attachment-0001.png>