"Competitors" or do we want to stay alive?
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.ht... 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.
Shotcut is also beginning to implement 10-bit and BT.2100, following the evolution of MLT. They are still behind, though. Kdenlive only supports 8-bit and indicates in the roadmap that it will work on HDR only in the “mid term” and OpenColorIO only in the “long term.” Wayland recently brought out the protocol for color management and some software is starting to implement it (mpv). But from what I understand it is mainly targeted for HDR video games and movies and not for graphics in general (for example, the protocol does not provide ICC and monitor profiling!). For now I am staying on X11 (I have an old monitor but wide gamut!). If Wayland continues to develop XWayland, we will have no problems with CinGG (I hope!).
On Fri, 4 Apr 2025, Andrea paz via Cin wrote:
Wayland recently brought out the protocol for color management and some software is starting to implement it (mpv). But from what I understand it is mainly targeted for HDR video games and movies and not for graphics in general (for example, the protocol does not provide ICC and monitor profiling!). For now I am staying on X11 (I
Perhaps I don't understand something. I thought in X11 there was long ago CMS color management, ICC profiles, etc. via either colord or via ArgyllCMS. I used ArgyllCMS to calibrate monitor, then it can load the corresponding LUT (or gamma) in X11, or a raw photo processing program can use these ICC profiles. Has Wayland developed something totally different? _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
пт, 4 апр. 2025 г., 19:41 Georgy Salnikov via Cin < [email protected]>:
On Fri, 4 Apr 2025, Andrea paz via Cin wrote:
Wayland recently brought out the protocol for color management and some software is starting to implement it (mpv). But from what I understand it is mainly targeted for HDR video games and movies and not for graphics in general (for example, the protocol does not provide ICC and monitor profiling!). For now I am staying on X11 (I
Perhaps I don't understand something.
I thought in X11 there was long ago CMS color management, ICC profiles, etc. via either colord or via ArgyllCMS. I used ArgyllCMS to calibrate monitor, then it can load the corresponding LUT (or gamma) in X11, or a raw photo processing program can use these ICC profiles.
Has Wayland developed something totally different?
different enough .... https://invent.kde.org/plasma/kwin/-/issues/11 In great developer tradition of offloading work "Wayland is just collection of protocols", everything else is someone's else problem. Now protocol part is in (finally) so kwin/mutter probably will regrow some hairs around this area. No idea about calibration step .... _______________________________________________________________________________
Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected]
_______________________________________________________________________________
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
@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. 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. 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. 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. 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-incubati... 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?
пт, 4 апр. 2025 г., 21:35 Andrea paz <[email protected]>:
@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. 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. 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. 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.
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-incubati...
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?
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.
On Fri, 4 Apr 2025, Andrea paz via Cin wrote:
A theoretical question: can CinGG be adapted to work in Wayland or is it impossible? Has XWayland limitation?
OK, perhaps I've understood. Your question is not about just color correction according to an ICC profile, it is about direct rendering of HDR where the complete tone mapping is to be done by the graphics driver (not by NLE) which must support both CMS and HDR. This is quite different thing, I know nothing about this perspective. As long as I understand, the current photo (not video) processing software for Linux works so. It takes camera profile from somewhere. ArgyllCMS calibrates the monitor and creates the monitor profile. The photo processing program converts RAW photos from the camera, taking into account the camera profile, to some kind of HDR (internal format) in memory. The photo processing program does all the effects through the photo developing pipeline. At the end, the program most probably, if there is no goal to save in EXR format or 16-bit TIFF, converts it to sRGB. Then, either the program itself applies the monitor profile to display the corrected image, or the program simply displays, while the correction is performed by colord. And there is a third possibility: the program applies the monitor profile, then colord applies it for the second time, and the resulting colors come wrong. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
Yes, thanks for a good summary. I think Cinelerra has its place and still serves as a learning tool also.. If the Olive NLE Matt had corroborated with CinGG, he would have been welcome and could have made major changes to update it instead of trying to write from scratch. On Fri, Apr 4, 2025 at 4:06 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
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.ht...
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. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
пт, 4 апр. 2025 г., 18:32 Phyllis Smith <[email protected]>:
Yes, thanks for a good summary. I think Cinelerra has its place and still serves as a learning tool also.. If the Olive NLE Matt had corroborated with CinGG, he would have been welcome and could have made major changes to update it instead of trying to write from scratch.
https://github.com/olive-editor/olive/issues/2383 lets see ......
On Fri, Apr 4, 2025 at 4:06 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
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.ht...
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. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (4)
-
Andrea paz -
Andrew Randrianasulu -
Georgy Salnikov -
Phyllis Smith