[argyllcms] Re: ArgyllCMS V1.1.0 RC1 is now available

  • From: "Alastair M. Robinson" <profiling@xxxxxxxxxxxxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Mon, 09 Nov 2009 00:30:37 +0000


Gerhard Fuernkranz wrote:

This applies indeed to the other, gamma-adjusted space presented by the
driver to the user.

Yup, that's right - I should have been clearer there. In fact, I present that gamma-adjusted space to Argyll, via a filter within gplin, (If I try and use the raw space directly the assumptions Argyll has to make about the colourspace in order to choose spacer colours no longer hold true, and the chart is unreadable by my DTP41!)

In the rest of my post I was just emphasizing that if that adjustment is "hidden" from Argyll, then the TAC calculation is compromised.

As an extreme example, one of my early experiments was to linearize my R285 on plain paper, then profile it in CMYK mode. I set per-channel ink limits to a point just short of saturating the paper, so when profiling the effective total ink limit was 100%.

When hunting for a saturated Red under an ink limit of 100%, you'd probably start with [0,50,50,0], but with a base gamma adjustment of about 0.3 happening behind the scenes you'd end up with roughly [0,10,10,0] making it to the paper. Needless to say the gamut of a profile made in this way was terrible!

I understand that this is the obvious reason why you wanted to calibrate
> the _raw_ space of the halftoning engine instead.

It's one reason, certainly - the main one, though, is just that I wanted to eliminate as many possible variables from the chain as possible, and have total control, so I could be certain that I understood what was going on!

There was likely a misunderstanding regarding my statement you cited
above. I actually meant that I agree that for characterizing the _RAW_
space of the halftoning engine

Yes, I understood that - and again I should have been clearer. :)

Is the sum of the dark and light cyan ink amounts still proportional
> to the cyan colorant value sent to the driver then?

No, it isn't, sadly - subchannel generation throws another spanner in the works - though a less severe one, I think. If I understand Gutenprint's subchannel method correctly, you could potentially see maybe 120% ink coverage from the main and subchannel combined, at about 75% input - but I'm not 100% certain of that.

All the best
Alastair M. Robinson

Other related posts: