Sorry to belabor my requests, but color is a topic that has always
interested me, from the days of Photoshop 3.0 and then Gimp...
The following link is interesting:
https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html
However, it is more suitable for image manipulation than for video
editing, where there are complications. So it is not appropriate in
our discussion.
However, when I was asking about the operation of the Color Space
plugin/Tool, it was to know if CinGG uses the “std formulas” used in
video productions. I will elaborate, but first I would like to pay
attention to the color models (RGB, YUV, and HSV) which are infinite
(although in fact artificially limited to the possibilities of human
vision) and the color spaces which are a fraction of that. The limits
of color spaces arise from the need not to exceed the hardware limits
of the devices (gamut). These limits have become std and consequently
so have the formulas for conversion between color spaces. Not that
there are not infinite other formulas, but often, for example for
YCbCr --> sRGB, the same formula is mainly used (see Poynton:
https://wangwei1237.github.io/shares/Digital_Video_and_HD_Algorithms_and_Interfaces_2nd_ed.pdf).
Here, I was wondering if CinGG uses these std formulas that are also
the basis of the LUTs used in CMSs, or does it have its own. If it
used the same formulas, I would dream of one day getting to color
management inside CinGG.
I think original Cinelerra get floating point modes for exactly avoiding clipping ussues in pipeline, among other things. No CMS, but everything was in linear gamma (so no gamma compression as in sRGB, it really breaks compositing, from my understanding of thread I linked) Then when overlay modes were added in cingg assumption that you must clip to defined 0-1.0 range sneaked in. We removed some of it lately, but run into problem when such limiting might be unavoidable due to ways algorithms work.
So, simplest manual "CMS" probably will be just lcms2 plugin working in 32fp and picking up display icc profile, and may be file input icc profile (so you apply it manually at input first and at very end of compositing second).
But so far no one wrote such plugin!
And of course ffmpeg was feeding us at best 16bit integers, so already pre-clipped to some range (if decoding in principle capable of producing fp values .. like MLV format? ), but may be it will be adjustable in future ffmpeg versions?
Unfortunately, I am not very convincing/knowledgeable person, so my attempts to bring this to ffmpeg devs attention failed.
Some parts of puzzle now should be there in ffmpeg-git, but I haven't tried to rebuild cin on top of that, yet.
Fighting with official pre-made Arch qcow hdd image, so far I chrooted into it from livedvd under qemu (there is problem with APIC for some reason? noapic to kernel command line fixed that), run into keys problem, run "pacman-key --populate archlinux " after pacman-key --init, updated with pacman -Syu, installed bunch of packages with pacman -S packagename, verified I have cmake 4.0.0 ... and learned there is no startx yet! Right now I work via VNC to qemu machine running Arch in framebuffer console mode, probably will retry from real X session on host because default screens resolution a bit too big for portraint-oriented tablet screen!
So ... Some steps done, more to do!