On Wed, May 6, 2026 at 2:29 PM Andrea paz <gamberucci.andrea@gmail.com> wrote:
I ran a few rendering tests using a patched version of CinGG and AppImage (unpatched). I used two presets: h265-med.mp4 e H265-12bit.mp4. The presets used do not show any issues with the patched CinGG. There is a significant drop in fps; for the h265-med.mp4 preset, it drops from 105 fps to 16 fps. For the h265-12bit.mp4 preset, it drops from 71 fps to 14 fps.
Yeah, software color correction is slow .... The rendered video displays the correct colors that the patches already showed in the Compositor. These presets (and the rendering file) include the “colorspace,” “trc,” and “primaries” parameters. However, I believe they only affect the metadata. Is there a way to tell if the color space of the final file has actually changed, beyond the metadata reported by ffprobe, MediaInfo, etc.? Those patches do not add icc profile into final rendered file, but may be you can "inject" it with MP4Box from gpac ? exiftool nowadays also can work with some video files
So far, I’ve only run tests in X11; I’ll try Wayland as well. One thing to understand is how patches affect the temporary directory and, consequently, how they affect rendering (if they do).
If by temporary directory you mean background render - it remains uncorrected. You can try few other profiles (qt/mov with various codecs, mpeg2/4 via ffmpeg ...) but my understanding it should render input images/video corrected according to their embedded profile and one you selected via CIN_CM_PROFILE. I guess it will slow down even more as you add more tracks for something like split-screen? At playback (not pause) it will remain speedy, but moving picture will remain not color corrected (I think it already a bit different in motion as opposed to paused state, already for speed reason). Basically I envision usage of this feature mostly for slideshows from pre color-corrected images, and may be rendering those rare video files with embedded profile (mostly from macos ?). Usual "video" colorimetry remain the same. I yet to find way to "flatten" dynamic range of HDR vid without sacrificing wide color gamut. From historical perspective (color correction appear in Photoshop 5.0 in 1998) I think at least some icc profiles definitely were useful even on 8bit per channel displays, bu yes, fully seeing all those wide colors probably required 30 bpp / 10 bpc mode from graphical system, and we do not do this. I am not sure how lcms2 converts images with profiles internally - via high-precision buffer? For now I set both input and output buffers to rgba8 (so i guess it should match what GIMP 2.10 does by default, and also geequie image viewer). I played around with rgba-float modes but never saw them directly engaged on pause - so may be for 8bit input it was going via staged buffer , so my examination of ->format filed of vframe structure did not catch this ...) may be ffmpeg's OCIO filter will give us better video results if we ever learn how to use it ?
NOTE: mpv no longer works for me in X11 (with gpu-next) but it works in Wayland. I’m afraid that X11 apps will face more and more issues in the future.
Hopefully it just temporary (gpu-next indeed needed for using embedded color profile at playback - cingg does not do this because 1) mode I hacked first not used for x11/x11 direct/ogl playback 2) as your rendered test (at FHD resolution?) showed slowdown will be massive ...)