X-Git-Url: https://git.sesse.net/?p=movit;a=blobdiff_plain;f=ycbcr.h;h=4eb9e73185794fc0118ec2590e4303892dfa8595;hp=7e5891f741907b48c5b00c52fb733d0614d4b8ef;hb=80fc4a6e806e5638ae050c3020962137ca5fd76b;hpb=ba60914d4e5eda7b28af700bf43e9699b7aa720d diff --git a/ycbcr.h b/ycbcr.h index 7e5891f..4eb9e73 100644 --- a/ycbcr.h +++ b/ycbcr.h @@ -1,7 +1,37 @@ #ifndef _MOVIT_YCBCR_H #define _MOVIT_YCBCR_H 1 -// Shared utility functions between YCbCrInput and YCbCr422InterleavedInput. +// Shared utility functions between YCbCrInput, YCbCr422InterleavedInput +// and YCbCrConversionEffect. +// +// Conversion from integer to floating-point representation in case of +// Y'CbCr is seemingly tricky: +// +// BT.601 page 8 has a table that says that for luma, black is at 16.00_d and +// white is at 235.00_d. _d seemingly means âon a floating-point scale from 0 +// to 255.75â, see Â§2.4. The .75 is because BT.601 wants to support 10-bit, +// but all values are scaled for 8-bit since that's the most common; it is +// specified that conversion from 8-bit to 10-bit is done by inserting two +// binary zeroes at the end (not repeating bits as one would often do +// otherwise). It would seem that BT.601 lives in a world where the idealized +// range is really [0,256), not [0,255]. +// +// However, GPUs (and by extension Movit) don't work this way. For them, +// typically 1.0 maps to the largest possible representable value in the +// framebuffer, ie., the range [0.0,1.0] maps to [0,255] for 8-bit +// and to [0,1023] (or [0_d,255.75_d] in BT.601 parlance) for 10-bit. +// +// BT.701 (page 5) seems to agree with BT.601; it specifies range 16â235 for +// 8-bit luma, and 64â940 for 10-bit luma. This would indicate, for a GPU, +// that that for 8-bit mode, the range would be 16/255 to 235/255 +// (0.06275 to 0.92157), while for 10-bit, it should be 64/1023 to 940/1023 +// (0.06256 to 0.91887). There's no good compromise here; if you select 8-bit +// range, 10-bit goes out of range (white gets to 942), while if you select +// 10-bit range, 8-bit gets only to 234, making true white impossible. +// +// We currently support the 8-bit ranges only, since all of our Y'CbCr +// handling effects happen to support only 8-bit at the moment. We will need +// to fix this eventually, though, with an added field to YCbCrFormat. #include "image_format.h" @@ -18,6 +48,10 @@ struct YCbCrFormat { // JPEG uses the Rec. 601 luma coefficients, but full range. bool full_range; + // Currently unused, but should be set to 256 for future expansion, + // indicating 8-bit interpretation (see file-level comment). + int num_levels; + // Sampling factors for chroma components. For no subsampling (4:4:4), // set both to 1. unsigned chroma_subsampling_x, chroma_subsampling_y;