Re: 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 <[email protected]>:

> 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" <[email protected]>
> Sent: Monday, May 11, 2009 2:01 AM
> To: <[email protected]>
> 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 <[email protected]>:
>>
>>> 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
>>> [email protected]
>>> http://list.xvid.org/mailman/listinfo/xvid-devel
>>>
>>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Xvid-devel mailing list
>> [email protected]
>> http://list.xvid.org/mailman/listinfo/xvid-devel
>
> _______________________________________________
> Xvid-devel mailing list
> [email protected]
> http://list.xvid.org/mailman/listinfo/xvid-devel
>
>