[ANNOUNCE] pixfmtdb

[Pekka Paalanen]

On Tue, 24 Jan 2023 00:54:07 +0100
Sebastian Wick <sebastian.wick at redhat.com> wrote:

> On Mon, Jan 23, 2023 at 11:43 PM Simon Ser <contact at emersion.fr> wrote:
> >
> > On Monday, January 23rd, 2023 at 21:25, Sebastian Wick <sebastian.wick at redhat.com> wrote:
> >  
> > > Why is the TF defined for GL formats and both the primaries and TF for
> > > Vulkan formats? The only exception here should be sRGB formats. Where
> > > did you get the information from?  
> >
> > This is what upstream dfdutils does [1]. Can you explain why you think
> > it should be undefined instead of linear?  
> 
> The channels have no meaning. You can put whatever you want in there.
> It doesn't have to be linear, it doesn't have to be colors and
> especially not colors with specific primaries. It's only when it's
> used to form an image that the TF and primaries are known. Vulkan
> specifically requires you to explicitly provide this information to
> the WSI and YCC samplers (generally everywhere where knowing them is
> required) and never assumes that certain pixel formats imply certain
> TFs and primaries (exception being the sRGB variants).
> 
> 
> (See also https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#_issues_26,
> Q 23)
> 
> The problem here seems to be that the Data Format spec describes more
> than the pixel format. If you want to share an image, the TF and
> primaries are essential but they are not an inherent part of the pixel
> format of the image. So yeah, I think what dfdutils does is...
> probably not wrong but not what you're after.
> 
> >
> > I was wondering what to do for DRM formats regarding these. I think it
> > would be worthwhile to do like Vulkan: set TF = linear, primaries =
> > BT.709, pre-multiplied alpha = yes. These are the things KMS assume
> > when there is no override (ie, when there is no KMS property saying
> > otherwise).  
> 
> Please no. All undefined is absolutely the right thing to do. Adding
> any more meaning to pixel formats is a horrible idea. The KMS
> properties are also not an override, they describe the image and the
> description has default values.

Hi,

I agree with Sebastian here.

The same with (plain) Pixman, Cairo and OpenGL formats. They don't
define primaries nor TF.

Personally I think that sRGB "pixel formats" are semantically simply
not a part of the same enumeration as plain pixel formats, but API-wise
it was a convenient trick to add a "pixel format" that implies
different processing in the same old API functions.

Most of the APIs do computations as if the TF was linear (assuming you
think in higher semantic terms than basic mathematical operations),
but the pixel format does not define that it is. The responsibility of
applying meaningful computations is left for the user of the APIs.


Thanks,
pq

> >
> > [1]: https://github.com/KhronosGroup/dfdutils/blob/5cd41cbdf63e80b00c085c6906a1152709e4c0f2/createdfd.c#L47
> >  
> 

-------------- 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/20230124/6c420389/attachment.sig>