Parameters in FlatSym module

Hi James

My apologies for being so quite on the pylinac front. I’ve been assisting with some other software and implementing FFF parameters in my own. I would like to bring what I have learned to pylinac and extend the FlatSym module with more parameters.

Although the FlatSym module can be extended easily as it stands I would like to refactor the module a bit and make all the parameters such as field edge and penumbra definable in a protocol set. This is to accommodate FFF parameters where the standard definitions of field edge (FWHM) and penumbra don’t hold.

I would also like to make the protocol set definable to make it easier to define a protocol as a set of parameters.

So essentially what I am proposing is something along the lines of:

“”“Function definitions for parameter calculations here
.
.
.”“”

PROTOCOLS = {
‘varian’: VARIAN_PARAMS,
‘elekta’: ELEKTA_PARAMS,
‘DIN’: DIN_PARAMS,
‘IEC’: IEC_PARAMS,
‘FFF’: FFF_PARAMS,
etc.}

VARIAN_PARAMS = {
'Field Edge: get_field_edges,
‘Field Size’: get_field_size,
‘Penumbra’: get_penumbra,
‘Symmetry’: symmetry_point_difference,
‘Flatness’: flatness_varian
}

We would need some kind of workaround for backwards compatibility, but in general do you think something like this would work and would you like to see it in pylinac?

Regards
Alan

Hi

The good news is that I have found a robust algorithm to do the sigmoid fitting for the field penumbras. See examples below.

The bad news is that maintaining backwards compatibility with the “analyze” function is a problem. It is possible using some form of multiple dispatch, but it adds a dependency and every possible calling form of the analyze function has to be catered for. It may be easier and cleaner to simply define a new module flatsym2 and put deprecation warnings in the original flatsym.

Comments and thoughts welcome.

Regards
AlanTest.pngTest4.pngTest5.png

Test3.png

Hi Alan,
Thanks for looking into this. Generally speaking, 2 is a bad approach since no one knows what it means. If you’re keen on this, make a pull request and instead of a new module make a new analyze function (e.g. .analyze_via_sigmoid()) that can be called instead of the original analyze function.

I’m a bit unclear on how field size, penumbra, and field edge detection parameters would be different between manufacturers, but I welcome new ideas.