Re: [RFC 0/5] Introduce drm sharpening property

[Pekka Paalanen <pekka.paalanen@haloniitty.fi>]

[-- Attachment #1: Type: text/plain, Size: 4070 bytes --]

On Tue, 12 Mar 2024 16:26:00 +0200
Pekka Paalanen <pekka.paalanen@haloniitty.fi> wrote:

> On Tue, 12 Mar 2024 08:30:34 +0000
> "Garg, Nemesa" <nemesa.garg@intel.com> wrote:
> 
> > This  KMS property is not implementing any formula  
> 
> Sure it is. Maybe Intel just does not want to tell what the algorithm
> is, or maybe it's even patented.
> 
> > and the values
> > that are being used are based on empirical analysis and certain
> > experiments done on the hardware. These values are fixed and is not
> > expected to change and this can change from vendor to vendor. The
> > client can choose any sharpness value on the scale and on the basis
> > of it the sharpness will be set. The sharpness effect can be changed
> > from content to content and from display to display so user needs to
> > adjust the optimum intensity value so as to get good experience on
> > the screen.
> >   
> 
> IOW, it's an opaque box operation, and there is no way to reproduce its
> results without the specific Intel hardware. Definitely no way to
> reproduce its results in free open source software alone.
> 
> Such opaque box operations can only occur after KMS blending, at the
> CRTC or later stage. They cannot appear before blending, not in the new
> KMS color pipeline design at least. The reason is that the modern way
> to use KMS planes is opportunistic composition off-loading.
> Opportunistic means that userspace decides from time to time whether it
> composes the final picture using KMS or some other rendering method
> (usually GPU and shaders). Since userspace will arbitrarily switch
> between KMS and render composition, both must result in the exact same
> image, or end users will observe unwanted flicker.
> 
> Such opaque box operations are fine after blending, because there they
> can be configured once and remain on forever. No switching, no flicker.

If you want to see how sharpness property would apply in Wayland
design, it would be in step 5 "Adjust (settings UI)" of
https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/color-management-model.md#compositor-color-management-model

To relate that diagram to KMS color processing, you can identify step 3
"Compose" as the KMS blending step. Everything before step 3 happens in
KMS plane color processing, and steps 4-5 happen in KMS CRTC color
processing.

Sharpening would essentially be a "compositor color effect", it just
happens to be implementable only by specific Intel hardware.

If a color effect is dynamic or content-dependant, it will preclude
colorimetric monitor calibration.


Thanks,
pq


> Where does "sharpeness" operation occur in the Intel color processing
> chain? Is it before or after blending?
> 
> What kind of transfer characteristics does it expect from the image,
> and can those be realized with KMS CRTC properties if KMS is configured
> such that the blending happens using some other characteristics (e.g.
> blending in optical space)?
> 
> What about SDR vs. HDR imagery?
> 
> 
> Thanks,
> pq
> 
> > > -----Original Message-----
> > > From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Simon
> > > Ser
> > > Sent: Monday, March 4, 2024 7:46 PM
> > > To: Garg, Nemesa <nemesa.garg@intel.com>
> > > Cc: Pekka Paalanen <pekka.paalanen@haloniitty.fi>; intel-
> > > gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; G M, Adarsh
> > > <adarsh.g.m@intel.com>
> > > Subject: RE: [RFC 0/5] Introduce drm sharpening property
> > > 
> > > On Monday, March 4th, 2024 at 15:04, Garg, Nemesa <nemesa.garg@intel.com>
> > > wrote:
> > >     
> > > > This is generic as sharpness effect is applied post blending.
> > > > Depending on the color gamut, pixel format and other inputs the image
> > > > gets blended and once we get blended output it can be sharpened based
> > > > on strength value provided by the user.    
> > > 
> > > It would really help if you could provide the exact mathematical formula applied
> > > by this KMS property.    
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]