Re: [Gimp-print-devel] "Raw" colour correction

[Alastair M. R. <bla...@fa...>]

Hi :)

Lorenzo M. Catucci wrote:

> I think only matte black got printed; from what you wrote, I understand 
> g-o was an unfortunate replacement for photo black!

That's right - and the reason was that I'd misspelled "Gloss Optimizer" 
in my colorant table!

Version 0.0.1-pre3 should fix that, but doesn't do anything else useful 
yet:  http://blackfiveimaging.co.uk/linearize/gplin-0.0.1-pre3.tar.gz

> Maybe I'm completely off-mark now (especially since I don't really grasp 
> all of that CIE L*a*b* coordinate scheme, and can't understand how to 
> do a scalar product of two colours)

The L* (Lightness) graph is the most important one as far as linearizing 
is concerned - if a plot of input value vs. L* is a nice straight line 
the device is giving perceptually linear results.  Because Yellow has 
such a shallow line, it's easier to linearize that against b instead, 
though.

As for doing a product of the colours, we shouldn't need to - the 
traditional approach is to linearize first, then measure combinations of 
colours afterwards, and use *those* to create a colour profile.

> but I'd think that somewhat inverting 
> the absolute description of the printed target, the device 
> characterization would be complete, and a driver correctly using
> that characterization would really be a good "linear" {s,Adobe}RGB driver.

Sadly it's nowhere near that simple.  Inverting the curves is, as you 
rightly say, an important step - the idea is that it will make the 
device response (a) nice and smooth so profiles can fit the response 
well (though Gutenprint is already pretty good in that regard), (b) 
ensure that the input values are well distributed perceptually through 
the printer's reponse - i.e. that we don't have the situation where 80% 
of the input values end up in the darkest 50% of the print, and (c) put 
the printer into a "known", repeatable state.  All of these improve the 
chances of creating a good colour profile - and also of being able to 
get tolerable results using a generic profile.

What it doesn't take into account is how inks *combine* - and the 
response there is generally pretty complex, especially when extra 
colours like Red and Blue enter the mix.  That's why even with a 
linearized printer a profile (or at the very least, an ad-hoc colour 
correction algorithm) is still needed.

>>From what I understand, if I send a CMYK file to the printer, in my case 
> the extra red and blue colours would be simply ignored.

Oh, I see - I don't have a CMYKRB printer to play with, so I'm not 
entirely sure which modes attempt to split out the RB and which don't. 
RGB definitely does.  I thought CMY did - maybe CMYK doesn't?  Raw 
doesn't, of course, since the channels are individually addressable.

> As for the gloss-optimizer, an option would be to (nicely) ask to 
> gutenprint to just overprint the right gloss optimizer pattern for any 
> raw density we are printing.

That would need a new "Raw + Gloss Optimiser" channel mode - which I 
doubt would be useful for any other purpose - so it's probably simpler 
to duplicate the GO algorithm in GPLin. :)

All the best,
--
Alastair M. Robinson