Help ColorYUV

[alemala]

I'm not able to see working the gamma_u and gamma_v parameters.

Here follows my script:
<<<
avisource("F:\Videoediting\lavorazione\adios con la familia.avi").converttoyuy2
stackHorizontal(last.colorYUV( gamma_u=50 ) , LAST.colorYUV( gamma_u=-50 ))
>>>
but nothing seems to change.
If I change gamma_y it works.

I try the version 2.56 and the last released alfa version.

Doe's sombody has an idea.
Thanks, Alessandro.

PS:
on my site you can find a new color correction filter for
virtualdub (LrgbColorAdjust):

web.tiscali.it/minomala

edit mod: corrected url to your homepage :)

[IanB]

@alemala,

Hmmm, the code does nothing with U or V gamma values.

Perhaps you would like to propose a suitable algorithm to implement this.for (int i=0; i < 256; i++) {
double v = (i - 128)/112.0; // -1 <= v <= 1

v = Proposed_Chroma_Gamma_Function(v, gamma);

int iv = int(v * 112.0) + 128;
if (iv > 240) iv = 240;
if (iv < 16) iv = 16;
LUT_V[i] = iv;
}Don't forget u and v will be negative and pow(-0.123, k) does not work!

[alemala]

I think You can use the same algorithm You use for gamma_y

that should be something like:

assuming:
gamma_corr between (let's say) 0.7 and 1.3
and 0<y<255

new_y = pow ((y/255.0), gamma_corr ) * 255.0

I normally (for VHS) adjust colors setting:

correction = 5
ColorYUV(off_u=-correction , cont_u=correction)

That shoud give (more or less) the same effect as decreasing gamma.

Thanks, Alessandro.

[foxyshadis]

If you ever want to test out your ideas, you can always use
mt_lut("255.0 x 255.0 / "+gamma+" ^ *",chroma="process")
Somehow I'm not sure this is the effect you're trying to achieve, but it is an interesting effect... I don't think any chroma-only process could legitimately be called "gamma" since it's so tied into lumanince. It could be the same formula, but it no longer is a gamma change.

[IanB]

@alemala,new_y = pow ((y/255.0), gamma_corr ) * 255.0Very definitly not! This would lead to lopsidedness in the chroma signal, 128 is zero chroma.Don't forget u and v will be negative ...Read my pseudo-code fragment again.

Try thinking about U and V in a polar coordinate system where R represents the saturation and Angle represents the Hue.

One solution is NewChroma = pow(Chroma+Luma, Gamma) - Luma but which Luma do you use, pre-corrected, post-corrected or add pre-corrected and subtract post-corrected.

Another solution is NewChroma = pow(abs(Chroma), Gamma) * sign(Chroma)

Both of these solution have hairs on them, maybe someone can propose some other alternatives.

[alemala]

I don't know so much about YUV encoding but U and V, should have a zero somewhere:
Assuming it (chroma) ranges from -128 up to 127, it could be something like:
chr = chroma + 128
new_chroma = (pow ((chr/255.0), gamma_corr ) * 255.0) -128

This should move mid chroma values to green, without affecting low and high values. And could be seen as a gamma correction of the "logical" signal carrying the u and v information.

Can it be ?

Alessandro.

[IanB]

You seem very intent on moving the UV zero point in all of your suggestions so far. Perhaps we should not be talking about GAMMA but talking about some other attribute that I guess seems to be related to white balance or white reference.

Do not worry how U and V are stored in a pixel. Think only about normalized values, i.e -1 < U < +1, -1 < V < +1, with U=V=0 being black, gray, white i.e. no colour.U V Colour
-1 -1 Green
-1 0 Yellow
-1 +1 Orange
0 -1 Blue Green
0 0 Grey
0 +1 Mauve
+1 -1 Light Blue
+1 0 Blue
+1 +1 Magenta

[alemala]

Well, now I think I was right !

May be I need it cause I work the most with analogue sources: capture VHS recorded on different (some times bad) hardware equipment, low quality VHS tapes, different colours registration due to different VHS manufacturers.
So, suppose I have film capture which is green, I can recover using
ColorYUV(off_u=10,off_v=10)
By doing that I will loose (overflow) mauve and blue “upper values”.
That (sort of) “gamma correction” will do the job: gradually move the greens pixel to grey while keeping all the colours (and “I” think it strictly relates to signal processing in the analogue world).

In RGB encoding too, changing the gamma of a single channel (red, green or blue) affects the "white balance" and, any case, that is what we need to correct colours.

Alessandro.

[IanB]

Okay, now with a little background I understand what you want and like I guessed it is nothing to do with gamma. You want to process the U and/or V channels with a power function just like the one used for gamma. A trickey but reasonable thing to do.

This script will do what you want:-AviSource("blah.avi")
V=VtoY().ColorYUV(gamma_y=1.2) # bend red-green
U=UtoY().ColorYUV(gamma_y=0.8) # bend yellow-blue
YtoUV(U, V, Last)You will have to experiment to find the right "gamma_y" values fix each dodgy capture.

Would being able to load the 256 element mapping translation tables from a text file be a useful filter. You could generate a CSV file in Excel for example to have what ever weird curve is required.

[alemala]

Well that is not the problem, i can code myself a filter to do whatever I like.

As you can see on my site I wrote an RGB filter that corrects GAMMA separately for red, green, and blue channels and I had many feedback from professional users used to such correction in professional equipments and happy to see it implemented in pubblic domain and non professional video processing applications.

I saw around many script and discussion about your gamma_u and gamma_v parameters:
I make software since 25-year, the minimal thing will be to remove them from the ColourYUV filter and from the manual but I know you will not remove them. It seems like you will win this discussion but that is not the problem and further more I think this is not the right way to approach pubblic domain software development. :-)

It's a long way ....
.. and I will not reply any more !

Alessandro.

[IanB]

Alessandro,

I am very sorry if you feel offended by my forthright expression of my views. I am just seeking to gather all of the information about the issue before jumping into code that may have bad side effects.

I very much appreciate that you pointed out that there was missing code for gamma_u and gamma_v. At the very least the documentation will be updated to reflect this. Also your idea to use a power function to "tune" the white point of a YUV clip has a lot of merit, watch for a function that implements this in the future.

Okay now the logic part of this post.ColorYUV(gamma_y=1.2, gamma_u=1.2, gamma_v=1.2)When implemeted correctly should be identical toConvertToRGB().Levels(0, 1.2, 255, 0, 255).ConvertBackToYUY2()orConvertToRGB().RGBAdjust(rg=1.2, gg=1.2, bg=1.2).ConvertBackToYUY2()None of your or my suggestions or the current implementation achieve this.

At this point we probably should open a new thread in the developer forum and discuss how to correctly implement this functionality.

[Fizick]

But what about this Levels documentation (by Ben?):
[qoute]
When processing data in YUV mode, Levels only gamma-corrects the luma information, not the chroma. Gamma correction is really an RGB concept, and I don't know how to do it properly in YUV.
[/quote]

May be do not create new thread, can moderator move whole this topic to "development"?

[IanB]

Ah! We have been moved, thanks!

@Fizick, Yes having briefly thought about and discussed this I can see that this is indeed a very tricky thing to do.

It is easy to analysis the case when all channels gamma are the same value, the hard part is choosing the most usefull effect when they are not the same. The other difficulty is writing a fast implementation, in all the obvious mappings the output is dependant on the luma value as well.

[Wilbert]

Can't you start with the gamma in RGB space, ie r^g', with g'=1/g. Linearize it about g'=1, thus

r^g' -> r + r*log(r)*(g'-1)

and work out what that means for Y, Cb, Cr (use some LUTs for r*log(r))? It all works linearily, so you should get some nice formula.

[alemala]

The best suggestion it's always keep it simple !!! ...

I think the advantage of haveing an exponential chroma correction in YUV is that luminance will not change.
I think it should change the "zero point" ( as off_u, off_v ) whitout affecting (so much) the luminance and the overall colour distribution.

Bye, Alessandro.

[Mug Funky]

an "s" curve could be a nice effect, but wouldn't be gamma as we know it, more a sort of soft-clamped saturation increase. i've tried it in photoshop and it can be useful, but increasing saturation is almost perceptually identical.

[IanB]

An "S" curve like this?NewChroma = pow(abs(Chroma), Gamma) * sign(Chroma)I guess the reason I am hesitant to do something is none of these functions are Gamma. I agree the power function Alessandro wants and an "S" curve will be extremely useful, but they are nothing to do with Gamma, hence the aversion to dumping any code behind the Gamma_u/v arguments that is not strictly Gamma.

Also there is already the spline function code in the script language which I believe will make an excelent basis for a general channel remapping function in 2.6.

[alemala]

It is interesting too, why not implementing booth of them !!! ....
:p