<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 5 Apr 2024 at 12:57, Pekka Paalanen <<a href="mailto:pekka.paalanen@haloniitty.fi">pekka.paalanen@haloniitty.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 5 Apr 2024 08:28:27 -0300<br>
salsaman <<a href="mailto:salsaman@gmail.com" target="_blank">salsaman@gmail.com</a>> wrote:<br>
<br>
> I don't think you are paying enough attention to the main points. Ir is not<br>
> simply a case of extending the fourcc values to include more. If I didn't<br>
> make it clear enough, the whole fourcc system is obscure, inadequate,<br>
> ambiguous. The only reason ever to use it would be when you don't have meta<br>
> data and you are forced to encode the format in the first 4 bytes.<br>
<br>
Right. You must be talking about some other fourcc system. There are<br>
many of them, and some combine multiple orthogonal things into a single<br>
enumeration, which then becomes very difficult to extend and work with.<br>
<br>
drm_fourcc.h is not one of those.<br></blockquote><div><br></div><div>I am talking about any system which tries to enumerate palettes (pixel formats) in four bytes in a non sequential way.</div><div>In my own system (Weed) for example, all RGB palettes are in the range 1 - 511, yuv palettes are 512 - 1023, alpha are 1024 <a class="gmail_plusreply" id="plusReplyChip-0">+</a></div><div><a class="gmail_plusreply"><br></a></div><div>In fact this header is enough to define every possible palette, there are standard enumerations for the most commonly used palettes, and</div><div>advanced palettes allows for the composition of new ones. In there also I have symbolic names for gamma types and yuv details,</div><div><br></div><div>interlacing and flags for pre-posr alpha are kept in another header,<br><a class="gmail_plusreply"><br></a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Metadata is always necessary anyway, either implied or explicit.<br></blockquote><div><br></div><div>Exactly, so I don't know why you keep mentioning fourcc as if it were some kind of complete solution.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Colorimetry is only relevant when displaying on a monitor. In the video<br>
> world we just have red, green and blue (plus alpha, y, u and v). These are<br>
> just labels for the colour channels, mapping them to bit formats.<br>
<br>
That is a very surprising opinion. Have you worked on HDR imagery?<br>
Or wide color gamut?<br></blockquote><div><br></div><div>As I have mentioned several times, these are display output parameters,</div><div> The only details which are relevant are the yuv/rgb conversion constants and the gamma transfer values, With those I can convert berween any two formats, which is all that is necessary for the steps between decoding and encoding / display.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> The values I mentioned are all necessary if you want to convert from one<br>
> colourspace to another. For example if I decode a video frame and the pix<br>
> format is YUV420P then to convert it to RGBA to display via openGL, I need<br>
> to know the YUV subspace (bt709 or itu601) and whether the values are<br>
> clamped or full range. Then I apply the standard conversion factors (Kr =<br>
> 0.2126, Kb = 0.0722 for bt709). This cannot be derived from the fourcc<br>
> (generally). No doubt there is a standard definition of definition of the<br>
> R,G,B primaries, but that isnr a concern.  I just feed the values into an<br>
> openGL texture buffer, and SDL buffer, a gdkpixbuf, QImage or whatever and<br>
> ask for it to be displayed. Now in an application I may optionally offer<br>
> the user filters to adjust the white balance, contrast, display gamma etc.<br>
> but that is outside of the scope of what I am proposing.<br>
<br>
Yes, those are all important properties, and not enough.<br>
<br></blockquote><div>Let's just say that the final display output is out of scope, what else is missing ?</div><div>Pre / post alpha is required for conversion between formats, I hadn't mentioned that because I was trying to avoid going into every little detail.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> And no, it is not a case of "adding another standard" and confusing things,<br>
> there is no standard.<br>
<br>
There are standards. ITU-T H.273, coding-independent code points, for<br>
example. That combines well with drm_fourcc.h. Also ICC combines well<br>
with drm_fourcc.h. This works, because drm_fourcc.h does not attempt to<br>
define anything outside of the memory layout and abstract channels.<br>
<br></blockquote><div>Sorry what I meant is there are standards on paper, but there is no standard set of enumerations (implementation vs specification).</div><div>Instead we have multiple implementations, each with their own definitions. In fact somewhere above I actually linked to the ITU709 standard.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I just had a look at pipewire, there is nothing bad about it per se, they<br>
> mention their palette values are based on gstreamer. So fine, we have yet<br>
> another library specific set of definitions.<br>
> <br>
> It's like I am trying to invent Esperanto, and all you can say is...."oh<br>
> you don't like English, well have you considered speaking German instead ?"<br>
<br>
That does seem like an apt analogue.<br>
<br>
> <br>
> Well that is it, I am done. I was asked how XDG video could be useful. I<br>
> explained the shortcomings of what exists currently, and outlined various<br>
> ways in which having a standard could be useful.<br>
<br>
Sorry, but I haven't understood what gap there is that would need to be<br>
filled with yet another pixel format enumeration. Or is it perhaps the<br>
same gap that we are filling in Wayland?<br>
<br></blockquote><div>Yes, yet another standard (implementarion), but a common standard that everyone agrees on, That is the entire basis for the existence of XDG, is it not ?</div><div>I have no idea what you doing in Wayland but from what you have said the focus is naturally on display devices, This is a logical place to include colour temperature, white balance and so on.</div><div>All fine and good, but these are monitor standards, video processing itself (converting between formats and applying effects) is independant of the display device. If I want to make an RGB delay effect I will split the image into R, G, and B components, add a delay and then recombine. I don't care about the colour primaries because that is irrelevant. What I do care about is, if my input image is in yuv format, what choice of values should I use to convert it to RGB.</div><div>If I am sending to openGL for display, I only care that the image I send is in RGBA format, post multiplied alpha, non interlaced, and sRGB gamma because that is what the openGL standard calls for,</div><div> For Wayland, libGL or whatever will get the monitor details and adjust the primaries etc. The same as if I connect a projector to the device, the display output can adjust the colours, but in my RGB delay effect it makes no difference.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We need to communicate a lot more about images than what pixel formats<br>
ever could. We are building that definition based on existing standards<br>
defining their own aspects: drm_fourcc.h, H.273 / ICC, and then adding<br>
what's missing like the how or if alpha channel is baked into RGB (the<br>
two ways to pre-multiply). Since these are all well-defined and<br>
orthogonal, there is no problem combining them.<br>
<br></blockquote><div>I totally agree ! I don't see what the argument is about. I just don't think that fourcc, alone or even supplemented with metadata is</div><div>a good idea, I prefer just to use plain integer enumerations</div><div><br></div><div>Sorry do you mean literally there are two ways to pre-multiply, or are you refering to pre multiplied vs. post multiplied ? The only way I know is to multiply each colour (RGB) value by the alpha value. With pre multiplied (such as what Cairo uses), the values have already been multiplied, with post alpha they have not. Most applications prefer post as it can avoid rounding errors, but pre can be faster when you have multiple layers,</div><div><br></div><div>ah here is my header</div><div><br></div><div><a href="https://github.com/salsaman/LiVES/blob/LiVES-4.0/libweed/weed-palettes.h">https://github.com/salsaman/LiVES/blob/LiVES-4.0/libweed/weed-palettes.h</a><br></div><div><br></div><div>the values are all described in the Weed standard (which I will split up into libweed and weed fx, as they have grown into independent entities).</div><div><a href="https://github.com/salsaman/LiVES/blob/d9cbe56c04569980a9c86b6df422a6bba1f451a8/libweed/docs/weedspec.txt#L1392">https://github.com/salsaman/LiVES/blob/d9cbe56c04569980a9c86b6df422a6bba1f451a8/libweed/docs/weedspec.txt#L1392</a><br></div><div><br></div><div>you will see nowhere a mention of the output display device, except for as I mentioned, aspect ratio and PAR which are useful for fixed sizing.</div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Wayland also already provides ways to handle some things, like pixel<br>
aspect ratio, so we don't want to define another conflicting way to<br>
define the same thing. That means the solution for Wayland is probably<br>
not applicable somewhere else, and vice versa.<br></blockquote><div><br></div><div><br></div><div>Well I thought this was the XDG list, not the Wayland list, The most community friendly way would be to develop these things as application neutral xdg standards and then have Wayland be compatible with that.</div><div><br></div><div>I will point out again, Wayland standards are geared towards display hardware, and whilst there is some overlap between that and video processing, the two things are not precisely the same. The former being device dependant, whilst the latter is a device independant abstraction dealing purely with manipulating bits and bytes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Thanks,<br>
pq<br></blockquote><div><br></div><div>Thankyou too, this is an interesting subject and something which I am involved in on a day to day basis,</div><div><br></div><div>G, </div></div></div>