Re: Shift Histograms

Great!  My primary reason for submitting this was in the hope that it would 
be helpful to you all and the community.   I do admire XVid.

I've written dozens of video filters myself and am quite familiar with the 
lossiness of RGB/YV12 conversion, so you don't have to worry about me :)

Regards,
Andrew



--------------------------------------------------
From: "Michael Militzer" <[email protected]>
Sent: Wednesday, May 13, 2009 3:02 AM
To: <[email protected]>
Subject: Re: [XviD-devel] Shift Histograms

> 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 <[email protected]>:
>
>> 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" <[email protected]>
>> Sent: Tuesday, May 12, 2009 12:52 AM
>> To: <[email protected]>
>> 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 <[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
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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