Created offset calculations for Catphan604

[crcrewso]

HU linearity module differences, Fixes #289

[coveralls]

Coverage increased (+0.01%) to 83.858% when pulling eca9821 on crcrewso:CatPhan604HURegistration into 1230dc7 on jrkerns:master.

[crcrewso]

Closed was due to me trying to track down an error message. This was caused not by the code but by the way I was testing it. Code change should work well

[jrkerns]

I'm confused, why are you slicing off the far end?

[jrkerns]

Okay so I tested this on a few more datasets, but they're all Varian so I'd like to ensure this works on other vendors' sets. I added some clarifications.

[crcrewso]

I had removed the distal slice because it looked like there was about 2 mm of contrast material past the end of the wire on that end.

Why is the step size hard coded? What does that number represent?

I have access to GE CT data sets and Varian CBCT. I wonder if anyone has used the phantom with Elekta or if they come with a different phantom.

[crcrewso]

I'm looking at the most recent version and it's pulling the slice one or two more proximal(?) than center.

Also, based on these image sets I'm wondering if the ROI diameter should be reduced to 4.5 mm to ensure that the ROI is always within the Contrast material. Some of those ROI's are right at the boundary.

[jrkerns]

After thinking about this I believe you'll be pretty happy with v2.4 and that this problem is an X/Y problem. Elekta comes with the CatPhan 503 (or used to; I haven't kept up).

-The step size is 2 as a performance hack. The step size is...well, the step size. Using a value of 2 means it looks at every other slice as it walks through the stack. This makes the analysis ~50% faster.
-It does indeed look like the contrast ROIs extend past the end of the ramp for the 604. this is why the "central" slice appears off w.r.t the ramp; it's the center of the contrast ROIs, not the ramp. I'm not sure this is actually a problem though. The ramp is consistent throughout its slices, so an evaluation +/- one or two slices should be consistent.
-In 2.4 you'll be able to construct your own phantom models and can offset the spatial resolution slice offset if desired.
-Also in 2.4, you can override the ROI size to your liking. You can see the upcoming documentation here: https://pylinac.readthedocs.io/en/latest/cbct_docs.html#customizing-module-locations.

Does this solve your problem?

[crcrewso]

Looking at your code and assumptions, I'm seeing a couple of ideological conflcts that I didn't understand before.

Catphan module distances are referenced off of the 528 module slice.

Would you be open to the following idea:

• continue to use your current brute force to find a good starting point for the HU
• calculate where 528 should be and analyze that slice
• analyze the slice before and after (or 2?), slice with 'best' result becomes new 0
• use new 0 and the CatPhan manuals to calculate the actual slices to analyze for each module based on distance.

I don't think the performance penalty would be too much of a pain for the current users.

[crcrewso]

I'm looking at the repository and I can't see the version 2.4 you've referenced. Is there a hidden branch I'm not able to see?