<div dir="auto"><div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">чт, 3 апр. 2025 г., 21:39 Andrea paz <<a href="mailto:gamberucci.andrea@gmail.com">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" 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" target="_blank">https://wangwei1237.github.io/shares/Digital_Video_and_HD_Algorithms_and_Interfaces_2nd_ed.pdf</a>).<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">yeah.</div><div dir="auto"><br></div><div dir="auto">At page 298 (in file)</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Figure 26.6 shows a set of primary SPDs conformant to SMPTE 240M, similar to BT.709. Many different SPDs can produce an exact match to these chromaticities; the set shown is from a Sony Trinitron display. Figure 26.5 shows the corresponding colour-matching functions. As expected, the CMFs have negative lobes and are therefore not directly realizable; nonetheless, these are the idealized CMFs, or idealized taking characterstics – of the BT.709 primaries. We conclude that we can use physically realizable analysis CMFs, as in the first example, where XYZ components are displayed directly. But this requires nonphysical display primary SPDs. Or we can use physical display primary SPDs, but this requires nonphysical analysis CMFs. As a consequence of the way colour vision works, there is no set of nonnegative display primary SPDs that corresponds to an all-positive set of analysis functions. The escape from this conundrum is to impose a 3×3 matrix multiplication in the processing of the camera signals, instead of using the camera signals to directly drive the display. Consider these display primaries: monochromatic red at 600 nm, monochromatic green at 550 nm, and monochromatic blue at 470 nm. The 3×3 matrix of Equation 26.2 can be used to process XYZ values into components suitable to drive that display. Such signal processing is not just desirable; it is a necessity for achieving accurate colour reproduction! </div><div dir="auto"><br></div><div dir="auto">======</div><div dir="auto"><br></div><div dir="auto">Thing us, all this matrix algebra is floating point YET most of video codecs and signalling to displays (DVI, HDMI ..) operate on integer math in some range!</div><div dir="auto"><br></div><div dir="auto">Until roughly R300/GF5xxx era (~2003?) GPUs had internal floating point pipeline BUT accessible via integer textures and renderbuffers! So, Cinelerra was coded in OpenGL part around this era standarts.</div><div dir="auto"><br></div><div dir="auto">We can make openGL go via fp textures/renderbuffers now, but for example libavcodec will still give you "pre-processed" integer values, both for software and especially gardware decoders.</div><div dir="auto"><br></div><div dir="auto">So, unless one deals with sequence of tiff/exrs there always will be at least one step between what libavcodec outputs (bunch of integers) and what cinelerra-gg can accept (32fp at best). Probably not big deal for already-compressed h265, but those video canera raw formats have their own import module in "Big" NLEs like DVR, as far as I understand, with various manual/interactive controls. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">There was BRAW decoder for ffmpeg by Paul Mahol, but it was left in patchwork place may be partially because for using it you must manually debayer etc, and this process ought to be highly visual, interactive - while ffmpeg at its core batch processing tool, or part feeding display engine. A bit too low level, perhaps?</div><div dir="auto"><br></div><div dir="auto">As various floating point transforms find increasing use in applications where ffmpeg desirable/unavoidable (anyone want to code h264 decoder from scratch?) ffmpeg will be forced to evolve from fast but unaccurate ~2003 hack, usable only for subset of operations most common on  consumer/display end into more accurate and versatile set of functions</div><div dir="auto"><br></div><div dir="auto">But because its developers assume all other developers will just quietly adapt or due ...I only can hope next update will be manageable by me.</div><div dir="auto"><br></div><div dir="auto">Back to topic of OCIO vs ICC based color management - I think mid thread conclusion there was you can get both, as long as you do not ruin your numbers in unexpected ways. Hopefully cinelerra-gg will not ruin them accidently now, when Georgy implemented custom, user-settable  overlay equations and more.</div><div dir="auto"><br></div><div dir="auto">But someone will need to push our existence into mesa, ffmpeg developers's happy little worlds so some mutual understanding will have chance to develop (because all those company individual devs too busy in their narrow burrowing to spend time looking around, away from spotlights).</div><div dir="auto"><br></div><div dir="auto">Unfortunately, I do not have means to  get to Eu and wave "Stop ignoring us!" banner. And email based communication easily (too easily) dismissed, unless you are Big Netflix (or Valve) with money to throw at.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>