Microsoft requires one to sign a EULA to view their Windows Media Photo Specification spec. I've done that, and probably given them naming rights on our first grandchild. Of course promises to all powerful unregulated monopolies don't count -- ethically anyway.
Microsoft's inevitable evil aside, it's a well written document, available, of couse, only in Word's proprietary file format (the free viewers are windows only). Nisus Writer Express opens it -- with the usual mangling. The part that caught my attention was the discussion of Gamma, something that's otherwise been a mystery (read this too). Since I don't want to spend the next fifty years chopping rocks, I'll paraphrase.
Image related devices need to make the best use of limited resources (sensor response, storage, internal data paths, processing capabilities, power utilization). To do this they have their own internal schemes for assigning numeric values to "colors" (frequencies) and "brightness steps" [1].
The color part (aka gamut) is bad enough, but with color profiles and the like there's a somewhat standard way to transform an image between viewing devices. Somewhat is the operative word here, because even in the OS X world this is done incompetently. (Forget XP -- there you have to live in Adobe.)
The brightness steps are the real nasty. The WMP spec claims that "brightness steps" are a part of the color profile, but I've never seen software handle them. These "brightness steps" are the "gamma curve".
Brightness steps, alas, are a non-linear transformation. (This is when I wish I hadn't ducked Caltech's famously nasty applied maths course, so the best I can say here is that I wonder if "non-linear" is computationally problematic.) The brighteness steps are simplified as a single numerical value representing the non-linear transformation as a "power function".
Although the Microsoft spec claims that color profiles contain information on gamma, I've never seen any image rendering software do the transformations needed to correct brightness steps based on the gamma of, say, a default Mac display setting (OS X allows me to set my display "gamma", but the appearance of the UI changes, so the UI is not being transformed to match the new display setting.).
Decades ago Apple went with a gamma of 1.8 and IBM chose 2.2. (I think Sun did something different.) I suspect Apple's choice was more consistent with the crude image technology of the 1980s and IBM's choice was a better fit for what television used back then.
Whatever the original reason, we know IBM's choice won out. An image created in a Gamma 2.2 world will appear dim and "muddy" on a 1.8 display, conversely an image created on a PC will appear bright and garish on a Mac (people prefer bright and garish to muddy incidentally). This has nothing to do with the display being "brighter", it's the mismatch between the original "power function" and the rendering device "power function".
I'd wondered if Apple would take advantage of the Intel conversion to shift to a PC gamma, but I don't think they have. Much of the Apple UI looks a bit odd in a PC gamma, since it was designed for a Mac gamma.
I run my iMac monitor with a Gamma of 2.0. The OS X UI elements don't look too bad and, if I edit my images to be a bit "bright", my pictures seem acceptable on Mac and PC. It's an ugly compromise. The one thing I'd like to see in Vista would be for it to manage gamma translation in software, but I suspect that might be computationally tricky. (My OS X 10.5 wish list is another matter -- but Jobs never gives me what I ask for ...).
I would love to see WMP succeed -- if Microsoft were to make it an open standard. I would be shocked if they did that. I am pretty confident they will be evil. In their (weak) defense, I suspect they will be paying some patent holder licensing fees somehow.
I'd hoped for years that we'd go to JPEG 2000, but it has two fatal problems. The underlying mathematics are heavily patented (thanks to Wikipedia for finally answering my question of the past few years) and JPEG encoding on modern CPUs is both computationally expensive and energy inefficient. The patent problem has loomed larger thank to our governments idiotic management of the patent process. So JPEG 2000 appears to be a dead issue. (Adobe Acrobat, btw, provides JP2K encoding as an option, it works very well for text documents because it manages edges well even with significant lossy compression.)
[1] Even I know I'm oversimplifying here. I think to really understand what's going on you need a deep knowledge of the physics of the photo sensor and be able to map the transformed output of the sensor into the odd and archaic terminology of visual perception (read this). I wonder how many people really understand the end-to-end process. I'm guessing maybe five.
Update 5/30/06: So why don't we just update JPEG to fix its problems with 16 bit color and braindead metadata? Heck, I'd be delighted with 12 bits and Adobe XMP! I don't know. Really, it would be a huge improvement over what we have now, and really 99% JPEG with modern encoders is pretty darned good in terms of artifact and resolution. Sure the files could be smaller, but it would still a huge improvement over DNG and TIFF ... As a former manager once told me 'don't let the perfect be the enemy of the good...'
No comments:
Post a Comment