Cheese Phantom - CIRS HU-ED

Hi Brains Trust,

Trying to adapt the Cheese Phantom module to the CIRS Electron Density phantom, and initially had some similar problems to the Gammex phantom errors. I implemented the recommendations, with the foam block, which fixed the “non-empty take” error, but Pylinac is now raising a ValueError and looks like it hasn’t found the phantom centre (traceback attached). I’m wondering if it’s due to the fact that the phantom isn’t cylindrical or if it’s another issue?.. Anyway, code also plots an image from the dicom stack before the analysis as a sanity check.

Would appreciate any help and/or insight people may have. Images attached. :slight_smile:


Ethan B. (3.04 KB)

traceback.txt (599 Bytes)

Can’t attach images it seems. Attached as link from onedrive.!AsHNZYx7bb_lg7lktg8hbHJvUiRz4Q?e=ffoMRS

You’re really close. Unfortunately, pylinac also needs a small change, or if you can change your setup just slightly it could work.

Here’s what I get after two tweaks.
hu_origin_slice_variance = 150
localization_radius = 60
catphan_radius_mm = 155

This is 90% of it. There’s an assumption that the localization ring values are mostly near the median. This is true when the ROIs are spaced fairly well apart. I’m using the closer ring of ROIs for localization.
If you want to use this ring then you’ll need to change this line (pylinac/pylinac/ at release-v3.13 · jrkerns/pylinac · GitHub). I used 60 and 20 and with the above changes I was able to get the analysis working.

The reason I didn’t use the outer ring, which probably would’ve not run into this problem is that the localization ring also assumes there are very low and very high HU values. In the catphan there is air and teflon, so that assumption holds true.
In your outer ring there’s no low HU ROI. This will fail the hu_origin_slice_variance test because it tests for HUs below the variance and above the variance. If you can and are willing to swap one of the outer ROIs with air/empty, then you
will likely be able to get this working with just the tweaks from above (albeit with different localization_radius).

I have been thinking about these “detection” tests and how I can rework them. I’m currently thinking of a plugin type framework where the user can specify functions for various things including detection. So in the future you’d write a custom function and it would (in this case) be passed the slice and you’d process the slice yourself to do custom logic.


I’m still getting the same ValueError…which is weird if it’s working on your system. I also tried making a new venv, reinstalling pylinac and then making your suggested changes, same issue. When I’m back in at work will swap one of the outer segments to air (or maybe the lung inhale) and try it again…seems like the easiest fix. Really appreciate your work and support!

That sounds fair, plugins sound great! I love the automation Pylinac provides, but I understand the difficulty in ensuring the system is flexible enough. A thought in that vein, I feel since we already need to input the ROIs to the Cheese module, since we know the geometry of interest (i.e. location and size), then you could pass the ROIs as a sort of initial guess and then, kind of like with the Winston Lutz algorithms, find the area of the inserts near the initial point. I.e. fit/check the circle, verify it’s close to the expected ROI size and then minimise the actual positions to expected positions to find the rotation…something like from scipy transform module I recommended for the MTWL stuff. That way you avoid the HU assumptions r.e. high/low HU…you’s just need to set a contrast-noise-ratio to determine if each circle. Big change vs how it’s currently implemented, but just a thought. :slight_smile:

Once again, thanks for the ideas! Will give it a try next week and report back then…

Hmm, weird. I used the 3.13 version and also master branch and both worked. Let me know if you’re still running into problems.

Took a new scan and it worked with the suggestions provided…except for using the outer diameter…for whatever reason it only seems to work with the inner diameter. shrug.

This is more a point of interest for field testing a project idea at the moment, so will possibly come back around to having a deeper look at the code when I’ve got some more free time. For the moment it gives me the data I need. Thanks again, you’re a legend and really appreciate your support! :slight_smile:

I’d like to support the CIRS phantom since it’s a commercial phantom. Would you be willing to send me those/more scans and/or allow me to use one set as the demo dataset? (I’d clean the basic tags).

So, I ended up messing around with it a bit more, and by pulling the “middle variation” in a bit further, was able to get it to work on my system with the inner ring by using 60 and 40 as bounds rather than 60 and 20.

I’ll check with my bosses, but I can’t imagine there being an issue. Let me know what sort of scans you’d like (kV/mAs/orientations/offsets/etc) and I can scan them one afternoon. Just wondering if it would be useful for pylinac if you had/posted a “wish-list” for images/datasets, so that way people know what would be most useful to contribute? From the outside, I don’t know what y’all would find useful. :slight_smile:

Oooh, a wish-list. That sounds like a great idea. I’ve been mulling over if I should switch forums to something more capable like discourse. That would provide better links, rendering, categorization, etc but I’d have to pay for it. Github also has a forum-like tool but it doesn’t seem as capable. I’ll have to investigate!

Coming back to this. Is the center supposed to be an ROI? It looks like it on the website but you had this commented out.

Looks like it can. “17 locations”

Hi mate,

Absolutely the central insert is supposed to be an ROI. We use a weird central insert locally and commenting the ROI out was for trying to get it to work with existing/old scans. Sorry for the confusion.