[XviD-devel] Shift Histograms

Wed May 13 12:02:04 CEST 2009

Hi,

it seems you're right. RGB->YV12 conversion had a precision (or mainly
rounding) issue. I've commited a patch to the xvid head branch that
improves precision for both the c and mmx code. The image histogram is
now preserved (more or less) over many runs.

While this should fix the brightness issue you observed still keep in
mind that the RGB<->YV12 conversions are lossy. Especially the YV12->RGB
mmx code is rather imprecise. The precision here can also not be improved
without rewriting the whole code (precision had been deliberately traded
for speed when we wrote that code).

So running YV12->RGB->YV12 conversions many times in a row on the same
image is not a good idea. If you have a choice always try to avoid RGB
colorspace conversions for best quality (and processing speed also).

Regards,
Michael

Quoting A Uio <a.xvid at uio9.org>:

> Hi again,
>
> Another bit of data...  I one of my tests, I had VirtualDub simply write out
> uncompressed 8-bit YV12, and then I read the file and converted it back to
> RGB.   This degraded the image some as one would expect (blurred chroma,
> banding, etc), but it didn't yield any significant bias even after 3
> iterations.   This would seem to suggest that there is an 8-bit RGB/YUV
> conversion (used internally by VDub) that's not biased.
>
> Trying the same test with a solid 50% gray frame RGB=[128, 128, 128], it
> holds stable in each iteration in VDub, always 128.   In comparision,
> encoding then decoing with XVid, the levels drop by 1 or 2 in each
> iteration, becoming [127, 127, 127], then 126, then 124, then 122, then 120.
>
> Hope this is helpful!  I'm trying very hard to isolate what is going on.
> But I still haven't gotten anyone to run the same tests,
> so it is always possible that I am somehow messing up :)
>
> Regards,
> Andrew
>
> --------------------------------------------------
> From: "Michael Militzer" <michael at xvid.org>
> Sent: Tuesday, May 12, 2009 12:52 AM
> To: <xvid-devel at xvid.org>
> Subject: Re: [XviD-devel] Shift Histograms
>
>> Hi,
>>
>> there have been tests. I especially remember that we fixed rounding issues
>> for the YV12->RGB conversion. So what you look at now is already an
>> improved version ;)
>>
>> In general, RGB->YV12 conversion is always lossy. You should avoid an
>> unnecessary YV12->RGB->YV12 chain when aiming for best quality. Obviously,
>> the conversion should not be biased. I'd say there however can be a small
>> bias either because of rounding issues or because of limited precision of
>> the conversion coefficients.
>>
>> When looking at the code I see that the coefficients for the RGB->YV12
>> conversion have just 8 bits precision. At least for the c-code it should
>> be easily possible to increase that number. If you can please try to
>> increase SCALEBITS_IN to e.g. 12 (line 155 in src/image/colorspace.c) and
>> check if this reduces the bias you measured for the c-code. If it does we
>> could modify the MMX code accordingly then.
>>
>> Regards,
>> Michael
>>
>>
>> Quoting A Uio <a.xvid at uio9.org>:
>>
>>> Thank for your reply!  That makes total sense.
>>>
>>> Do you know if this bias is well known?  Has anyone besides me ever
>>> tested
>>> this?  Random variations of plus or minus 1% for individual pixels is no
>>> big
>>> deal, but having the whole image get 1% darker is.  It seems a shame to
>>> have
>>> such a cool codec as Xvid be so accurate when given Yv12 source, and then
>>> have it become so inaccurate if handed RGB.  Obviously I can choose to
>>> feed
>>> it only YV12, but I'm guessing less tech savvy users would get confused
>>> about this.
>>>
>>> Regards,
>>> Andrew
>>>
>>>
>>>
>>> --------------------------------------------------
>>> From: "Michael Militzer" <michael at xvid.org>
>>> Sent: Monday, May 11, 2009 2:01 AM
>>> To: <xvid-devel at xvid.org>
>>> Subject: Re: [XviD-devel] Shift Histograms
>>>
>>>> Hi,
>>>>
>>>> Xvid's RGB <-> YUV conversions have been designed to be fast. It is
>>>> known
>>>> that they aren't precise (especially the MMX versions). So if you
>>>> measure
>>>> a ~1% deviation this may not be a big surprise.
>>>>
>>>> The implementation in C should be more precise. So for a test you may
>>>> want
>>>> to disable MMX/SSE optimizations in the xvid GUI and check whether the
>>>> C-code provides better results.
>>>>
>>>> In general especially the YUV -> RGB conversions have been included into
>>>> xvid at a time when graphics cards with YUV overlay support were not the
>>>> norm and when low-end PC processors still had a hard time to decode PAL
>>>> resolution video in realtime. So the primary goal was to make the
>>>> conversions fast to enable fluent playback...
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> Quoting A Uio <a.xvid at uio9.org>:
>>>>
>>>>> Howdy,
>>>>>
>>>>> I think I may have found a bug in Xvid's RGB/YUV conversions. I've been
>>>>> posting about it at
>>>>>
>>>>> http://forum.doom9.org/showthread.php?p=1281193
>>>>>
>>>>> Despite what responders have posted, I'm fairly sure its not a PC/Video
>>>>> levels or 601/709 issue.  No one took me up on my request to replicate
>>>>> the
>>>>> tests on their systems, so it is always could just be something wrong
>>>>> with
>>>>> my system.
>>>>>
>>>>> Hope this is helpful!
>>>>>
>>>>> Regards,
>>>>> A
>>>>>
>>>>> _______________________________________________
>>>>> Xvid-devel mailing list
>>>>> Xvid-devel at xvid.org
>>>>> http://list.xvid.org/mailman/listinfo/xvid-devel
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xvid-devel mailing list
>>>> Xvid-devel at xvid.org
>>>> http://list.xvid.org/mailman/listinfo/xvid-devel
>>>
>>> _______________________________________________
>>> Xvid-devel mailing list
>>> Xvid-devel at xvid.org
>>> http://list.xvid.org/mailman/listinfo/xvid-devel
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Xvid-devel mailing list
>> Xvid-devel at xvid.org
>> http://list.xvid.org/mailman/listinfo/xvid-devel
>
> _______________________________________________
> Xvid-devel mailing list
> Xvid-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>
>