[argyllcms] Re: Gamut mapping?

  • From: <graxx@xxxxxxxxxxxx>
  • To: <argyllcms@xxxxxxxxxxxxx>
  • Date: Mon, 11 May 2020 10:36:53 -0400

Edmund,

 

The ICC « system » *is* the way it is because no one bothered that it would 
different. Remember Microsoft ICM? It is still shipped with every versions of 
Windows and uses “dynamic” gamut mapping, to the best of my knowledge. 
Everybody was in awe when it came out but no one bothered to support it.

 

/ Roger

 

From: argyllcms-bounce@xxxxxxxxxxxxx <argyllcms-bounce@xxxxxxxxxxxxx> On Behalf 
Of edmund ronald
Sent: Monday, May 11, 2020 10:22 AM
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: Gamut mapping?

 

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 
<mailto: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 
<mailto: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:

  1. Home
  2. argyllcms
  3. Archive
  4. 05-2020