possible patch for x265 on cmake 4.0?
https://bitbucket.org/multicoreware/x265_git/commits/b354c009a60bcd6d7fc0401... not sure libsvtav1 yet ....
Without svtav1 and x265 the error looks different to me, but it is still there.... The upgrade to cmake 4 occurred on March 29. I use bash.
ср, 2 апр. 2025 г., 22:30 Andrea paz <[email protected]>:
Without svtav1 and x265 the error looks different to me, but it is still there....
The upgrade to cmake 4 occurred on March 29.
I use bash.
there was movement in Debian at least to use lightweight shell as /bin/sh, independent from user's shells .... but I guess this was not The error point ... Log still says it tries to build x265 ... you can try to manually fix CmakeLists.txt inside thirdparty/x265_4.0 folder and see if make in thirdparty will go further? soooooorry.
Ahemm! Sorry but I can't find any folders inside thirdparty, only src folder. Neither before nor after doing configure. Where do I go wrong?
ср, 2 апр. 2025 г., 22:52 Andrea paz <[email protected]>:
Ahemm! Sorry but I can't find any folders inside thirdparty, only src folder. Neither before nor after doing configure.
Where do I go wrong?
they appear when make call commands to unpack/patch/compile ... so just do make, wait until it fail, try to manually patch x265's CmakeLists.txt ... But I guess if you are not in a hurry we can try to fix this tomorrow?
Kind of a bad temporary solution presented here: https://github.com/pytorch/pytorch/issues/150167 i.e. "Stick to CMake 3.31" On Wed, Apr 2, 2025 at 1:26 PM Andrew Randrianasulu <[email protected]> wrote:
https://bitbucket.org/multicoreware/x265_git/commits/b354c009a60bcd6d7fc0401...
not sure libsvtav1 yet ....
чт, 3 апр. 2025 г., 05:15 Phyllis Smith <[email protected]>:
Kind of a bad temporary solution presented here: https://github.com/pytorch/pytorch/issues/150167 i.e. "Stick to CMake 3.31"
I do not know if you can have two CMake versions in Arch .. Time to install Arch, I guess ;) But not at 5am ... Sorry for not catching this earlier - Termux wisely stay at 3.31 :)
On Wed, Apr 2, 2025 at 1:26 PM Andrew Randrianasulu < [email protected]> wrote:
https://bitbucket.org/multicoreware/x265_git/commits/b354c009a60bcd6d7fc0401...
not sure libsvtav1 yet ....
Is there a pacman command to downgrade or an automatic script on AUR. I put in cmake 3.31.6 and now I should mask cmake 4 so that it will not be re-updated at next upgrade. But I do the CinGG build and then go back to cmake 4 with tomorrow's daily upgrade, hoping they will fix the problem soon. Compilation went well (with svtav1 and x265); Andrew's patch to remove clipping to Blur and Title works and, so far, I haven't seen any problems. Is it possible to remove clipping from Color Space as well? Histogram Bezier and 3 Color Way we had already tried it without success. PS: @Andrew. Did you stay up until 5 a.m. to follow my attempts? I beg your pardon!
чт, 3 апр. 2025 г., 10:27 Andrea paz <[email protected]>:
Is there a pacman command to downgrade or an automatic script on AUR. I put in cmake 3.31.6 and now I should mask cmake 4 so that it will not be re-updated at next upgrade. But I do the CinGG build and then go back to cmake 4 with tomorrow's daily upgrade, hoping they will fix the problem soon.
if problem not reported then may be no one is aware about it YET. Not all Arch users build cmake-depend packages .....
Compilation went well (with svtav1 and x265); Andrew's patch to remove clipping to Blur and Title works and, so far, I haven't seen any problems. Is it possible to remove clipping from Color Space as well?
I'll look into it .... Histogram Bezier and 3 Color Way we had already tried it without
success.
PS: @Andrew. Did you stay up until 5 a.m. to follow my attempts? I beg your pardon!
No, I just walk with Fennec at around that time, then sleep some more.
On Thu, 3 Apr 2025, Andrew Randrianasulu via Cin wrote:
clipping to Blur and Title works and, so far, I haven't seen any problems. Is it possible to remove clipping from Color Space as well?
I'll look into it ....
Hmmm... I thought, HDR is conceptually not colorspace dependent, per definition, colorspace appears only when tonemapping is being performed into that colorspace? _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
In theory yes, since HDR are simply float values over 1.0. However, it is also true that a Color Space has been made for HDR, the BT 2100. I don't quite understand the point: maybe it's just the technology side of building HDR monitors and TVs?
On Thu, 3 Apr 2025, Andrea paz wrote:
In theory yes, since HDR are simply float values over 1.0. However, it is also true that a Color Space has been made for HDR, the BT 2100. I
And which colorspaces the Color Space plugin operates on? Does it support the BT 2100 by design? _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
Only 601, 709 and 2020. Il gio 3 apr 2025, 11:18 Georgy Salnikov <[email protected]> ha scritto:
On Thu, 3 Apr 2025, Andrea paz wrote:
In theory yes, since HDR are simply float values over 1.0. However, it is also true that a Color Space has been made for HDR, the BT 2100. I
And which colorspaces the Color Space plugin operates on? Does it support the BT 2100 by design?
_______________________________________________________________________________
Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected]
_______________________________________________________________________________
On Thu, 3 Apr 2025, Andrea paz wrote:
And which colorspaces the Color Space plugin operates on? Does it support the BT 2100 by design?
Only 601, 709 and 2020.
So, what we have: HDR potentially could be processed in BT 2100, but the plugin does not support this color space. The other color spaces which are known in the plugin, are restricted to 0..255 by definition (some even narrower restricted), and are undefined outside this clip range. How can we wish these colorspaces be unclipped, in the range where they have indefinite values? Perhaps we have first redefine them for the new range, then publish our brand new standard so that it could be potentially recognized by other tools?:) _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
Unfortunately you are asking precise things that I am not able to answer. Looking at the plugin code (I understand it much less than Andrew, practically 0) I saw a part where it uses 8- and 16-bit integers and uses floats for RGBA-FLOAT. It just seems strange to me that the Color Space plugin, which as you say should not be about clipping, shows clipping with the two Blender Program test you wrote. However, the only difference is putting a sentence, in the manual, in the description of the plugin; it is certainly not something to waste time on.
On Thu, 3 Apr 2025, Andrea paz wrote:
Unfortunately you are asking precise things that I am not able to answer. Looking at the plugin code (I understand it much less than Andrew, practically 0) I saw a part where it uses 8- and 16-bit integers and uses floats for RGBA-FLOAT. It just seems strange to me that the Color Space plugin, which as you say should not be about clipping, shows clipping with the two Blender Program test you wrote. However, the only difference is putting a sentence, in the manual, in the description of the plugin; it is certainly not something to waste time on.
I mean, the coordinate system of some colorspace, and the equations to transform one coordinate system to another, may be defined not between -infinity and +infinity, but inside some range. Like, for example, the mathematical arcsine function (real, without an imaginary part) is defined between -1.0 and +1.0 and not defined for, let's say, 1.25. Likewise, the Hue coord of the HSV space is defined between 0.0 and 360.0, and saturation between 0.0 and 1.0 (what btw should a saturation = 2.0 mean after all?). I mean, we should firstly look at the equations defining the source and target color spaces, namely, in what range are their definitions. If, let's say, one space is defined 0..255, the other 16..223, then it can be questionable, what equations may we implement outside the range where we have standartized equations? I mean, the question why does the color space plugin clip values, can actually appear totally meaningless, i.e. the equations with removed clipping may cease working outside the defined range anyway. So removing clipping call can be insufficient, one has additionally to extend the transformation equations to the extended range. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
OK, I understand your explanation. Just one point: does it only apply to plugins that refer to color spaces (which by definition are limited (0, 1))? Or does it apply to all, e.g., Histogram and the like? Another question: generally conversions between color spaces are referred to CMS, i.e. via ICC color profiles; OpenColorIO; ACES, etc. Since CinGG does not have CMS how does the Color Space plugin work? And how does the “YUV Color Space” tool in “Preferencies” work?
чт, 3 апр. 2025 г., 18:46 Andrea paz <[email protected]>:
OK, I understand your explanation. Just one point: does it only apply to plugins that refer to color spaces (which by definition are limited (0, 1))? Or does it apply to all, e.g., Histogram and the like? Another question: generally conversions between color spaces are referred to CMS, i.e. via ICC color profiles; OpenColorIO; ACES, etc. Since CinGG does not have CMS how does the Color Space plugin work? And how does the “YUV Color Space” tool in “Preferencies” work?
Video typically stored in YUV colorspace, so for anything internally working in RGB and back to yuv for most video codecs SOME colorspace transform is applied, even if there no ICC/OCIO in pipeline, from my understanding.
On Thu, 3 Apr 2025, Andrea paz wrote:
OK, I understand your explanation. Just one point: does it only apply to plugins that refer to color spaces (which by definition are limited (0, 1))? Or does it apply to all, e.g., Histogram and the like? Another question: generally conversions between color spaces are referred to CMS, i.e. via ICC color profiles; OpenColorIO; ACES, etc. Since CinGG does not have CMS how does the Color Space plugin work? And how does the \u201cYUV Color Space\u201d tool in \u201cPreferencies\u201d work?
An immanent property of a pixel is its color. All pixels have some color. If there is some video in a clip (not only audio), it consists of video frames, and each frame consists of pixels, and each pixel has some color. Color is expressed as at least 3 values (usually 3 but it may be more) in some coordinate system. This color coordinate system composes a color space. Some color space always exists. If some plugin alters only geometry (changes X and Y coords of pixels but does not change colors), it still works in some color space, but in this case the particular color space does not matter as pixel colors remain constant. If some other plugin changes colors or in some way accounts for colors, it almost always must bear in mind the color coordinate system, the color space pixels are in. Not just color perception CMS and ICC profiles are for, but more fundamental. Not all color spaces are limited to 0..1. For example, in YUV only Y is 0..1, U and V are -0.5 .. +0.5, while in HSV H is 0..360. Should you calculate an Hue histogram in HSV color space (why not?), you must take into account the particular range of Hue. Despite Hue has no ICC profile. An MP4 video color space is some kind of YUV. If you wish to apply, let's say, Chromakey, the latter works in HSV space. Therefore, you have to convert pixels from YUV to HSV making use of some mathematical equations for coordinate transformations. The Color Space conversion plugin also uses some equations to do the job. If you wish to extend it to a broader range to perform similar transformations for HDR, you have to write the corresponding mathematical equations. But as soon as you have the equations, you can easily express them in form of one more blend program function, and you will have your HDR transformation working. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
чт, 3 апр. 2025 г., 10:35 Andrew Randrianasulu <[email protected]>:
чт, 3 апр. 2025 г., 10:27 Andrea paz <[email protected]>:
Is there a pacman command to downgrade or an automatic script on AUR. I put in cmake 3.31.6 and now I should mask cmake 4 so that it will not be re-updated at next upgrade. But I do the CinGG build and then go back to cmake 4 with tomorrow's daily upgrade, hoping they will fix the problem soon.
if problem not reported then may be no one is aware about it YET. Not all Arch users build cmake-depend packages .....
Compilation went well (with svtav1 and x265); Andrew's patch to remove clipping to Blur and Title works and, so far, I haven't seen any problems. Is it possible to remove clipping from Color Space as well?
I'll look into it ....
sorry, math in colorspace plugin is not my friend .. there was long thread about difference or sameness between negative and positive > 1.0f floating point values in image editing due to some , ah editing or other operations. https://discuss.pixls.us/t/unbounded-floating-point-pipelines/6483/58?page=2 I am currently at this reply: ==== Currently GIMP/RawTherapee/PhotoFlow/darktable/etc work at floating point precision. All of these softwares have a plethora of editing algorithms and blend modes that are *totally* unsuitable for being performed on channel values that are outside the display range, and many of which totally destroy the scene-referred nature of the RGB data, assuming it was even scene-referred to begin with, which isn’t always the case. Nonetheless, even in high bit depth GIMP/RawTherapee/PhotoFlow/darktable/etc many times it is *useful* to retain out-of-display-range colors instead of summarily clipping them, even when and though the goal is eventually reducing the final image to fit within the display range of one or another chosen output device. ===== sounds like what we try to do, but my lack of understanding of even basics (can histogram go to infinity in positive direction? will it take infinite time?) definitely not helping .....
Histogram Bezier and 3 Color Way we had already tried it without
success.
PS: @Andrew. Did you stay up until 5 a.m. to follow my attempts? I beg your pardon!
No, I just walk with Fennec at around that time, then sleep some more.
Just FYI: based on the URL reference from Andrew, using the attached patch for CinGG on Fedora 32 which has cmake 3.17.4 works (only did a single build and test). On Wed, Apr 2, 2025 at 1:26 PM Andrew Randrianasulu <[email protected]> wrote:
https://bitbucket.org/multicoreware/x265_git/commits/b354c009a60bcd6d7fc0401...
not sure libsvtav1 yet ....
participants (4)
-
Andrea paz -
Andrew Randrianasulu -
Georgy Salnikov -
Phyllis Smith