I tried to use the light_rad.py to test, buy it showed the error message. Would you help me to fix it?
Thanks~
C:\Medphy>python light_rad.py
Traceback (most recent call last):
File “light_rad.py”, line 1, in
from pylinac.core.image import DicomImage, ArrayImage, FileImage
File “C:\Python\Python36\lib\site-packages\pylinac_init_.py”, line 12, in
from pylinac.ct import CatPhan504, CatPhan600, CatPhan503, CatPhan604
File “C:\Python\Python36\lib\site-packages\pylinac\ct.py”, line 27, in
from skimage import filters, measure, segmentation
File “C:\Python\Python36\lib\site-packages\skimage_init_.py”, line 125, in
from .util.dtype import (img_as_float32,
File “C:\Python\Python36\lib\site-packages\skimage\util_init_.py”, line 17, in
from ._map_array import map_array
File “C:\Python\Python36\lib\site-packages\skimage\util_map_array.py”, line 2, in
from ._remap import _map_array
File “init.pxd”, line 918, in init skimage.util._remap
ValueError: numpy.ufunc size changed, may indicate binary incompatibility. Expected 216 from C header, got 192 from PyObject
I’m interested in implementing this at our center. I’m confused by the Light-Rad difference. It says in your example that:
X is 0.13mm
Left is -0.46mm
Right is -0.72mm.
Am I misunderstanding how the values are being represented? Can you clarify if the sign of the values means that the light field or the rad field is bigger (or does it just mean ‘is to the left’ as opposed to bigger/smaller)? It seems like the X value is half the size it should be?
If you are referring to Landon’s example, I believe the ‘Light-Rad difference: X’ referrs to the the difference in the X direction between the centre coodinate of the light field (as indicated by the central BB from set up to the reticule) and the centre coordinate of the radiation field (derived from the FWHM centre). The equation is along the lines of
x_diff_mm = (x_central_bb - x_rad_center)*px_spac_corrected
Where px_spac_corrected is the correction factor to convert the difference in pixels to millimeters. This is found by the equation px_spac_corrected = px_spac_at_sid * (sad/sid) and those values are found from the DICOM attributes of the file using pydicom.
In his example the central bb (light field) in the x direction is at 319.78px and the radiation centre in the x direction is 319.52px (it will be helpful to know the coordinates of the image in the x direction start at 0 from the very left hand side). This indicates that the light field is shifted to the right with respect to the radiation field by +0.26px (the conversion factor turns this into the 0.13mm which is why I believe you thought it was half what you expected).
So Light-to-Rad is right when positive and left when negative.
Similarly for Y (coordinates of the image start at 0 at the top), Light-to-Rad is positive when light field is shifted to G w.r.t Rad, and T when negative.
As for the Left/Right & Top/Bottom, the sign denotes how much shorter or longer the radiation field edge is compared to the expected field size from the CAX (either 50mm or 75mm). So negative means Rad size is smaller than expected and positive larger than expected.
Sorry that got a bit long winded, but hope that helps.
Using either your or Landon’s code, I have issues processing 15MV images on TrueBeams. Any idea why or how to fix? (I’ve attached a sample)
Ben, using your piece of code, the light field center is determined by the center of the other detected BBs, right?
Is there a reason why you don’t just set the light field to be 75mm from the detected light center and ignore the top plate assuming we’re using 15cmx15cm light field exclusively?
That image wont work with my code without a little modification due to it having more BB’s. I’m assuming you are using the FC-2? Did you use the top plate with this image? I tried it with Landon’s code and I’m having issues with it too. I don’t know if it’s just the window/level, but it looks to me like there’s not much contrast defining the BB’s making it hard for the script to find them. Possibly due to it being 15MV or using too many MU. We only use 6 & 10 MV at our centre so I’ve not tested this with 15MV before. Have you tried with a lower energy?
As for your question about the top plate, I think my thoughts at the time were that SI must have a reason for including a top plate, so I was going along with that. Possibly because having a central BB top plate is another independent setup to the CAX or it could catch if the reticule was misaligned? I’m not sure now though, I don’t see a reason I why it can’t be as you say. Maybe I’ll have a look at changing it soon.
Thanks Ben. Yes, I used the top plate in those images. And yes, they work just fine when using 6X.
I think it makes sense that the top plate tells you where the linac crosshair is.
What imaging mode do you all use to acquire your light to rad images? We are using HighRes Single for our TrueBeams and integrated image (50 MU) for our Clinacs.
Just to update everyone, I tried doing the TrueBeam 15X tests without the FC-2 top plate and still get incorrect placement of BBs.
My temporary solution is to analyze the other energies (10X/15X) in conjunction with 6X. The BB detection (and thus light field parameters) is done using the 6X image only and radiation analysis is done on the images separately.
Sorry for the slow reply. Yes we use HighRes Single on Truebeam to take the image. It works for me for 6MV and 10MV images. Not sure how many MU it delivers, but it’s pretty low. About 5MU?
If you delivered a 15cmx15cm field and removed the FC-2 top plate you will see the incorrect placement of BB detection in both mine and Landon’s code. Landon’s; because it is expecting a central BB, and mine; because it is not expecting to see >4 BB’s.
If you send me some images in the configuration you’d prefer to QC I’ll see if I can modify it to accomodate.
Would something like this work on your 15X Truebeam image? If I change the “roi_size_px” parameter it can either miss the bb entirely or catch too much of the field edge.
Please review my snippet and make sure that I am using the pylinac CT module methods correctly.
