jrkerns / pylinac Goto Github PK

TG-142 states that beam profiles (flatness & symmetry) should be analyzed against a baseline. Currently, the flatsym module only computes objective values. It would be advantageous to be able to load in a baseline image, e.g. taken at the time of commissioning/annual/repair, and the relative profile analyzed to see if it exceeds the 1%/2% relative change.

this function works fine with the demo file, but I get the error
IndexError: arrays used as indices must be of integer (or boolean) type
when I call it on my own data file, at the link below
https://www.dropbox.com/s/mj77xdjqjx4f5qr/ZZ.bin?dl=0

Given that the minimum diameter is found using an evolutionary algorithm it is understandable that results can vary. Unfortunately, results can vary widely, creating an unnecessarily wide range of results. A more predictable minimization function should be used.

Trajectory log creation also (most of the time it seems) makes a *.txt file, which carries a few pieces of additional information like patient ID, plan name, and beam energy. If the txt file is in the same directory it should be incorporated into the MachineLog data

The Winston Lutz analysis looks for the BB using a few conditions. Unfortunately, it would not discriminate between very small looking ROIs (noise) and the BB. A minimum size criteria should be added.

The calculation of the phantom z-offset is not being applied when passed.

There were sporadic problems with reading in the txt file before, but I think I've got a handle on it now. When a blank line is encountered (sometimes but not always the case) splitting the item in two crashes the process.

This can be fixed by checking the length of the line.

pylinac is installable in python 2, but will fail as it has certain py3-only components. pylinac should issue a warning if trying to use pylinac on py2, before an error raises that is not immediately apparent what's going on.

This is apparently caused by default Python behavior.

The most common issue is that a starshot image has a uint8 or uint16 data type. When manipulating profiles to find the FWHM or FWHM center, the profile may bitwise invert, causing peak searching to be inaccurate.

Trajectory logs generated when taking imaging beams return a NaN for RMS calculations and should return 0.

Another verification of MLC performance could be to additionally load the machine log from a picket fence delivery. This could compare the log picket locations to the EPID picket locations.

The log analyzer currently looks for changes in the beam hold state by taking the diff of the beam hold state array and looking for differences of 1 (e.g. 0 -> 1, 1 -> 2). This does not catch trajectory log holds that go from 0 -> 2. Bug report here; thanks to Anthony for catching it.

The DPI and SID currently can't be passed using the main classes' init methods, but should be able to do so.

CR images can have an RTImageSID tag, but may not be valid (i.e. not numeric). This causes an error in the starshot algorithm.

As of April 21st, Varian has re-released RapidArc QA files and procedure details. The VMAT module will be reworked for v0.6 to conform to these specifications.

For logs where none of the leaves move for the entire treatment, the log crashes when asking for the RMS.

The CBCT module would account for roll of the phantom, but this is being applied the wrong way for the spatial resolution slice and HU linearity nodes.

the treatment type property is not working for dynalogs.

Add the ability to perform a gamma analysis on an arbitrary Image. This is probably easiest to implement by adding a method to the base image class. The gamma algorithm is already implemented for the log analyzer; it simply needs to be generalized for an Image.

Several conditions are nullifying Leeds analysis. This is largely due to the uneven background of various images. kV imagers are performing very differently, as well as the various exposure protocols allowed.

Non-local filters and histogram equalization would help; unfortunately these are in the skimage libary and has not been incorporated into pylinac...yet.

The wobble calculation doubly-accounts for the SID. For SIDs of 100cm, this doesn't matter, but skews results to be smaller than reality for SID >100.

Oftentimes a physicists will add a mark or pin prick to the image to know the orientation of the image. These usually cause extreme values, and can cause analysis to fail because the image inversion goes the wrong way.

ReadTheDocs currently does not have matplotlib for the Python 3 build interpreter, and a pip install fails, thus, the matplotlib directive can't be used. When RTD gets matplotlib for py3, then the directives can be used. Until then, pictures will have to suffice.

Sometimes a physicist wants to combined multiple images to form one single image. E.g. a collimator star shot can be formed by taking single EPID images of one specific collimator angle. These single angle images can be superimposed to form a full collimator star shot. Other examples exist.

If a CBCT slice thickness is != 2.5mm, pylinac does not correct for the different thickness.

Easy fix, big mistake.

As pointed out here, the dynalog load order (Bxxx.dlg first vs. Axxx.dlg first) may reverse fluence in the left-right direction

Small but large noise values disrupt the process of finding the pickets/MLC peaks. A small median filter should be added.

When a full ring artifact is present in a CBCT acquisition, the algorithm thinks the ring is the phantom edge, causing all radius-based calculations to fail.

Pylinac is currently an egg; support wheel as well.

kV and MV setup images create a trajectory log, but there are no "beam-on" snapshots, and a crash occurs when trying to calculate the fluence. A zeroes array should be returned.

Pickets are derived from a median profile along each image axis, but if the picket fence pattern itself is smaller than half the image (e.g. a large SSD) then the median will be zero and not detect the pickets. Behavior should take the maximum instead.

During testing when the CBCT demo files are quickly being unpacked/deleted, sometimes the test runner gets tripped up by the OS being too slow and can't load the demo files because an empty folder is left from the unpacked demo files.

MachineLog currently only handles one file at a time. It should be trivial to add batch processing (e.g. a directory), at least for reading in. Batch processing of, say, fluence should be allowable, perhaps through a method.

Wheels consistently builds a .whl file that uses stale files. Unsure why. Fixed by emptying build directory and building again.

As of now, the behavior is to calculate the leaf fluence as one pixel, which does not allow for partially-covered leaves. This may (slightly) affect the gamma score. One solution is to calculate the fluence more realistically in the y-direction. The pixels would simply be mapped to the realistic leaf width.

When calculating the fluence for a trajectory log that was only generated during imaging, the MU is 0 and thus causing ZeroDivision warnings.

Dead pixels outside the field can throw off the thresholding algorithm and not detect the field and/or BB. The algorithm should threshold using percentiles, not a maximum value

Add a method and/or function to anonymize dynalogs and trajectory logs.

Currently, pylinac uses PyQt4 for it's GUI (which is fine), but if a user only wants the API-level interface, it still uses PyQt4, almost exclusively for File Dialogs. This should be converted to something simpler and without a dependency, namely tkinter.

The error between the MLC position and picket fit is signed, causing errors that are on the left (negative error) to not be caught.

Add the ability to load multiple images (e.g. two EPID images) in the picketfence module.

Hi,

I tried to install pylinac using pip on winpython as well as trying python setup.py install but I get the error message no pylinac module found. I have all your dependencies with the latest versions. I have python 2.7.6.

It would be helpful to have methods to save logs to files (CSV, Excel).

Wobble diameter for the starshot is not correct, giving a wobble slightly smaller than what it should be. The point-to-line distance algorithm should be fixed.

conda is the pip for scientific python package management, and binstar seems to be the pypi of conda. Given that pylinac depends on scientific packages, it may be better in some cases to install pylinac via conda.