Closed brjdenis closed 1 year ago
Hey Denis, that's correct.
The implementation I published here was only tested with fixed jaw plans, which were the ones I had available at that time.
Can you provide anonymized DICOM-RTPLAN files with moving jaws alongside the results you got using ESAPI?
I guess it would not be much difficult to compute the complexity using moving jaws.
Many thanks.
Hi, sorry for the late reply. Sure, I can give a couple of plans. If it is not too much to ask, would it be possible to make ApertureComplexity compatible with Halcyon MLCs as well? Halcyon uses two levels of leaves that are displaced by 0.5 cm laterally. I tried modifying the ESAPI script (https://github.com/umro/Complexity/issues/1) and got some sensible results, but would really like to see the same in your code.
Hey, I noticed you put your C# code here, I can translate it to python easily... https://github.com/umro/Complexity/issues/1
But I have a question, are you handling the overlap between Halcyon's two jaw banks? The aperture computation algorithm actually considers jaw, MLC overlaps only:
When computing the sidePerimeter
Hey @brjdenis, I added Jaw tracking on the complexity computation. Check out the latest commit:
https://github.com/victorgabr/ApertureComplexity/commit/7dbe2f230d0b3b0f3e677fcb7a2a938c720d6621
Can you test that on your plans?
Merged pull request for this issue. https://github.com/victorgabr/ApertureComplexity/pull/5
Hi there! I experimented a little and compared the calculations with varian.esapi. For most plans the result is the same, but for plans with moving jaws, there is a small difference. I think ApertureComplexity does not take into account that each control point may have different positions of the jaws.