[Intel-gfx] [PATCH v2 00/10] Color Manager Implementation

[Hans Verkuil]

On 07/14/15 12:16, Daniel Vetter wrote:

<cut away old quotes>

>>>> I would guess that a LUT supporting 16 bit color components would need a precision
>>>> of 0.20 or so (assuming the resulting values are used in further calculations).
>>>>
>>>> High dynamic range video will be an important driving force towards higher bit depths
>>>> and accurate color handling, so you can expect to see this become much more important
>>>> in the coming years.
>>>>
>>>> And as I mentioned another consideration is that this fixed point data type might
>>>> be useful elsewhere in the kernel where you need to do some precision arithmetic.
>>>> So using a standard type that anyone can use with functions in lib/ to do basic
>>>> operations can be very useful indeed beyond just DRM and V4L2.
>>>
>>> 0.20 would still comfortably fit into 8.24. And yeah worst-case (in 10
>>> years or so) we need to add a high-bpp variant if it really comes to it.
>>
>> I think this is much closer than you think. I agree that you are not likely to see
>> this soon for consumer graphics cards, but for professional equipment and high-end
>> consumer electronics this is another story.
>>
>> And if it is being done for input, then output will need it as well: after all,
>> what's the point of 16-bit color components if you can't display it? Whether Intel
>> will support it is another matter, but there are other vendors, you know... :-)
> 
> Input is different because of post-processing - you need that much depth
> to be able to get useful data out of the dark areas, without the risk for
> the highlights to clip. While processing you need that depth to avoid
> banding (because integer math sucks). But tbh I haven't seen anything but
> 12bpc (and those usually use dithered 10bpc panels internally) anywhere
> and the common screens top out at 10bpc.
> 
> So from my pov of drm s8.24 will be enough for a long time, but if you're
> convinced that the input side needs this soon I guess it makes sense to go
> with the bit more overhead and 32.32. Otoh we'll never need 32 of integer
> part if we normalize to 0.0-1.0, and that normalization is really
> something I think we want.

I think 32.32 is primarily important as a standard data type for public APIs
and as the standard data type for math operations. How it is stored in the
driver is driver (or possibly subsystem) specific. Is it a problem for you to
store it as 8.24 in the driver (specifically for LUTs) to reduce memory usage?
Converting from 8.24 to 32.32 and vice versa is trivial, so this might be the
best of both worlds.

Regards,

	Hans