Unclear documentation in demo d13_HelicalGeometry.py

[Mr-Blue-Sky-Candy]

Some numbers about helical CT scan simulation is given in this line d13_HelicalGeometry.py

Expected Behavior

offOrigin behaviour should be specified and each of the numbers should be defined. Besides, it is hard to understand the phrase "images in the detector" in the line, '# about 256^3 images fit int he detector with this size.'. It would be helpful to elaborate this.

Moreover, in the demo, default Cone beam geometry is used with square detector array self.nDetector = np.array((128, 128)). However, helical CT scans do not have square detector arrays:

or

Is that array specification correct?

Specifications

• MATLAB/python version: 3.11
• OS: Arch linux
• CUDA version: 11.8.86

[AnderBiguri]

@Mr-Blue-Sky-Candy Thanks for the comments! Indeed some things can be clarified.

Just to start here:

1- TIGRE does not support curved detectors (yet, I need to test this code) (also in python by someone who claimed they tested it)
2- The demo showcases how to simulate the helical movement, but is not specific to any existing scanner, and therefore an imaginary scanner that I made up has a square detector :) In fact, the only time I used this code was in a muCT scanner that indeed had a flat and square detector. Hopefully other demos showcase how to change the rest of the geometry, as its not just the shape of the detector that will need to change, but all the rest of the geometry parameters (DSD, DSO, etc), for your specific scanner.
3- # about 256^3 images fit int he detector with this size. I have absolutely no idea what I meant with this, sorry .... My guess: given the geo.sVoxel of the geometry specified, a 256^3 image (volume) would be projected fully into the detector size. But who knows, its been too long :)

Feel free to suggest/make a PR helping fix the demo to be a little bit more clear, but otherwise I will add it to the TODO list 👍

[Mr-Blue-Sky-Candy]

Shit happens;)

I understood there is no curved detector support and other parameters to change from the other demos. The thing is if I enter the actual values, the image has serious artefacts. Now, I am also working with some made up values because I do not understand the numbers in offOrigin and I have an absolutely beautiful reconstruction:)

In this line , offOrigin is defined as '3x1 or 3xN array with the offset in mm of the centre of the image from the origin.' Is N the number angles so that offset is specified for each angle.

Also, in this line, is the number of loops the total number of loops throughout the scan or the number of loop per slice?

If I understand what I am doing in the end, I would be happy to help. Your software has been really helpful for my PhD.

[AnderBiguri]

Hi @Mr-Blue-Sky-Candy ,

About artefacts: being CBCT so ill-posed, its hard to know what has gone wrong. Any of the parameters gone a little bit wrong would cause serious artifacts. Common culprits can be e.g. the sign of the angles.

offOrigin is the location of the volume to be reconstructed. By default, the center of the volume is in centered around the axis of rotation, but sometimes this is not the case. For example in helical, if we assume the machine is not moving, what is happening is that in each projection, the image gets offseted towards the Z direction (along the axis of rotation). Thus, to simulate helical, you need to offset the image, for each projection (the pitch I think its called sometimes in helical CBCT). offOrigin will be a N (number of angles) sized vector of 3 values each, [x,y,z], where x and y are 0.

I miss you second link though, I think there is a typo. What in particular you ask there?

[Mr-Blue-Sky-Candy]

I am back after some holidays. I fixed the hyperlink my previous but your comment already clarified it. I am trying to debug it with plots right now. Thank you.

[AnderBiguri]

I'll close this for now, but let me know if there are more questions