There is an almost infinite number of colors we could use for the false coloring by spinning the color wheel, but it’s easiest to pick a primary color (red, green, or blue) and use its complementary color for the opposite. Some colors are harder to distinguish against bright backgrounds; think about picking out a bright yellow object against a bright white background. While other colors are harder to pick out against dark backgrounds; blue on black, for example. Is there an optimal choice that’s also inexpensive to compute?

Let’s find out. Here’s what happens when you perform the “What’s different?” test using the three obvious choices of red/cyan, green/magenta, and blue/yellow:

(Click any image to see it larger and/or full-size.)

The blue/yellow version is not very good because it suffers from the problems listed above, while the green/magenta and red/cyan false colorings seem to produce fairly equivalent results. What to do? The ever-practical Loren suggested that we see what happens if we ask people with color-blindness color confusion. Turns out, we know a couple of such folks, but they were in meetings. What to do?

Oh, that’s right!! A while back, I wrote some MATLAB code that simulates the two most common forms of anomalous color vision. Let’s run that and see what happens. (The speckling in the images is an artifact of the conversion and doesn’t represent how they actually look to people with protanopia or deuteranopia.)

The results are a no-brainer! (Sorry about the pun.) While the red/cyan and green/magenta images are very similar for the majority of us with normal color vision, the red/cyan images become very difficult to use for people with any kind of anomalous color vision. Even though the green/magenta starts to look a lot like the blue/yellow row, which has its own issues of color discrimination, it makes a very good compromise. Green/magenta it is.

Conflict of interest statement: I work at a company whose software is used to design, simulate, and (possibly) control various parts of the automated pancreas, but I have no personal involvement in the APP . . . although I’m willing to help out in any way I can. (I also contribute money to JDRF, which is funding the APP.) In addition, among the MathWorks’ various technology offerings are products that can be used for controller design; I make no claims about their fitness for use in a clinical setting. These opinions are my own and may not reflect those of my employer.

Kim has given a very accurate description of the Artificial Pancreas Project (APP) and raised some very valid concerns about it. It’s important to be realistic about what the APP is and is not. We agree that, although it has the ability to change the lives of people with diabetes for the better, it is most definitely not a cure; and it does have a significant amount of risk.

But I don’t think the risks should keep us from moving forward with the APP and seeing it as an important therapy until an actual cure is available. I will lay out why I think it’s important to keep moving forward and trying to get as many people on an AP as safely possible. But first, let’s look at Kim’s three main objections:

1. She doesn’t want to give up control over her personal treatment actions, especially to a system she doesn’t completely trust.
2. Neither CGM nor pumps are “fool-proof or absent of errors.”
3. Faster acting insulins leave little room for error and may lead to more rapid overdose if the algorithms miscalculate or the devices malfunction.

Before I get to each of these, let’s look at why we should welcome an artificial pancreas into our lives. The AP can prevent lows and dampen postprandial excursions. It will get us closer to normoglycemia until researchers develop a true cure to type 1 diabetes. As I understand it, the expectation isn’t perfectly tight “control” — I don’t think that’s realistic to expect from anything other than correctly functioning islets. The goal is to smooth out spikes, eliminate lingering highs, and prevent lows.

Essentially an AP will make the “glucoaster” go away and take most of the burden for balancing insulin and food off the shoulders of people with diabetes (PWDs). We have too many variables to consider when making insulin delivery decisions. In fact, we have heuristics (rules of thumb) instead of rules specifically because we’re treating ourselves without all of the information about the hundred different factors that affect blood glucose (BG), and no one can reasonably expect us to make all of the minute-by-minute decisions required by all those things that affect blood glucose.

Most of us just aren’t as good at achieving our BG targets as we want to be, no matter how earnestly we endeavor to hit them. I’m not being judgmental or suggesting that’s a sign of failure. It’s just a testament to the difficulty of this disease. I think the AP will help reduce the emotional toll of diabetes by helping us get more BG and A1c values that we and our healthcare providers hope to see and by removing a lot of the guilt and despair when our decisions don’t work out as we would like.

It’s natural to be skeptical or hesitant before making big changes, especially when they’re related to our health. But we need to accept our own limitations and fallibility and to accept help from technology when it’s available and reliable.

I don’t want anyone to think that I’m sugar-coating or downplaying the very real risks associated with the AP hardware and with more-or-less removing people from the loop. Every treatment option has risks.* Both multiple daily injection (MDI) and conventional pump therapy have risks. It’s possible to draw up the wrong amount of insulin. Pumps can fail, giving too much insulin or too little. BG meters and CGM sensors can give incorrect information or we can miscalculate the number of carbs in a meal, leading us to incorrect dosing. It’s currently too early to say there is any evidence that the AP has a larger risk exposure than MDI or open-loop pumping.

An AP won’t be any more (or less) fallible than a human pumper. If a pump is going to fail, it’s going to fail. I’ve personally had three pumps fail in about ten years of pumping, one of which led to an overdose of about 40 or 50 extra units of insulin during an infusion set change and two of which led to inoperative pumps. Clearly these are unacceptable events. Every AP pump should be built with even more fault-tolerance and redundancy than the current generation of devices. And it’s likely that some automatic decisions may still require confirmation. For example, if the pump exceeds a certain number of units per hour, the wearer may be required to confirm that they ate or provide an estimate of the number of carbs in the meal.

Based on the kind of questions that the FDA regulators were asking at yesterday’s public workshop, I think the level of testing and validation by the FDA is going to be agonizingly thorough. PWDs will eventually grumble about all the delays getting the AP into our hands. And the legal departments of medical device manufacturers are going to be very reticent to give a thumbs up to any device where “normal use” would cause more risk — and therefore bigger lawsuit costs — than the options currently available.

Furthermore, there’s no requirement that the pumps use the fastest acting insulin available. Patients hopefully will be able to choose whether to use it after consultation with their endocrinologists and gathering feedback from those who are using it. And putting glucose or glucagon in the second chamber of the pump should help reduce the possibility of accidental overdose during normal operation.

Finally, there’s the issue of CGM accuracy. This is the trickiest problem, and the one where I most agree with Kim. I think it’s correct to be skeptical of anything that’s currently in clinical trials — anything that uses CGMS, in fact. Having looked at my own data when I wore a CGM sensor for a week, I saw too many deviations from my BG meter and from how my body felt. Clearly this part of the technology is not sufficient for the fully closed loop that defines the APP.

Does this mean that I’m packing it in? Do I doubt the promise of the whole artificial pancreas project? No. It does mean that I wouldn’t volunteer for a closed-loop trial right now.

But I do think it’s wrong to judge the value of the AP, which is at least 2-3 years away from being submitted to the FDA, using today’s options. What is eventually submitted will have to be much more awesome. Fortunately, CGM technology will continue to improve, and the APP offerings will have to include the most-reliable options or it will likely not be approved.

Is the AP perfect? No. Is it riskier than MDI or open-loop pump therapy. Maybe, maybe not — but that’s not a bad assessment for technology that’s still in the prototype and clinical trials stage. The first regulator-approved offerings (hopefully) will be both more robust and much more accurate.

While it’s important to reiterate that the AP is not a cure — and I sincerely hope that companies selling AP devices never try to market it that way — I think it holds enough promise that I’m willing to set aside my fears about mechanical failures and losing control over the minutiae of a disease that I can’t really control on my own.

* — Remember risk is magnitude of a possible problem combined with the likelihood of that problem occurring.

For me it was also a history of what I avoided by being diagnosed with type 1 diabetes after 1922. Bliss includes a small sample of the lives of some of the people afflicted with diabetes before the discovery of insulin. I was truly inspired by those who were fortunate enough to receive this “miracle drug,” but I was heartbroken by all of the people of that age who didn’t make it because the only treatment was to survive on a meager 500-or-so calories for intolerable months until slipping into the coma of ketoacidosis and then (eventually) death.

It’s been almost 89 years since the first successful clinical use of insulin, but we still don’t have a cure. At best, insulin is the key part of a hormone replacement therapy where people with diabetes try to mimic a pancreas. At worst, insulin is a fickle treatment that is difficult to use, expensive, and out of reach of millions of people worldwide.

While I’m so grateful for what I have — a treatment that gives life — what we need now is a cure . . . even if it’s only useful for people who are not yet sick or are newly diagnosed.

If you’re working on a cure or a new therapy for diabetes, the rest of this post is for you.

I will help you with any technical software aspects of your research that you need. If you have questions about MATLAB or C++, I will do my very best to answer them. If you need help with software design or object-oriented analysis/design, I can help you structure your solution. If you require some help with the non-development aspects of software development — such as project management or using tools — I will help you there, too.

My particular areas of expertise are MATLAB, C++, medical imaging formats (such as DICOM), some familiarity with image processing, and multithreaded programming using Intel’s TBB. I also know my fair share about life with diabetes. I can’t promise that I’ll have all of the answers to your particular question, but I’ll work with you as much as I can. And I’ll connect you with my coworkers as much as I can, if it comes down to that. Finding a cure that’s safe, effective, and universally accessible isn’t my day job, but moving into the third era of diabetes where no one dies from it and no one has to impersonate a pancreas is something I’d love to be a small (even anonymous) part of.

You can e-mail me at work or home, and you can hit me up on Twitter, too.

% Jeff Mather - 3 October 2001
% Connect to meter.
s = serial('com1', 'baudrate', 19200, ...
           'FlowControl', 'Software');
fopen(s);

% Initiate communication.
fprintf(s, 'mem');
fprintf(s, 'log250');

% Read diagnostics.
fgetl(s);   % First line is empty.
meter_ID     = fgetl(s);
software_ver = fgetl(s);
current_time = fgetl(s);
num_readings = str2num(fgetl(s));

for p = 1:num_readings

    reading = fgetl(s);
    sprintf(reading)
    
    pause(0.25);
    
end

fclose(s);

And I ♥ my job. I won’t try to take credit for any of the hard work that JDRF-funded scientists and industry R&D folks are doing to make an artificial pancreas a reality. They deserve all of the credit and so much more. But I know for certain that many people at those institutions and others are using our tools as part of the day-to-day toil of making this a reality. (MATLAB’s graphics have a very *ahem* distinctive appearance, which I’ve seen in presentations about the artificial pancreas and diabetes self-management findings.)

The MathWorks‘ mission statement is that we “accelerate the pace of engineering and science worldwide.” Although it might just sound like nice words on a web site or T-shirt, at times like this it makes me very proud to know that we really do make great things happen faster. And knowing that — even as a peripheral actor — I help with progress, well, that inspires me to do my job that much better, by putting a little more care and polish into my features (especially those related to medical imaging), by rooting out all of the hidden software defects that I might otherwise overlook, and by working hard to get as many of those customer-requested features into the product that I can. That may sound a little corny, but I know that everything I do to accelerate the development of our products helps other people accelerate the creation of their products. And I’m not the only one in the office who feels this way.

Now, back to (indirectly) helping other people fight the good fight. . . .

Here’s one of the reports. It has a bit of everything, including the kitchen sink. The one I’m taking with me to my endocrinologist tomorrow is much more focused. Visualizing all of the data associated with diabetes is kind of tricky, so I’m working on that. More features to come. . . .

(Please, don’t judge me based on my readings. :^) Right now I’m using food to cover my insulin, which is the opposite of how it should work — it seems I never really got switched from the NPH mindset. Getting past that is one of the main reasons why I’m doing in this project.)

I’m committed to releasing everything under some kind of open source license. Everything, that is, except the data and anything that would involve a diagnosis or recommend a particular kind of treatment. I don’t want to be on the hook for FDA approval and all that involves.

Several years ago I read Greenspun’s Tenth Rule of Programming: “Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.” Basically it’s a joke about feature creep in software. I was reminded of this quotation today when I started reading Joshua Kerievsky’s Refactoring to Patterns. He describes the perils of over-engineering, which is basically the same as wasting money.

You see, about seven or eight years ago, I added a Lisp parser to a feature in MATLAB’s Image Processing Toolbox. If you have the toolbox, just take a look in toolbox/images/iptformats/private/dicom_create_IOD.m. There you’ll see a part of the code that looks like this:

function tf = check_condition(expr, metadata)
%CHECK_CONDITION  Determine whether a condition is true.
%
%   Conditions are LISP-style cell arrays.  The first element
%   is a conditional operator, remaining cells are arguments
%   to the operator.
%
%   Conditions can be nested.  Each cell array in expr indicates
%   a new conditional expression.

%[snip]

%
% Process conditional expressions recursively.
%
switch (lower(operator))
case 'and'
    
    % This AND short circuits.
    for p = 1:numel(operands)
        tf = check_condition(operands{p}, metadata);
        
        if (~tf)
            return
        end
    end

[snip]

So why did I do this? The DICOM file format has conditional elements, which only show up in the file if other elements are present, are absent, or have a particular value. I wanted to create a general-purpose, reusable, extensible mechanism for describing these conditions so that I didn’t actually have to write code for all of those conditionals. Moreover, I wanted our customers to be able to write the conditions in a nice tabular form rather than writing code, because — you know — one day they would want to write more of the dozens of kinds of DICOM information objects from scratch than we supported right out of the box.

You probably see where this is going. We ended up extending the product in a different direction after we learned more about how our customers actually wanted to use the DICOM export functionality. So, if you need a Lisp-like algebraic Boolean logic parser in MATLAB, just go look in the previously mentioned file. (Also take a look at the dicom_modules.m file in the same directory to see how to express those conditions.) But for g-d’s sake, ask yourself if you really, really need that, or if you aren’t just fooling yourself into over-engineering your code.

As usual, I learned something new and talked to a lot of people about imaging and MATLAB. Last year, the new-to-me things concerned image quality for mobile devices and image forensics. This year’s big surprises were 3-D imaging, which apparently is going mainstream. (According to Andrew Woods, the chair of the Stereoscopic Displays and Applications conference, there are already two million televisions in people’s homes which are capable of displaying 3D video.) Every year that I attend, I seem to get a different view of the conference; so I’m cautious to read too much into any given year. But somehow, 3D felt different this time.

The exhibitors behind us were demonstrating their more advanced 3D displays and video capture systems, and the person across from us was selling 3D notecards and prints. So my coworker and I thought we’d get in on the action during the waning hours of the exhibit. We decided to try our hand at making an anaglyph, one of the easier kinds of 3D images to make (along with stereograms, which are a bit lo-fi for MATLAB, after all).

The recipe calls for combining two images of the same scene from slightly different perspectives using a simple function that combines the red channel from the left image and the green and blue channels from the right image. And of course, you need the funny glasses. First, the images that we made with my camera phone:

Left image

Right image

Using some MATLAB code that we found on MATLAB Central, you get the following image:

The anaglyph

(Unfortunately, I can’t help you with the funny glasses. Go get yer own.)

I am told the results are “okay for a cha-cha picture.” I don’t have binocular vision, so what do I know?

Have fun. (And don’t be like the guy who said that the 1.57% of the population with monocular vision aren’t really worth worrying about.)

About five years ago I wrote a little program to help me find numeric patterns in arrays. Basically I needed to find byte patterns like 0xFFFE 0xE000 in the data from DICOM files. Something like MATLAB’s strfind function, except more general than looking for substrings in strings.

So I wrote a rather naïve algorithm to do just that. It wasn’t very fast, but it worked for exploratory use. But then today I needed to do something like that in production code. So I asked one of my coworkers for tips with a faster implementation.

Turns out the strfind works just as well on numeric arrays as it does on strings. And it’s really fast, too.

% "data" is a 1,200,000 element UINT8 array.
% It contains 29 instances of the pattern.
tic; offsetTable = strfind(data, [254 255 0 224]); toc

% Elapsed time is 0.027390 seconds.

Update: Loren Shure posted an even better solution on her blog.