Log in

View Full Version : color correction


freelock7
25th May 2004, 17:11
I have a problem about color saturation ( red overflow) with DVD PAL MPEG2 encoding:

LoadPlugin("C:\Program Files\AviSynth 2.5\MPEG2Dec3.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\asharp.dll")
mpeg2source("C:\Mes documents\tanguy.d2v",cpu=2)
asharp()
#VBR:min:2000-max:9000

What kind of sharpen filter may I use to keep original colors?-I use QuEnc0.51.
Is it possible to encode movie without colors correction?
Is Asharp able to degrade color quality with this setting?
Could Xsharpen, awarsharp or Msharpen be better in color conversion?


Thanks for help!

rfmmars
26th May 2004, 01:27
Since nobody has replied to your post it sounds like that the sharping is being applied to both the color and luminence signal.

I have not use Asharp but have used many other sharping filters without affecting the color.

Hold on, I am sure somebody will respond with the solution.

richard
www.photorecall.net

Guest
26th May 2004, 02:20
Originally posted by freelock7
Could Xsharpen, awarpsharp or Msharpen be better in color conversion? Why don't you try them and find out!?

freelock7
27th May 2004, 08:59
Thank you for response...
I tried and found these conclusions:
1)Using TMPGenc I needed to convert to RGB. The problem is there. Color conversion from native DVD format (YUV12)is always the wrong way to keep original colors.
The best way is to NOT convert at the end of the avisynth script in RGB or in YUY2.
2)asharp works in YUV space color on luminance only and makes no dammage in chrominance.
Knowing that I'll probably obtain best accurate results in future. I have to test more movies to affirm it's right.
(To be continued)

Wilbert
27th May 2004, 09:22
1)Using TMPGenc I needed to convert to RGB. The problem is there. Color conversion from native DVD format (YUV12) is always the wrong way to keep original colors. The best way is to NOT convert at the end of the avisynth script in RGB or in YUY2.
Somehow, I don't believe this. Can you upload a small part of the vob (where the problem occurs) somewhere?

ps, it's YV12.

Boulder
28th May 2004, 06:27
IIRC, TMPGEnc itself will convert internally to RGB24 so you can't avoid it in either way. I suspect that there's something wrong with the program settings - and didn't TMPGEnc have a color issue with certain systems (the fix was on sh0dan's page some time ago)?

freelock7
28th May 2004, 20:30
To Wilbert:
Why not?
1)Working in YV12 space is better than RGB, no?
"So basically YUV stores more relevant data at a lower accuracy than RGB.This is important because when you convert between the two colorspaces, either you lose some data, or assumptions ..."
From:
http://www.animemusicvideos.org/guides/avtech/colorspace.html

2)HELIX Yv12 codec
This codec works fine with TMPGenc without conversion at the end of the script.
take a look at:http://forum.doom9.org/showthread.php?s=&threadid=56972&highlight=color+problem
I don't know if it influence TMPgenc encoding quality.
See the question to karl_lillevold at this thread.

Wilbert
28th May 2004, 20:40
1)Working in YV12 space is better than RGB, no?
In this case yes (depends on source, and target).

My point is that it shouldn't matter whether the conversion YV12->RGB is done by some external codec, or in AviSynth itself (in the last line). (Assuming source is progressive.)

trevlac
28th May 2004, 22:01
Originally posted by freelock7
1)Working in YV12 space is better than RGB, no?
"So basically YUV stores more relevant data at a lower accuracy than RGB.This is important because when you convert between the two colorspaces, either you lose some data, or assumptions ..."
From:
http://www.animemusicvideos.org/guides/avtech/colorspace.html

2)HELIX Yv12 codec
This codec works fine with TMPGenc without conversion at the end of the script.
take a look at:http://forum.doom9.org/showthread.php?s=&threadid=56972&highlight=color+problem
I don't know if it influence TMPgenc encoding quality.
See the question to karl_lillevold at this thread.

I've wanted to comment on this for a while, but have generally kept my mouth shut. :)

But here goes ....

YUV 4:4:4 to RGB conversion and back is virtually lossless at 8-bit. At 10bit, i believe it is completely lossless.

So the issue is converting from 4:4:4 to 4:2:0. This process of subsampling is a resize filter that basically removes high frequency detail (blurs).

So, if you are starting with 4:2:0, you have already blurred the chroma. I believe the link you posted compared an original 4:4:4 to a 4:2:0. The down size did a blur. You should compare a 4:2:0 to a 4:2:0->4:4:4. Very hard to find such a compare. This is because if you are looking at it, it is in RGB. So it is hard to seperate what does the blur... putting it in 4:2:0 or getting it back out.

1st Question: How much does an upsize 4:2:0->4:4:4 blur? Well, depending upon how the chroma is resized (and assuming progressive source), very little. So little that i'd bet no one could tell on a single resize. I've a bunch of tests if you would like to see.

2nd Question: If you keep converting back and forth, can you see the blur? No doubt.

3rd Question: Can you use TMPGEnc without something converting to RGB? No. As Wilbert is trying to point out.

4th Question: Why is YV12 better than RGB? Well it certainly isn't because it can contain more info (detail). In fact, it is better for the opposite reason. It contains less data so it is faster to work with and takes up less space. ~ by a factor of 2.

Sorry for the rant ... but I get a bit tired of the RGB is bad thing without any logic applied. ;) I'm waiting for the flames ... :scared:

[edit]

PS: On your comment that working in luma does not effect red. Luma is made of Red+Green+Blue. Increasing the luma on a red pixel will in fact make the red brighter and might push it off the scale (clip it).

freelock7
9th June 2004, 07:02
the color problem seems to be corrected .
Now I use helix codec and unfilter in my avisynth script better than asharp.

Soulhunter
9th June 2004, 18:16
Originally posted by trevlac
1st Question: How much does an upsize 4:2:0->4:4:4 blur? Well, depending upon how the chroma is resized (and assuming progressive source), very little. So little that i'd bet no one could tell on a single resize. I've a bunch of tests if you would like to see.
AFAIK, AviSynth uses bilinear upsampling for the chroma (same as VMR9) !!!


Bye

trevlac
9th June 2004, 21:07
Originally posted by Soulhunter
AFAIK, AviSynth uses bilinear upsampling for the chroma (same as VMR9) !!!


Hi,

It does indead. Question is, can you tell the difference between that and say a Lanczos on 1 resize. PS: It is not fair to compare it to original RGB. The down size to 4:2:0 does the damage.

http://virtualdub.everwicked.com/index.php?act=ST&f=5&t=6909&st=0

There are some tests on 4:2:2. :)

Soulhunter
10th June 2004, 17:11
Originally posted by trevlac
Question is, can you tell the difference between that and say a Lanczos on 1 resize.Not sure... :rolleyes:

But its easy to see the difference to a "pixel doubling" that old renderer's are using !!!


Bye