<div dir="auto"><div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">пт, 28 мар. 2025 г., 12:07 Andrea paz via Cin <<a href="mailto:cin@lists.cinelerra-gg.org">cin@lists.cinelerra-gg.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> If you really want to compare RGBA with YUVA under Blend Algebra, then you<br>
> have either to change COLORSPACE_RGB to COLORSPACE_YUV in the blend<br>
> function, or to remove the 'COLORSPACE' declaration completely, or to change<br>
> the colorspace parameter in the plugin dialog from the default 'by function'<br>
> to the explicit 'RGB' or 'YUV' value. Have you done this?<br>
<br>
No, I didn't. I knew that Blend Algebra uses float and RGB by default,<br>
and it just seemed interesting to me to see the differences this makes<br>
from patchbay (I chose YUV media on purpose, for the test, because<br>
they are the most common). I would actually like to see all parts of<br>
CinGG unified to the internal float engine and RGB color space, but I<br>
know that is impossible, as each tool/plugin goes its own way. </blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">If I understand correctly most  non-ffmpeg plugins should technically work in all modes, due to their history. But clipping probably occur in some of them even in rgba-float mode as you discovered earlier?</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">In some sense rgba/yuv modes are "speed hacks", but 4x difference in cpu/mem usage is not something you can easily dismiss as irrelevant (this is why variants of yuv still around).</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">So I<br>
think it is important to point out each time that with various tools,<br>
various results can be achieved. I guess for programmers this is an<br>
obvious and unnecessary aspect. But not to me. Another impossible<br>
thing I would like to do is to indicate on the manual how each<br>
tool/plugin works, regarding color spaces, color depths, and use of<br>
the internal engine in float, but that is information available only<br>
in very few cases.<br>
In short, I think Blend Algebra is more reliable (consistent) than<br>
patchbay overlays, because of its internal conversions to a single<br>
mode; this is precisely why I would like to try IgorV's tutorial with<br>
Blend Algebra again.<br>
I guess I was just talking nonsense and doing useless tests!  :)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">well, consistency has cpu cost, while I think yuv modes were left in half-working state in cingg because you only have defined equations for rgba compositing? With assumption that users who use yuv mode will not use overlays (say because it either pre edit/assembly or final pass from yuv compressed source).</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">
<br>
PS: @Phyllis; actually “polemica” is an intalian word I used, I don't<br>
know why DeepL translated it into “polemic.”<br>
-- <br>
Cin mailing list<br>
<a href="mailto:Cin@lists.cinelerra-gg.org" target="_blank" rel="noreferrer">Cin@lists.cinelerra-gg.org</a><br>
<a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
</blockquote></div></div></div>