[Cin] Stupid question about pixel conversions in CinGG (xfer functions)
randrianasulu at gmail.com
Wed Feb 19 07:09:58 CET 2020
I was looking again at
and I think it works (via generated functions from guicast/xfer) by doing pixel-at-a-time, with slices done at different CPUs.
Is there possibility to optionally add few stagin buffesr, so something like http://gegl.org/babl/index.html#Usage will have chance to work?
"The processing operation that babl performs is copying including conversions if needed
between linear buffers containing the same count of pixels, with different pixel formats."
So, address calculations usually send down to Cin's own (slow?) functions will be reused to calculate size of buffer
(per slice, as done by slicer function), and then babl or ffmpeg or something will transfer pixels to this new buffer, and then ..
I dunno, signal 'done' to upper calling function and switch pointers to this new buffer? So, tricking Cin
into thinking conversion (per sliced area) was done by its of functions, yet using different set of them
(not those row-based macro expanded functions I see in build tree)? As long as pixels organized the same (row x column),
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 ...
for total of 16 bytes per pixel) this should work? Or I missed something?
More information about the Cin