search

jrkerns / pylinac

An image analysis library for medical physics
https://pylinac.readthedocs.io/en/latest/
MIT License
158 stars 99 forks source link

Significant, sometimes silent, Winston Lutz offset occuring in some cases #333

Closed SimonBiggs closed 3 years ago

SimonBiggs commented 3 years ago

In some cases with out of field artefacts pylinac can give a no-error result where the BB and field are offset from reality. An example out of field artefact that can cause this is the following:

image

In the particular case above the BB is not found by PyLinac, but other images with similar artefact patterns do produce a field and BB to both be found, however incorrectly.

The PyLinac result for the image above looks like the following:

image

When the artefacts are cropped out of the image and PyLinac is rerun on the cropped image the result is the following:

image

The following pinned Google Colaboratory Notebook can be utilised to reproduce this issue:

https://colab.research.google.com/github/pymedphys/pymedphys/blob/5c28ad3a36befa328b97f73908d0f1bfcefb0d30/prototyping/wlutz/pylinac-offset.ipynb

SimonBiggs commented 3 years ago

Here is the raw image that produces this issue:

pylinac_offset

SimonBiggs commented 3 years ago

Also, worth mentioning, this isn't causing an issue for me, as my work-around downstream is to essentially crop all images before passing them through to PyLinac. So, just reporting so that you're aware of the issue. No expectation for a fix 🙂.

SimonBiggs commented 3 years ago

Also, if you're interested, I do have a range of other cases where there appears to be deviations to reality on the order of ~0.3 mm. Let me know if you'd like me to collect together that data to submit.

As a note to self, an example case where this smaller deviation occurs is in 00005323.jpg.

SimonBiggs commented 3 years ago

It's quite hacky... but for those who are interested, my internal fix for this is to run PyLinac multiple times, the first time without cropping, then I utilise the first result to define the centre of where to crop and I crop using parameters called "edge_lengths" essentially I crop around the original PyLinac determined centre at twice the maximum edge length. I then repeat that centre finding and cropping process until two consecutive results agree within 0.2 mm. Then finally I march on and undergo the final PyLinac calculation with the crop determined, this time I run PyLinac across multiple versions so that the result of each version can be compared.

The code for this wrapper is over at:

https://github.com/pymedphys/pymedphys/blob/6c09d3ebdf43ca8a804c974ad53dfb579f0ee7ba/lib/pymedphys/_experimental/wlutz/pylinacwrapper.py#L152-L219

Usage of this wrapper can be seen at:

https://github.com/pymedphys/pymedphys/blob/6c09d3ebdf43ca8a804c974ad53dfb579f0ee7ba/lib/pymedphys/_experimental/wlutz/main.py#L125-L137

jrkerns commented 3 years ago

Thanks for the report. I would be far more concerned with how such an image could be made and what problems the linac has than the computation error itself in this case. However, limiting the range of possible positions to near the image center seems easy to do. Added to the list, thanks.

Image uploads are always welcome: here

SimonBiggs commented 3 years ago

However, limiting the range of possible positions to near the image center seems easy to do.

I'd honestly be okay if it was left un-fixed. Limiting to the centre might cause issues when people try and do off-axis Wlutz for testing the veracity of multi-met like cases.

SimonBiggs commented 3 years ago

I would be far more concerned with how such an image could be made and what problems the linac has

If you have any ideas I'm all ears. It only occurs for one energy. For what it's worth Elekta has put that particular panel as end of life and that panel is only used for QA purposes.

brjdenis commented 3 years ago

Hi there Simon. I used to have the same problem with 6 FFF and 10 FFF, but a couple of years ago it was fixed with a new iview version (software) and some calibrations.

SimonBiggs commented 3 years ago

I used to have the same problem with 6 FFF and 10 FFF, but a couple of years ago it was fixed with a new iview version (software) and some calibrations.

Cheers, thanks for the heads up. Our machines themselves are due for replacement in two years-ish, I suspect we won't be getting the iView upgrade. My suspicion with this one is that it's something to do with the synchronisation calibration. But, I don't expect it to get much of a look in any time soon.

Also, I've been meaning to say thank you for the following documents:

https://synergyqatips.readthedocs.io/en/latest/

They are beautifully written. They layout some of our internal ground rules but also expand into areas I had not yet had to tackle, so thank you very much. A very useful problem solving tool and it provides a lovely heads up of a few more things to look out for.