Re: Color space API
Andrea Canciani <[email protected]>
| Newsgroups | gmane.comp.lib.cairo |
|---|---|
| Message-ID | <CAN_5=BA8+pkTs9RNxv+Kbx=9TmBmdczEaHqFgc2h6EzCEu7tSQ@mail.gmail.com> |
On Sun, Jul 29, 2012 at 2:43 PM, Adrian Johnson <[email protected]> wrote: > On 28/07/12 05:49, Bill Spitzak wrote: >> In your plan, if an on-screen surface is given colorspace X where X is >> not sRGB, what does this mean? I think this is what leads to a lot of >> the confusion when color space is discussed. >> >> IMHO the solution is that the numbers in that surface are put unchanged >> on the screen. Thus no matter what colorspace it is set to, if there is >> a 5 in the red channel of a pixel, then a 5 is put into the output >> buffer sent to the screen. >> >> The way to get color-correct output is to set the destination surface to >> the colorspace that the screen (or the input to the screen driver) has. >> Changing the destination colorspace never changes the appearance of that >> surface on the screen. >> >> What the colorspace of the destination does is indicate what conversion >> is done to source colorspaces before compositing. The destination can be >> set to Y and the source to X, and what happens is the source is run >> through the X->Y conversion before compositing. However after the >> numbers come out of the compositing, the setting of Y has NO effect on >> what happens to those numbers. They go onto the screen or output device >> unchanged. >> >> Any other interpretation I think results in unworkable difficulties. >> >> Correct/incorrect? > > That is correct. The destination surface is set to the color space of > the destination device. Source colors are converted to the destination > color space before compositing. If the application wants to do > compositing in a different color space it can create a similar surface > with the different color space, composite to it, then paint it to the > destination surface. I guess this confirms what I asked in the previous e-mail. Sorry, I should have read the whole thread before replying. > > When using the PDF surface, the color space of the destination device is > usually not known. Instead the PDF page is set to the color space that > compositing will be done in. When the PDF is rendered the destination > surface is set to the device color space, a similar surface with the > color space of the PDF page is created then rendered to. The colors will > be transformed to the device color space when the similar surface is > painted to the destination surface. > >> Another aspect is "linear" or "gamma corrected" compositing. In this >> both the source *AND* the destination are converted from their spaces to >> a "linear" space, composited, and then the result is converted back to >> the destination space. The linear space is chosen so this conversion is >> fast (it has the same primaries as the destination). >> >> I believe your proposal has no possible setting that will cause this to >> happen. I think this can be a different setting, independent of the >> destination color space. Either it is a flag on the destination >> surfaces, or it is different compositing operations (ie LINEAR_OVER >> verses OVER). I don't think it is part of the colorspace, because it has >> no effect on how the source is handled. In the PDF drawing model, to do this you would composite over a surface whose colorspace is linear. If you needed the destination to be in another colorspace you would then paint the previous result on the destination. Pseudocode: dest = cairo_create_my_nonlinear_surface(); cr = cairo_create(dest); cairo_push_with_colorspace (cr, my_linear_colorspace); /* draw in linear space */ cairo_pop_to_source(); cairo_set_operator(cr, SOURCE); cairo_paint(); > > I don't currently have a proposal for this since looking at the ICC > specification I could not see how to extract this linear space from an > ICC profile. In general it will not be possible to extract such a color space, because ICC profiles can define a color mapping which is almost completely arbitrary. > > -- > cairo mailing list > [email protected] > http://lists.cairographics.org/mailman/listinfo/cairo -- cairo mailing list [email protected] http://lists.cairographics.org/mailman/listinfo/cairo