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