[Cin] "Competitors" or do we want to stay alive?

[Andrew Randrianasulu]

пн, 7 апр. 2025 г., 17:18 Pekka Paalanen <pekka.paalanen at haloniitty.fi>:

> On Mon, 7 Apr 2025 14:44:25 +0300
> Andrew Randrianasulu <randrianasulu at gmail.com> wrote:
>
> > пн, 7 апр. 2025 г., 14:19 Pekka Paalanen <pekka.paalanen at haloniitty.fi>:
> >
> > > On Fri, 4 Apr 2025 22:14:10 +0300
> > > Andrew Randrianasulu <randrianasulu at gmail.com> wrote:
> > >
> > > > пт, 4 апр. 2025 г., 21:35 Andrea paz <gamberucci.andrea at gmail.com>:
> > > >
>
> ...
>
> > > > > A theoretical question: can CinGG be adapted to work in Wayland or
> is
> > > > > it impossible? Has XWayland limitation?
> > >
> > > X11 and Wayland designs for color management are fundamentally
> > > incompatible.
> > >
> > > With X11, applications never tell the display server what kind of
> > > pixels they are producing or which, if any, color profile they used for
> > > the display. With Wayland, applications must describe their pixels to
> > > the display server. Since X11 applications tell nothing to the X
> server,
> > > Xwayland has no color information to forward to the Wayland compositor.
> > >
> > > There can be case-specific manual solutions, though, that rely on
> > > correctly configuring both the X11 apps and the Wayland compositor. X11
> > > apps need to be configured to render for a specific display profile,
> > > and the Wayland compositor needs to assume the X11 windows are rendered
> > > for the same specific display profile. How that is actually done is up
> > > for each X11 app and each Wayland compositor.
> > >
> >
> > Is there possibility for X extension for Xwayland allowing relatively
> > simple way to tell Xwayland what to do with each window/region?
>
> Hi,
>
> sure, but would it not be more useful to invest that effort in a proper
> Wayland integration?
>

Cinelerra-gg like other cinelerra forks uses custom gui library:

https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=tree;f=cinelerra-5.1/guicast;h=0c7946e891c758f1b4df89c8459cbac926bf4b3b;hb=HEAD

I have no idea how much effort will be needed to add Wayland to it.

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.

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).

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. )

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.

So, if only more developers were not afraid to experiment with 'legacy
'..... After all, retrocomputing is a thing now!




> X11 is fundamentally limited to max 32-bit pixels so its stuck at 30
> bpc max with only 2 bits of alpha. That's probably the only thing that
> cannot be worked around.
>


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 ....


> > A bit like
> >
> >
> https://github.com/oyranos-cms/oyranos/blob/master/libxcm/include/X11/Xcm/Xcm.h
>
> That's an interesting one, I wasn't aware of this. I have to take some
> statements back.
>
> So this is communicating ICC profiles and associated window regions to
> an X11 compositing manager. If a profile covers the whole window, this
> should be relatively easy to hook up in a Wayland compositor's XWM
> (embedded X11 window manager).
>
> Being limited to ICC profiles is a hindrance for HDR, although the CICP
> extension for ICC does exist. Unfortunately CICP does not carry
> everything we have in the Wayland color-management protocol extension.
> Most notably, it misses the reference white level which would be
> necessary[1].
>


Somewhere there also was cinepaint fork (unrelated to cinelerra) that also
can be used for testing this functionality.


I suspect working with std body behind ICC will be ... challenging, if
anyone decided to add missing info into standart.


>
> Thanks,
> pq
>
> [1]:
> https://www.freelists.org/post/argyllcms/Standard-spec-for-ICC-file-that-can-be-used-for-HDR-calibration,1
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20250407/8528d0cb/attachment.htm>