Re: Questions about the UI at 1.8 gamma
Re: Questions about the UI at 1.8 gamma
- Subject: Re: Questions about the UI at 1.8 gamma
- From: bruce fraser <email@hidden>
- Date: Tue, 22 Jun 2004 15:25:47 -0700
At 7:03 PM -0700 6/21/04, John Zimmerer wrote:
As usual, Bruce, you are the exception to the rule. I mean that in a nice way.
Thanks, but see below.
You are exceptional, in that you work in what would accurately be
described as a "color-friendly" environment. Many (read: most) self
proclaimed color professionals do not. Some can't afford to, others
simply need to multitask too much and aren't willing to keep a room
that dark all of the time, or even to modulate the light output when
necessary. Let's not even begin to discuss how many aren't in
neutral surrounds.
You miss the point. This is not a particularly dark room. All I did
was to draw the blind, and position the monitor so that window light
doesn't fall directly on it. It's plenty bright enough to read small
print without additional illumination. I find it hard to believe that
anyone doing color work wouldn't do something very similar. Most pros
who visit my office are surprised at the HIGH ambient light level.
BTW, your argument that gamma 1.8 is better suited to bright
environments than gamma 2.2 is exactly ass-backwards. Gamma 1.8 has a
lower apparent contrast than gamma 2.2, which is why Karl Lang
designed it into the Artisan spaces that are designed for working in
a cave. You need to raise, not lower, the gamma to preserve the same
apparent contrast as the ambient light gets brighter.
Everyone cares about color whether they articulate it or not. Apple
is just trying to strike a middle ground and uses reasonable
defaults to do that. The minute we swing too far in one direction,
we get jabbed from a different group. So we land in the middle, and
put in enough flexibility to allow users to customize their
environment as they see fit.
Right now you're making it extremely difficult for anyone who uses
Safari to print untagged content correctly, especially if that
content was prepared following the recommendations of the W3C. Which
group jabbed you in the direction of swimming upstream and not using
sRGB for untagged data? I and several heavily-built friends need to
have a quiet talk with them.
I'm not going to argue any longer about how to treat untagged data.
It's all subjective; we chose not to go the sRGB route for
system-wide handling of untagged RGB data.
The point is not that one or another interpretation of untagged RGB
is better-that's simply an impossible call to make. The point is that
97% of the planet interprets untagged data one way, and for reasons
that quite honestly don't stand up under any serious technical
investigation, Apple has chosen, unilaterally, with no warning and
precious little documentation, to do it another way.
The goal of color management has never been to make color correct.
That's still a function that demands AI (Applied Ignorance/Artifical
Intelligence, take your pick) or intelligent human intervention.
Rather, the goal has always been to communicate color consistently
and unambiguously, whether it's right or wrong. Assuming this
peculiar little color space for untagged data just makes it more
difficult for Macintosh users to get consistent color in a
cross-platform world.
In particular, I just don't see that the following behavior is a good idea.
Take a screen grab, launch preview, and paste the screen grab into a new doc.
Export this new doc as a .pdf.
Open the doc you've just exported.
Does it match the appearance of the screen grab in preview?
(For the lazy among you, here's what happens. Preview sends the RGBs
of the pasted screen grab straight to the display. In color
management terms, it assumes monitor RGB as the profile. When you
export as PDF, however, it assumes and embeds Generic RGB, so when
you open the exported PDF, it doesn't match the doc from which it was
exported.)
Please tell me why this is not fundamentally broken. It seems idiotic
that you can open a doc, export it in a different format, and have
the color change by default.
I've passed along the requirement for Safari. We'll see if they agree.
If they don't, they won't be W3C-compliant. It's that simple.
--
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.