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 > General > Newbies

Reply
 
Thread Tools Search this Thread Display Modes
Old 21st April 2012, 04:04   #1  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,151
Will there be quality loss for YV12-> RGB32 -> YV12 colorspace conversion?

if there is, will it be visible or just some mathematical rounding difference
lansing is offline   Reply With Quote
Old 21st April 2012, 15:51   #2  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,936
Yes, visibile quality loss

Whether or not you see it depends on many factors including the viewer and the type of content

Deterioration is more visible on things like graphics (like titles), anime , or content that has clear crisp color borders to begin with - there will be blurring
poisondeathray is offline   Reply With Quote
Old 21st April 2012, 16:12   #3  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,478
He's doing YV12-> RGB32 -> YV12, not RGB32 -> YV12 -> RGB32.
sneaker_ger is offline   Reply With Quote
Old 21st April 2012, 16:53   #4  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,936
Quote:
Originally Posted by sneaker_ger View Post
He's doing YV12-> RGB32 -> YV12, not RGB32 -> YV12 -> RGB32.
Yes, there is still loss

Have you ever tried redoing a DVD menu or titles in an RGB program like photoshop, AE, video editors, ... etc? . It deteriorates noticably, edges becomes blurry, even before using lossy compression. It's due to color model (colorspace) conversion - the color information is upscaled then downscaled.

Other types of content, like fast moving live action, you typically won't notice unless you zoom in and go frame by frame
poisondeathray is offline   Reply With Quote
Old 21st April 2012, 16:59   #5  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,478
There may be rounding errors in the color conversions, but the chroma up- and downscaling can be lossless depending on the algorithm. If I use pointresize(), it's lossless. So it does not have to result in any blurriness.
sneaker_ger is offline   Reply With Quote
Old 21st April 2012, 17:10   #6  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,936
Quote:
There may be rounding errors in the color conversions, but the chroma up- and downscaling can be lossless depending on the algorithm. If I use pointresize(), it's lossless. So it does not have to result in any blurriness.
Are you using ConvertToRGB(matrix="Rec601", interlaced=false, chromaresample="point") , (and back to YV12 using same thing) ?
or using some other chroma resampling method?

If you have time, here is a test video from a DVD menu for you . (The goal was to redo the text animating on, but the reason is not important). It's really an almost worst case scenario, because of thin red text.

Using "normal" ConvertToRGB.ConvertToYV12 routine (and then ConvertToRGB for the screenshot) . It's similar result in other programs which use slightly different chroma sampling methods


Comparisons:
Original YV12 (and RGB for screenshot)
http://i40.tinypic.com/1zofcjp.png

YV12=>RGB=>YV12 (and RGB for screenshot)
http://i40.tinypic.com/348ivbo.png

original .m2v
http://www.mediafire.com/?52xp6d7p5881fvo

Last edited by poisondeathray; 21st April 2012 at 17:15.
poisondeathray is offline   Reply With Quote
Old 21st April 2012, 17:16   #7  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,478
He didn't mention AviSynth or any specific algorithm.
sneaker_ger is offline   Reply With Quote
Old 21st April 2012, 17:17   #8  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,936
Quote:
Originally Posted by sneaker_ger View Post
He didn't mention AviSynth or any specific algorithm.
But you claimed it could be done without blurriness, so I'm interested in the how to do it (with any program)?
poisondeathray is offline   Reply With Quote
Old 21st April 2012, 17:23   #9  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,478
Untested:
ConvertToYV12(chromaresample="point")
ConvertToRGB32(chromaresample="point")
sneaker_ger is offline   Reply With Quote
Old 21st April 2012, 17:32   #10  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,936
Quote:
Originally Posted by sneaker_ger View Post
Untested:
ConvertToYV12(chromaresample="point")
ConvertToRGB32(chromaresample="point")
Well I did test these before (and the other sampling methods), and for a YV12 source it should be:

ConvertToRGB32(chromaresample="point")
ConvertToYV12(chromaresample="point")

(and back to RGB , for consistency of the screenshots, I used same default ConvertToRGB() for the screenshot, which uses Bicubic in avisynth 2.6)

http://i41.tinypic.com/15dtlcz.png
Still some blurring - and introduces aliasing
poisondeathray is offline   Reply With Quote
Old 21st April 2012, 17:52   #11  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,478
I don't know where that error comes from. If you upscale using PointResize by factor 2 and downscale by factor 2 again, you get the same result. Either chromaresample="point" does not do what I think it does, or it has something to do with the MPEG-2-chroma-placement. Will try to make a test to reproduce the issue myself, but I stand by my original statement that this is algorithm dependent and it is possible to do it without additional blurriness, but not without color skewing (putting some edge cases aside).
sneaker_ger is offline   Reply With Quote
Old 21st April 2012, 17:57   #12  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,936
Quote:
Originally Posted by sneaker_ger View Post
I don't know where that error comes from. If you upscale using PointResize by factor 2 and downscale by factor 2 again, you get the same result. Either chromaresample="point" does not do what I think it does, or it has something to do with the MPEG-2-chroma-placement. Will try to make a test to reproduce the issue myself, but I stand by my original statement that this is algorithm dependent and it is possible to do it without additional blurriness, but not without color skewing (putting some edge cases aside).
There was some discusion here about whether or not "PointResize" in avisynth was true nearest neighbor
http://forum.doom9.org/showthread.php?p=1569907

On a practical level, this loss occurs, even in other programs that use "nearest neighbor" - so how do it without bluriness or other detrimental effets like aliased edges in any program???

You can use the YV12 mpeg2 clip provided above in the mediafire link as a test example

Last edited by poisondeathray; 21st April 2012 at 18:00.
poisondeathray is offline   Reply With Quote
Old 21st April 2012, 18:04   #13  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,478
Quote:
Originally Posted by poisondeathray View Post
You can use the YV12 mpeg2 clip provided above in the mediafire link as a test example
Yes, you are correct. I tested it with your sample and it looks horrible, indeed.
sneaker_ger is offline   Reply With Quote
Old 22nd April 2012, 02:37   #14  |  Link
natt
Registered User
 
Join Date: Mar 2012
Posts: 10
yv12->yv24->yv12 can be lossless with pointresample of chroma, provided the algorithm is correct. avisynth's yv12->yv24 with chromaresample=point is rather incorrect.

Consider a set of 4 luma samples in 4:2:0. Place them on a coordinate plane with the top left one at (0, 0) and the bottom right one at (1, 1).

So MPEG1 chroma is (0.5, 0.5), and MPEG2 chroma is (0, 0.5).

Avisynth's yv24->yv12 chromaresample=point uses chromaloc (0,0). Due to the limitations of point resize, only luma cosited chroma is possible. This is ok.

Avisynth's yv12->yv24 chromaresample=point uses chromaloc (1.5, 1.5) for MPEG1, and chromaloc (0.5, 1.5) for MPEG2. This is wrong and makes no sense at all. MPEG1 can be exactly represented at (0.5, 0.5), and MPEG2 can be better represented with either (0.5, 0.5) or (-0.5, 0.5).

Using a correct MPEG1 yv12->yv24 would allow yv12->yv24->yv12 to be lossless.

Last edited by natt; 22nd April 2012 at 02:43.
natt is offline   Reply With Quote
Old 22nd April 2012, 19:49   #15  |  Link
TheSkiller
Registered User
 
Join Date: Dec 2007
Location: Germany
Posts: 637
Thanks natt, I have wondered why RGB<->YV24 conversions were not lossless color wise using chromaresample=point - now I know why.

However, I'm not sure though and can't test it now but if memory serves me right there also was something fishy going on if doing an (interlaced) YV12<->YUY2/YV16 conversion using pointresize, meaning converting back and forth is not lossless as one would expect.
TheSkiller is offline   Reply With Quote
Old 22nd April 2012, 20:19   #16  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,936
Quote:
Originally Posted by TheSkiller View Post
Thanks natt, I have wondered why RGB<->YV24 conversions were not lossless color wise using chromaresample=point - now I know why.

However, I'm not sure though and can't test it now but if memory serves me right there also was something fishy going on if doing an (interlaced) YV12<->YUY2/YV16 conversion using pointresize, meaning converting back and forth is not lossless as one would expect.
But Natt was referring specifically to Y'CbCr conversions (YV12<=>YV24), not RGB<=>Y'CbCr conversions like the OP was referring to.

Y'CbCr <=> RGB conversions are lossy for other reasons beside chroma sampling. Y'CbCr and RGB are non overlapping color models. You can have out of range gamut even with Rec1361 wide gamut RGB transfer function. Also there are rounding errors - worse when the calculations are done in 8-bit. So even if you disregard chroma up/downscaling algorithms there are other reasons for loss

In practical terms, many programs use RGB/A internally, but very few use Y'CbCr 4:2:0 , and even fewer Y'CbCr 4:4:4. So it would benefit many people to find optimal way with minimal losses for Y'CbCr <=> RGB conversions. Right now you choose trade offs between chroma blurring vs aliasing and "blocky" color edges.
poisondeathray is offline   Reply With Quote
Old 22nd April 2012, 21:53   #17  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,383
Quote:
Originally Posted by natt View Post
yv12->yv24->yv12 can be lossless with pointresample of chroma, provided the algorithm is correct. avisynth's yv12->yv24 with chromaresample=point is rather incorrect.
Agreed it can be lossless with the appropriate algorithm, but it's debatable whether Avisynth's behaviour is incorrect (rather than simply not appropriate for this purpose).

It is consistent with the way PointResize works, which is to use, for each output pixel, the nearest source pixel looking above and to the left (hence not strictly 'nearest' neighbour, as it ignores nearer pixels below or to the right).
However, the effect is that YV12->YV24->YV12 using chromaresample="point" introduces a chroma shift.
But, as the original pixels are still preserved in YV24 (just in the 'wrong' place), this can be corrected by shifting them back before reconversion to YV12.

Thus,
Code:
ConvertToYV24(chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1)) # mpeg2
# or MergeChroma(PointResize(width, height, 1, 1)) for mpeg1
ConvertToYV12(chromaresample="point")
is completely lossless.

See also posts #284-290 of this thread.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 23rd April 2012, 06:16   #18  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,151
Quote:
Originally Posted by poisondeathray View Post
Well I did test these before
ConvertToRGB32(chromaresample="point")
ConvertToYV12(chromaresample="point")
So this way is the closest to a lossless conversion I can get from a YV12->RGB32->YV12 ?


I'm trying to use neat video with avisynth plugins. I tried to load it as a plugin in an avs, but it requires a converttoRGB32 before that.
lansing is offline   Reply With Quote
Old 23rd April 2012, 10:16   #19  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,383
Quote:
Originally Posted by lansing View Post
So this way is the closest to a lossless conversion I can get from a YV12->RGB32->YV12 ?
Since YV12<->RGB32 goes via YV24, this also gives rise to an effective chroma shift as I described above. To avoid this, do the conversion explicitly to YV24 and shift the chroma back before the conversion to RGB32.
Code:
ConvertToYV24(chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1))
ConvertToRGB32()
... # filtering in RGB32
ConvertToYV12(chromaresample="point")
Then the only losses come from the YUV/RGB conversion (rounding, etc, as described by poisondeathray).
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 23rd April 2012, 15:52   #20  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,151
Quote:
Originally Posted by Gavino View Post
Since YV12<->RGB32 goes via YV24, this also gives rise to an effective chroma shift as I described above. To avoid this, do the conversion explicitly to YV24 and shift the chroma back before the conversion to RGB32.
Code:
ConvertToYV24(chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1))
ConvertToRGB32()
... # filtering in RGB32
ConvertToYV12(chromaresample="point")
Then the only losses come from the YUV/RGB conversion (rounding, etc, as described by poisondeathray).
thanks for the help to all of you guys

And one more thing, if i ran neat video in virtualdub and output the result as lagarith lossless in YV12, before putting it into avs, will i get the same result as the avs conversion above?
lansing is offline   Reply With Quote
Reply

Tags
colorspace conversion, quality, rgb32, yv12

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 15:18.


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