Re: Anomaly between Photoshop 7.0.1 and 6.0.1
Re: Anomaly between Photoshop 7.0.1 and 6.0.1
- Subject: Re: Anomaly between Photoshop 7.0.1 and 6.0.1
- From: bruce fraser <email@hidden>
- Date: Mon, 9 Sep 2002 09:17:05 -0700
At 8:49 AM -0700 9/9/02, email@hidden wrote:
Hi Bruce,
OK, it wasn't a bug. Notice that Tom says that this limitation in
PS 6 only applied to one-way input profiles, but the profiles I was
testing are not one-way input profiles. They are two-way profiles,
and the limitation does apply to them in PS 6. Oh well, close
enough.
Besides, the main point of my original observation to Paul was with
regard to the source simulation behavior, which is what broke in my
system as a result of the change to a different default intent for
source simulations (percep to relcol). I like the architecture as
it is now. What do you think about the change of the source
simulation behavior? If it's right, maybe Apple should copy Adobe
with the small tweak.
You mean they should revise their CMM to meet the current ICC spec? <s>
Yes, I think it would be a good idea. It would also be a good idea
for Adobe to release ACE as a standalone CMM, a battle I've been
fighting without notable success for several years now....
Interesting background though, thank you. We still do get into a
potential mess, what with the lack of control over the rendering
intent of each transformation into or out of the PCS, as we have
discussed previously, at least if anybody wants to have more than
one intent facilitated in a source profile (counting the
colorimetric intents as one). Perhaps the solution is just to
always provide a colorimetric table only, or in the relevant
situations to just make sure all three tables are identical,
especially when you expect to convert all the way from the source
profile to a printer profile. The current implementation would be
especially nice for converting from a multiple-intent scanner or
DCam profile into an RGB working space.
The workaround is to convert 16-bit/channel source to 16-bit Lab
using desired rendering intent, then convert from 16-bit Lab to
target using desired rendering intent. With matrix working spaces
it's moot because the PCS-to-Target side is always whatever intent is
built into the matrix (my hope would be that it's always relcol).
I'm just not sure that the world is ready yet for a UI that required
you to specify two rendering intents for a transform...
Recall my earlier idea for ICC support of a "certified intent"
scheme whereby profile making apps would label each tag in a profile
with a Yes or No, meaning the tag does or does not actually refer to
data which can provide the intent suggested by the name of the tag,
and this information then being usable in the interface during
conversions to make complete information for ther user possible,
instead of this hodgepodge of determination partially controlled by
the profile and partially controlled by the interface, with the user
being especially unlikely to be able to have certainly about the
intent of each step.
I think that would be a great feature request for Steve Upton's
ColorThink. I'm a bit leery of putting it in application UI's because
I think it would, at this point, confuse more people than it helped.
Getting the ICC to do anything useful would take even longer than
getting Steve to finish ColorThink!
Sticking to RelCol in the source to PCS step solves the problem for
input conversions, but still, there are other situations (like using
a proofer along with a printer, or even sometimes just when doing a
soft proof) where being able to specify and be certain of the intent
for each step would be preferable.
The only time you can't do this now is when you're going from a
table-based space as source. Proofing transforms and soft-proofing
transforms both let you specify RI from source to simulation and from
simulation to output. With matrix WS's, source to PCS is always
relcol, and from there on you have full control. If you need to use a
table-based WS, you're probably better off converting manually from
WS to Lab.
I always want more control, but the current UI took a lot of
politicking to get to its fairly reasonable form (the first alpha I
saw of Photoshop 6 had not three but 12 policies, with names like
"Strict" and "Very Strict"), so I'm wary of suggesting changes to it
that would benefit a relatively small number of users at the expense
of confusing the daylights out of all the others.
It would be nice if all this stuff were documented by Adobe, though.
I'm not holding my breath...
B
--
email@hidden
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.