[cairo] Color, Cairo and Cups

[Russell Shaw]

Billy Biggs wrote:
 > Russell Shaw (rjshaw at netspace.net.au):
 >
 >>Billy Biggs wrote:
 >>
 >>>Larry Ewing (lewing at gnome.org):
 >>>
 >>>>On Wed, 2006-03-08 at 18:13 -0500, Behdad Esfahbod wrote:
 >>>>
 >>>>>On Wed, 8 Mar 2006, Larry Ewing wrote:
 >>>>>
 >>>>>>Additionally if you ignore gamma (which Cairo does anyway
 >>>>>>right?) the working space doesn't matter too much for many
 >>>>>>operations.
 >>>>>
 >>>>>It does matter for any operation involving color blending, like
 >>>>>all operations with non-opaque alpha, and all with antialiasing
 >>>>>on.
 >>>>
 >>>>To clarify I was talking mainly about other RGB spaces here, not wildy
 >>>>different ones.
 >>>
 >>> The problem is that Cairo currently deals with sRGB (gamma-corrected)
 >>>values, and compositing in a gamma-corrected colour space is wrong
 >>>and leads to artifacts.  This problem is known but fixing it is hard
 >>>(read: slow, and most other software also gets it wrong).
 >>
 >>It's really insane to make the data non-linear for anything other than
 >>at the final output to a display device, or to linearize the input from
 >>an input device.
 >
 >   I'm not sure exactly what you're getting at.
 >
 >   I would agree that the idea of normalizing to the sRGB chromaticities
 > only makes sense if you're accepting floating-point linear RGB, assuming
 > that Larry has linear data.
 >
 >   In general I think cairo needs to keep using 8-bit per channel sRGB
 > colours, with their specified gamma curve, since that's a reasonable
 > default for digital images and user interface colours.

For mathematical operations to work right, gamma correction should be done
on RGB data so that any nonlinear light-input vs voltage-output on input devices
such as cameras are linearized. After the data is transformed in various
ways, it should gamma "nonlinearized" to compensate for nonlinear intensity vs
voltage of output devices such as CRTs.