Hi, Sorry for the trouble. Cuda 12 is now handled by the master HEAD: https://github.com/RTKConsortium/RTK/pull/589. I'm working on a release. I don't fully understand the other errors but RTK 2.5.0 is not compatible with ITK 5.3 but ITK 5.4rc01 https://github.com/RTKConsortium/RTK/releases/tag/v2.5.0. RTK is only compatible with the latest tag of the release branch and ITK master, see INSTALLATION.md <https://github.com/RTKConsortium/RTK/blob/master/INSTALLATION.md>. I can let you know if the GPU memory issue is expected if you provide more details. There's recently been a fix for memory <https://github.com/RTKConsortium/RTK/pull/598>. Simon
On Wed, Jun 5, 2024 at 12:17 PM Christian Riesch <christian.rie...@live.com> wrote: > Hello Simon, > > I finally managed to build RTK-2.5.0 against ITK-5.3.0 with CUDA support > on Windows with VS2022. > Since I have met some problems along the way, maybe this will help someone: > > - Current CUDA 12.5 doesn't work, 11.8 does. Maybe the documentation > should be updated? See > https://discourse.itk.org/t/about-gpu-version-compilation-of-rtk/5905 > - Before building ITK, I had to add "find_package(CUDAToolkit > REQUIRED)" in the CMakeList.txt of the CudaCommon module to fix a CMake > error > - There still was a linker error in some ITK test project, which I > ignored > - There is a missing const in > ITK-5.3.0\Modules\IO\XML\include\itkDOMNode.h which caused a compiler error > when building RTK. This is fixed in ITK/master > > It also turns out that I apparently don't have enough GPU memory (8GB) to > even use CUDA on full-resolution data: Description: ITK ERROR: CUDA ERROR: > out of memory > > Best regards, > Christian > ------------------------------ > *Von:* Simon Rit <simon....@creatis.insa-lyon.fr> > *Gesendet:* Dienstag, 4. Juni 2024 14:15 > *An:* Christian Riesch <christian.rie...@live.com> > *Cc:* rtk-us...@openrtk.org <rtk-us...@openrtk.org> > *Betreff:* Re: [Rtk-users] Reconstruction geometry > > Hi, > The way I calculate the --neworigin depends on the spacing as it passes > the coordinates of the center of the first pixel which would change if you > bin the data. Maybe you can use the first parameter I gave you originally. > Note that you can keep the full resolution and bin the data with --binning > 6,6 if you'd like, the origin is then automatically adjusted. > For iterative reconstruction, I use rtkconjugategradient by default with a > quadratic regularization of the gradient (parameter --gamma). But be aware > that such truncated data are difficult to reconstruct. BTW, you might want > to try the option --pad 1 to manage truncation in rtkfdk. > Good luck! > Simon > > On Tue, Jun 4, 2024 at 12:41 PM Christian Riesch < > christian.rie...@live.com> wrote: > > Hello Simon, > > First of all, thank you for your efforts. The command line below indeed > produces the best result I have seen using RTK so far. > When going back to the full resolution images, is it correct to just set > --newspacing=0.09, or do I need to modify something else too? It seems that > this results in a much noisier reconstruction compared to the downscaled > images. > > I also remember you mentioning iterative reconstruction. Do you have any > pointers for that, besides using rtksart instead of rtkfdk? > > Best regards, > Christian > > ------------------------------ > *Von:* Simon Rit <simon....@creatis.insa-lyon.fr> > *Gesendet:* Montag, 3. Juni 2024 16:14 > *An:* Christian Riesch <christian.rie...@live.com> > *Cc:* rtk-us...@openrtk.org <rtk-us...@openrtk.org> > *Betreff:* Re: [Rtk-users] Reconstruction geometry > > Hi, > FDK's formula is an integral over 360°. If there is an angular gap above > --short (20° by default), rtkfdk will try to apply Parker short scan. If > you disable Parker's weighting (with --short 360), then you'll get huge > artifact because the two projections adjacents to the angular gap will get > ~135° weights whereas the other projections get ~1° weight. I don't know > what Astra does, it might simply apply a constant angular weights but > rtkfdk is able to calculate non constant weights (which is required for, > e.g. Elekta CBCT acquisitions). > If you want to circumvent that, you can add 0-filled projections at the > beginning and at the end of the acquisition. But rtk also guesses the flat > field constant of your projections so you need to account for that too.... > So I got some results by adding a 7000 filled 000.tif and 092.tif > projections and running > rtksimulatedgeometry -o"geo.xml" -n93 -f-46 --sdd=482.53 --sid=75.46 --arc > 92 > rtkfdk -p . -r '.*.tif' -o fdk.mha --newspacing=0.594 > --neworigin=-151.767,-151.47,0 -g geo.xml --spacing 0.09 --dimension 512 > --hardware cuda --short 360 --i0 7000 > I can't say if the result is good, I don't know what I'm looking at and > 90° is a really short scan. But you can maybe try if it's close to ASTRA's > result. > Cheers, > Simon > > On Mon, Jun 3, 2024 at 11:16 AM Christian Riesch < > christian.rie...@live.com> wrote: > > Hello Simon, > > I realize that a 90° scan only allows for a partial reconstruction of the > volume. This approach seems to be quite common in industrial applications > due to space and time constraints, but I have not found much information > about it in the literature. > The Astra toolbox's FDK implementation seems to cope with this quite well, > at least in the center of the volume. > > The rescaled pixel size should be 6 * 0.099 mm = 0.594 mm. > > Best regards, > Christian > ------------------------------ > *Von:* Simon Rit <simon....@creatis.insa-lyon.fr> > *Gesendet:* Sonntag, 2. Juni 2024 08:00 > *An:* Christian Riesch <christian.rie...@live.com> > *Cc:* rtk-us...@openrtk.org <rtk-us...@openrtk.org> > *Betreff:* Re: [Rtk-users] Reconstruction geometry > > Hi Christian, > Thanks for the share. It was not clear to me that you had a 90° scan > sorry. FDK is not appropriate for such a 90° scan, it's meant for a full > 360° scan. rtkfdk tries to apply a short scan but Parker weighting is for > 180°+fan-angle. So I'm not sure what to expect from FDK with such a scan. > The projections that you shared are 512x511, can you please clarify the > pixel size? I would try iterative reconstruction with such a scan. > Cheers, > Simon > > On Fri, May 31, 2024 at 12:25 PM Christian Riesch < > christian.rie...@live.com> wrote: > > Hello Simon, > > Thanks for the quick response. > So I have tried rtksimulatedgeometry with --arc 273 together with adding > --neworigin=-153.5985,-153.2025,0 to rtkfdk. > The result is different than before, but still looks very wrong (two > ribbons and some vertical lines). > > I may be able to share some data later. > > Best regards, > Christian > > ------------------------------ > *Von:* Simon Rit <simon....@creatis.insa-lyon.fr> > *Gesendet:* Donnerstag, 30. Mai 2024 08:48 > *An:* Christian Riesch <christian.rie...@live.com> > *Cc:* rtk-us...@openrtk.org <rtk-us...@openrtk.org> > *Betreff:* Re: [Rtk-users] Reconstruction geometry > > Hi, > I can see two problems: > - you need to indicate the short scan to rtksimulatedgeometry, e.g. --arc > 273 or, if the angle convention is opposite in your system, --arc -273. You > may have to tune the --first_angle option to position the volume as you > wish but that should not prevent accurate reconstruction. > - you need to center your projections, i.e., add the option > --neworigin=-153.5985,-153.2025,0 to rtkfdk, computed with > -0.5*(3104-1)*0.099 and -0.5*(3096-1)*0.099. > Don't hesitate to share a dataset if that does not help. > Good luck! > Simon > > > On Thu, May 30, 2024 at 6:58 AM Christian Riesch < > christian.rie...@live.com> wrote: > > Hello, > > > > I'm currently trying to use RTK for a reconstruction from a stack of > images that resulted from a 90° scan, but struggling to get the parameters > right. > > On the other hand, I was able to get what looks like a faithful > reconstruction using the Astra toolbox and the script from > https://tomroelandts.com/articles/astra-toolbox-tutorial-reconstruction-from-projection-images-part-1 > > > > I have these parameters from the X-ray device that captured the images > (size 3104x3096): > > "fod_mm": 75.46, (focus to object distance) > > "odd_mm": 407.07, (object to detector distance) > > "pixel_size_mm": 0.099, > > "start_arc_deg": 45.0, > > "stop_arc_deg": -45.0 > > (There is also "detector_offset_mm": 9.8, which I have ignored so far with > both Astra and RTK.) > > > > So I have tried to create a geometry using > > .\rtksimulatedgeometry.exe -o"geo.xml" -n91 -f45 -a90 --sdd=482.53 > --sid=75.46 > > where sdd = fod_mm + odd_mm and sid = fod_mm, > > and a reconstruction with > > .\rtkfdk.exe -p"images" -r".*tif" -g"geo.xml" -o"out.tif" > --dimension=512,512,200 --newspacing=0.099 > > > > However, out.tif contains mostly zeros and a weird ribbon-like shape in > the center. So I think my geometry is wrong, but I don't know how to fix it. > > > > For comparison, here are the input parameters for the Astra script: > > distance_source_origin = 75.46 # [mm] > > distance_origin_detector = 407.07 # [mm] > > detector_pixel_size = 0.099 # [mm] > > num_projections = 91 > > start_angle_deg = 45 > > stop_angle_deg = 135 > > > > Any pointers would be appreciated. > > > > Best regards, > > Christian Riesch > > > _______________________________________________ > Rtk-users mailing list > rtk-us...@openrtk.org > https://www.creatis.insa-lyon.fr/mailman/listinfo/rtk-users > >
_______________________________________________ Rtk-users mailing list rtk-us...@openrtk.org https://www.creatis.insa-lyon.fr/mailman/listinfo/rtk-users
