[Openicc] GoSoC 2011: CPD and Color Management
Chris Murphy
lists at colorremedies.com
Wed May 4 18:55:49 PDT 2011
On May 4, 2011, at 6:09 PM, Robert Krawitz wrote:
> On Wed, 4 May 2011 13:07:19 -0600, Chris Murphy wrote:
>> On May 3, 2011, at 3:57 AM, Richard Hughes wrote:
>>
>>> Don't get me wrong, I think it makes a lot of sense to have a
>>> super-dialog for people printing on modified hardware on 42" canvas
>>> with 9 custom inks. But we can't design a general purpose architecture
>>> to be compatible with that, and also for a regular user just wanting
>>> to print his tax return without being bamboozled with gobbledygook.
>>
>> Depends on context. If I want to print my taxes on 42" canvas with 9
>> custom inks, the general purpose printing architecture should print
>> that document, by default, with black only ink, just like any other
>> device. And if I print a pretty picture, it should know to use the
>> perceptual intent, also by default.
>
> Not so obvious, actually. There are some RGB (dyesub) and CMY-only
> printers (the Epson C80 is a CMYK printer, but the black ink cannot be
> used on glossy paper), and there are other printers whose "black" ink
> isn't. The Epson 2100, for example, has a "black" ink that's actually
> a medium brown, which needs to have a fair amount of cyan ink added to
> achieve a decent black. And even the current UltraChrome photo black
> ink isn't very dark (the matte black ink is, but it's not compatible
> with glossy paper), so it's necessary to add some CMY to get a solid
> black.
True but the end user has far less knowledge of this, usually, than the driver developer. The driver developer is in a much better position to map "black" in the context of "black text, lines, and UCR/GCR" to a formula other than black ink only, if the black ink isn't really black or particularly dark. And it also depends on the register of the device. It doesn't matter if black ink is not very dark or if it's brown if the device has less than perfect register, that single colorant is the black ink and "black text" must live with that non-ideal ink on such class of devices.
For inkjet printers, it's a balancing act for cost of fixing a non-ideal black ink in effect with UCA. Again, in my view that's the domain of the driver developer, not the user. Now maybe there's a use case where the user has a slider from "economy black" to "darker black".
Chris Murphy
More information about the openicc
mailing list