<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 3 апр. 2025 г., 21:39 Andrea paz <<a href="mailto:gamberucci.andrea@gmail.com" rel="noreferrer noreferrer" target="_blank">gamberucci.andrea@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry to belabor my requests, but color is a topic that has always<br>
interested me, from the days of Photoshop 3.0 and then Gimp...<br>
The following link is interesting:<br>
<a href="https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html</a><br>
However, it is more suitable for image manipulation than for video<br>
editing, where there are complications. So it is not appropriate in<br>
our discussion.<br>
<br>
However, when I was asking about the operation of the Color Space<br>
plugin/Tool, it was to know if CinGG uses the “std formulas” used in<br>
video productions. I will elaborate, but first I would like to pay<br>
attention to the color models (RGB, YUV, and HSV) which are infinite<br>
(although in fact artificially limited to the possibilities of human<br>
vision) and the color spaces which are a fraction of that. The limits<br>
of color spaces arise from the need not to exceed the hardware limits<br>
of the devices (gamut). These limits have become std and consequently<br>
so have the formulas for conversion between color spaces. Not that<br>
there are not infinite other formulas, but often, for example for<br>
YCbCr --> sRGB, the same formula is mainly used (see Poynton:<br>
<a href="https://wangwei1237.github.io/shares/Digital_Video_and_HD_Algorithms_and_Interfaces_2nd_ed.pdf" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://wangwei1237.github.io/shares/Digital_Video_and_HD_Algorithms_and_Interfaces_2nd_ed.pdf</a>).<br>
Here, I was wondering if CinGG uses these std formulas that are also<br>
the basis of the LUTs used in CMSs, or does it have its own. If it<br>
used the same formulas, I would dream of one day getting to color<br>
management inside CinGG.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">But so far no one wrote such plugin!</div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">Unfortunately, I am not very convincing/knowledgeable person, so my attempts to bring this to ffmpeg devs attention  failed.</div><div dir="auto"><br></div><div dir="auto">Some parts of puzzle now should be there in ffmpeg-git, but I haven't tried to rebuild cin  on top of that, yet.</div><div dir="auto"><br></div><div dir="auto">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!</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">So ... Some steps done, more to do!</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>