[cairo] [PATCH] Add support for RGBA128F and RGB96F formats.

[Bryce Harrington]

On Wed, Jun 27, 2018 at 02:27:44PM +0200, Maarten Lankhorst wrote:
> Op 12-06-18 om 22:00 schreef Bill Spitzak:
> > If the values are 0-1 then one bit of exponent is not used, and also the sign bit it not used. So you could claim there are two wasted bits.
> >
> > However in all practical cases floating point is a better representation of image brightness than any integer representation of a linear or gamma corrected value as long as you have 16 or more bits per channel. Hardware support and standardization is a big win.
> >
> > And going outside the 0-1 range is very useful. >1 is necessary to represent HDR, and negative numbers allow infinite color spaces. It is true that some compositing operators designed for sRGB don't deal with this well, but I think the solution is to just not use them if you have such data.
> I think sticking to the 0-1 range is good, HDR support would still be possible but I don't think cairo has support for it currently. :)
> Nothing about the format would prevent it though.
> 
> Any consensus on 3 floats for RGB or 4 floats with the 4th set to 1.0?

I'd be interested in hearing about what the envisioned use cases for
RGB96F are, sounds like Intel's needs are more around the RGBA128F
format, yes?

Offhand, I would guess if someone is preferring to use only RGB, then
perhaps they'd be more interested in the reduced memory usage, in which
case it feels like the 3 float approach would be better.

If a particular use case does care about the alignment to 4 floats for
some need, is there any reason they couldn't just use the RGBA128F
format and set alpha to 1.0 themselves?

Bryce