[Openicc] What is exactly needed: Embedded Profile in CUPS raster !!

[Chris Murphy]

On Jun 3, 2011, at 1:32 AM, edmund ronald wrote:

> 
> 
> On Fri, Jun 3, 2011 at 4:48 AM, Chris Murphy <lists at colorremedies.com> wrote:
> 
> 
> What if the driver Media Types were simply a means of choosing a behind-the-scenes sRGB to deviceN device-link profile? (or sRGB to RGB, or sRGB to CMYK, or Adobe RGB to CMYK - whatever the combination would necessarily be that produce the best out of box experience that the driver manufacturer/bundler is willing to produce).
> 
> Chris Murphy
> 
> The device link profile from sRGB idea is one which we have all thought about, I think it was even discussed at some point.  Actually I wonder if Epson etc don't use it. in their "Vendor Mode" drivers?  Maybe you could describe more in detail the advantages in quality which one would attain by implementing it? 

It's a prebaked transform without a PCS so we lose things like rendering intents and black point compensation unless we explosively create 4-5 device-links where one output device profile would have been used. However, since they're hidden from the user, the rendering intent selection in effect could even be renamed and made more intuitive (or automatic).

Implementing device-links in a non-proofing context, in a PDF workflow, is a problem because it's an assumed profile workflow. That it's simpler and will work well 99% of the time when the print pipeline gets the correct assumed source space (e.g. sRGB), if anything is tagged and needs to be converted with a conventional output device profile, it gets tricky how to implement this and the simplicity starts to vanish. OR that unique space is ignored in favor of sRGB (or whatever is assumed).

One resolution would be to use a normalization workflow for the average everyday user: assume all of their stuff is sRGB, if it's not convert it to sRGB, and then pass it through a device-link that converts from sRGB to CMYK/deviceN (I'm still unclear on which it would be). So...that's pretty straightforward.

The expert user could create more of those device-links themselves, which would merely appear as new Media-Types, nothing else to select.

Or the expert user could create a new Media Type with a flag so that a non-normalization workflow is used, i.e. allow arbitrary source spaces to be directly converted to print space with a conventional output device profile.


> There is another trick, much nastier, which print inspection leads me to believe Epson may be using: I have the impression they may be clipping to the user's monitor gamut, so as to preserve WYSIWYG. It is an interesting question whether we should be doing such an ugly thing.

I have no evidence they are clipping to Display RGB, at least on Mac OS X. It doesn't enter the equation. The default path for Epson driver's on OS X can cause more than one conversion to occur even if ColorSync is not selected, the first one from the actual source space of the image to either sRGB or Adobe RGB (1998) using Apple CMM, and then from either of those spaces to deviceN through the Epson black box (which are just a set of LUTs).

I count 12 "Media Types" with the Epson Mac OS X driver. All three color modes are separate LUTs so we end up with 36 LUTs accounting for color modes. Not all resolutions are supported for all media types, all but one support two out of five possible resolutions. So I get 72 possible LUTs.

These are one size fits all LUTs, no rendering intents or BPC, BTW.


Chris Murphy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110603/1eeee8e4/attachment.htm>