How to prevent grain induced block noise in uniform areas?

[RadicalEd]

Originally posted by virus
Actually YUV is not a burden to carry on for historical reasons, but a way to provide better compression. The YUV components are (almost) decorrelated whilst the RGB ones are not. That means less variance for the U and V planes, hence less entropy, thus they can be represented with less bits.

That and there's the whole HVS factor, where our ability to sense change in color is that much lower than change in luma, thus allowing for even fewer bits.

[virus]

Originally posted by RadicalEd
That and there's the whole HVS factor, where our ability to sense change in color is that much lower than change in luma, thus allowing for even fewer bits. Yes. This is related to the fact that the luma component has a lot of green in it (see the equation above), since the eye is especially sensitive to the intensity of the green component and thus less sensitive to the U and V planes (which contain little green, being almost uncorrelated to the luma component).

Also, U/V signals have typically slow variations: that means that the U and V planes have a lower bandwidth than luma and thus they can (almost) safely be subsampled. And with this step we move from a generic YUV space to the well-known YUY2/YV12 spaces. And the eye still feels pretty fine :D

[JasonFly]

This is a very intereting topic. I am very surprised concerning the conversion from rgb to YV12 so I also made some tests.

I made an RGB gradient image in photoshop. Here is the source:
http://perso.wanadoo.fr/paille/GradientRGB_source.png

I made two 2 seconds clips(one giving RGB and one giving YV12) with avisynth using those script.

RGB:
ImageReader("E:\GradientRGB_source.png", 0, 0,25,false).Loop(50,0,0)
YV12:
ImageReader("E:\GradientRGB_source.png", 0, 0,25,false).Loop(50,0,0).ConvertToYV12()

The results confirmed what that has already been said,RGB->YV12 conversion is lossy.
RGB in Vdub:
http://perso.wanadoo.fr/paille/Vdub_RBG.png

YV12 in Vdub:
http://perso.wanadoo.fr/paille/Vdub_YV12.png


I aslo made a test giving the RGB source to Vdub and encode with divx 5 and XviD. The test was made at q=2with almost defaut param for both codecs. I think I just put "slowest" for DivX and "hvsbest" for XviD. Anyway, that's not very important.Filesize for XviD is bigger than the DivX one. Concerning image quality, DivX is better than XviD.

DivX5:
http://perso.wanadoo.fr/paille/GradientRGB_divx5.png

XviD, hvsbest:
http://perso.wanadoo.fr/paille/GradientRGB_hvsbest.png

Does tat mean that DivX YV12 conversion is better than the XviD one?

[Manao]

To compare DivX5 and XviD on that particular matter, you should use for XviD the H263 matrix. And I would also try to use the same DCT / iDCT.

[JasonFly]

Yes you're rigth, results are far better with h263 than with hvsbest. But,is it possible to use the same idct for the both codecs? What is the DCT used by DivX?

H263
http://perso.wanadoo.fr/paille/GradientRGB_h263.png

[dude051]

@JasonFly
This test you did to compare DivX to XviD doesn't seem to prove anything about XviD's color space conversion to me. This is because when you changed the matrix, the result was in fact better... so doesn't this show a defect in the compression used with the matrix? To me, im no expert though, the problem looks to be mainly in the VDub or Avisynth's color conversion factors.

Just an opinion to throw out.

[drcl]

is it possibly caused by using only 8 bit matrix?

[lordadmira]

Originally posted by virus
Actually YUV is not a burden to carry on for historical reasons, but a way to provide better compression. The YUV components are (almost) decorrelated whilst the RGB ones are not. That means less variance for the U and V planes, hence less entropy, thus they can be represented with less bits. No no no!! YUV isn't a way to get better compression it's a way to cheat on bandwidth. YUV's only "advantage", if it can be called that, is that it allows for chroma subsampling of an image. That's fancy tech speak for chinsing on the color bandwidth. A hack. Now there would be nothing wrong with a full range full sample 4:4:4 YUV colorspace. But thanks to bean counters we have abominations like YV12, 4:2:0, 4:1:1. These non pure YUV spaces make certain YUV <-> RGB conversions lossy. Pushing more significant data into the Y channel doesn't decrease the total entropy. Entropy always increases, the zeroeth law of thermodynamics. You can take advantage of that with high entropy encoding schemes for the Y channel and low entropy schemes for the UV channels but I don't think that will save any bandwidth.

virus wrote
That and there's the whole HVS factor, where our ability to sense change in color is that much lower than change in luma, thus allowing for even fewer bits. Only by using subsampling which increases the lossiness of the compression.

virus wrote
Yes. This is related to the fact that the luma component has a lot of green in it (see the equation above), since the eye is especially sensitive to the intensity of the green component and thus less sensitive to the U and V planes (which contain little green, being almost uncorrelated to the luma component). Uh, I don't think u know what ur talking about. :D U and V are not red and blue.

@Jason
Yes a *color* RGB -> YV12 conversion will always be lossy since YV12 subsamples the chroma planes. U can see that in ur YV12 image, those are the subsampling artifacts. The B&W examples before should not have been lossy going from RGB -> YV12 because there is no chroma information. I don't know why that AviSynth function was mapping the 256 RGB grays into 219 Y grays. It's probably some attempt to compensate for the fact that each RGB channel contributes differently to the intensity of the gray. Ur compression tests on the gradients make sense since Mpeg4 can't replicate a gradient. It transforms images into waveforms, waves that must rise, peak, and fall. A gradient has no fall so it cannot be encoded.

LA

[Manao]

drcl : no

lordadmira : you may be interested in reading this (http://jehoo.netian.com/tech%20brief/brief%203/dvcontents/dv-14.html)Entropy always increases, the zeroeth law of thermodynamics.In the real world, yes, but we're talking about informatics here.Uh, I don't think u know what ur talking about. U and V are not red and blue.They are when Y = 0. When U = V = 0, the picture can vary from dark green ( Y = 0) to bright green ( Y = 255 ).

[virus]

lordadmira, mate, listen to me ;)

Statements like that:
Originally posted by lordadmira
Entropy always increases, the zeroeth law of thermodynamics.
where you mix stuff from physics which has nothing in common with information theory, only show a lack of understanding of the very basics of data compression. If you never hear words like "random variable", "zeroth order entropy of a source", "mutual information", "coding gain" or "spectral decorrelation" it doesn't mean they don't exist, just that you know nothing about that. I'd warmly suggest you to read a book on information theory ;)

Uh, I don't think u know what ur talking about. :D strange, I was thinking the very same thing about you :D
Anyway FYI I have an engineering degree, took with a thesis on lossless image compression (and related theory behind it). Looks like I've been really lucky that they didn't trash all my work altogether uh? ;)

virus

[lordadmira]

Originally posted by Manao
lordadmira : you may be interested in reading this (http://jehoo.netian.com/tech%20brief/brief%203/dvcontents/dv-14.html) That's a really good article. Helps to elucidate this YUV phenomenon. Jason, it helps explain the 219 grays issue, "white clipping".

They are when Y = 0. When U = V = 0, the picture can vary from dark green ( Y = 0) to bright green ( Y = 255 ). When U and V are 0 the picture is grayscale. The R, G, and B values will always be equal. When Y is 0 you have black. This is because the presence of any R, G, or B value will raise the Y value. They all must be 0 for Y to be 0. But strictly speaking, U and V, they are not red and blue. I created a spreadsheet to play around with the values. I used these formulas: RGB -> YUV
Y = 0.299*R + 0.587*G + 0.114*B
U = -0.147*R - 0.289*G + 0.436*B
V = 0.615*R - 0.515*G - 0.100*B

YUV -> RGB
Red = Y + 1.140*V
Green = Y - 0.396*U - 0.581*V
Blue = Y + 2.029*U
@virus
I must disagree. Physics has everything to do with this discussion. Video encoding and display come directly from the physics of electromagnetic waves and their interaction with the human eye. The standards evolved from the study of these physical phenomena. And I wasn't the one who brought the word "entropy" into this. ;) Some people call video compression "entropy encoding". When u touch the dragon of entropy it will only get bigger, never smaller. Lossy encoding can be considered a form of allowing entropy to grow. Everything's information anyway, matter, energy it's all information (ref: implicate order). Data compression? This forum has nothing to do with data compression. U might want to visit a RAR or BZ2 forum...:cool:

Anyway, it's good that u have a degree. Let's not let this fall into a stupid tomâto, tomäto argument.

LA

[virus]

lordadmira:

ROTFL :D
Really, you should make a job out of posts like these... please keep on enlightening and entertaining us with your stuff. :D

[Manao]

lordadmira : no, the picture is in greyscale when U = V = 128 ( around 128 at least ). You have the correct mathematical formulas, but in computer science, Y, U and V are ranged from 0 to 255, and your formula ( RGB to YUV ) give negative U and V. So you have to offset them after multiplying them by a matrix.

For the rest of your post : entropy in computer science is nothing less than the minimal (considering no prediction schemes are used) mean of number of bits per symbol needed to write a serie of symbols. Shanon told us 50 years ago that you could not write that serie of symbol with a lower mean of number of bits per symbol. Entropy coding refers to lossless encoding schemes which allow to almost reach the entropy while compressing.

[lordadmira]

Originally posted by Manao
lordadmira : no, the picture is in greyscale when U = V = 128 ( around 128 at least ). You have the correct mathematical formulas, but in computer science, Y, U and V are ranged from 0 to 255, and your formula ( RGB to YUV ) give negative U and V. So you have to offset them after multiplying them by a matrix. I based my statements off the RGB -> YUV equations. I knew that a remapping had to take place to put U and V into 8 bits unsigned. Y has a natural range of 0 to 255, U -111.2 to +111.2, V -156.8 to +156.8. V's range exceeds 256 values so it has to be smashed into that range. U and V can never have their minimum values simultaneously, that yields invalid RGB values no matter what Y is. R, G, and B can have values independant of each other. The values of Y, U, and V cannot have arbitrary values since they are constrained by the other two variables.

For the rest of your post : entropy in computer science is nothing less than the minimal (consi........................<snip> I don't see what any of that has to do with this thread, u should address that to virus, he's the one that brought it up. No reply necessary, but I disagree with that definition of entropy.

Hmm, somewhere does any of this have anything to do with the failure of YUV color spaces to handle gradients? :D

LA

[OCedHrt]

Originally posted by Manao
What bothers me, however, is that if I open the avi directly with virtual dub, or with avisynth, ( AVISource("foo.avi", pixel_type="YV12") ), I get different results.

Edit : for the number of color : somebody ( something ) put a limiter somewhere ( hence reducing the luma range to 16-235 which, omg, makes only 219 available grey levels ) [/B]

I think that has to do with what I just read on avisynth's site:
This parameter will extend the YUV range from 16-235 (this is the range used by all avisynth converters) to 0-255.

[Wilbert]

@Manao,

Sorry, I have nothing useful to say about your problem.

@lordadmira,

No no no!! YUV isn't a way to get better compression it's a way to cheat on bandwidth. YUV's only "advantage", if it can be called that, is that it allows for chroma subsampling of an image. That's fancy tech speak for chinsing on the color bandwidth. A hack. Now there would be nothing wrong with a full range full sample 4:4:4 YUV colorspace. But thanks to bean counters we have abominations like YV12, 4:2:0, 4:1:1. These non pure YUV spaces make certain YUV <-> RGB conversions lossy.
That's true, but note that may colorformat conversions are lossy. RGB <-> HSV is also lossy.

Anyway, chroma subsampling is not a hack. The eye is less sensitive for changes in chroma than in luma. So, why not use that? It enables us to put more info on a dvd. Of course, if your source/target is YUV you shouldn't convert to RGB in the first place.

Yes a *color* RGB -> YV12 conversion will always be lossy since YV12 subsamples the chroma planes. U can see that in ur YV12 image, those are the subsampling artifacts. The B&W examples before should not have been lossy going from RGB -> YV12 because there is no chroma information. I don't know why that AviSynth function was mapping the 256 RGB grays into 219 Y grays. It's probably some attempt to compensate for the fact that each RGB channel contributes differently to the intensity of the gray. Ur compression tests on the gradients make sense since Mpeg4 can't replicate a gradient. It transforms images into waveforms, waves that must rise, peak, and fall. A gradient has no fall so it cannot be encoded.

The main problem is that you have YUV [0,255], YUV [16,235], RGB [0,255] and RGB [16,235].

MPEG1/2/4 is all YV12 [16,235]. That's why AviSynth (and most codecs) changes the luma range when converting from RGB to YUV. Of course, it would be nice if a RGB->YUV (luma range unchanged) conversion would exist in AviSynth. But, that is only useful for "artificial" purposes.

Note that some mjpeg keep the luma range fixed when converting YUV to RGB, getting RGB [16,235] (assuming your YUV clip is also [16,235]).

The main problem is just that there are different color spaces being used, and we need to convert between them sometimes. An additional problem is the two luma ranges floating around.