A curated list of open source healthcare software, tools and resources
github.com
github.com
Back when I had a tympanomastoidectomy (how's that for a medical mouthful?) they gave me the images of the before/after CT scans on CD. I used OsiriX to view them and it totally blew my mind. While the "lite" (free) version wasn't exactly like the medical-grade imagery, it was close enough to make me very familiar with every nook and cranium. (sorry for the pun, the CT scans were of my skull!)
When you look at the images individually, it makes it more obvious and simultaneously more fascinating how the software maps everything into a 3D image. It's actually not that complicated as long as each layer of the scan is consistent. Basically they are a greyscale version of http://thescienceexplorer.com/brain-and-body/dead-body-slice... that the software interprets and colours. I assume DICON viewers could easily interpret the sliced dead-body images because of that.
I'm very happy to see that DICOM viewers have since appeared in open source. I look forward to re-imaging my scans to see what shows up.
More on topic -- I always wanted to write a DICOM-diff to make before/after comparisons, which can also be useful in seeing progressions over time, but don't have the knowledge for the graphical interpretation of each pixel on a 3D plane. But with an open-source solution, that part is already done and I just have to think about a plugin or new menu item for alignment and highlighting in an already-existing package.
1. github.com/brenthuisman/medimage
2. github.com/brenthuisman/dosia
DICOM itself is baroque but at least some of the complexity can be managed by easily available libraries. If you want to play with this stuff 3DSlicer (see the fine article) is a good starting place - access to a lot of ITK filters etc. without direct programming.
For example, you can fairly easily do your "diff" idea there (usually called a subtraction image) directly. It turns out this is not as useful as you might first think, although CT images are much less problematic than, say MRI. Still it's mostly used for contrast pairs (i.e. images taken in the same session, one baseline and one with a contrast agent). With much time between scans you often need to do more work.
I was thinking specifically about my case, which is all bone. It should work for that, but you're right about the rest. So my idea is probably of limited interest.
1. CT images measure densities of tissue (in Hounsfield units).
2. The images will first need to be aligned/registered/fused. There are different ways to do this but it can be difficult if the two scans were done with different protocols/hardware as the image resolutions and dimensions can differ but also anatomy regularly changes (not as much in the head area).
3. Fusions are often described as having a primary (unchanged) and a secondary (the image that's modified to align to the primary).
4. Fusions can be very basic rigid alignments (like moving one photo on top of another) or be fancy by moving voxels independently (often called deformable registration, like cutting a photo into squares and moving them) however these are difficult to evaluate for correctness.
5. Fusions are often viewed as a transparency overlay of one image on top of another (in the case of deformable it's the deformed image over top the primary).
6. After doing a fusion a subtraction can be performed to find the difference in image values (the densities).
Best of luck and enjoy the field.
1. There is a lot of terminological abuse in this area, but fusion is properly a display (or production of new images) technique, (co-) registration is the mapping of one image to another.
2. You almost certainly do not want deformative or even affine transforms in the registration of same patient bony anatomy in CT (because it is stereo-tactically accurate). You want a rigid transform here. Also because of CT you can rely on the units are meaningful so you don't need to normalize.
3. Because you are doing rigid transform only , you should not resample the moving image here (could be both images move, more often as you describe). Most package will get this wrong. Save the resampling for the end and do it once.
4. You will have to resample one or both images, as their underlying lattices will not be aligned. There is a bit of subtlety here, but in the OPs case probably best to sample both to a similar isotropic grid (e.g. 1mmx1mmx1mm) and subtract.
5. You can do the resampling explicitly or implicitly (i.e. as part of computing the subtraction) but either way use a proper smoothing filter not tri-linear interpolation.
6. Oh, a note - your original images are probably 12 bit encoded in 16 bit ints, make sure your loader isn't truncating or rescaling to 8 bit.
I also put an interview with one of the developers in each email.