Prebinding, redux
Prebinding, redux
- Subject: Prebinding, redux
- From: Marco Ugolini <email@hidden>
- Date: Thu, 14 Oct 2004 18:34:35 -0700
I am only now catching up on a lot of unread email, so I apologize for being
late in my contribution to the topic, but I wish to add my opinion to a
somewhat recent debate.
>> At 10:04 PM -1000 6/10/04, mo wrote:
>> Prebinding is a term I picked up reading Chris Murphy / Bruce Frasers book.
>> It was a descriptive lingo that fit somewhere between early binding and
>> late binding.
Actually, to the best of my knowledge, there is no mention of any such thing
as "prebinding" in Bruce and Chris' book "Real World Color Management." Not
as an intermediate stage between "early" and "late binding," or as anything
else whatsoever. (Bruce or Chris: please correct me if I'm wrong on this)
What I think has originated this rather silly controversy (if I may be so
bold as to call it that) is that someone, maybe due to imprecise
recollection, probably started the fire by incorrectly substituting
"prebinding" for what the book refers to as "early binding."
And, if so, that's where the mystery thickened, and head-scratching began.
If by "prebinding" we mean the same as "early binding" -- as is my
contention -- then its meaning is the following (as quoted from the "Color
Management with Mac OS X Panther" white paper to be found at
<http://images.apple.com/pro/pdf/Color_Management_in_Mac_OS_X.pdf>):
>> "Late binding vs. early binding.
>>
>> When ColorSync matches an image from a source profile to a destination
>> profile [...] the actual data for the image is modified.
>> Every time this happens, some information and accuracy is lost.
>>
>> One way of handling this problem is called "late binding." You manage the
>> color workflow to stay in the RGB color space as long as possible, possibly
>> even handing RGB files to the printer.
>>
>> Another approach is called "early binding." In this case you convert the data
>> as soon as possible to the ultimate destination color space and keep it there
>> through the workflow.
>>
>> Choosing a late binding or early binding scenario depends on the factors in
>> your particular circumstance. For example, passing RGB files to your printer
>> might be an excellent choice if you know the printer can convert RGB to CMYK
>> with satisfactory results. On the other hand, if you don¹t know who will do
>> the printing, you should convert your RGB data to CMYK in house before
>> sending the files out."
So, to summarize, "prebinding" (if it is "early binding" with a misquoted
name) indicates the process of committing an image to its ultimate output
space (a flavor of CMYK in the case of prepress), that is, of converting it
to that color space BEFORE it is handed to its intended users.
The other meanings offered for "prebinding" in this mailing list sound to me
rather nonsensical, otherwise. After all, to quote Graeme Gill's note from
June 11, the only possible dictionary meanings of "bound" are indeed
"restricted to, limited, restrained, ready, prepared." So, "prebound" has
got to have something to do with an image being pre-configured for, limited
to one particular destination, e.g. pre-separated for a specific press
output ("bound to" that device), whereas the very nebulous definitions
advanced by "mo" in his message of June 9 pointed to quite the opposite,
i.e. to images that are reversible, not "bound" to any particular device or
output.
So, pray tell, how would such a definition as this latter one possibly
signify "prebinding" at all?
In our business, technical as it is, language MUST be clear, as direct as
possible, and precise; and has to be used clearly and precisely; and must
mean something as clear and precise as possible too. Or else we are
obfuscating, blowing smoke at each other. Which I see as precisely the thing
that our mailing list is meant to prevent and avoid, its mission being to
shed light on inconsistencies and, yes, expose (as opposed to "espouse")
nonsense.
Am I alone in seeing the issue this way? And I also hope that no one will
take offense, since no offense is meant. Thank you.
--------------
Marco Ugolini
Mill Valley, CA
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden