[Printing-architecture] [Openicc] [Gimp-print-devel] Colour

[Kai-Uwe Behrmann]

Am 16.11.09, 20:23 -0500 schrieb Robert Krawitz:
>   Date: Tue, 17 Nov 2009 02:08:14 +0100
>   From: Gerhard Fuernkranz <nospam456 at gmx.de>

>   And applying an additional device -> PCS -> abstract -> PCS ->
>   device transformation in a *separate* post-processing step (after
>   converting the object colors to the color space associated with the
>   printer's process color model, but before half-toning) will
>   certainly not help to improve the overall accuracy of the color
>   transformations, and some colors may already have been clipped,
>   which cannot be undone any more afterwards by a de-saturation
>   effect (though this clipping would have been avoided if the
>   de-saturation would have been applied before applying the output

It is really good to mention that for the record.

>   profile). So I think the effects should be rather incorporated into
>   the color transformation chain from object colors to the printer's
>   process color model. Or alternatively, the intermediate color space
>   before applying the effects would need to be rather PCS.
>
> That's why I think the intermediate color space should be high
> precision with extremely wide gamut.  I know memory and CPU isn't
> free, but I think arguing over 8 vs. 16 bits of precision is
> distinctly penny-wise and pound-foolish.

A)
One alternative would be to replace the object ICCbased profiles with ones 
which contain the abstract effect(s):
object space (sRGB) -> abstract effect(s) (CIE*Lab)
    ==> new profile (replacing sRGB)
If the input (object) profile has several tables, the unused ones can be 
omitted using only the wanted rendering intent. Its like a device link 
with a output colour space of CIE*Lab. Some refere to it as backing in a
profile. It would need to iterate over all PDF objects and replace their 
ICC profiles. The intermediate replacement ICC profile can be considered a 
additional conversion even if it does not alter any colour values. This is 
due to the interpolations during the profile table creation.

B)
An other alternative is to put the effect profile(s) into the job ticket 
for later usage during object colour conversion:
object space (sRGB) -> abstract effect(s) -> device space (printer)
But that largely depends on the spoolers capabilities. From a CM point of 
view that would be ideal, as it allows to follow a   as few as possible 
conversions strategy.

The colour binding can be moved from a early to a late stage with both 
alternatives. As well the output intent remains untouched as Chris Murphy 
suggested.  ... feature complete


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org