<div dir="auto"><div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">пн, 7 апр. 2025 г., 17:18 Pekka Paalanen <<a href="mailto:pekka.paalanen@haloniitty.fi">pekka.paalanen@haloniitty.fi</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 7 Apr 2025 14:44:25 +0300<br>
Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com" target="_blank" rel="noreferrer">randrianasulu@gmail.com</a>> wrote:<br>
<br>
> пн, 7 апр. 2025 г., 14:19 Pekka Paalanen <<a href="mailto:pekka.paalanen@haloniitty.fi" target="_blank" rel="noreferrer">pekka.paalanen@haloniitty.fi</a>>:<br>
> <br>
> > On Fri, 4 Apr 2025 22:14:10 +0300<br>
> > Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com" target="_blank" rel="noreferrer">randrianasulu@gmail.com</a>> wrote:<br>
> >  <br>
> > > пт, 4 апр. 2025 г., 21:35 Andrea paz <<a href="mailto:gamberucci.andrea@gmail.com" target="_blank" rel="noreferrer">gamberucci.andrea@gmail.com</a>>:<br>
> > >  <br>
<br>
...<br>
<br>
> > > > A theoretical question: can CinGG be adapted to work in Wayland or is<br>
> > > > it impossible? Has XWayland limitation?  <br>
> ><br>
> > X11 and Wayland designs for color management are fundamentally<br>
> > incompatible.<br>
> ><br>
> > With X11, applications never tell the display server what kind of<br>
> > pixels they are producing or which, if any, color profile they used for<br>
> > the display. With Wayland, applications must describe their pixels to<br>
> > the display server. Since X11 applications tell nothing to the X server,<br>
> > Xwayland has no color information to forward to the Wayland compositor.<br>
> ><br>
> > There can be case-specific manual solutions, though, that rely on<br>
> > correctly configuring both the X11 apps and the Wayland compositor. X11<br>
> > apps need to be configured to render for a specific display profile,<br>
> > and the Wayland compositor needs to assume the X11 windows are rendered<br>
> > for the same specific display profile. How that is actually done is up<br>
> > for each X11 app and each Wayland compositor.<br>
> >  <br>
> <br>
> Is there possibility for X extension for Xwayland allowing relatively<br>
> simple way to tell Xwayland what to do with each window/region?<br>
<br>
Hi,<br>
<br>
sure, but would it not be more useful to invest that effort in a proper<br>
Wayland integration?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Cinelerra-gg like other cinelerra forks uses custom gui library:</div><div dir="auto"><br></div><div dir="auto"><a href="https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=tree;f=cinelerra-5.1/guicast;h=0c7946e891c758f1b4df89c8459cbac926bf4b3b;hb=HEAD">https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=tree;f=cinelerra-5.1/guicast;h=0c7946e891c758f1b4df89c8459cbac926bf4b3b;hb=HEAD</a></div><div dir="auto"><br></div><div dir="auto">I have no idea how much effort will be needed to add Wayland to it. </div><div dir="auto"><br></div><div dir="auto">We lost our main/only developer nearly 5 years ago, so all I can do is fixing minor bugs and trying to catch up with ffmpeg API changes.</div><div dir="auto"><br></div><div dir="auto">So, we are on look out for c++ developer who is not afraid of "legacy" and will not try to 'refactor' it on first sight (efforts to refactor cinelerra proved to be LONG at best and unworkable at worst).</div><div dir="auto"><br></div><div dir="auto">I do not have HDR capable GPU/Monitor, and things most likely will remain so in foreseeable future (I am officially invalid, so my income sources are limited, and VERY limited by USA standarts. )</div><div dir="auto"><br></div><div dir="auto">Even if cinelerra(-gg) might never rise up to prominent position in Linux/*bsd world again - I still consider us useful as example of working NLE with internal 32fp pipeline, hw decoding, some OpenGL integration.</div><div dir="auto"><br></div><div dir="auto">So, if only more developers were not afraid to experiment with 'legacy '..... After all, retrocomputing is a thing now!</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
X11 is fundamentally limited to max 32-bit pixels so its stuck at 30<br>
bpc max with only 2 bits of alpha. That's probably the only thing that<br>
cannot be worked around.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I am not sure we need alpha over video region on final output .... right now x11/x11 opengl outputs definitely live without. If linux DRM can transmit 12bit hdmi/DP - may be this functionality can be implemented as separate output module? I looked into how psychtoolbox implement HDR rendering .. very funny, a bit like using Vulkan to put output in HDR mode and doing framebuffer blit manually in shaders ....</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> A bit like<br>
> <br>
> <a href="https://github.com/oyranos-cms/oyranos/blob/master/libxcm/include/X11/Xcm/Xcm.h" rel="noreferrer noreferrer" target="_blank">https://github.com/oyranos-cms/oyranos/blob/master/libxcm/include/X11/Xcm/Xcm.h</a><br>
<br>
That's an interesting one, I wasn't aware of this. I have to take some<br>
statements back.<br>
<br>
So this is communicating ICC profiles and associated window regions to<br>
an X11 compositing manager. If a profile covers the whole window, this<br>
should be relatively easy to hook up in a Wayland compositor's XWM<br>
(embedded X11 window manager).<br>
<br>
Being limited to ICC profiles is a hindrance for HDR, although the CICP<br>
extension for ICC does exist. Unfortunately CICP does not carry<br>
everything we have in the Wayland color-management protocol extension.<br>
Most notably, it misses the reference white level which would be<br>
necessary[1].<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Somewhere there also was cinepaint fork (unrelated to cinelerra) that also can be used for testing this functionality.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I suspect working with std body behind ICC will be ... challenging, if anyone decided to add missing info into standart. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Thanks,<br>
pq<br>
<br>
[1]: <a href="https://www.freelists.org/post/argyllcms/Standard-spec-for-ICC-file-that-can-be-used-for-HDR-calibration,1" rel="noreferrer noreferrer" target="_blank">https://www.freelists.org/post/argyllcms/Standard-spec-for-ICC-file-that-can-be-used-for-HDR-calibration,1</a><br>
</blockquote></div></div></div>