From top to bottom:
Original RGB
Convert to YV12 with Lanczos Re-sample and then convert back to RGB with Lanzos Re-sample
Convert to YV12 with Lanczos Re-sample and then convert back to RGB with Point Re-sample
Convert to YV12 with Lanczos Re-sample and then convert back to RGB with Windows Default (My GPU?) Re-sample
Convert to YV12 with Point Re-sample and then convert back to RGB with Lanzos Re-sample
Convert to YV12 with Point Re-sample and then convert back to RGB with Point Re-sample
Convert to YV12 with Point Re-sample and then convert back to RGB with Windows Default (My GPU?) Re-sample
Now the reason why there is a conversion back to RGB is because our displays output only in RGB, so the conversion is automatically done regardless, but I have a way to force a method, hence why I do it to show a difference.
Note: View each picture in full screen to see it better.Honestly, I don't see any difference. At all.
Honestly, I don't see any difference. At all.
Your image is scaled-down and thus irrelevant.
What you should do to compare is open one image in its own window, and then a second image in that window, and flip back and forth between them. The differences are subtle enough that you can't easily see them in Aktan's post, but they're there.
I don't know if it's just me, my monitor, or a combination, but I just can't see a visible difference between the images, even when zoomed.
Check the sonic ones =D
Doesn't H.264 always perform the yuv transformation before encoding, regardless of which compression method is used? Wouldn't that mean that the above artifact would be shown in a regular published encode as well? Does it?
I don't know if it's just me, my monitor, or a combination, but I just can't see a visible difference between the images, even when zoomed.
Original material (no artifacts)
Encoding: RGB→YV12 Using Lanczos
Decoding: YV12→RGB Using Lanczos (High-quality software)
Comment: The spheres are very round and pleasant to look at, but there are ringing artifacts where chroma changes are most dramatic (the 5 and 6 balls look like they're floating on jello)
Encoding: RGB→YV12 Using Lanczos
Decoding: YV12→RGB Using Nearest-neighbor (Software default)
Comment: There are extra grays and the spheres appear blockier. The 3 ball has grown a ghost image. The 5 ball has changed shape entirely. Even the wall has grown a shadow for no reason at all.
Encoding: RGB→YV12 Using Lanczos
Decoding: YV12→RGB Using Windows default (maybe hardware-accelerated, maybe software quadratic scaling)
Comment: The difference to lanczos-lanczos is almost unnoticeable. The ringing artifacts are smaller though.
Encoding: RGB→YV12 Using Nearest-neighbor
Decoding: YV12→RGB Using Lanczos (High-quality software)
Comment: This combination smudges stuff profusely.
The smudging still only happens on chroma; the luma (luminance, which is what the grayscale image shows) is unaffected and appears as in the original.
Encoding: RGB→YV12 Using Nearest-neighbor
Decoding: YV12→RGB Using Nearest-neighbor (Software default)
Comment: The effect of halving the chroma resolution is very noticeable. Some pixels are simply wrong color. The score meter is very blocky. But there are no ringing artifacts whatsoever.
This is the picture you should look at, if you want to learn what chroma supersampling ― using the same chroma for every 2x2 pixel group ― means and what are its practical consequences. All of the others use mathematical filter trickery to attempt to make the fact less noticeable.
Encoding: RGB→YV12 Using Nearest-neighbor
Decoding: YV12→RGB Using Windows default (maybe hardware-accelerated, maybe software quadratic scaling)
Comment: Better than the above two. There is an artifact beside the number "5" that does not exist in the lanczos-encoded versions. The power meter edges are very blurry.
I am actually surprised of the fact that the grayscale images did not appear to be completely identical. Wasn't the point of these filters to scale the chroma, not the luma? But in retrospect, this is probably an artifact of RGB conversions; there are YUV values that cannot be expressed losslessly in RGB, so additional brightness is "loaned" from other color components by decreasing the saturation. Or something. Waiting for a better explanation.
SUMMARY:
Encode Decode Prob* Appearance & score
------------------------------------------------
Lanczos Lanczos 10% Good (9pts)
Lanczos Point 40% Horrible (1pts)
Lanczos Something 50% Good (9pts)
Point Lanczos 10% Horrible (1pts)
Point Point 40% Tolerable (6pts)
Point Something 50% Good (9pts)
Prob* = estimated probability of being decoded this way
As an encoder, you can only control how you encode stuff. You cannot control what will be used to decode it. You should maximize the chances of it looking good when decoded.
Summary of the consequences of your choices according to this chart:
Lanczos: 60% * 9pts + 40% * 1pts = 5.8pts
Point: 50% * 9pts + 40% * 6pts + 10% * 1pts = 7.0ptsI am actually surprised of the fact that the grayscale images did not appear to be completely identical. Wasn't the point of these filters to scale the chroma, not the luma? But in retrospect, this is probably an artifact of RGB conversions; there are YUV values that cannot be expressed losslessly in RGB, so additional brightness is "loaned" from other color components by decreasing the saturation. Or something. Waiting for a better explanation.
The two horizontally adjacent images are completely redundant. Aktan forgot to deobfuscate his post.
That's a reasonable explanation oh Bisqwit's findings, rhebus! Thanks for the information.
For some reason, I'm not getting the artifacts you do on Sonic. http://bisqwit.iki.fi/kala/yv12scaledemo/ I have tried offsetting the Sonic image by a pixel or two in any direction, but no matter what I try, I cannot seem to get the horrible red-distorted version you have, Aktan, regardless of the choice of filters. I think there's something wrong in your setup instead. Maybe you converted the images a few times back & forth in succession? It would explain the way heavier ringing artifacts than in my results, too...
I tried both Imagemagick's -type grayscale and -colorspace gray options, and they both gave the same result, which according to Imagemagick documentation, is calculated with that Y formula (in both cases). -fx (R+G+B)/3 gives the other grayscale result, which was not shown here. So no, that was a good theory, but not the right explanation. The real reason is still unknown.
Pink (228,0,88) ->YUV-> (78,6,82)
Green (0,68,0) ->YUV-> (40,X,X)
Resultant YUV: (40,6,82)
Resultant RGB: (155,-21,51)
My guess is that some hackery maps this "fake" RGB value into the real RGB value that results in the image (190,0,50) in some way which doesn't preserve luma -- and at least one of luma or chroma must be diddled to get back to real RGB values.
EDIT 2:
In the above imageset, I went to painstaking efforts to preserve the luma in the unrepresentable colors. Here is what most software does instead, i.e. clamping:
To my surprise, the same also happens in the upper region. Once the luma becomes small enough, too stark chroma values will cause RGB components to appear negative. When only simple clamping is done, these colors will appear anything but black. I am not sure what to make of this. On the other hand, color distribution in these graph correlates with the color of noise patterns seen on badly tuned tv receivers…
*) Not exactly right. The colors are the same, but the real SMPTE color bars are actually 100% saturated color bars in which RGB components are always either 0 or 75%. Consecutively, the luma varies. They are sorted in order of increasing luma.YUV can express colors that are not possible to express in RGB.
I decided to go and do independent tests with the same basic idea. The test results are here, as is the shell script that I used to run ffmpeg to create all these images. http://bisqwit.iki.fi/kala/yv12scaledemo/