<div dir="ltr"><div>yes this looks like it could be good.  However, I am just one coder.</div><div>This could take quite some time.  It is true that a lot of the calculations</div><div>in the xfer setup are not the most optimal (BC_CModel et al) but these</div><div>are more to ensure consistency, not speed.  The bulk of the time is spent</div><div>shoveling data from here to there.  Surprisingly, one big problem is to</div><div>decide how big the slices should be, relative to the task setup for the</div><div>slicer.  For a small frame, this overhead is a considerable fraction of time.</div><div><br></div><div>Pixel format colorspace mapping is done using YUV::yuv.</div><div> YUV::yuv.rgb_to_yuv_8(r, g, b, y, u, v);</div><div>YUV::yuv.yuv_to_rgb_8(r, g, b, y, u, v);</div><div>which is applied in the transfer functions generated by bccmdl.py</div><div><br></div><div>Insead of using a constant lookup table (lut) that could be changed</div><div>easily to a pointer, as in yuv->rgb_to_yuv_8</div><div>since the lut init already accepts (Kb,Kr) , and can be created and <br></div><div>cached pretty easily.  The xfer function could use a lut</div><div>that depends on the demand.  On some examination, I found that</div><div>the number of operational parameters needed makes the colorspace</div><div>conversion messy: in_cs, out_cs, in_range, out_range, at least... I</div><div>was up to 6 params when I decided it was too messy to start that day.<br></div><div>This is manageable, but I am pretty backed up on projects and problems.</div><br><div>The ffmpeg transfer function is great.  It has a lot of parameter flexibility</div><div>and frequently will use asm for the most likely transfers.  Even so, It is</div><div>complex, and can be slower than cin.  The colormodel<->AVPixelFormat</div><div>mapping is good, but not great.  When frame data is transmitted between</div><div>the two, direct moves are used if the mapping is good, and the data is</div><div>moved twice when an intermediate compatible format is needed .<br></div><div><br></div><div>A pretty good idea (which CV/Einar uses, so there is a chunk of code</div><div>that is already moving this way) might be to abandon the BC_CModels</div><div>and use AVPixelFormat.  Then all transfers could be done with</div><div>ffmpeg swscale.  This puts all of the eggs in the ffmpeg basket, for</div><div>better or worse.  The interface would probably speed up, but all of the</div><div>plugins and other stuff would need a lot of work.</div><div><br></div><div>There is a  class called LoadBalence (bad name) that creates load</div><div>client threads that apply a function to a parameter set (usually a slice).</div><div>Row data is usually best when it is memory cache align, and</div><div>sequentially/locally processed in non-overlapping chunks.  It is hard</div><div>to imagine that using a more complex schedule would improve</div><div>throughput.  I have not benchmarked the xfer recently, but that may</div><div>be a good idea to see if thirdparty functions offer help.<br></div><div><br></div><div>Permuting/Remapping color components  is a really</div><div>weird idea in the first place, since everything seems to agree on</div><div>what RGB is, and nobody seems to agree on what YUV is.</div><div>The attached picture shows an RGB cube (smaller black cube</div><div>inside the others) and the enclosing YUV cubes for BT601,</div><div>BT709, and BT2020.   The black line in the middle is the white line</div><div>which goes from YUV(0.0,0.5,0.5) black to YUV(1.0,0.5,0.5) white.</div><div>As you can see, a bunch of the numerical space is outside of the</div><div>RGB cube.  In fact, since the diagonal of RGB(grey scale) is an</div><div>axis, it makes the YUV cube approx 2.8 times as large, and so</div><div>the coverage is really very poor.  Almost 2/3 of the YUV colors</div><div>are not legal RGB values.</div><div><br></div><div>To much data...</div><div>morrroww</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 18, 2020 at 11:18 PM Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com">randrianasulu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, all!<br>
<br>
I was looking again at <br>
<a href="https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra-5.1/guicast/bcxfer.C;h=8eb6533baa68b7cc8b3fe1d763f03d65a3d28b4e;hb=HEAD" rel="noreferrer" target="_blank">https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra-5.1/guicast/bcxfer.C;h=8eb6533baa68b7cc8b3fe1d763f03d65a3d28b4e;hb=HEAD</a><br>
<br>
and I think it works (via generated  functions from guicast/xfer) by doing  pixel-at-a-time, with slices done at different CPUs.<br>
<br>
Is there possibility to optionally add few stagin buffesr, so something like <a href="http://gegl.org/babl/index.html#Usage" rel="noreferrer" target="_blank">http://gegl.org/babl/index.html#Usage</a> will have chance to work?<br>
<br>
"The processing operation that babl performs is copying including conversions if needed <br>
between linear buffers containing the same count of pixels, with different pixel formats."<br>
<br>
So, address calculations usually send down to Cin's own (slow?) functions will be reused to calculate size of buffer <br>
(per slice, as done by slicer function), and then babl or ffmpeg or something will transfer pixels to this new buffer, and then ..<br>
I dunno, signal 'done' to upper calling function and switch pointers to this new buffer? So, tricking Cin<br>
into thinking conversion (per sliced area) was done by its of functions, yet using different set of them <br>
(not those row-based macro expanded functions I see in build tree)?  As long as pixels organized the same (row x column), <br>
and internally represented by same datatypes (like, first 4 bytes is R in float, second is G, third is B, and last 4 bytes is alpha ...<br>
for total of 16 bytes per pixel) this should work? Or I missed something? <br>
-- <br>
Cin mailing list<br>
<a href="mailto:Cin@lists.cinelerra-gg.org" target="_blank">Cin@lists.cinelerra-gg.org</a><br>
<a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
</blockquote></div>