Re: A thread about red
Re: A thread about red
- Subject: Re: A thread about red
- From: Joel <email@hidden>
- Date: Fri, 29 Jun 2001 10:54:02 -0500
Since everyone appears to be going on summer holiday I though I would
introduce a thread which stuck in my head some time back and is
causing me to rethink our TIFF workflow (thanks Henrik). In
particular reproducing RGB Reds to achieve maximum brightness/hue
using four, six, and/or eight ink mixes.
Currently we are reproducing a local art period-piece which includes,
as its centrepiece, a bright Red 1955 Chevy Convertable. We work in
AdobeRGB and here's the guff:
Print Relative (BPC) workflow: we print directly to our RIP from
Photoshop (Profile-to-Profile conversion using Relative colormetric,
BPC on, print using document profile, SAS). RIP Color Correction
Input On, Output rendering intents set to Bitmap Images = Relative,
Vector = relative. 1955Red renders flat,dull appearance. Remainder of
colors (primarily blues, nuetral grays, skin tones) render well.
Drag-n-Drop Perceptual Workflow 2: Drag embedded RGBTiff directly
into RIP, Color Correction Input ON with Output rendering intents set
to Bitmap Images = Perceptual, Vector = relative. Brighter 1955Red
but no depth, loss of black in shadow detail. Remainder of colors
(primarily blues) render well, though not as deep and true as
Workflow 1, nuetral grays and shadow details lighten. The RIP
rendering intent has no BPC so A Bitmap rendering set to Relative
blows out the shadow detail with the Absolute Black point (thanks
Henrik).
Absolute Print: set RIP output rendering intent to Bitmap Images =
Absolute, Vector = relative, Input Color Correction OFF. 1955Red
bounces to an incredible bright, deep likeliness of our screen
represented RGB RED, shadow detail and black rendering is good, but
nuetral grays and midtones brighten too much. But in this case the
Adobe CMM in Photoshop blows out the white point during conversion.
Apple CMM (as used by our output profile) maintains White Point
accuracy and highlight detail.
A way back when:
Message: 3
Date: Wed, 15 Nov 2000 16:18:53 +0100
To: email@hidden
From: Henrik Holmegaard <email@hidden>
Subject: Proofing ABC
I used to think a proofing ABC was something to write once only.
Seeing the kind of black box implementations Adobe and Quark market,
maybe a proofing ABC bears repeating about once every month -:).
a. The first step is that (in most cases) the RGB source color space
is larger than the CMYK production color space, so you need gamut
remapping to handle the out of gamut colors. The gamut remapping uses
a displacement strategy which is proprietary to each profiling tool,
yet interpretable by open CMMs like the Apple and Heidelberg CMMs
(there are also proprietary tables and proprietary CMMs, for
instance, Kodak's). Such a displacement strategy is in principle just
like a pair kerning table that takes care of the fact that the Roman
alphabet forces curves, verticals and angles to meet up in
wordshapes, except in the case of colors the remapping tables serve
to avoid that colors which are out of gamut for the destination color
space aren't just clipped to the surface of the destination gamut.
In the case to of RGB red (255), CMYK is mapped to C=0, M=87, Y=100,
K=0. The result, as expected, is a darker, duller rendering than the
transmissive screen original. When using an Absolute RGB>CMYK
rendering workflow, editing in PShop using Absolute in softproof,
converting Profile-to-Profile, saving for Drag-n-drop with embedded
output profile or printing directly from Photoshop, the usual out of
gamut RGB appears optimal compared to other perceptual or relative
workflows, especially if the CMM engine used in PShop matches the CMM
used by the Output profile.
Previewing the various engines in Profile-to-Profile (Absolute), each
CMM renders varying results - some close, some considerable. But,
with ColorSync CMM rendering set to Automatic, the Colorsync
selection in P-to-P renders the same result as the AppleCMM. So I
assume Colorsync defaults to the AppleCMM under this setting.
Yet, if a convert to profile using absolute appears to render the
best RGB>CMYK conversions for out-of-gamut colors when using the
destination profile's CMM, doesn't it make sense to have the
application recommend or default to use the engine which matches the
profile's CMM?
(Sorry for the long post. Too much coffee and if it appears confusing
it's just because, well, I am confusing.)