- From: Rik Cabanier <cabanier@gmail.com>
- Date: Fri, 6 Dec 2013 22:48:11 -0800
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Dean Jackson <dino@apple.com>, Chris Lilley <chris@w3.org>, www-style list <www-style@w3.org>
- Message-ID: <CAGN7qDAVvHD2FE=84C0iDg57C16BHU3oOj5jREL7dOtoOVyGwg@mail.gmail.com>
On Fri, Dec 6, 2013 at 10:22 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote: > On Sat, Dec 7, 2013 at 4:39 PM, Rik Cabanier <cabanier@gmail.com> wrote: > > On Fri, Dec 6, 2013 at 9:07 PM, Tab Atkins Jr. <jackalmage@gmail.com> > wrote: > >> On Sat, Dec 7, 2013 at 3:31 PM, Rik Cabanier <cabanier@gmail.com> > wrote: > >> > Can you tell me where the color workflow is defined? > >> > For instance, it is defined that all CSS colors should be tagged with > an > >> > sRGB profile. Image can optionally have a tag as well. > >> > >> Not quite. It's currently allowed for CSS colors to be unmanaged, if > >> untagged images are also unmanaged, and so they just get blasted into > >> the monitor's gamut without adjustment. It's just tagged images that > >> have to be managed right now. > >> > >> > How are those colors actually mapped when going to screen? > >> > I believe that in the case of Core Graphics, everything is drawn into > a > >> > sRGB > >> > device which is then mapped to the output device. > >> > So, a tagged imaged would go: Image profile -> sRGB -> monitor > profile. > >> > Assuming that the output device is properly calibrated, you would get > >> > the > >> > same colors everywhere. > >> > > >> > Is this how it's supposed to work? Or is a tagged image supposed to go > >> > to > >> > the monitor profile directly? > >> > >> That's how it's supposed to work, yes. Anything else is really bad, > >> because it means you're leaking color profiles all over intermediate > >> stages. > > > > > > So, should it go directly to the monitor profile, or use sRGB as an > > in-between? > > It makes a big difference. > > Sorry, my answer had a parallel structure to your question, so I > assumed it was clear. > > The colors should be sRGB internally, until the last moment when > they're sent to the display. > > Trying to store colors in a monitor profile before that is just > terrible, as it means you have to do tricky things when a window moves > between monitors (or crosses them!). > > It also means that things that can examine the colors, like a <canvas> > with an image painted into it, see a weird result, which is also a > pretty major entropy link for fingerprinting purposes. > Great! That is the right approach. For reference, Adobe's applications *roughly* do the following for a color managed workflow: 1. colors can come in with a profile. If a color has no profile, it is tagged with the device colorspace 2. colors are then mapped to the device colorspace. If the profiles match, this is a no-op. 3. compositing/blending happens in the device colorspace. The end result is a bitmap with the device profile. 4. For display, this bitmap is then mapped to the monitor colorspace and displayed. > > >> > Can you specify the rendering intent anywhere? > >> > >> I don't think there's a need to? > > > > Maybe not, but you need to define it somewhere if there's mapping between > > colorspaces. Perceptual is probably a reasonable default. > > Ah, yeah, definitely. > > ~TJ >
Received on Saturday, 7 December 2013 06:48:40 UTC