[argyllcms] Re: Gamut mapping?

  • From: edmund ronald <edmundronald@xxxxxxxxx>
  • To: "argyllcms@xxxxxxxxxxxxx" <argyllcms@xxxxxxxxxxxxx>
  • Date: Mon, 11 May 2020 16:21:45 +0200

Samuel,

In the ICC workflow, nobody is asking the printer to make a decision *on
gamut mapping*, and the same object gets printed the same anywhere it is
found in an image; that's the whole point. With an adaptive workflow, if
you crop a print to eliminate a saturated part of the image,eg there
are two models in two dresses and you crop one out,  Bang! your gamut
transform has changed and the crop would print  differently.

The ICC workflow prevents such issues from occurring by enforcing a
one-size fits all model. Which is convenient in an industrial setting but
does not appeal to artists who are trying to innovate. And in fact if you
want to do art with your inkjet printer, you can do very well by using much
warmer monitor settings, incandescents to examine prints, and working
directly in printer-gamut space rather than a "standard" sRGB or Adobe RGB
for retouch. Artists and industrial practitioners do not have identical
needs.


Edmund

On Mon, May 11, 2020 at 9:48 AM Samuel Chia <inksandpaper@xxxxxxxxx> wrote:

edmund ronald wrote:
 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.



I disagree. The (usual) ICC workflow was dictated by computational
efficiency concerns. Computing gamut mappings on the fly was beyond
the capabilities of desktop computers when ICC was designed. Hence
the use of pre-computed tables.
Graeme Gill.


Edmund, my opinion is Graeme is right, whatever that's worth.

Properly done, image-specific or "smart" on-the-fly gamut mapping is ideal
and it should not result in unpredictability and should not cause a body of
work to look inconsistent when printed as a batch.

When printed in separate sessions, it may be a bit of a problem if say,
the gamut mapping methods are improved or if you've forgotten the special
combination of commands for a previous session. But then printers drift,
printers go bust and new ones are purchased with different inksets, paper
may change from batch to batch, or even be discontinued etc. Editions that
need to look the same should all be printed at the same time. I would not
happily guarantee a client that I will definitely be able to reproduce a
print years down the road.

Samuel

On Mon, 11 May 2020 at 15:32, Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:

edmund ronald wrote:
 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.

I disagree. The (usual) ICC workflow was dictated by computational
efficiency concerns. Computing gamut mappings on the fly was beyond
the capabilities of desktop computers when ICC was designed. Hence
the use of pre-computed tables.

Graeme Gill.


Other related posts: