[RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

[Pekka Paalanen]

On Mon, 16 Aug 2021 15:37:23 +0200
sebastian at sebastianwick.net wrote:

> On 2021-08-16 14:40, Harry Wentland wrote:
> > On 2021-08-16 7:10 a.m., Brian Starkey wrote:  
> >> On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote:  
> >>> Hello Brian,
> >>> (+Uma in cc)
> >>> 
> >>> Thanks for your comments, Let me try to fill-in for Harry to keep the 
> >>> design
> >>> discussion going. Please find my comments inline.
> >>>   
> > 
> > Thanks, Shashank. I'm back at work now. Had to cut my trip short
> > due to rising Covid cases and concern for my kids.
> >   
> >>> On 8/2/2021 10:00 PM, Brian Starkey wrote:  
> >>>>   
> >> 
> >> -- snip --
> >>   
> >>>> 
> >>>> Android doesn't blend in linear space, so any API shouldn't be built
> >>>> around an assumption of linear blending.
> >>>>   
> > 
> > This seems incorrect but I guess ultimately the OS is in control of
> > this. If we want to allow blending in non-linear space with the new
> > API we would either need to describe the blending space or the
> > pre/post-blending gamma/de-gamma.
> > 
> > Any idea if this blending behavior in Android might get changed in
> > the future?  
> 
> There is lots of software which blends in sRGB space and designers
> adjusted to the incorrect blending in a way that the result looks right.
> Blending in linear space would result in incorrectly looking images.

Hi,

yes, and I'm guilty of that too, at least by negligence. ;-)

All Wayland compositors do it, since that's what everyone has always
been doing, more or less. It's still physically wrong, but when all you
have is sRGB and black window shadows and rounded corners as the only
use case, you don't mind.

When you start blending with colors other than black (gradients!), when
you go to wide gamut, or especially with HDR, I believe the problems
start to become painfully obvious.

But as long as you're stuck with sRGB only, people expect the "wrong"
result and deviating from that is a regression.

Similarly, once Weston starts doing color management and people turn it
on and install monitor profiles, I expect to get reports saying "all
old apps look really dull now". That's how sRGB is defined to look
like, they've been looking at something else for all that time.
:-)

Maybe we need a sRGB "gamut boost" similar to SDR luminance boost. ;-)

> >> I still think that directly exposing the HW blocks and their
> >> capabilities is the right approach, rather than a "magic" tonemapping
> >> property.
> >> 
> >> Yes, userspace would need to have a good understanding of how to use
> >> that hardware, but if the pipeline model is standardised that's the
> >> kind of thing a cross-vendor library could handle.
> >>   
> > 
> > One problem with cross-vendor libraries is that they might struggle
> > to really be cross-vendor when it comes to unique HW behavior. Or
> > they might pick sub-optimal configurations as they're not aware of
> > the power impact of a configuration. What's an optimal configuration
> > might differ greatly between different HW.
> > 
> > We're seeing this problem with "universal" planes as well.  
> 
> I'm repeating what has been said before but apparently it has to be said
> again: if a property can't be replicated exactly in a shader the
> property is useless. If your hardware is so unique that it can't give us
> the exact formula we expect you cannot expose the property.

From desktop perspective, yes, but I'm nowadays less adamant about it.
If kernel developers are happy to maintain multiple alternative UAPIs,
then I'm not going to try to NAK that - I'll just say when I can and
cannot make use of them. Also everything is always up to some
precision, and ultimately here it is a question of whether people can
see the difference.

Entertainment end user audience is also much more forgiving than
professional color management audience. For the latter, I'd hesitate to
use non-primary KMS planes at all.

> Either way if the fixed KMS pixel pipeline is not sufficient to expose
> the intricacies of real hardware the right move would be to make the KMS
> pixel pipeline more dynamic, expose more hardware specifics and create a
> hardware specific user space like mesa. Moving the whole compositing
> with all its policies and decision making into the kernel is exactly the
> wrong way to go.
> 
> Laurent Pinchart put this very well:
> https://lists.freedesktop.org/archives/dri-devel/2021-June/311689.html

Thanks for digging that up, saved me the trouble. :-)


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20210915/81e9c87c/attachment.sig>