Verify YUV conversion factors correctness

[morousg]

We tried to implement in include/fused_kernel/algorithms/image_processing/color_conversion.cuh color conversions from YUV (YCbCr) to RGB, taking into account the following parameters:

1. enum ColorSpace { YUV420, YUV422, YUV444 }; // Maybe is more correct to say Chroma Subsampling?
2. enum ColorRange { Limited, Full }; // Also known as tv and pc. I found somewhere the concept of "studio". Do pixels in the format from 0.f to 1.f have a name?
3. enum ColorPrimitives { bt601, bt709, bt2020 };
4. enum ColorDepth { p8bit, p10bit, p12bit };

Then, the concept of pixel format, enum PixelFormat { NV12, NV21, YV12, P010, P016, P216, P210, Y216, Y210, Y416 }; will contain ColorSpace and ColorDepth information, in addition to how the pixel information is stored in memory (pixel layout?).

Finally, we defined: enum ColorConversionDir { YCbCr2RGB, RGB2YCbCr };

Which specifies the direction in which we want to convert, either from YCbCr to RGB, or from RGB to YCbCr.

Now, we tried to generalize the operations necessary in order to do the conversions, and we are using the following:

struct SubCoefficients { const float luma; const float chroma; };

Where we store a number that needs to be subtracted to the luma or chroma values, before aplying the multiplication part of the formula.

Then we defined a 3x3 matrix, made of floating point numbers, whose values are different, according to: ColorRange, ColorPrimitives and ColorConversionDir.

We found very different answers for the values of this 3x3 matrix that we call Color Conversion Matrix (ccMatrix).

We need to verify the following:

1. Are the numbers we have correct?
2. If the ColorRange is Limited, then do we have to scale the input values to the full range, before applying the ccMatrix? Or can we have specific values in thie ccMatrix, that will take the color range into account?
3. We found an instance of a ccMatrix, that was ment to be used with pixels in the range 0.f to 1.f. Would it be recomendable to always work with 0.f to 1.f ranged pixels? Would it be faster? Would the code be simpler?