|
Issue 105, December 24, 1997 Table of Contents
Editorial NoteThe 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!
BeOS Demos: MacWorld Expo and SD '98 in San Francisco; IT Forum/Comdex in Paris, France
BE ENGINEERING INSIGHTS: Loading An Image, One Photon At a Time...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:
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:
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.
BE ENGINEERING INSIGHTS: Bugger OffI 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: Q: Why can't you review my bug faster? A: There are three QA and one DTS engineers who look at incoming developer bugs. Don't make the assumption that this is all they do. Doug, our DTS guy, spends his days answering e-mail and most of his nights writing source code. The QA guys spend their days writing evil tests and running them on unsuspecting machines. They also spend a lot of time fixing broken hardware. Here is where I poke you, the developer, to write better bug reports. If you did, it wouldn't take us an average of one hour to review a bug and we could look at more of them. Q: How come my bug took a month to be reviewed? A: At nine bugs a day, each taking about an hour to review and approve, we would need to dedicate one full-time engineer to this process. We'd rather take a little longer and save the money. Q: Why don't you fix my bug? A: We do. See the statistics below. Q: Why don't you implement my feature? A: We have implemented 44 feature requests. This is not the greatest number, but remember that we are still working on the basic functionality of the BeOS. We believe that fixing crashing bugs and moving to other hardware platforms is more important than implementing features. Be patient. We are running out of hardware platforms and we will get to your features in another couple of releases or so. Q: Why isn't there more documentation? A: We have two technical writers. In ten months they wrote the 1000-page "Be Developers Guide" that O'Reilly published in November 1997. As they finish documenting more of the BeOS core functions, you will see more documentation. Q: Why can't the bug database do everything? A: It is a work in progress. As soon as the bug database guy, Ron, gets out of web hell (anticipated to be in about 5 months) he may have time to implement some of your requests. (That's assuming more work doesn't come up.) Of course, if all you developers want to donate about $100,000 for a full-time bug database person, we wouldn't say no.
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: The Information RevolutionBy Doug Wright "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...
THE BEBOOK The BeBook is the complete programmer's reference to the BeOS API. It is available on-line on BeOS CDs or in print as the "Be Developer's Guide," from O'Reilly and Associates. Currently, chapters on the Application Kit, Storage Kit, Interface Kit, Kernel Kit, Device Kit, and Support Kit are updated for PR1 and PR2. DR8 versions of the other kits are still available, but are out of date. Our documentation team is hard at work finishing the BeBook. As chapters are written they will be posted, and O'Reilly will publish the complete book as the "Be Developer's Guide, Volume 2."
THE BE HEADERS The Be header files are included on all BeOS CDs and
downloads. They are the ultimate guide to programming for
the BeOS. The easiest way to find out exactly how to call a
function or create a class is to check out the header file.
The headers are divided into the same Kits as the BeBook,
and are always up to date for the release with which they
shipped. Find them on your CD or HD in
SAMPLE CODE The web site's sample code section contains projects you can download or view on a per file basis. There's also a search engine for checking all the source and header files on-line. Keep in mind that not all our sample code is up on the web site yet. You can find additional code on the ftp site in ftp://ftp.be.com/pub/samples/.
TUTORIALS The tutorials section of the web site contains detailed articles on certain aspects of programming the BeOS, like setting up icons and resources for your application.
THE BE NEWSLETTER The Be Newsletter is the most valuable source of hard core programming information and inside jokes that Be has to offer. Each week a Be engineer or two takes up a subject they know and care about deeply. This information is often not yet available anywhere else. Past issues of the Newsletter are available on-line, but it can be hard to find information. That is why we're going back through every issue and indexing them by topic. This is part of the work we are doing to enhance the Be Developer web site. Also each week, there's this column, the Developers'
Workshop. It is intended to help developers get up to speed
with more basic BeOS programming information, which isn't
always easy. Your suggestions on the information you need
will help us deliver it to you in the Developers' Workshop.
BE DEVELOPER CONFERENCE TRANSCRIPTS The proceedings of the BeDC in May and August '97 were transcribed and posted to the web soon after the conference. All the sessions have the presenter's complete dialog and include slides. Sample code for some sessions is available from the ftp site. That's our complete source list of development information. In addition, there are some third-party tutorials and sample code out there on the web. We're trying to index as much of this as possible, so we can provide links >from the Be site. If you know of a third-party site or have one of your own that provides sample code or tutorials, please let us know by sending the URL to devservices@be.com.
Best Wishes...By Jean-Louis Gassée 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.
|
Copyright ©1997 Be, Inc. Be is a registered trademark, and BeOS, BeBox, BeWare, GeekPort, the Be logo and the BeOS logo are trademarks of Be, Inc. All other trademarks mentioned are the property of their respective owners. Comments about this site? Please write us at webmaster@be.com.