Graeme,
It took me a long time to understand *why* the ICC workflow is set up to
be non adaptive by default. Thing is, the ICC workflow was designed for
print media at the base, and one wants the output to be perfectly
predictable, and also, a set of pictures of the same objects made at
different times when bunched together should always match. This implies
that rigid gamut mapping is enforced by default, and in fact AFAIK no tools
are built in to Photoshop and cousins to simplify an optimised use of the
gamut, which is precisely why Klaus wrote that droplet which builds on your
software to provide a simpler interface for this task.
Edmund
On Mon, May 11, 2020 at 7:33 AM Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:
edmund ronald wrote:
If I may make a comment about the image gamut thing - in printing youwant
gamut mapping consistency, ie if an image is printed alone or in a batchit
gets printed the same. This means one does not attempt to optimise the
printing of any one image.
It's very much up to the creator to decide what they are after.
Yes, a series of related pictures may look better if they
all have the same gamut mapping (and this is easily accomplished).
A series of unrelated pictures may not.
A fine art printer sometimes has a different objective, which is to
maximise the quality of a single print for his customer.
Yes.
Unfortunately, ICC workflows are not really suited to the needs of fineart
work;
At it's heart, an ICC profile is just a profile of the device. It doesn't
dictate a workflow.
Yes, most popular workflows that use ICC device profiles do it in
a certain way, and assume that they can/should use the pre-computed
B2A tables. But a device link workflows proves that this is not
inherent.
Cheers,
Graeme Gill.
