Hi,
> > + * The YUV color representation were acquired via the colour python > > framework. > > + * Below are the function calls used for generating each case. > > + * > > + * For more information got to the docs: > > + * > > https://colour.readthedocs.io/en/master/generated/colour.RGB_to_YCbCr.html > > + */ > > +static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = { > > + /* > > + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>, > > + * K=colour.WEIGHTS_YCBCR["ITU-R BT.601"], > > + * in_bits = 16, > > + * in_legal = False, > > + * in_int = True, > > + * out_bits = 8, > > + * out_legal = False, > > + * out_int = True) > > + */ > > We should really detail what the intent and expected outcome is supposed > to be here. Relying on a third-party python library call for > documentation isn't great. > > Maxime This was requested by Pekka in the [v2] of this series. I can add something like this before each tests, but I think having the exact python code used may help people to understand what should be the behavior, and refering to the python code to understand the conversion. I can add something like this before each tests to clarify the tested case: Test cases for conversion between YUV BT601 limited range and RGB using the ITU-R BT.601 weights. Or maybe just documenting the structure yuv_u8_to_argb_u16_case: @encoding: Encoding used to convert RGB to YUV @range: Range used to convert RGB to YUV @n_colors: Count of test colors in this case @format_pair.name: Name used for this color conversion, used to clarify the test results @format_pair.rgb: RGB color tested @format_pair.yuv: Same color as @format_pair.rgb, but converted to YUV using @encoding and @range. What do you think? Thanks, Louis Chauvet [v2]:https://lore.kernel.org/all/20240229141238.51891cad.pekka.paala...@collabora.com/ [v5]:https://lore.kernel.org/all/20240328152631.63af0e8c.pekka.paala...@collabora.com/
