On Thu, Sep 12, 2013 at 5:31 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote: > On Thu, Sep 12, 2013 at 3:29 PM, Rik Cabanier <cabanier@gmail.com> wrote: > > On Thu, Sep 12, 2013 at 2:55 PM, Tab Atkins Jr. <jackalmage@gmail.com> > > wrote: > >> On Thu, Sep 12, 2013 at 1:37 PM, Rik Cabanier <cabanier@gmail.com> > wrote: > >> > On Thu, Sep 12, 2013 at 12:54 PM, Simon Sapin <simon.sapin@exyr.org> > >> > wrote: > >> >> Maybe, but that’s different from the feature specified in GCPM (and > >> >> that > >> >> we just decided to move into Color) which does *device* CMYK, where > the > >> >> profile is intentionally unspecified. > >> > > >> > Sure, but if you're showing it on screen, you have to convert it to > RGB > >> > as > >> > some point. > >> > What is the profile for that conversion? > >> > >> An unspecified, device-dependent profile. > > > > ok, in that case it might be best to do the simple conversion to RGB: > > > > red = 1.0 - min(1.0, cyan + black) > > green = 1.0 - min(1.0, magenta + black) > > blue = 1.0 - min(1.0, yellow + black) > > > > > > Doing the reverse during printing, you know both profiles so you can do > an > > ICC conversion. We probably want to special case rgb(0,0,0) though since > > everyone wants that to be 100% black. > > That would be a device-independent profile, which obviously goes > against the apparent point of the function > Not sure if I follow. When you print, you will use the profile of the device. The CMYK values will be used as-is since they are assumed to be in the colorspace of the device (hence *device*-cmyk). RGB is always in sRGB so you will go from sRGB to device dependent CMYKReceived on Friday, 13 September 2013 02:34:12 UTC
This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:32 UTC