- Cin - Cinelerra-GG Mailing Lists

Alternative patch for x265 and cmake 4.0
by Andrew Randrianasulu 09 Apr '25

09 Apr '25

Use it instead of my previous patch? Tested on updated today Arch linux, it will be nice if it will not break ubuntu 16.04 (i tried to set cmake version to 3.5.1)

2 2

Paste without the remainder moving
by Stefan de Konink 08 Apr '25

08 Apr '25

Is there an option to copy paste everything (track, keyframes, etc.) so it would overwrite, instead of move the remainder of the track to the right? -- Stefan

3 3

Mailing list
by Andrea paz 08 Apr '25

08 Apr '25

I noticed that the mailing-list archive is not showing some of the mails of a new subscriber (Pekka Paalanen). It only reports one. https://lists.cinelerra-gg.org/pipermail/cin/2025-April/thread.html Is this the usual problem with new subscribers or is it my system not updating the archive?

2 1

Re: [Cin] "Competitors" or do we want to stay alive?
by Andrew Randrianasulu 08 Apr '25

08 Apr '25

вт, 8 апр. 2025 г., 10:59 Pekka Paalanen <pekka.paalanen(a)haloniitty.fi>: > On Mon, 7 Apr 2025 18:31:17 +0300 > Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > > > пн, 7 апр. 2025 г., 17:18 Pekka Paalanen <pekka.paalanen(a)haloniitty.fi>: > > > > > On Mon, 7 Apr 2025 14:44:25 +0300 > > > Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > > > > > > > пн, 7 апр. 2025 г., 14:19 Pekka Paalanen < > pekka.paalanen(a)haloniitty.fi>: > > > > > > > > > On Fri, 4 Apr 2025 22:14:10 +0300 > > > > > Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > > > > > > > > > > > пт, 4 апр. 2025 г., 21:35 Andrea paz < > gamberucci.andrea(a)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=cinelerr… > > > > 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! > > > > Sorry to hear, I wish you and the project all the best. > Thanks .... > > > > 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 .... > > Linux DRM KMS is not inherently limiting bit depth, it all depends on > the hardware and the driver. E.g. a driver can support a framebuffer > with half-float RGB (16 bpc) or 16 bpc integer or 32-bit float, > whatever anyone desires. Adding new formats to a list is easy, it's all > about what the hardware and HDMI, DisplayPort etc. can do. > > I'm not aware of how psychtoolbox works, but I guess it needs complete > control over an output for scientific experiments. One way to do that > is to use DRM leasing. > yes, this is how I come to discover that this probably strictly scientific project grow some HDR player ;) http://psychtoolbox.org/docs/PsychHDR also link at the bottom of page to source file. I am not sure radv supported all required extensions last time I looked at it. Andrea does have AMD card but "only" wide-gamut monitor. May be some kind of measurement overlay exist in .. mangohud or something? To see pixel and metadata values even w/o HDR monitor .... > It appears that Xwayland has support for DRM leasing, so X11 apps can > lease a KMS CRTC and a KMS connector from a willing Wayland compositor. > The advantage is that the app gets complete, direct access to the > display device and monitor, unobstructed by the window system. The > disadvantage is that the same monitor disappears from the rest of the > desktop environment, and you have to use the KMS UAPI to drive it - IOW > without a window system to lean on. I'm not sure what EGL nor Vulkan > offers to make that easier. > > The monitor disappearing from the rest of the desktop environment is > absolute, including input delivery. The user cannot move the mouse > pointer to the leased monitor. This means you need either some > input means outside of the desktop environment, or you need a regular > window on another monitor for controls. > > The primary use case for DRM leasing is head-mounted displays for > virtual reality. DRM leasing might be a good way to drive a separate > mastering display. > > > Thanks, > pq > > > > > A bit like > > > > > > > > > > > > https://github.com/oyranos-cms/oyranos/blob/master/libxcm/include/X11/Xcm/X… > > > > > > 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-ca… > > > > >

1 0

Re: [Cin] "Competitors" or do we want to stay alive?
by Andrew Randrianasulu 08 Apr '25

08 Apr '25

пн, 7 апр. 2025 г., 17:18 Pekka Paalanen <pekka.paalanen(a)haloniitty.fi>: > On Mon, 7 Apr 2025 14:44:25 +0300 > Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > > > пн, 7 апр. 2025 г., 14:19 Pekka Paalanen <pekka.paalanen(a)haloniitty.fi>: > > > > > On Fri, 4 Apr 2025 22:14:10 +0300 > > > Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > > > > > > > пт, 4 апр. 2025 г., 21:35 Andrea paz <gamberucci.andrea(a)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=cinelerr… 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/X… > > 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-ca… >

2 1

Fwd: Mentioned in [Cinelerra-GG 0000672]: Crash when using the speed curve
by Andrew Randrianasulu 08 Apr '25

08 Apr '25

so, I looked at this bug and it seems that only taking back change to auto.C "fixes" it But may be I just tested too little (in virtual Arch) full backtrace is big, but I think it crashes here: #6 MWindow::normalize_speed (this=this@entry=0x7ffe5099ab80, old_edl=0x62bf3d52dd40, new_edl=0x7a75402bbd50, edit_speed=edit_speed@entry=0) at mwindowedit.C:2705 old_keyframes = <optimized out> new_keyframes = 0x7a7538311830 old_auto = 0x0 new_plugin = <optimized out> plugin_start = <optimized out> orig_start = <optimized out> plugin_end = <optimized out> orig_end = <optimized out> old_plugin_set = <optimized out> new_plugin_set = 0x7a75382080a0 old_plugin = <optimized out> i = 0 old_size = <optimized out> new_size = <optimized out> n = <optimized out> old_speeds = <optimized out> old_speed = <optimized out> old_edit = <optimized out> new_speeds = <optimized out> new_speed = <optimized out> edit_plugins = 1 edit_autos = 1 edit_labels = 1 result = 1 first_track = 0 old_track = <optimized out> new_track = <optimized out> #7 0x000062befc37112a in MWindow::speed_after (this=0x7ffe5099ab80, done=done@entry=0, edit_speed=edit_speed@entry=0) at mwindowedit.C:2753 so *may be* old_auto being 0x0 causes crash ? Not sure where to put guard in this function yet ... ---------- Forwarded message --------- From: Cinelerra GG Bug Tracker <noreply(a)cinelerra-gg.org> Date: Tue, Apr 8, 2025 at 6:03 AM Subject: Mentioned in [Cinelerra-GG 0000672]: Crash when using the speed curve To: <randrianasulu(a)gmail.com> On 2025-04-08 03:03, PhyllisSmith mentioned you on: https://www.cinelerra-gg.org/bugtracker/view.php?id=672 @Lukas I think I have isolated the crash and reverted 3 files to a previously working version. BUT it does not make any sense why that would solve the problem AND I am not even sure that it solves all cases. However, I will create an older version AppImage with the change in for you to test when I boot that O/S desktop tomorrow. @Andrew-R Here is an exact set of minimum steps to create the problem. Start with a new bcast, i..e. CIN_CONFIG=/tmp/bcast5 bin/cin Just dismiss the note of the day window (x it gone) load media using replace current project turn on generate keyframes while tweaking drag chromakeyhsv to video bring up chromkeyhsv menu play a little and move the slider in the chromkeyhsv menu to get keyframes stop play, then move cursor and play a little to get another set of keyframes use View to turn on speed curve move cursor to between the 2 sets of keyframes in front of cursor, try to move speed curve it gets stuck and crashes THIS COMMIT CRASHES: commit 25e944875e181186eeb59a124c1822e5b55d2248 Author: Good Guy <good1.2guy(a)gmail.com> Date: Fri Sep 4 09:17:01 2020 -0600 fix auto id 'that' blunder, tweak keyfrm popup speed undo THIS COMMIT SEEMS TO WORK: commit 22c6251d37911a11e322bf7518e6a992ea0bb6c7 Author: Good Guy <good1.2guy(a)gmail.com> Date: Wed Sep 2 19:16:24 2020 -0600 add ids to auto/labels, fix awdw gui deadlock, fix fourier bfr bug, fix cache critical section, rework normalize_speed, fix delete_track gang bug So I reverted cinelerra keyframepopup.C, keyframepopup.h, and auto.C to the Sept 2, 2020 version since no further changes were made to those other than a comment.

1 0

Some tests on blending
by Andrea paz 07 Apr '25

07 Apr '25

In reference to the email: https://www.mail-archive.com/cin@lists.cinelerra-gg.org/msg04905.html and to the whole of the following discussion, which includes a workaround by IgorBeg. I have tried further testing, now that we have Blend Algebra that allows us to customize the various Blends. I do not know whether it is appropriate to reopen an issue that is now closed and has also led to tensions (you can see the article: https://linuxvideoediting.blogspot.com/2022/09/transparent-text-effect-with…. I warn that it contains polemics). So I will only report the result of some of my tests; they are probably not even worth reading.

4 33

Re: [Cin] "Competitors" or do we want to stay alive?
by Andrew Randrianasulu 07 Apr '25

07 Apr '25

пн, 7 апр. 2025 г., 14:19 Pekka Paalanen <pekka.paalanen(a)haloniitty.fi>: > On Fri, 4 Apr 2025 22:14:10 +0300 > Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > > > пт, 4 апр. 2025 г., 21:35 Andrea paz <gamberucci.andrea(a)gmail.com>: > > > > > @Georgy > > > X11 supports CMS more or less well. Even I was able to profile the > > > monitor and install it with colord. It's not full support like Windows > > > or Apple has, but it's doable. > > Hi, > > X11 supports color management by having nothing to do with it. It's a > strictly hands-off design. Each application can choose a different CMS > simultaneously. An application that does not explicitly use a CMS also > does not have any color management with X11. > > The X server can step out of the way and let applications post pixels > as-is to each monitor. This is good for application-side color > management, the pixel values do not get arbitrarily munged. However, > X11 also offers a number of interfaces to force the X server to munge > the pixel values. It allows loading a VCGT, but it also allows any > app to change any of the pixel munging settings, so the display > calibration is fragile. > > On X11 it is the responsibility of each application to make each part > of their windows color-managed for the monitor they happen to overlap. > X11 does nothing to help with that. > > > > For Wayland the big problem, why they didn't want to make a CMS, is > > > its being decentralized, a protocol to which various software could > > > interact by bringing their own version of CMS. The trouble is that a > > > CMS must be centralized by definition, if everyone fakes their own > > > implementation goodbye std. > > In the Wayland model, the color management is centralized in the > Wayland compositor you use. Any application that does not choose to > manage its own colors will get color-managed by the compositor > automatically and unavoidably. > > > > On Wayland, good programmers but bad color scientists, they didn't > > > even know how to start. Then Valve created The Gamescope to be able to > > > play games in HDR, and Wayland started from that to implement its CMS. > > > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 > was created 5 years ago. > > https://github.com/ValveSoftware/gamescope/pull/1168 was filed 1 year > ago, after the above had already settled on the fundamental information > to be carried. > > EGL and Vulkan HDR extensions are the real API predecessors here for > both, and ITU-R recommendations and SMPTE specifications have had their > influence as well. > > > > The result is not a real CMS but just something for video games and > > > movies. True, lately they seem to have figured out the problem and one > > > can hope that they will be able to solve it. > > The decision to concentrate first to the HDR aspect was a deliberate > decision due to popular demand. The professional color-managed > workflows were always in my mind from the start. In fact, people were > in a hurry to implement HDR support without any thought to color > management, but I'm really happy to have been able to sell the idea > that color management is a prerequisite to HDR support. Otherwise we > would now have ad hoc HDR support that would quite likely be > fundamentally incompatible with the goals of color management. > > > > For the time being, the main developer said:... > > > The color-management Wayland extension is enough for entertainment > > > purposes like games and movies. However, it is not enough for > > > professional color management needs including photo editing and print > > > preview. The major missing piece is the ability to measure the display > > > response. Every monitor is unique, and measuring is the only way to > > > achieve reliably repeatable and accurate display behavior. > > > ... > > > > > > Introduction to CMS in Wayland by the lead developer: > > > > > > > https://www.collabora.com/news-and-blog/news-and-events/12-years-of-incubat… > > You quoted that part, but conveniently ignored everything else that > goes against your statements. > > My plan for display profiling and calibration was documented 2 years > ago: > https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/27 > > and this was linked in the text you quoted, and below. > > Note, that it is possible to calibrate and profile a monitor without > anything from issue 27, it's just tedious and error-prone to achieve. > Issue 27 makes that process easier to get right, more robust, and more > user friendly. The one thing that issue 27 does mention is the > programming of a VCGT, but I am unsure whether that has any benefit for > any HDR monitor driven in HDR mode. > > > > > > > A summary by Paalanem of everything that happened in the 12 years of > > > development: > > > https://gitlab.freedesktop.org/pq/color-and-hdr > > > > > > Old discussion on monitor profiling (in the thread, user Graeme Gill > > > is ArgylCMS's developer): > > > https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/27 > > > > > > Wayland CMS implementation in Gnome: > > > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4291 > > > > > > > > > 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? A bit like https://github.com/oyranos-cms/oyranos/blob/master/libxcm/include/X11/Xcm/X… I looked in libplacebo (for avoiding to deal directly with Vulkan et al) and ... it was not simple for me. > I happened to see there is a Cinelerra.GG ticket open for ICC support. > A native Wayland application would not necessarily need to work with > ICC profiles, the color management protocol has an alternative > (and HDR-capable!) interface for "parametric image descriptions" which > are much closer to video metadata interfaces than ICC. EGL and Vulkan > color related extensions will map to the Wayland color-management > protocol as the support lands and matures in Mesa, so it's possible to > take advantage of Wayland color features without touching the protocol > yourself. > > > > > IF i understand correctly basically screencapture, user input, > > monitor/compositor all tied to X11. There are (or were) different output > > modules (to DV tape, to mjpeg card), so I guess SOME abstraction between > > core and video i/o exist in cinelerras. Right now cingg reported to work > > over Xwayland but I do not know how any (external) color management etc > > work in this case. Under wayland you need EGL not GLX and cingg uses > rather > > obscure Xserver pbuffer mechanism. Not sure how easy/impossible is to > > rewrite it for EGL. > > > > I do not even know where such questions should be asked now! On > xorg-devel? > > in gitlab issues? > > > > cc xorg-devel because I have them in my auto-address book in gmail. > > Wayland-related things can be discussed on wayland-devel@, cc'd, but it > requires subscription to avoid the manual moderation queue when sending > email to it. > > I'm happy to discuss color management topics in > https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues as well. I'm > also subscribed to argyllcms and lcms-user lists for topics around ICC. > > > Thanks, > pq >

2 1

"Competitors" or do we want to stay alive?
by Andrew Randrianasulu 07 Apr '25

07 Apr '25

Sorry for being frustrated lately. Realities of all this "modern development" vs me tend to be not in favor of our project. I looked up two "other" projects in video editing. MLT is well-known and going on for nearly two decades. In this year release notes we see: https://github.com/mltframework/mlt/releases ===== https://github.com/mltframework/mlt/releases/tag/v7.30.0 Added support for mlt_image_yuv420p10, mlt_image_yuv444p10, and mlt_image_yuv422p16 in avfilter, swscale, and rescale filters. This facilitates using these pixel formats end-to-end when using only FFmpeg producers, certain avfilters, and avformat consumer. This means it is possible to do 10-bit end-to-end on the CPU when being careful to select compatible components and options to avoid conversions. One can pass-through HDR; however, you must set the color_trc and pix_fmt properties on the avformat consumer (see ffmpeg -h full for these values). The avformat consumer automatically converts MLT colorspace (integer value) to FFmpeg's colorspace and color_primaries (unless explicit) options. ==== I take this as "floating point pipeline still not here". Olive branch is even more depressing: https://github.com/olive-editor/olive/issues Last non-CI commit was in ... september 2023? May be developing moved somewhere, but this mean all exiting new bugs and state of being incomplete for few more years, given that even with most of hard work done by OpenGL, OCIO, ffmpeg etc remaining NLE core is not that simple, as it turned out to be. Natron does not do audio, as far as I know, and also hanging on a thread (single developer). Blender is a Big Shot now, with predictably big requirements both in software (try to build it on Slackware) and in hardware. Driven by higher end! And whole "Oh lol X is deprecated, everyone rewrite themselves to Wayland" push. I bet there might be way to resistance say Intel's or Nvidia "HDR on X" proposals in Xwayland but who will do all this work for single application? It took Valve's money effectively to get anything at all done in this area. https://www.phoronix.com/news/X11-DeepColor-Visual-RFC from 2017 .... https://lists.freedesktop.org/archives/wayland-devel/2017-December/036403.h… It took whole 8 years to get into "usable in mpv" state, and producing video usually have higher demands than playing back. I am fairly sure someone will write something in Rust (so it will break in 6 months time because Rust is for Big D Developers who have no problems with such churn) or c++ 25 because c+11 is too archaic and all new courses are about $latest (double meaning of $ here). Again, I do not think this is only individual developers fault, just more complex issue with constant stream of *new* hardware we supposed to fix in field by writing software, somehow (HDR displays are all or nothing, so HD(R), SD and GUI all must be mixed on host side). And general "culture" of individualism (because Silicon Valley, bebe!) and effectively social darwinism (where are XDTV and libquicktime? killed by constant API churn ....). I see no escape from this, at larger scale. And this makes me even more frustrated. cc ffmpeg-user/libav user because otherwise no one from "outside" will ever read this.

4 8

"Unbounded" floating point image manipulation
by Andrew Randrianasulu 04 Apr '25

04 Apr '25

I think this forum post (with still working image inserts) illustrates what Andrea trying to do inside CinGG: https://discuss.pixls.us/t/unbounded-floating-point-pipelines/6483/199 On input image a bit blown out, but after few layers of correction (_as long as you editing software does not clip to 1.0_) you get more details, in final image. Very unavoidable fact that _everything_ (camera, monitor, projector, printer, eyes) all non-linear in their transmission/sensing/emitting lightwaves of different frequencies makes all this quite complex topic!

3 5