Wii Fit, Day 15 (wherein I bitch about OsiriX)

Whoo! Second day below BMI 25-- down to 24.75! And my Wii Fit age, whatever that's worth, is now down to 29. Given that I felt like refried ass when I got home to do this, those numbers are saying something. I'm not sure what they're saying ("Be tired when you work out! That way, the board will think you're doing well!" or "When you're awake, your mind is working so much your body twitches and lowers your ability to balance. Stop thinking, and you'll be younger!"), but hey, it was a nice shot in the arm after a very long day.

Another great part was when it told me that Melodie was spending too much time asleep, and I should wake her up. Not only is the Wii Fit harassing me if I traipse above the 25 BMI mark, but now it wants me to harass my wife as well. Good job, Nintendo!

But really, I spent the morning fixing my car and (re)writing a physics lab report. OsiriX is a program used to view DICOM on the Mac. It's free, but it's got some serious usability problems, and those problems cost me quite a bit of time. First, it converts PET values to SUV values by default. SUV stands for, really, Silly Useless Value-- it's an attempt to calibrate the activity in a location by the amount that should be expected in that area given your probe. So if you're imaging, say, radioactive oxygen, then the lungs should be bright, and if they're not (or rather, where they're not) you've got a blockage in the lungs, and you now know where the blockage is so you can go and remove it. That last bit of information is important; before PET, you could know something was wrong with the lungs, but not necessarily pinpoint it. What was frustrating about OsiriX assigning PET values automatically was that the lab involved imaging a phantom, not any actual tissue, so there really is no baseline expectation from which to draw any conclusions, so the numbers that were being reported for pixel values were all wrong, and I had to rewrite big chunks of it.

The other problem with OsiriX is that it's truly Volume of Interest (VOI) retarded. The region of interest capability of the software is entirely based off of planar selections, and it is impossible (at least from what I could do) to save all of the regions of interest for a 3D PET image. Sure, there were menu options to do so, but none of them worked, so I ended up doing a lot of the VOI stuff by hand, which was a pain. And I really didn't want to do a volume rendering in order to get statistics under the VOI, and the volume rendering capability was all but useless, and wrong to boot. It could not render a simply cylinder, as it kept putting holes in the side.

The program may be useful for a simple viewer and simple DICOM database, but anything more complicated seems to be beyond its reach, or so much of a pain that you'd spend the majority of your time wrestling with the program rather than getting answers you need.

The major problem is that the people who're writing the program have a very crufty attitude towards 3D volumetric data-- they think it's just a bunch of 2D images layered on top of each other. That view is a convenience of the old hack of storing volumes of data as 2D images, and in the age of a modern computer which can handle more than a megabyte of memory at a time, should be banished from any realistic imaging software. I'll say it again: imaging software that thinks of 3D images as 2D slices is WRONG. 2D slices may be a convenience for viewing data on a film, if that's your poison (and I'm not a radiologist, maybe there's some reason beyond "we've always done it this way" for the 2D slice viewing of 3D medical data), but when you're using a computer screen, you should take advantage of modern graphics hardware and treat the data as truly volumetric.

Any software that wants to do so should:
1) Store all data as single blocks of data. There are no separate planes in a 3D data set. I repeat, there are no single TIFF or DICOM planes in a 3D data set, so never save them as such. There is only one block of data, or, if you're backprojecting, the original data itself.
2) Visualize only in 3D. Viewing on axis should be just moving a clipping plane through a 3D dataset, and any axis should be selectable for this treatment, not just the z axis (which is what is normally done now). Hell, if I want my axis to be 45 degrees off from x, y, and z, and I want to step through the data a plane at a time like that, that is extremely simply to do mathematically and provides the user with much more freedom from arbitrary constraints. Anatomic data is not aligned to a grid, and treating it as such may prevent the visualization of useful objects.
3) Use VOI's as entirely 3D datasets as well. Since there are no 2D planes, there are no 2D ROI's either, but 3D VOI's. I should be able to mark regions on my clipping plane, or place a sphere, or use a segmentation threshold (directly on the data, or on some derivative data, like the laplacian) to gather regions. If I want to be particularly snazzy, segmentation routines like Luminita's or Achi's should start to become standard. None of this restriction of drawing VOIs as the sum of ROIs, except as the simplest case. This VOI data should be a full 3D data block, just like my underlying data.

Done with bitching. To work!