Re: PAL/UYVY/YUV width requirement

Bob Friesenhahn <[email protected]> Tue, 12 Apr 2005 16:41:26 -0500 (CDT)
Newsgroups gmane.comp.video.graphicsmagick.core
Message-ID <[email protected]>
On Tue, 12 Apr 2005, Glenn Randers-Pehrson wrote:

> At 03:35 PM 4/12/2005 -0500, Bob Friesenhahn wrote:
>> It seems that the PAL/UYVY/YUV formats fail a read/write test when the
>> width is not a power of two.  This is apparently due to the use of
>> subsampling in the output.
>>
>> Does anyone know if this is a specific design limitation for these
>> formats, or should some sort of pad be added for odd-widths?
>
> I think (but don't know for a fact) that these were designed for
> video so would only expect to be found in standard video sizes.
> But don't our codecs try to cope with odd sizes?  Look at the
> resampling opeation around line 543 in coders/yuv.c (which probably
> would fail a round-trip test).

Yes, I did notice that resizing, which would certainly cause problems 
for an automated test.  The UYVY coder does not include that resizing. 
It adds values into one byte which which is then "pushed" out every 
two samples.  So if there are three samples the last value never gets 
pushed out and the image becomes distorted.  Maybe this could be 
handled by adding a last sample equal to the previous one if the image 
has an odd width.

It may be that these formats were designed for video, but the output 
is scaled for use with computers and is not appropriately scaled for 
video.

Bob
======================================
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click