Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 15th January 2010, 01:34   #1  |  Link
Aktan
Registered User
 
Join Date: Feb 2002
Posts: 303
ConvertBackToYUY2() only works after ConvertToRGB()?

I have a capture in RGB of game footage. My final output would to H.264 so the colorspace would change to YV12(). Since I don't want to lose the color information, I did a PointResize(last.width*2,last.height*2) on the source. I read from the Sampling page of AviSynth that in order to avoid interpolating the chroma, I would need to use ConvertBackToYUY2(). I tried using it and after some testing, I found out that it does exactly the same as ConvertToYUY2()! Here is the two scripts I compared:

Code:
#RGB Clip
AVISource("test.avi")
PointResize(last.width*2,last.height*2)
ConvertBackToYUY2()
Code:
#RGB Clip
AVISource("test.avi")
PointResize(last.width*2,last.height*2)
ConvertToYUY2()
Now if I add the following two lines, ConvertBackToYUY2() seems to work:

Code:
ConvertToRGB()
ConvertBackToYUY2()
Here are the two scripts I compared:

Code:
#RGB Clip
AVISource("test.avi")
PointResize(last.width*2,last.height*2)
ConvertBackToYUY2()
ConvertToRGB()
ConvertBackToYUY2()
Code:
#RGB Clip
AVISource("test.avi")
PointResize(last.width*2,last.height*2)
ConvertToYUY2()
ConvertToRGB()
ConvertToYUY2()
It seems to me ConvertBackToYUY2() only works after ConvertToRGB(). Is this right? If this is true, is there any way I can convert to YUY2 without interpolating the chroma?
Aktan is offline   Reply With Quote
Old 15th January 2010, 04:00   #2  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
Why are you so worried about this?

You'll have to be in YV12 eventually, which means losing tons of chroma resolution.

Who cares though?

I'm not sure its possible to do what you want to do without interpolating any data.

~MiSfit
__________________
These are all my personal statements, not those of my employer :)
Blue_MiSfit is offline   Reply With Quote
Old 15th January 2010, 04:44   #3  |  Link
`Orum
Registered User
 
Join Date: Sep 2005
Posts: 178
I second Blue_MiSfit's comments. I don't know of a H.264 encoder that supports 4:4:4 (thought there are probably some, x264 doesn't). So just deal with the color loss or use a different codec...or wait til x264 gets 4:4:4 support (or write the patch yourself!).

This is a known annoyance in video that has high detail chroma planes, like video game captures.
__________________
My filters: DupStep | PointSize
`Orum is offline   Reply With Quote
Old 15th January 2010, 12:27   #4  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
Code:
AVISource("test.avi")
Info()
What colorspace does it state?
Wilbert is offline   Reply With Quote
Old 16th January 2010, 17:15   #5  |  Link
Aktan
Registered User
 
Join Date: Feb 2002
Posts: 303
Quote:
Originally Posted by Blue_MiSfit View Post
Why are you so worried about this?

You'll have to be in YV12 eventually, which means losing tons of chroma resolution.

Who cares though?

I'm not sure its possible to do what you want to do without interpolating any data.

~MiSfit
The colorloss won't be there if I resize it to 4x the original resolution. This means if no interpolating was done, there would be no colorloss at all since each pixel would cover 4 pixels now.

Last edited by Aktan; 16th January 2010 at 17:19.
Aktan is offline   Reply With Quote
Old 16th January 2010, 17:19   #6  |  Link
Aktan
Registered User
 
Join Date: Feb 2002
Posts: 303
Quote:
Originally Posted by wilbert View Post
what colorspace does it state?
rgb32
Aktan is offline   Reply With Quote
Old 17th January 2010, 21:43   #7  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,576
If your source is RGB and target is YV12 you don't need ConvertBackToYUY2()
AFAIK ConvertBackToYUY2() used only if you source was YUY2 to begin with, then you converted it to something inside the script and as output you need also YUY2
Keiyakusha is offline   Reply With Quote
Old 17th January 2010, 22:25   #8  |  Link
Aktan
Registered User
 
Join Date: Feb 2002
Posts: 303
Quote:
Originally Posted by Keiyakusha View Post
If your source is RGB and target is YV12 you don't need ConvertBackToYUY2()
AFAIK ConvertBackToYUY2() used only if you source was YUY2 to begin with, then you converted it to something inside the script and as output you need also YUY2
I use ConvertBackToYUY2() in order to avoid the interpolating of the chroma, as said in the first post. Looking at this URL: http://avisynth.org/mediawiki/Sampling will explain what I mean.
Aktan is offline   Reply With Quote
Old 17th January 2010, 22:33   #9  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,576
Quote:
Originally Posted by Aktan View Post
will explain what I mean.
Actually its not. Could you quote exact statement that shows how it helps in your case?
This function mentioned once under "RGB -> YUY2 conversion" This is not your case. And it doesn't helps to avoid interpolating, in makes it less noticeable.

Quote:
Originally Posted by from wiki
use ConvertBackToYUY2() to convert back to YUY2, when you applied a YUY2->RGB conversion prior to that in your script. This will reduce color-blurring, but there are still some precision lost
YUY2 is NOT the same as YV12

Such construction:
Quote:
ConvertBackToYUY2()
ConvertToRGB()
ConvertBackToYUY2()
Only makes loss of quality and the result will be converted internally in x264 if you feed this to it.

Last edited by Keiyakusha; 17th January 2010 at 22:37.
Keiyakusha is offline   Reply With Quote
Old 18th January 2010, 03:50   #10  |  Link
Aktan
Registered User
 
Join Date: Feb 2002
Posts: 303
here is all quoted from the same page:

"The other mode ConvertBackToYUY2 uses chroma from the left pixel, thus "

frame line
Y1C1 Y2 Y3C3 Y4 line 1
Y1C1 Y2 Y3C3 Y4 line 2
Y1C1 Y2 Y3C3 Y4 line 3
Y1C1 Y2 Y3C3 Y4 line 4



YUY2 -> YV12 progressive conversion :

frame lines weights
Y_Y_Y_Y line 1
C___C__ chroma of YUY2_lines (0.5)*1 + (0.5)*2
Y_Y_Y_Y line 2
Y_Y_Y_Y line 3
C___C__ chroma of YUY2_lines (0.5)*3 + (0.5)*4
Y_Y_Y_Y line 4

Thus if 1 pixel becomes 4 pixels, this is how it will look if using first ConvertBackToYUY2() then ConvertToYV12():

frame lines
Y1_Y1_Y2_Y2 line 1
C1___C2__
Y1_Y1_Y2_Y2 line 2
Y1_Y1_Y2_Y2 line 3
C1___C2__
Y1_Y1_Y2_Y2 line 4

Note: Formatting is terrible=/
Aktan is offline   Reply With Quote
Old 18th January 2010, 03:58   #11  |  Link
Aktan
Registered User
 
Join Date: Feb 2002
Posts: 303
Here, I'll trying to explain from start.

4 pixels:

Y1C1 Y2C2
Y3C3 Y4C4

PointResize(last.width*2,last.height*2):

Y1C1Y1C1 Y2C2Y2C2
Y1C1Y1C1 Y2C2Y2C2
Y3C3Y3C3 Y4C4Y4C4
Y3C3Y3C3 Y4C4Y4C4

ConvertBackToYUY2() (at least if it worked):

Y1C1Y1 Y2C2Y2
Y1C1Y1 Y2C2Y2
Y3C3Y3 Y4C4Y4
Y3C3Y3 Y4C4Y4

ConvertToYV12():

Y1Y1 Y2Y2
C1 C2
Y1Y1 Y2Y2
Y3Y3 Y4Y4
C3 C4
Y3Y3 Y4Y4

As you can see, there is no color loss per pixel anymore.

Last edited by Aktan; 18th January 2010 at 04:02.
Aktan is offline   Reply With Quote
Old 18th January 2010, 06:47   #12  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
ConvertBackToYUY2() is only for RGB to YUY2 conversions!

Anything else and you will get this error message "ConvertBackToYUY2: Use ConvertToYUY2 to convert non-RGB material to YUY2.".

It uses sampling of the left RGB pixel only to generate the chroma UV values and the left-hand Y value. The right RGB pixel is only used to calculate the right-hand Y value and has no influence on the resulting chroma values, i.e. the chroma is point resampled.


ConvertToYUY2() for RGB to YUY2 conversions uses the pure average of the left and right RGB pixels to generate the chroma UV values. This is technically wrong and results in a 0.5 pixel shift right of the chroma. This is original BenRG code and was used for performance reasons circa Pentium-MMX 166Mhz.


Conversions between YUY2 and YV12 for progressive are correct. There is a 50% additional loss in vertical chroma resolution going to YV12, both YV12 and YUY2 already have 50% horizontal chroma resolution implicit in the formats.


So yes pointresizing the RGB image by 2 first can maintain the original chroma resolution, but at some point before committing to H264 you will have to subsample the chroma as YV12.


Hint: Currently RGB to YV12 conversions are all via YUY2, so a performance gain can be obtained by deferring the vertical times 2 until the YUY2 to YV12 conversion, i.e.
Code:
# RGB Source
PointResize(Width()*2, Height())
ConvertBackToYUY2() # Left and Right pixels are the same, so use Left only.
PointResize(Width(), Height()*2)
ConvertToYV12()
...
Note: from 2.6 there is YV24 format than offers full chroma resolution.
IanB is offline   Reply With Quote
Old 18th January 2010, 10:50   #13  |  Link
juGGaKNot
Registered User
 
juGGaKNot's Avatar
 
Join Date: Feb 2008
Posts: 733
So pointresize by 2 to yuy2 will keep the full chroma and ConvertToYV12() from yuy2 will reduce it back to 50% ?

Same result if you just use ConvertToYV12() but faster ?

Avisynth 2.6 has ConvertToYV24() but x264 does not support it yet.

Right ?
__________________
Quote:
Originally Posted by Dark Shikari View Post
If they can beat x264 in visual quality on ordinary test clips without postprocessing, I'll eat my hat.
juGGaKNot is offline   Reply With Quote
Old 18th January 2010, 11:03   #14  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
I am not really sure why you think 2:1 subsampling the chroma is such a bad thing, all the popular domestic media formats do it. The ocular input for species Homo Sapien is far more restricted than 2:1 chroma subsampling. If you have an industrial application then perhaps you should be leaving the data in RGB format.
IanB is offline   Reply With Quote
Old 18th January 2010, 12:52   #15  |  Link
Aktan
Registered User
 
Join Date: Feb 2002
Posts: 303
Quote:
Originally Posted by IanB View Post
ConvertBackToYUY2() is only for RGB to YUY2 conversions!

Anything else and you will get this error message "ConvertBackToYUY2: Use ConvertToYUY2 to convert non-RGB material to YUY2.".

It uses sampling of the left RGB pixel only to generate the chroma UV values and the left-hand Y value. The right RGB pixel is only used to calculate the right-hand Y value and has no influence on the resulting chroma values, i.e. the chroma is point resampled.


ConvertToYUY2() for RGB to YUY2 conversions uses the pure average of the left and right RGB pixels to generate the chroma UV values. This is technically wrong and results in a 0.5 pixel shift right of the chroma. This is original BenRG code and was used for performance reasons circa Pentium-MMX 166Mhz.
That's the thing, my source is RGB32 and it seems
ConvertBackToYUY2() still causes a 0.5 pixel shift, i.e. it looks exactly the same as ConvertToYUY2()!

I know there is interpolating when converting back to RGB32 for display, so maybe that's the shift I'm seeing, but I was expecting to see a difference between ConvertBackToYUY2() and ConvertToYUY2(). When I checked, there was no difference. The only time I saw a difference was when I went from RGB -> YUY2 -> RGB -> YUY2. Then I noticed that ConvertBackToYUY2() seem to keep more color.

This is why I'm wondering if ConvertToRGB() sets some flag that ConvertBackToYUY2() checks before doing the sampling via just taking the left pixel chroma. Something like:

Code:
if (flag) {
convert with taking left pixel chroma
}
else {
call ConvertToYUY2()
}
I guess I should mention I am using version 2.58 of AviSynth.

Quote:
Originally Posted by IanB View Post
Hint: Currently RGB to YV12 conversions are all via YUY2, so a performance gain can be obtained by deferring the vertical times 2 until the YUY2 to YV12 conversion, i.e.
Thanks for the tip! It makes sense why that would be faster

Last edited by Aktan; 18th January 2010 at 13:00.
Aktan is offline   Reply With Quote
Old 18th January 2010, 13:07   #16  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: UK
Posts: 1,673
Quote:
Originally Posted by IanB View Post
I am not really sure why you think 2:1 subsampling the chroma is such a bad thing, all the popular domestic media formats do it. The ocular input for species Homo Sapien is far more restricted than 2:1 chroma subsampling.
If you think that taking RGB PC screen captures, and converting them to YV12, doesn't cause visible degradation because "ocular input for species Homo Sapien is far more restricted than 2:1 chroma subsampling", then can I respectfully suggest you go and look at the result - because to my eyes the degradation is clearly visible, and last time I checked I was "species Homo Sapien"!

Aktan - as you've found at one stage, whether the output looks like you expect depend on the output decoding / chroma upconversion.

Can a point resize to 4x resolution, convert to yv12, and then point resize down to "only" 2x resolution get what you want? Or does point resize happen to grab the interpolated chroma pixels by default?

Cheers,
David.
2Bdecided is offline   Reply With Quote
Old 18th January 2010, 13:38   #17  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by Aktan View Post
That's the thing, my source is RGB32 and it seems ConvertBackToYUY2() still causes a 0.5 pixel shift, i.e. it looks exactly the same as ConvertToYUY2()!
After a PointResize(width*2, height*2), ConvertBackToYUY2 will have the same result as ConvertToYUY2, since the two pixels in each relevant pair will be equal - hence taking the left pixel is the same as the average of the two.
Gavino is offline   Reply With Quote
Old 18th January 2010, 14:31   #18  |  Link
Aktan
Registered User
 
Join Date: Feb 2002
Posts: 303
Quote:
Originally Posted by Gavino View Post
After a PointResize(width*2, height*2), ConvertBackToYUY2 will have the same result as ConvertToYUY2, since the two pixels in each relevant pair will be equal - hence taking the left pixel is the same as the average of the two.
Hmm, that's an interesting point. If indeed that's how it is done as IanB said, then the http://avisynth.org/mediawiki/Sampling page is wrong. According to that page:

Code:
More about RGB -> YUV color conversions can be found here: Color Conversions. Recall the layout of a 4:4:4 encoded image
frame 	line
Y1C1 Y2C2 Y3C3 Y4C4 	line 1
Y1C1 Y2C2 Y3C3 Y4C4 	line 2
Y1C1 Y2C2 Y3C3 Y4C4 	line 3
Y1C1 Y2C2 Y3C3 Y4C4 	line 4

In AviSynth, the default mode is using a 1-2-1 kernel to interpolate chroma, that is

C1x = (C1+C1+C1+C2)/4 (C1 is used three times, since this is the border)
C3x = (C2+C3+C3+C4)/4
C5x = (C4+C5+C5+C6)/4

The 4:2:2 encoded image becomes
frame 	line
Y1C1x Y2 Y3C3x Y4 	line 1
Y1C1x Y2 Y3C3x Y4 	line 2
Y1C1x Y2 Y3C3x Y4 	line 3
Y1C1x Y2 Y3C3x Y4 	line 4
which is not the same as averaging just the left and right pixel.

Maybe I'll just go dig around in the source and pray it isn't in ASM
Aktan is offline   Reply With Quote
Old 18th January 2010, 14:37   #19  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
See this thread.
Gavino is offline   Reply With Quote
Old 18th January 2010, 14:39   #20  |  Link
Aktan
Registered User
 
Join Date: Feb 2002
Posts: 303
Quote:
Originally Posted by 2Bdecided View Post
Can a point resize to 4x resolution, convert to yv12, and then point resize down to "only" 2x resolution get what you want? Or does point resize happen to grab the interpolated chroma pixels by default?
I'm not sure what you mean. Just to clarify, the 4x resolution is 2x width and 2x height. If I were to resize down to 2x, which direction did you mean? I don't get a shift when I point resize to 4x resolution in RGB32. I only get a shift once I convert to YUY2, which is before the convert to YV12.
Aktan is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 08:51.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.