Re: Microsoft vs. ICC
Re: Microsoft vs. ICC
- Subject: Re: Microsoft vs. ICC
- From: Jan-Peter Homann <email@hidden>
- Date: Mon, 19 Sep 2005 09:33:42 +0200
Hello Erik, hello list
Erik Koldenhof wrote:
Back to the ICC once more: It's my believe that most of the so called
'color errors' that we might find today, are based on implementation
errors by the OS/application software developers on one hand, and
enduser errors in settings on the other. Not the ICC spec itself.
Jan-Peter:
The ICC-Specs are big step forward for a vendor-neutral open
colormanagement. The strong points are:
- application neutral colorsettings
- good softproof
- digital contract-proof on Inkjets
- profiles for standard printing conditions
- profiles for RGB-workingspaces
- easy way from RGB-input to RGB workingspace.
Thanks to ICC, PDF/X-1a and widly accepted standard printing conditions,
it was never easier to set up a complete colormanagement workflow. Just
install Adobe CS2 and a EfI / GMG proofing system with their standard
settings, and the systems runs. No more need for a consultant, if only
PDF/X-1a for ISOcoated is generated and proofed.
On the other hand, the ICC-specs are really problematic. They are the
source of a lot so called "color errors":
- The concept of static precalculated rendering intents is not suitable
for late binding workflows. This concerns especialy documents or files,
where individual objects (images, vector-graphics) can have their own
embbedded profiles and rendering intents. I call it "mixed colored
documents.
The "mythos" of late binding for mixed colored documents is a central
(but never verified) idea of the ICC specs. It is e.g. implemented in
the PDF-specs, in Apple colorsync and in PDF/X-3, the ISO-standard for
exchange of printing-data.
- The ICC has no clear defined workflow, how OS, applications and
printerdrivers should interact.
- As such a workflow is not defined, it is not possible to test, if the
OS, the applications or the printerdrivers behave like the ICC has defined.
As a result, ICC based workflows are espialy very problematic when:
- "mixed colored documents" are generated and processed with different
applications
- "mixed colored documents" are exchanged between different users
Such kinds of documents can easily cause automaticly triggered
colortransformations of parts of the document - or the whole document -
which the user didn´t wanted.
As the ICC gives no clear workflow definitions, every vendor implements
it like he thinks. Apple has failed to make a transparent configurable
colorworkflow in several points. Adobe made a big step forward from CS
to CS2. (if you use PDF/X-1a settings and avoid PDF/X-3...)
One of the big steps in CS2 is a colormanagement-policy, where in mixed
colored documents, placed CMYK-objects are prevented from ICC based
colortransformations.
If one of the big ICC players must deactivate some ICC-functionality in
his own applications for a better usability, there is for true a problem
in the ICC specs itself.
--
To the end of this mail, I will explain why I will have a close look to
Micorsoft, even if I have never bought a computer with a Microsoft OS in
the last 20 years I use computers, and even if I prefer Opensource and
Open standards.
The biggest problem of the ICC, I actually see, is the missing detailed
wokflow defintion for OS, applications and drivers.
For the old Microsoft solution: Input->sRGB->Output, Microsoft had a
clear workflow definition incl. testsuites and testprocedures. If
Microsoft will be able to do this also for WCS, it will be a real big
step forward for highend colormanagement.
If either Apple or the ICC will fail to make clear workflow-definitions
incl. testsuites and testprocedures, WCS has the potential to be the
colormanagement-architecture and OS for both the consumers and graphic
arts professionals.
One really interesting scenario would be an Adobe Creative Suite, which
uses the Smart Gamutmapping of WCS for repurposing Adobe CS documents or
for optimal gamutmapping to the printer. This could e.g. realized by
converting the WCS transformation internaly to a ICC devicelink-profile
for using it in a standard Adobe color environment.
:-) Jan-Peter
--
homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Kastanienallee 71 ------- http://www.colormanagement.de
10435 Berlin --------- mailto:email@hidden
_______________________________________________
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