GUI graphic system Color Management Requirements ------------------------------------------------ Author: Graeme W. Gill Date: 7th December 2020 Version: 1.0 This is general, but is writen in the context of adding modern color management to the Wayland protocol. R. Requirement J. Justification/explanation P. Priority S. Current status within desktop application programming environments: M = Supported by Microsoft Windows A = Supported by Apple OS X X = Supported by X11 based systems. ----------------------------------------------------------------------------------- 1) R: Applications need to know display pixels colorspace, and be able to do color transforms into this colorspace for display on that display device. Practically this means reference and access to an ICC profile that defines the colorspace of each display/pixel. P: Mandatory X: Some key applications deal with a wide range of source colorspaces, and their core job is to accurately render these for display. Sources are as diverse as other RGB colorspaces, CMYK and higher number of colorant print spaces, named colors, device independent color specifications, etc. Sources are not necessarily defined by ICC profiles. (See for instance how PostScript, PDF and XPS allow colors to be defined.) Accuracy of processing and correct gamut limitation/mapping handling is only possible with a direct conversion between the native source colorspace and the display colorspace. Existing application code assumes this capability is available, and these complex applications are not trivial to re-write or re-target. S: M, A, X 2) R: Applications need to be able to upload & set the profile that defines a displays colorspace. P: Mandatory X: Without this only the grossest problems of non-color managed displays can be dealt with. Manufacturer supplied profiles are at best generic, and often misleading when derived from (say) EDID information. Color sensitive uses of computer systems require calibration and profiling their specific display in a state of specific adjustment, and require verification and re-calibration/profiling on a regular basis. Applications used for calibration and profiling are normal applications that expect to target the same devlopment environment and API's as any other color managed application to be able to do their job. Like other complex and highly technical applications they are not trivial to create, maintain or port to new environments. S: M, A, X 3) R: System wide default color management. There should be a default source colorspace that the system will color convert to the display colorspace if the application doesn't want to handle the color conversion itself. P: Desirable X: Many application writers do not have the necessary knowledge to deal with color management, and the extra complexity needed in rendering with color management cannot be justified for many applications. This capability also allows for applications to work sucessfully in the face of unanticipated changes in display characteristics such as wide gamut, HDR etc. S: A 4) R: System will honour defacto standard display calibration curves included in display ICC profiles. Maximum HW precision will be used. P: Mandatory X: Although some displays have a capability of setting white point and brightness progromatically, this is not true for all displays and is not published, standardized or available via a standard API. Using graphic card 1D LUTs allows universal and standardized setting of these key display characteristics, and this is assumed by most existing display ICC profiles and color management tools. Additionally it is typicall that frame buffers have a more limited resolution that the final output of graphics cards/display adapters (i.e. 8 bit per component frame buffers typically have 10 bit outputs after 1D lookup tables, 10 bit frame buffers have 12/14 bit 1D LUTs etc.), and it is desirable to use this to ensure that the more limited precision of the frame buffer is fully utilized by using the higher precision of the 1D LUTs to perceptually even the quantization steps out. S: M, A, X 5) R: Application is able to set and get display calibration curves P: Mandatory X: Display calibration and verification support. See explanation above in 2). S: M, A, X 6) R: Application is able to display a rectangular window of pixels on a chosen display and set un-managed pixel values. P: Mandatory X: Display calibration and profiling support. See explanation above in 2). S: M, A, X 7) R: Commonly used profiles be readily available to applications P: Desirable X: Ties in with 3), as profiles are neede by the system for implementation, and this allows an application to determine what default system color management is actually doing. S: none 8) R: Support for easy intermixing HDR and SDR displays. This means supplementing the display and source spaces profile information with HDR profile and handling details. P: Highly desirable X: ICC profiles don't have complete enough information to convenienly specify HDR <-> SDR transformations. S: unknown. Some recent releases of MSWindows and OS X have added support for HDR displays, but this appears to be in a way that is not entirely backwards compatible with SDR displays. 9) R: Support global display modifications within the color managed context for the purposes of applications such as "blue shift" or equivalent. P: Desirable X: People use and enjoy such application, and these typically rely on the availablility of per channel lookp curves in the graphics hardware to do crude global display modifications. A way of accomodating this while working harmonously with color management is desirable. S: A