Winston Lutz - inconsistent "unable to locate BB" error

Hi all,

I’m running pylinac 2.3.2 on Ubuntu, and have been testing the WinstonLutz module with Elekta iView images.

I’ve created a step+shoot beam sequence to cycle through gantry angles in 60 degree steps (7 images to inc both +/-180), and collimator also in 60 deg steps all at gantry0 (5 images, as gantry0coll0 already done).

I’ve scripted the automatic naming of the images knowing the sequence they are delivered in, and so use WinstonLutz(path, use_filenames=True)

The first couple of sets of images from one linac were analysed fine, I’ve since acquired some more at another energy and also on another linac, but for these I get an error:

Traceback (most recent call last):
File “/home/wocqat/venvs/qatrack3/lib/python3.6/site-packages/pylinac/”, line 680, in _find_bb
bw_bb_img = np.where(labeled_arr == np.argsort(roi_sizes)[-3], 1, 0) # we pick the 3rd largest one because the largest is the background, 2nd is rad field, 3rd is the BB

IndexError: index -3 is out of bounds for axis 0 with size 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

File “”, line 1, in
File “/home/wocqat/venvs/qatrack3/lib/python3.6/site-packages/pylinac/”, line 116, in init
self.images = ImageManager(directory, use_filenames)
File “/home/wocqat/venvs/qatrack3/lib/python3.6/site-packages/pylinac/”, line 72, in init
img = WLImage(file, use_filenames)
File “/home/wocqat/venvs/qatrack3/lib/python3.6/site-packages/pylinac/”, line 607, in init = self._find_bb()
File “/home/wocqat/venvs/qatrack3/lib/python3.6/site-packages/pylinac/”, line 693, in _find_bb
raise ValueError(“Unable to locate the BB. Make sure the field edges do not obscure the BB and that there is no artifacts in the images.”)
ValueError: Unable to locate the BB. Make sure the field edges do not obscure the BB and that there is no artifacts in the images.

I’ve visually inspected a set of images which work, and a set which fail, and I cannot see any tangible difference in the appearance of the images.

After some trial and error, I found that if I replace the coll60, coll120, coll 240 and coll300 images with the equivalent images from the set which work, then the error goes away. There must be something about these particular images which is preventing detection of the BB.

Links to zip files of example image sets (both 6MV but from different linacs):

Broken: - Google Drive
Working: - Google Drive

If anybody can shed some light, I’d be very appreciative!

Also, is there any reason why I shouldn’t use 60 degree steps?

Many thanks,

Hi there,

I didn’t check it myself, but by the looks of it the first seven images should work without a problem. And image number 10 should also work. Others may not because the field is rotated and the bounding box is very large. When pylinac is searching for the BB it decides if the BB was found , among other things, by the size of the region tested. In your case all the rotated fields will have huge bounding boxes and the ratio of tested BB region area vs bounding box area will not be withing tolerance, therefore the region will not be accepted. Hence pylinac will not find the BB.

I suggest that you decrease the size of the field to, say 5x5 or even better 3x3. Then everything should work.


Regarding the selection of angles. The more angles you have the better will be your sampling. If you are doing this test once a year then it is good to use many angles for the gantry, collimator and couch. But if you o it frequently go with less because your findings will not get that much different.

Yeah it is probably not the bounding box. Sorry.

Thanks Denis, if nobody has any other suggestions I may try a smaller field anyway…

Hi again. it turns out that the problem really is the ratio BB/field size.If you really need to analyze images with such a large field, you can lower the tolerance for the BB finding algorithm. Go to module, find function is_modest_size and change the return to:

rad_field_area * 0.001 < np.sum(logical_array) < rad_field_area * 0.3

Hi Denis,

You were right, that solves the problem. I don’t need to use such a big field so I’ll change the field to 5x5 rather than change the code.

Many thanks for your help!