Re: use of sRGB as a default
Re: use of sRGB as a default
- Subject: Re: use of sRGB as a default
- From: bruce fraser <email@hidden>
- Date: Sun, 20 Jun 2004 15:23:04 -0700
At 2:41 PM -0700 6/20/04, John Zimmerer wrote:
>
>
If we're talking about assuming sRGB in the browser, I'm glad to
>
hear you have a fast Mac and a DSL connection since at that point,
>
every image would have to be matched to the display profile. And
>
again, profiles do not have to be large. Our sRGB profile weighs in
>
at 1,080 bytes.
Internet Explorer for the Mac has been performing this feat (matching
to the display) since sometime around 1999. The performance hit is
trivial, and it certainly takes less time to do the display
compensation than it does to download the REAL sRGB profile which
weighs in at 3,144 bytes, and uses a multi-point 1024-point curve for
each channel rather than a simple 2.2 gamma curve. (This is important
for the shadow behavior.)
Are we to believe that the engineers at Adobe and Microsoft are
capable of feats that Apple can't yet approach?
>
>
>a) sRGB is the space that comes closest to representing the
>
>"average" viewing condition.
>
>
Sorry, don't agree. sRGB uses a 2.2 gamma, which assumes a much
>
darker environment than the average user's. Refer to earlier emails
>
for other criticisms of sRGB.
That is flat-out incorrect on a number of different levels-see, for
example, Michael Stokes white paper at
http://www.w3.org/Graphics/Color/sRGB
One significant statement in said paper...
We feel that there are many reasons to support a 2.2 CRT, including;
* compatibility with a large legacy of images
* Photo CD,
* many Unix workstations,
* PC's with 256+ colors and their desktop color
schemes and icons,
* several ultra-large image collections,
* analog television,
* Apple Macintosh video imagery,
* CCIR 601 images,
* a better fit with Weber's fraction,
* compatibility with numerous standards,
* TIFF/EP,
* EXIF,
* digital TV,
* HDTV,
* analog video,
* it is closer to native CRTs gamma,
* and consistency with a larger market of displays.
The bottom line, though, is that a user's ambient light level does
not affect the physics of the display. Everyone I know who uses an
LCD display calibrates it to a gamma of 2.2. To the extent that we
should even use the term "gamma" in conjunction with LCDs, the native
tone response of the display is a great deal closer to a gamma 2.2
curve than to a gamma 1.8 one.
In any case, if you did display matching, it wouldn't matter what the
destination display was calibrated to. We're talking about image
encoding gamma, and a gamma of 2.2 is much closer to the way eyeballs
and brains interpret light than gamma 1.8. Gamma 2.2 encoding puts
the bits in the shadows, where we need them because we're more
sensitive to small differences in shadows than we are in highlights.
>
>
>b) most consumer-level cameras and printers, most online printing
>
>services, and a very large number of digital minilabs assume sRGB
>
>and at least attempt to simulate it.
>
>
Not 100% accurate. Most devices lie about their color space,
>
claiming sRGB when, in fact, they have much broader color spaces and
>
try to shoehorn data into sRGB when saving JPEG data. Most printing
>
services aren't ICC savvy, and therefor resort to using the EXIF
>
data to try and do color matching. But anyone who uses custom ICC
>
profiles for cameras knows that, while the EXIF might say sRGB, the
>
data certainly doesn't.
The fact remains that the data is characterized as sRGB. Anything
smart enough to use profiles interprets the data as sRGB. Everything
else blasts RGB counts straight to the screen. sRGB is a better
representation of random uncalibrated monitor RGB than anything else
we have.
>
>
>(Combining both c and d points)
>
>
As I've stated in an earlier email, I'm happy to pass along the
>
requirement that Safari assume sRGB as the color space for untagged
>
images.
>
>
>Yes, the idea of scanners, cameras, and printers producing sRGB is
>
>of course a damned lie, but that's how people view, evaluate, edit,
>
>and on rare occasions, tag said RGB. Arbitrarily remapping all that
>
>color to something else seems distinctly unhelpful.
>
>
Ironic, since that's exactly what happens when assuming sRGB....
Nope. All the systems that use EXIF/PIM and the other sRGB-assuming
workflows behave consistently unless and until they have the
misfortune of encountering OS X, which applies an arbitrary
lightening and desaturation by arbitrarily reinterpreting the numbers
as Generic RGB (In the cases where it actually succeeds in doing so).
To the user, the situation appears that the color behaves
consistently until OS X munges it.
--
email@hidden
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.