RadDB: Storing and viewing test data

Development on my equipment database has slowed down a bit partly because of being busy at work and partly because the database files on my home computer keep getting corrupted for some reason and I haven’t bothered to figure out why or fix it yet.

The equipment tracking part does pretty much everything I need now (still a few things to take care of), so my latest efforts have been on trying to get the test data locked in my spreadsheets into the database.

I started off using the PhpSpreadsheet package (which is still under development), but I found a lot of what was in the documentation wouldn’t work. I ended up going to the older PHPExcel package instead. Using this made it relatively easy to create some Laravel Artisan commands that pick out the test data from my spreadsheets and stick them into the database. Now I can batch add data to the database using a simple shell script. One problem with the current commands is that they won’t work with older version of my spreadsheets yet because the locations of some of the data has changed over time. Not sure I’m too worried about that yet. They also don’t handle problems very gracefully yet. Something to work on later perhaps.

The DB schema for the test data is still being worked on, but I think I’ve got something that will let me pick out data for an individual survey, as well as show a time series from a specific test for a given machine.

Current works in progress are views to display the test data. I’ve got a few done, but still have a bunch more to do.

I love how easy doing all of this has been with Laravel.

An array of focal spots

Some time ago, I came across an image acquired using a pinhole array that showed very nicely how the effective focal spot changes across the image receptor due to the x-ray tube anode angle. I don’t recall if it was in a textbook or a paper, but it’s something I’ve been wanting to replicate for myself to include in my teaching file.

I found some ~1 mm thick sheet lead left over from from some past experiments and punched a bunch of holes in it on a 10 mm grid using a push pin.

Pinhole Grid
1 mm pin holes on a 10 mm grid punched into a sheet of lead

After some experimenting to find a decent x-ray technique to use, I ended up with these two images for the large and small focal spots.

Large focal spot 81 kV 1mAs
Large focal spot. Acquired at 81 kV, 1 mAs, 181 cm SID
Small focal spot 81 kV 1mAs
Small focal spot. Acquired at 81 kV, 1 mAs, 181 cm SID

I’ve chosen to invert the grayscale to use a black background instead of the normal white to make the focal spot images easier to see.

The pinholes are a little bit on the large side (~1 mm diameter) so the focal spot images aren’t as well defined as what I’d have gotten using a pinhole camera (which has a ~0.1 mm diameter hole), but these are good enough for demonstration purposes.

What’s going on here?

In all x-ray tubes, the tungsten anode is angled about 12-17° from the perpendicular relative to the anode-cathode direction, as shown in the image below (taken from Review of Radiologic Physics by Walter Huda).

Line focus principle
Diagram illustrating the line focus principle

When most people think about the focal spot of the x-ray tube, they’re thinking about the effective focal spot (F). The focal spot size of a tube is specified along the central axis of the beam perpendicular to the image receptor. If you were to look up from the image receptor to the x-ray tube (along F), you’d see a tiny little rectangle where the x-rays come from.

Now, consider the situation where we move away from the perpendicular to some other location along the image receptor. Now if you look back at the x-ray tube, the effective focal spot size has changed (G and H).

Effective focal spot size from different locations
Effective focal spot size from different locations

The effective focal spot gets larger as you move toward the cathode, and smaller moving toward the anode. In addition, the shape of the focal spot changes as well. This is most easily seen in the large focal spot image above.

This effect has some interesting ramifications when it comes to talking about focal spot blurring. Because the effective focal spot size changes across the image receptor, this means the amount of focal spot blurring also changes across the image receptor.  Fortunately, focal spot blurring is relatively small compared to other sources of blurring in medical imaging, so even though focal spot blurring varies across the image, it’s not a huge thing to worry about.

RadDB: Radiology Equipment Tracker

Long ago, when I first started at MUSC, I inherited a stack of binders that contained all the reports for the imaging equipment that needed to be tested annually.

There was a total of about 50-55 or so  units, and for the first couple of years, I’d find a few units here and there that weren’t in the binders, but still needed annual testing. By the time I was reasonably sure I had all of them accounted for, there were around 70 units.

For a while, I could keep track of all the units and when they needed testing in my head for the most part. I knew I was going to need a better system to keep track of things though.

Around mid-2001, I came up with what seemed to me to be a reasonable database schema to store everything in, and cobbled together a bunch of PHP scripts (back when PHP was used mostly for templating and generating dynamic HTML pages) to serve as the front end.

It worked pretty nicely, but adding anything new was a fair bit of work and my scripts didn’t really interact with each other. On my list for a long time was to rewrite the whole thing as a more self-contained web application that would be easier to maintain and enhance. Work and life kept me busy, and my scripts worked well enough that there wasn’t a whole lot of motivation to revamp everything (“If it ain’t broke…”).

Fast forward 15 years later to 2016. With my equipment inventory at around 175 units, people discovering my project, and asking for new functionality, there was significantly more motivation to rewrite everything. I spent a few months in early 2016 checking out various PHP frameworks before settling on Laravel.

The RadDB project kicked off around May of 2016. With most of my programming time happening during short windows between testing equipment, and after work, I managed to replicate about 80% of the functionality of my original hodge podge of scripts by the end of 2016. With the start of the new year and a new round of testing, I decided that RadDB was ready for production, so I set it up on my desktop at work and released it into the wild.

I use it to:

  • keep an inventory the imaging units and x-ray tubes I need to lay hands on each year
  • add/edit new imaging units and tubes
  • generate reports on the types of machines, where they’re located, and who made them
  • track when they were tested
  • track any problems I might have found during testing
  • tell me what machines
    • still need to be tested
    • which ones have been scheduled for testing
    • which ones have already been tested
  • store test reports and service reports
  • track calibration dates for my test equipment

Still a lot of work that needs to be done on the project. Most of the other features I want to implement involve learning other parts of Laravel (authentication, services, unit testing) so I don’t think those will be too hard to get done.

I’ve really enjoyed working on this rewrite, and learning how to use Laravel in the process. It’s a pretty cool framework and easy to learn. For the most part, I can imagine what I want, think about how to do it and then code it up without having to do a lot of mental gymnastics and translating to get it to work. I’m looking forward to doing other projects in Laravel.

 

Climbing the Laravel learning curve

After checking out several different PHP frameworks, I settled on using Laravel for redoing the x-ray equipment tracker that I use at work. It’s been a TODO project on my list for quite a while now and for the past couple of months, I’ve been studying the Laravel docs, writing up the redesign of my project and trying to put together some code.

I’ve managed to learn how to use Laravel enough to implement some simple tasks such as displaying lists of the x-ray units stored in the database. It’s actually been surprisingly easy, and I haven’t really had to write a whole lot of code. For the simple tasks that I’ve implemented so far, Laravel has done most of the heavy lifting. I just write the code to say what I want and how to display it, and Laravel does the rest.

So far most of the work I’ve had to do was in redoing the database schema to match the conventions used by Laravel’s Eloquent ORM. That mostly involved renaming tables and indexes, and trying to figure how to define the relationships in the model files.

Still have lots of learning and work to do, but I’m making progress. Baby steps.