The Be Newsletter will take a well-deserved holiday next Wednesday: December 31. Look for the next issue of the Newsletter in the new year: January 7,1998!

When I go home in the evening, I sometimes use my BeOS machine for some of my hobbies. I thought it would be fun to describe some of the things I do, and why the BeOS works so well for them.

Recently, I became interested in extremely low-light imaging. There's a device called an "image intensifier," which has the wonderful ability to amplify any incoming light by a huge factor—up to 30,000 times, without adding much noise. These devices are great, but often there's so little light to work with (to take pictures of galaxies for instance) that a single image appears "snowy." The snow is actually individual photons detected by the system.

This is where a computer can work its magic. The intensifier tube is re-imaged by a black and white video rate camera, its signal digitized by a Hauppauge frame grabber ($129 at Fry's Electronics). The resulting data is transferred by DMA using the Bt848 driver—and then the fun begins!

The first problem to deal with is the huge amount of data you get: One second of recording gives you 9 megabytes of data! That kind of stream is enough to keep even a 225 MHz system pretty busy. The second problem is that a lot of processing needs to be done on the individual frames before you can accumulate them.

The first step after grabbing a frame is to remove any systematic bias of the camera and intensifier tube. You can do this by using some calibration data that determines the fix bias and sensitivity of every pixel.

In C you'd use:

*clean_pixel = (*src_pixel - *bias_map) * (*response_map);

After that, if you're imaging galaxies, you need to account for atmospheric effects. Just like the heat rising over a road in summer, the image you see through a telescope moves all the time, because of minute temperature differences in the different layers of the atmosphere. To compensate for that motion, you use a reference object in the image. You measure the position of the object with a centroiding algorithm, which measures the "center of gravity" of an area of the frame:

void    centroid(float *x, float *y)
{
    int     x;
    int     y;
    float   sum_x;
    float   sum_y;
    float   total_count;

    sum_x = 0;
    sum_y = 0;
    total_count = 0;

    for (y = 0; y < FRAME_Y_SIZE; y++)
        for (x = 0; x < FRAME_X_SIZE; x++) {
            if (pixel[y][x] > THRESHOLD) {
                sum_x += x * pixel[y][x];
                sum_y += y * pixel[y][x];
                total_count += pixel[y][x];
        }

    if (total_count == 0) {
        *x = 0;
        *y = 0;
    }
    else {
        *x = (sum_x / total_count) + 0.5;
        *y = (sum_y / total_count) + 0.5;
    }
}

This great for tracking bright areas, and is accurate down to a fraction of a pixel!

Now that you can stack individual frames after recentering them, you can decide which frames to add to the image, and which to reject. Once again, the atmosphere can degrade the sharpness of some frames but leave others nice and clean. Therefore, you need to measure the sharpness of every frame before adding it to the final image.

One easy way to measure the sharpness is to measure the amount of high frequency in the current image. You could use a 2D FFT, but it's pretty slow. Instead, you can measure only the very high frequencies by computing:

float   sharpness()
{
    int     x;
    int     y;
    float   sum;
    float   delta;

    sum = 0;

    for (y = 0; y < FRAME_Y_SIZE - 1; y++)
        for (x = 0; x < FRAME_X_SIZE - 1; x++) {
            delta = pixel[y][x] - pixel[y + 1][x];
            sum += delta * delta;
            delta = pixel[y][x] - pixel[y][x + 1];
            sum += delta * delta;
        }
    sum = sum / ((FRAME_Y_SIZE - 1) * (FRAME_X_SIZE - 1));
    sum = sqrt(sum);

    return sum;
}

After all that image processing, my 225 MHz BeOS system can handle only 25 frames per second. But since you reject part of the 30 frames per second produced by the camera using the sharpness criteria, this is not a problem. However, sharp frames seem to arrive in group, so you need to decouple the image production from the image stacking process.

The program has a bunch of buffers that store images to be processed. A producer thread receives the data from the frame grabber and measures the image's sharpness. If the sharpness is better than the worst frame currently in the buffers, that frame replaces the one stored in the "offending" buffer. A second thread takes images out of the buffer pool and processes them, and a final thread is responsible for displaying the current stack of images.

I will bring this camera to the next developer conference, and show how an image appears on the screen in near total darkness. The glow of a watch is enough to illuminate a large room—and my BeOS machine is happily crunching 9 millions pixels every second!

For people with little cameras like the QuickCam, many of the same techniques can be used. One common QuickCam problem, for example, is that some bright pixels overlay the image. The technique of measuring the fix bias of the camera works well to remove them. Just take a few images in the dark with the QuickCam and subtract their average from the images you take in full light, and you'll get a much nicer result. If you have questions about tricks you can do with CCD cameras, please e-mail me at benoit@be.com.

I would like to put a plug in for the people at Be who support you, the developer. The best way I can come up with to do this is by using statistics.

But first, some typical questions we get from developers:

Now for the statistics:

These numbers are all from developer reported bugs. They do not reflect internal bugs (which we also find and fix).

Average number of bugs reported by developers      9/day

Total number of developer bugs reported            2801
Number of actual, unique bugs reported             1456

Current number of bugs to be investigated          156
Current number of open feature requests            396
Current number of open bugs                        329

Total number of fixed bugs to date                 575
Total number of dev bugs fixed for PR1             391
Total number of dev bugs fixed for PR2             146

Average time for a bug to move
  from "incoming" to "reviewing"                   5 days
Average time for a bug to move
  from reviewing to acknowledged                   4 weeks

Percentage of developer bugs fixed for PR1         45%
Percentage of developer bugs fixed for Pr2         38%

Average release length (history of Be)             4 months

Let's summarize: We have one DTS engineer, three QA engineers, and twenty-two development engineers working on the whole system. At this very moment, the development engineers each have an average of 78 bugs or features assigned to them. They also have to finish Intel, do their own engineering work, and fix/find bugs. The reality is that we have to prioritize things. Some bugs (those that affect a large number of people) win, and some bugs (those that only affect one or two or even ten people) lose.

Next time you're thinking about writing that flame-O-gram, ask yourself if you have a workload like this and if so, what are your turn-around times and percentages? Have empathy friends, we all are in this together!

Oh, and just for grins, why don't you ask Microsoft and Apple what their statistics are?

"Developers' Workshop" is a new weekly feature that provides answers to our developers' questions. Each week, a Be technical support or documentation professional will choose a question (or two) sent in by an actual developer and provide an answer.

We've created a new section on our website. Please send us your Newsletter topic suggestions by visiting the website at: http://www.be.com/developers/suggestion_box.html.

Two weeks ago I said I'd let you in on who the newest addition to Developer Technical Support is. DRUMROLL...The new DTS Engineer is...DRUMROLL...Stephen Beaulieu, formerly of Purity Software. Stephen, take it away...

...Greetings all! I'm glad to be fighting the good fight here at devsupport. As a long-time Be Developer I have personal experience of what devsupport has done, right and wrong, in the past. Doug, Brian, and I are looking forward to revamping devsupport to better meet your needs. If you have concerns, problems, or (best yet) development questions, please drop us a line through the online form in the Registered Developers Area. If you've got questions, we've got answers (or will try and find them for you). Stephen Beaulieu

...And now on with the show! This week I'm going to tell you more about how to find information on programming for the BeOS. We've been busy organizing all the information and sources available to developers from our web site. In the next couple of weeks, you will see the fruits of our labors appear in the developers section of the site.

Each of the BeOS programming sources is explained in detail below...

I write this from a house in a Paris suburb, as I struggle to connect to the 'Net and get my mail. It's supposed to work "seamlessly," but it's broken. Be's office modems are busy, but I have a fallback position, Compuserve, with POPs all over the world.

It does get me on the 'Net, but many California sites appear to be dead. I ping be.com, best.com, sun.com, apple.com, sony.com and even gassee.com. Only sun.com responds. Consumers can't conceive of a telephone that doesn't give a dial tone when you lift the receiver, or a TV that crashes. Imagine a media culture where, when you turn the set on, you're not sure if the scheduled show or game will appear on screen.

This stuff isn't for my mother. Even a well-designed appliance such as WebTV won't spare her some of these indignities because their source is in the infrastructure. In a more positive light, we're still in the pioneer years, with much fun and grief ahead of us, much experimentation, many surprises, before the so-called "commoditization" sets in.

A year ago, we were looking with mixed feelings at an undone deal. Had we missed an opportunity to be acquired by Apple, get broad distribution for our work, and make our shareholders liquid, or were we saved from joining, or re-joining, a company in trouble? Time will tell.

The best scenario is one where Apple goes on to recover a leadership role, by innovation if not by size—and one where we gain critical mass in the Intel space as a specialized media OS, coexisting with the general-purpose OS, Windows.

After shipping several PowerPC releases in 1997, we are now distributing a very small number copies of an Intel pre-release to BeOS developers. The idea is to provide them with a test vehicle for moving their applications to Pentium II hardware in preparation for MacWorld, held in the first week of January 1998 in San Francisco. We'll have a broader developer conference a little later, and PC Expo and Comdex for likely milestones and coinciding release dates, with all the usual caveats stipulated.

There is much work ahead of us in a space where we have to assume our prior experience is of unknown value. Yes, we have a product, the PowerPC releases have helped its maturing process, but the Intel playing field isn't just bigger—we have to learn new rules. Fortunately, we have already found supporters willing to guide us and, if the daily flow of e-mail is to be believed, many users seem willing to give us a try -- which is all we ask. We need good word-of-mouth from bleeding edge users, the opinion shapers.

Our old supporters have been very good to us in a year that started with questions about our future. Be employees voted with their dedicated work, shareholders with their funds, BeOS developers with a growing number of applications and users with field reports showing they actually used the product. To all, our heartfelt thanks and our best wishes for an exciting New Year.