<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 4 авг. 2022 г., 09:28 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">Thank you for the explanations.<br>
I am trying to write a color section for the CGG manual.<br>
I have a doubt: a long time ago GG said that on the<br>
timeline/compositor we always see an sRGB output:<br>
<br>
"CinGG, works internally at 32 bits in RGB, but the output in timeline<br>
is sRGB, and performs a first conversion from YUV of the original file<br>
to RGB with the scaler (matrix function, not primaries or transfer<br>
characteristic function), using its internal settings."<br>
<br>
Does this mean that it is useless to have wide-gamut monitors? And<br>
that it is useless to have ICCs or LUTs unless they are limited to<br>
sRGB only? </blockquote></div></div><div dir="auto"><br></div><div dir="auto">I think some ffmpeg plugins work internally in rgba-float, so correction happens with high precision, just display truncate/dither image. So yes, not truely 'what you see is what you get' {as far as I understand all image processing happens in linear space ? Because converting back and forth at each effect sounds wasteful on cpu ...}</div><div dir="auto"><br></div><div dir="auto">I wonder if mpv can read those yuv4mpeg raw streams with color transfer info? May be you can render to pipe and add mpv as gl accelerated and color-corrected external player?</div><div dir="auto"><br></div><div dir="auto">But I think fixing display stage will be as 'simple'  as using specialised color-corrected rgba-float-> 10bit rgb (or may be dithered/tonemapped 8bit rgb) function, as long as display driver support 30 bit color. I commented in  few bugs in the past:</div><div dir="auto"><br></div><div dir="auto"><a href="https://www.cinelerra-gg.org/bugtracker/view.php?id=297">https://www.cinelerra-gg.org/bugtracker/view.php?id=297</a></div><div dir="auto"><a href="https://www.cinelerra-gg.org/bugtracker/view.php?id=294">https://www.cinelerra-gg.org/bugtracker/view.php?id=294</a></div><div dir="auto"><a href="https://www.cinelerra-gg.org/bugtracker/view.php?id=238">https://www.cinelerra-gg.org/bugtracker/view.php?id=238</a></div><div dir="auto"><br></div><div dir="auto"><br></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">If so, it would be extremely limiting for color correction<br>
in CGG.<br>
My other doubt: what is the purpose of the "YUV color space" in<br>
Preferences, just for encoding?</blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I think it also used indirectly via FFVideoConvert::convert_vframe_picture in convert_cmodel function, in turn used by FFVideoStream::load</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">all those in cinelerra/ffmpeg.C</div><div dir="auto"><br></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"> Any use of YUV type color spaces<br>
should be discouraged since the signal on the screen is always sRGB.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Well, there is Xv (yuv) output, and encoded video tend to be variation of subsampled yuv (because it takes less space this way)</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>