Re: Why don't drivers use a CMYK profile?
Re: Why don't drivers use a CMYK profile?
- Subject: Re: Why don't drivers use a CMYK profile?
- From: Dave Camp <email@hidden>
- Date: Wed, 08 Nov 2000 18:02:34 -0800
on 11/8/00 4:11 PM, email@hidden at email@hidden wrote:
>
The location at which the RGB driver profiles are applied (before the
>
screening) is not a place where CMYK profiles could be used; for that a
>
non-OS level printing system (PostScript or an application specific CMYK
>
driver) would need to be used. CMYK control can be provided without
>
PostScript, but it is application specific and problematic.
In my driver the current process looks like:
- Get RGB bands from OS, along with a source profile
- Convert RGB to CMYK values, using vendor supplied algorithms/tables for
the current paper type (generic stuff like plain, glossy, coated, etc).
- Pass 32 bit CMYK values to halftoning code to generate CMYK dots to be
fired by the CMYK print heads
What I'd like to see happen is a way to bypass the vendor supplied generic
CMYK conversion (second step) and allow a more advanced user to create a
CMYK profile that is accurate for the media they are using. One of the
reasons for this is that the vendor supplied RGB to CMYK value converter is
coded to assume that the source RGB space is sRGB (darn Windows centric
engineers). Thus, the single profile that ships with the printer is
essentially a sRGB profile.
I'd like to do better than that, or at least give a smart user the ability
to do better than that. However, I'm not a color scientist, and I don't play
one on TV. So, I thought I'd bring this up here and tap the brains of those
who know more than I about color science.
Thanks for the help.
Dave