On Mon, Mar 4, 2019 at 4:27 AM Pekka Paalanen <ppaala...@gmail.com> wrote:
> I'm still wondering, if an application uses an ICC profile for the > content it provides and defines an intent with it, should a compositor > apply that intent when converting from application color space to the > blending color space in the compositor? Well, in an ICC context it can be your (the programming infrastructure designer and builder) choice to only offer perceptual rendering. That is the only required tag in the profiles under discussion, all of which are 'display class' profiles. That applies to real display profiles (colord EDID based, or measurement base) as well as most instances of "artificial" color spaces like sRGB, opRGB, ROMM RGB and so on. In an HDR context this is still an open question, but someone or something will have to account for mismatches or suffer dramatic consequences in rendering. > Should the same application provided intent be used when converting the > composition result of the window to the output color space? It can be image specific. Again for ICC, standard dynamic range, output referred context, it's sane to always and only permit perceptual. There are use cases for absolute colorimetric, but they are special use cases and for them to be effective you have to apply such white point simulation across the entire UI. And because this is still lacking on Windows and macOS, the way it's handled in those workflows that require it is, hardware level calibration of display white point to match print media white point. In that case, an absolute colorimetric and media-relative colorimetric transform are the same. Also, because there is an 'input class' (scanners and cameras), and 'output class' (printers and presses) ICC profiles. I tend to refer to source profiles (the origin or starting point of a transform) and destination profiles (the intended or end point of a transform) rather than referring to input and output color spaces. That is, a display is not an output. It could be a source or destination, by using its 'display class' profile. > What would be a reasonable way to do those conversions, using which > intents? Always do perceptual rendering. And special use cases need to do things differently. Quite often, media simulation implies CMYK like the case of Scribus doing proof simulations, you probably don't need to get involved in that, just give Scribus a way to opt out of display compensation by indicating they've already done it. > Do I understand correctly that an ICC profile can provide separate > (A2B and B2A) cLUT for each intent? It's rare outside of the output class and occasionally for input class. And in the output class case, it's mainly the B2A (PCS to device) that have different tables, since the gamut mapping is baked into the profile rather than intelligently/dynamically performed by an engine. Most often I see output class have one A2B table (device to PCS), which is what applies in the application display use case, with the rendering intent choices pointing to that table. -- Chris Murphy _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
