Re: Conversion Steps/PRO/Observations
Re: Conversion Steps/PRO/Observations
- Subject: Re: Conversion Steps/PRO/Observations
- From: email@hidden (Bruce Fraser)
- Date: Sat, 4 Aug 2001 16:01:12 -0700
At 3:01 PM -0700 8/4/01, email@hidden wrote:
Hi Bruce,
I presume in the neg scanning workflow that you have described (your
own) that you are making all of your big moves in Photoshop instead
of in the scanning application. I didn't notice that you had
explicitly stated this, and it's an important issue, especially if
one is flirting with the possibility of trouble from the space
getting too wide, with 24-bit data and when faced with the need to
work with 24-bit-only tools. Doing generic scans into 48-bit files
is a particularly valuable workflow when one is having scans done by
someone else.
Yes. When I said that I scan raw 48-bit, that's exactly what I meant.
The scanner is set wide open, and I'm making no moves whatsoever in
the scanner software.
I always do all my major moves in the scanning software, but underdo
them, so that I never have any desire to backtrack. That way, I can
be covered completely with a 24-bit-only path after leaving
Linocolor, with 48-only prior to leaving Linocolor.
You're pretty much forced to do that by Linocolor, since on the Mac
it lacks any facility for 48-bit output.
I believe there is an exception to the rule you suggested about
input profile-to-working space conversions always being RelCol or
AbsCol. Remember your Kodak scanner profiles. Kodak likes to use
perceptual intents in scanner profiles. And one might also mention
the oddball TIFF RGB profile from Linotype, which does perceptual
mapping into it and should probably be considered a working space
profile. (It would seem that there is an exception to almost
everything that has to do with color management.)
Yes, there are exceptions. However, none of the built-in Photoshop
working spaces, or ProPhoto RGB, number among them, and I've yet to
see an input profile that had more than one table, mainly for the
reason given below.
Also, I think you said in one of the last two or three posts that
the intent when you convert from profile A to profile B is
controlled by the default intent of B. I believe it's the other way
around (when the default intents are paid attention to, which they
usually are not, except in a RIP). Maybe you were talking about
something else.
What I actually said is that when you choose a rendering intent, it's
the table in the target profile (B) that gets used. Source is always
transformed to PCS using relative colorimetric. (Otherwise it would
be impossible to do any perceptual renderings out of the Photoshop
working spaces, since they don't actually have perceptual tables.) If
you don't choose a rendering intent, though (as in QuarkXpress, where
you can't), the default table in profile B, the target profile, is
the one that does the rendering. The only exception is input profiles
like Kodak can build, where the single rendering table that gets used
to convert into the PCS is actually perceptual. You can't control the
rendering into the PCS except by building a profile that contains the
rendering intent you want.
It may well be that the workflow I've been discussing is fairly
specific to the Imacon scanner. It's predicated on making raw 48-bit
scans, which are always flat and unsaturated, converting the raw scan
from scanner RGB to ProPhoto RGB, then editing entirely in Photoshop,
and almost all in 48-bit. It's been working very well on a wide range
of reasonably-exposed (and some unreasonably-exposed) negs, but it's
certainly not the only way to go.
If I was driving a LinoColor scanner, obviously I'd have to do something else.
Bruce
--
email@hidden