Carsten Haitzler (The Rasterman) wrote: Hi,
> but is the intent that compositors MUST support color management and > applications will fail entirely or fail to display even partly correctly if > compositor doesnt support color management or doesnt support the color > profile/space requested by the client? My intent is directly the opposite. An application could choose to fail if core color management is not present, or fall back into a non-color managed mode. An application that wants to use Enhance color management and finds it is not present, could fall back to application color management (although it probably wouldn't, because it doesn't want to work that hard), or fall back into a non-color managed mode. > or will it be expected that apps need to > always be able to convert to sRGB for compatibility and then have added > colorspace capabilities if it's supported? what is the intent? I thought I'd explained this in the previous post ? - perhaps I'm simply not understanding where you are coming from on this. The intent is to enable proper color management. In general, only the application will be able to do this to its own satisfaction, so core color management is essential. Providing enhanced color management is a convenience to applications that don't wish to implement their own color management and are content with quite limited set of capabilities, as well as making available a facility to force default color management onto applications that are not color aware. If this doesn't make sense to you, then perhaps the best thing would be for me to lay out the nuts and bolts of what's happening in these different color management scenarios. Cheers, Graeme Gill. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
