[Ffmpeg-devel] moving non-SIMD parts of libswscale to LGPL

[Michael Niedermayer]

Hi

On Mon, Dec 11, 2006 at 04:37:16PM +0100, Luca Abeni wrote:
> Hi all,
> 
> On Tue, 2006-12-05 at 10:23 +0100, Luca Abeni wrote:
> > Hi Michael,
> > 
> > On Mon, 2006-12-04 at 13:31 +0100, Michael Niedermayer wrote:
> > [...]
> > > 117579*255/76309        = 392.91... = /2 = 196.455...
> > > 138453*255/76309        = 462.665...= /2 = 231.33...
> > > (25675+53279)*255/76309 = 263.83... = /2 = 131.91...
> > > 
> > > 256 + 2 *232 = y range + max chroma table range
> > > 
> > > 393+463+264+256*3 = 1888
> > > 197 + 2*682 + 256 + 132 = 1949
> > > so it seems this table is larger then needed ...
> > > 
> > > i suggest that you simply check which index in the table the max/min yuv
> > > values would reach and then use that to allocate the table and set the index
> > > of each "subtable"
> > Ok; thanks for the explaination. I'll perform this check, changing the
> > values to the correct ones and adding comments about them.
> Done... A new version of yuv2rgb_init.c is attached; comments are
> welcome.
> 
> (I still have to compute more precise values for the yuv ---> rgb
> matrix... But I am under the impression that the MPEG2 standard
> truncates the values of the numbers in the rgb ---> yuv conversion
> matrices: does anyone have the "correct" values?)

RECOMMENDATION ITU-R BT.601-5 says:
The construction of luminance and colour-difference signals is as follows:
                                          EY = 0.299 ER + 0.587 EG + 0.114 EB
whence:
                             (ER - EY ) = ER - 0.299 ER - 0.587 EG - 0.114 EB
                                           =   0.701 ER - 0.587 EG - 0.114 EB
and:
                             (EB - EY ) = EB - 0.299 ER - 0.587 EG - 0.114 EB
                                           = - 0.299 ER - 0.587 EG + 0.886 EB
...
            Construction of re-normalized colour-difference signals (ECR and ECB )
                                                                                 ??        ??
3.5.2
Whilst the values for EY have a range of 1.0 to 0, those for (ER - EY) have a range of + 0.701 to - 0.701 and for (EB - EY)
a range of + 0.886 to - 0.886. To restore the signal excursion of the colour-difference signals to unity (i.e. + 0.5 to - 0.5),
coefficients can be calculated as follows:
                                        0.5                      0.5
                                       -----                    -----
                                  KR = 0.701 = 0.713       KB = 0.886 = 0.564
Then:
                            ECR = 0.713 (ER - EY ) =   0.500 ER - 0.419 EG - 0.081 EB
and:
                            ECB = 0.564 (EB - EY ) = - 0.169 ER - 0.331 EG + 0.500 EB
where ECR and ECB are the re-normalized red and blue colour-difference signals respectively (see Notes 1 and 2).
NOTE 1  The symbols ECR and ECB will be used only to designate re-normalized colour-difference signals, i.e. having
the same nominal peak-to-peak amplitude as the luminance signal EY thus selected as the reference amplitude.
NOTE 2  In the circumstances when the component signals are not normalized to a range of 1 to 0, for example, when
converting from analogue component signals with unequal luminance and colour-difference amplitudes, an additional
gain factor will be necessary and the gain factors KR, KB should be modified accordingly.

------

so yes, you are correct the values are truncated, but apparently not by mpeg*
the equations in ITU-R BT.601-5 are simply wrong 0.5/0.701 is not 0.713 for
example ...

anyway you should have no difficulty reconstructing the correct values in all
cases by simply following the same path as above just without the senseless
rounding


[...]

> #include "avutil.h"
> #include "swscale.h"
> #include "swscale_internal.h"
> 
> #define YTABLE_MIN 384
> 
> /*
>  * An YUV -> RGB conversion matrix is in the form
>  *              | 1  0 Rv |
>  *              | 1 Gu Gv |
>  *              | 1 Bu  0 |
>  *
>  * Here, we store | Rv Bu Gv Gu | * 255/224*2^16
>  */

doxygen ...


[...]
> 	    *table_r = *table_g = *table_b = table + 233;

tab and that is not the only one ...


[...]
> 	ytable[i] = FFMIN(FFMAX(value, 0), 255);

clip_uint8()


[...]
>     switch (fmt_depth(c->dstFormat)) {
>         case 32:
>             for (i = -198; i < 256 + 197; i++) {
>                 int value;
>                 value = ytable[i + YTABLE_MIN];
>                 if (isBGR(c->dstFormat)) {
>                     value <<= 16;
>                 };
>                 ((uint32_t *)table_r)[i] = value;
> 	    }
>             for (i = -133; i < 256 + 132; i++) {
>                 ((uint32_t *)table_g)[i] = ytable[i + YTABLE_MIN] << 8;
>             }
> 	    for (i = -233; i < 256 + 232; i++) {
>                 int value;

id put int value; before all that instead of duplicating it every time


> 
>                 value = ytable[i + YTABLE_MIN];
>                 if (!isBGR(c->dstFormat)) {
>                     value <<= 16;
>                 };

what does the ; do?

[...]

except the stuff above and without checking the actual numbers ... this
looks ok

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras