Re: synchronizing color - not really possible today -- Honey: Didn't you say MACs can solve this?

Subject: Re: synchronizing color - not really possible today -- Honey: Didn't you say MACs can solve this?
From: "Richard G. Combs" <richard -dot- combs -at- voyanttech -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Thu, 16 Oct 2003 12:04:23 -0600


David Neeley wrote:

> Excuse me, but what does "light emitting device" or "light reflecting
device" have to do with the color model? The fact is that a monitor could
presumably be made using phosphors that emit in the CMY colors <snip>
>
> The primary difference between monitor color and paper color results from
the more intense hues resulting from the transmissive color compared to
reflective. Also, the RGB model is built upon an additive color model rather
than the CMYK subtractive one--but again that is an implementation detail.
Obviously, it is simpler to build monitors on a three color model with the
simpler math involved in additive processes.
>

I'm sure Peter and others are more qualified to respond than I. But "intense
hues" aren't the issue. And additive vs. subtractive isn't an
"implementation detail."

A light emitting device (what you call "transmissive") uses an additive
color model _of necessity_. What you see is the sum of the wavelenths
_emitted_.

A light reflecting device (e.g., paper) uses subtractive _of necessity_.
What you see depends on the wavelengths _absorbed_ -- that is, _subtracted_
from the light hitting it. That's why its appearance depends on the "color
temperature" of the light striking the reflective surface (how "white" is
it?). When the ink absorbs x units of blue, how it looks depends on how much
blue was in the light hitting it.

We're at the edge of my knowledge now, so I don't know if you could make a
monitor emit CMY or not. But even so, there would still be the fundamental
difference between emission (addition) and absorption (subtraction) -- so
all attempts to duplicate a monitor color on paper (or vice versa) would
still be approximations.

Of course, I could be wrong -- but that hardly ever happens. ;-)

Richard


------
Richard G. Combs
Senior Technical Writer
Voyant Technologies, Inc.
richardDOTcombs AT voyanttechDOTcom
303-223-5111
------
rgcombs AT freeDASHmarketDOTnet
303-777-0436
------







^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

HAVE YOU SEEN THE LATEST FRAMEMAKER PUBLISHING TOOL?

RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or view a live demo at: http://www.ehelp.com/techwr-l3

---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit
http://www.raycomm.com/techwhirl/ for more resources and info.



Previous by Author: Re: Punctuation
Next by Author: Re: FRAMEMAKER ERROR SOLVED!
Previous by Thread: Re: synchronizing color - not really possible today -- Honey: Didn't you say MACs can solve this?
Next by Thread: Re: synchronizing color - not really possible today -- Honey: Didn't you say MACs can solve this?


What this post helpful? Share it with friends and colleagues:


Sponsored Ads