[PATCH] Fix blurry Xv image
Hi, The attached patch fixes the issue of blurry images under Xv, compared to unaccelerated rendering. The texture sampler for CbCr used to be configured to use bilinear interpolation when upscaling. This results in a smoothing of the chroma channels, and is perceived as being blurry when a lot of sharp changes in colour is present. Simply flip the bits to use nearest-point interpolation instead. Cheers, -- Yang Zhao http://yangman.ca
On Mar 03, 09 18:03:22 -0800, Yang Zhao wrote:
The attached patch fixes the issue of blurry images under Xv, compared to unaccelerated rendering.
The texture sampler for CbCr used to be configured to use bilinear interpolation when upscaling. This results in a smoothing of the chroma channels, and is perceived as being blurry when a lot of sharp changes in colour is present. Simply flip the bits to use nearest-point interpolation instead.
Yang, I wouldn't change that. AFAIU color subsampling in the normal
YCb'Cr' color spaces is defined to be interpolative. If it does look to
blurry, there could be a different bug. Also, with nearest-neighbor
interpolation at least I always stumble over hard edges at smooth
surfaces, especially if they are red.
BTW - I already tried to use bicubic filters once, and I couldn't get
them to work. Apparently they need a little extra love (read:
coefficients) to actually work.
Of course one can always emulate bicubic filters by manually fetching
the necessary samples.
Matthias
--
Matthias Hopf
On Wed, Mar 4, 2009 at 10:18 AM, Matthias Hopf
On Mar 03, 09 18:03:22 -0800, Yang Zhao wrote:
The attached patch fixes the issue of blurry images under Xv, compared to unaccelerated rendering.
The texture sampler for CbCr used to be configured to use bilinear interpolation when upscaling. This results in a smoothing of the chroma channels, and is perceived as being blurry when a lot of sharp changes in colour is present. Simply flip the bits to use nearest-point interpolation instead.
Yang, I wouldn't change that. AFAIU color subsampling in the normal YCb'Cr' color spaces is defined to be interpolative. If it does look to blurry, there could be a different bug. Also, with nearest-neighbor interpolation at least I always stumble over hard edges at smooth surfaces, especially if they are red.
BTW - I already tried to use bicubic filters once, and I couldn't get them to work. Apparently they need a little extra love (read: coefficients) to actually work. Of course one can always emulate bicubic filters by manually fetching the necessary samples.
I looked into the bicubic stuff and it has a fairly complex kernel setup, and, unfortunately, it was dropped on r7xx hardware. All in all, it's probably easier to implement it in shaders. The relevant shader code already exists for r3xx-r5xx hardware. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/3/4 Matthias Hopf
On Mar 03, 09 18:03:22 -0800, Yang Zhao wrote:
The texture sampler for CbCr used to be configured to use bilinear interpolation when upscaling. This results in a smoothing of the chroma channels, and is perceived as being blurry when a lot of sharp changes in colour is present. Simply flip the bits to use nearest-point interpolation instead.
Yang, I wouldn't change that. AFAIU color subsampling in the normal YCb'Cr' color spaces is defined to be interpolative. If it does look to blurry, there could be a different bug. Also, with nearest-neighbor interpolation at least I always stumble over hard edges at smooth surfaces, especially if they are red.
Does MPEG/BT.601/BT.709 define an upscaling method for chroma when decoding, or is that up to each decoder implement as they see fit? I failed to find any secondary source information on this, and acquiring specs myself is a PITA. In any case, I was purely going by user feedback and comparing results to the mplayer software converter: http://yangman.ca/r600_xvtest/ The blurring is very, very subtle, and, frankly, neither bilinear nor nearest-point produces very good results for images with a lot of file detail. On the other hand, bilinear clearly does lose a lot of detail, and it comes down to a question of whether we want sharp images with some red artifacts, or slightly fuzzy images with less said artifacts. Alternatively, we try bicubic filtering with the shader. (Actually, I think I'll try that for kicks anyway.) -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Mar 04, 09 09:38:58 -0800, Yang Zhao wrote:
Yang, I wouldn't change that. AFAIU color subsampling in the normal YCb'Cr' color spaces is defined to be interpolative. If it does look to blurry, there could be a different bug. Also, with nearest-neighbor interpolation at least I always stumble over hard edges at smooth surfaces, especially if they are red.
Does MPEG/BT.601/BT.709 define an upscaling method for chroma when decoding, or is that up to each decoder implement as they see fit? I
It seems that even the definition of where the subsamples lie is exactly defined, and different per codec, and it turns out to be a nightmare. JPEG/JFIF, M-JPEG, H.261, and MPEG-1 define the sampling points at the center of a 2x2 block, while Rec.601 (don't know the codecs here) defines 4:2:2 to be situated in the center of even lum samples, and Mpeg-2 mixes both schemes - best take a look at http://books.google.com/books?id=ra1lcAwgvq4C&pg=RA1-PA93&lpg=RA1-PA93&dq=chroma+subsampling+interpolation&source=bl&ots=bOh8AFXU9a&sig=QmssmmY3maRjYrSw27vcAi3OKZA&hl=en&ei=_e2vSbjFAcOe_ga94ri1BA&sa=X&oi=book_result&resnum=3&ct=result#PRA1-PA93,M1 I haven't found a spec for how the values have to be reconstructed. But the original sample positions would influence that very much.
failed to find any secondary source information on this, and acquiring specs myself is a PITA.
Read http://www.glennchan.info/articles/technical/chromata/chromata.html IMHO bilinear filtered already looks *much* better than nearest neighbor. http://www.glennchan.info/articles/technical/chroma/chroma1.htm looks like an interesting read. Haven't read yet, though.
In any case, I was purely going by user feedback and comparing results to the mplayer software converter: http://yangman.ca/r600_xvtest/
The test image is particular suited for letting nearest neighbor lookup
look better. There are others that are favouring interpolation.
But even in this case I like the filtered one better. In this case it's
personal taste. But for a really good interpolation we need gamma
corrected interpolation. Which makes the filter nonlinear.
Matthias
--
Matthias Hopf
2009/3/5 Matthias Hopf
On Mar 04, 09 09:38:58 -0800, Yang Zhao wrote:
Does MPEG/BT.601/BT.709 define an upscaling method for chroma when decoding, or is that up to each decoder implement as they see fit? I
It seems that even the definition of where the subsamples lie is exactly defined, and different per codec...
I haven't found a spec for how the values have to be reconstructed. But the original sample positions would influence that very much.
From page 93: "To interpolate the missing chroma samples prior to conversion back to R'G'B', low-end systems simply replicate the subsampled Cb and Cr values throughout the 2x2 quad. This technique is ubiquitous in JPEG/JFIF... and is used in M-JPEG, H.261, and MPEG-1"
This seems to imply that stored chroma is upscaled using nearest-point interpolation by standard, or at least that's the common way for renderers to operate. This is the same conclusion I arrived at after comments of blurriness prompted me to investigate how the up-sampling is done.
failed to find any secondary source information on this, and acquiring specs myself is a PITA.
Read http://www.glennchan.info/articles/technical/chromata/chromata.html
IMHO bilinear filtered already looks *much* better than nearest neighbor.
http://www.glennchan.info/articles/technical/chroma/chroma1.htm looks like an interesting read. Haven't read yet, though.
That's one of the more useful sites I did manage to find, but I didn't give it much thought since it seemed to be geared toward how to encode the stills such that artifacts as a result of nearest-neighbour decoding doesn't end up producing crappy results. Looking over it again, it seems to have some hints for decoders as well. I'll give it a better read through. In any case, I'll keep working on this to see if I can come up with a better solution. It's easier to let results do the talking. I'll check my university's library catalogue to see if it has copies of the various MPEG-related specs. Cheers, -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Mar 05, 09 09:34:56 -0800, Yang Zhao wrote:
I haven't found a spec for how the values have to be reconstructed. But the original sample positions would influence that very much.
From page 93: "To interpolate the missing chroma samples prior to conversion back to R'G'B', low-end systems simply replicate the subsampled Cb and Cr values throughout the 2x2 quad. This technique is ubiquitous in JPEG/JFIF... and is used in M-JPEG, H.261, and MPEG-1"
This seems to imply that stored chroma is upscaled using nearest-point interpolation by standard, or at least that's the common way for renderers to operate. This is the same conclusion I arrived at after comments of blurriness prompted me to investigate how the up-sampling is done.
I rather read this as: the simple way is to use nearest neighbor, more elaborate versions do interpolation.
That's one of the more useful sites I did manage to find, but I didn't give it much thought since it seemed to be geared toward how to encode the stills such that artifacts as a result of nearest-neighbour decoding doesn't end up producing crappy results. Looking over it again, it seems to have some hints for decoders as well. I'll give it a better read through.
Same to me.
Matthias
--
Matthias Hopf
On Thu, Mar 5, 2009 at 12:34 PM, Yang Zhao
2009/3/5 Matthias Hopf
: On Mar 04, 09 09:38:58 -0800, Yang Zhao wrote:
Does MPEG/BT.601/BT.709 define an upscaling method for chroma when decoding, or is that up to each decoder implement as they see fit? I
It seems that even the definition of where the subsamples lie is exactly defined, and different per codec...
I haven't found a spec for how the values have to be reconstructed. But the original sample positions would influence that very much.
From page 93: "To interpolate the missing chroma samples prior to conversion back to R'G'B', low-end systems simply replicate the subsampled Cb and Cr values throughout the 2x2 quad. This technique is ubiquitous in JPEG/JFIF... and is used in M-JPEG, H.261, and MPEG-1"
This seems to imply that stored chroma is upscaled using nearest-point interpolation by standard, or at least that's the common way for renderers to operate. This is the same conclusion I arrived at after comments of blurriness prompted me to investigate how the up-sampling is done.
failed to find any secondary source information on this, and acquiring specs myself is a PITA.
Read http://www.glennchan.info/articles/technical/chromata/chromata.html
IMHO bilinear filtered already looks *much* better than nearest neighbor.
http://www.glennchan.info/articles/technical/chroma/chroma1.htm looks like an interesting read. Haven't read yet, though.
That's one of the more useful sites I did manage to find, but I didn't give it much thought since it seemed to be geared toward how to encode the stills such that artifacts as a result of nearest-neighbour decoding doesn't end up producing crappy results. Looking over it again, it seems to have some hints for decoders as well. I'll give it a better read through.
In any case, I'll keep working on this to see if I can come up with a better solution. It's easier to let results do the talking.
I'll check my university's library catalogue to see if it has copies of the various MPEG-related specs.
You might also check the hw setup in the intel or nouveau drivers as a reference for comparison. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
It appears that I've made some incorrect assumptions about the current implementation, and it's producing terrible results when the image is resized. I'll give an update when I've implemented it correctly. Cheers, -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
participants (3)
-
Alex Deucher
-
Matthias Hopf
-
Yang Zhao