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 Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 1st July 2007, 22:40   #1  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Change ConvertToRGB to consider display primaries

Hi,

I have a suggestion to this filter that would be great. Unfortunately, I don't have the skills to implement it myself. Maybe someone here could do it, it appears to be a simple thing.

I know this filter already considers the 601 and 709 colorspaces. But there is still a problem: the correct primaries of the display.

We can convert a video to RGB that was created with ITU.BT-709 colorspace, but the colors only will show correctly on screen if the display primaries are the ITU.BT-709 ones. The problem is there are several displays with different primaries, and when we display the video on it the colors are not correct.

I have done some math and realized that if we correct for the display primaries we could have the correct colors on screen. Since this correction is just a multiplication of the YUY2->RGB matrix and the correction matrix, this could be easily done in ConvertToRGB.

My idea is:
The user specifies the primaries color coordinates(red,green,blue and white point) and with this we can calculate the matrix for the correction. Multiply the correction matrix with the YUY2->RGB matrix. Convert YUY2 to RGB.

The primaries color coordinates could be obtained with a colorimeter.

The ideal solution is correcting the primaries in the display, but only some displays have this capability.

I could post my test files with the calculations I have performed if someone would like to look at it.

Thanks.
yesgrey is offline   Reply With Quote
Old 2nd July 2007, 00:04   #2  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
In 2.6 the YUV<->RGB conversion uses a generic matrix conversion. Currently it only has 2 matrices defined, I see no problem allowing a user specified matrix.
Code:
[R]   [.]   [. . .] * [Y U V]
[G] = [.] + [. . .] 
[B]   [.]   [. . .]
Also the Plugin ColorMatrix has some interesting options.
IanB is offline   Reply With Quote
Old 6th July 2007, 00:05   #3  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
I have seen ColorMatrix and noticed that it have some C code, and that the matrix coefficients are available. I will try play with it a little, but your idea of allowing a custom matrix is also good. The matrix needs to be calculated only once, so it's better to use math software for it instead of writing C code for all that stuff. I have written a little matlab program for it. I will let you know when I have some results.

Thanks.
yesgrey is offline   Reply With Quote
Old 15th September 2007, 18:03   #4  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Where could I see the 2.6 code for the YUV<->RGB conversion routines?

Thanks.
yesgrey is offline   Reply With Quote
Old 16th September 2007, 01:25   #5  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
http://avisynth2.cvs.sourceforge.net...v=avisynth_2_6

See convert_planar and convert_matrix, the code is a bit incestuous so you may need to look wider.
IanB is offline   Reply With Quote
Old 18th September 2007, 23:39   #6  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
IanB,
I have seen ColorMatrix but it doesn't fit what I need. It's for converting between different colorspaces but the final result is still in YUV.

What I am thinking is in correcting the RGB values to the display primaries colorspace. This conversion should be done after the YUV conversion. So, I would like to know if you still could add the option of a custom matrix for the conversion YUV->RGB.

There are two options:
-You simply add the possibility of a custom matrix for the YUV->RGB, which will be used instead of the BT.601/BT.709
-You keep the two options of YUV->RGB conversion BT.601 and BT.709, but create the possibility of giving a matrix for the RGB correction. Like this:
[RGB]disp = [RGB->RGBdisp] x [BT.709->RGB] x [YUV].
If we multiply the two matrices prior the conversion from YUV, there would be no processing penalty.

The first should be easier to do, but then the REC and PC modes should be given a different variable, so we could also use it with the custom matrix.

The second option doesn't need a different variable for REC and PC modes. In fact, we always have to consider the BT.601 or BT.709 matrix, and this way we could still use the REC and PC modes the way it is now.

Last edited by yesgrey; 18th September 2007 at 23:42.
yesgrey is offline   Reply With Quote
Old 19th September 2007, 07:26   #7  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
The engine is capable of
Code:
D = (S + A) * B + C
i.e.
[d]   ([s]   [a])   [b b b]   [c]
[d] = (|s| + |a|) * |b b b| + |c|
[d]   ([s]   [a])   [b b b]   [c]
So the easiest is to just allow the user to specify the 15 values.

I am not inclined to evaluate a user matrix times a standard matrix. If the standard matices are published then the user can use maple, etc, to generate the aggregate matrix.

However what might be more useful could be to specify K.red, K.blue, Max.Y, Min.Y, Max.uv and Min.Uv and generate the appropriate matrix.

I am almost certainly going to add this last function, at least internally, as there is currently some discrepancy and confusion with the current matrix values.
IanB is offline   Reply With Quote
Old 19th September 2007, 11:08   #8  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
If I am understanding correctly, we should supply A, B and C. For me it would be great and will solve all that everyone will ever need, because you are giving access for the entire engine.
There is one thing I did not understand: the equation should not be: D = B * (S + A) + C since B is a 3x3 matrix?

Quote:
Originally Posted by IanB View Post
However what might be more useful could be to specify K.red, K.blue, Max.Y, Min.Y, Max.uv and Min.Uv and generate the appropriate matrix.
Sorry, I did not understand this. Can you explain me which values are those?

Please update this thread after doing the changes of the code, so I could know it and get it.

Thanks.
yesgrey is offline   Reply With Quote
Old 19th September 2007, 22:34   #9  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Quote:
Originally Posted by yesgrey3 View Post
Sorry, I did not understand this. Can you explain me which values are those?
I already know. I have read a link posted by wilbert to the avisynth color conversions page and saw what you mean.

But the supply of K.red, K.blue, Max.Y, Min.Y, Max.uv and Min.Uv for calculating the matrix is only possible for the YUV<->RGB conversion. What I am thinking is calculating a matrix that performs the conversion to a RGB space with different primaries coordinates, which does not obbey the same rules. This matrix is calculated by the multiplication of the YUV->RGB matrix with the matrix to convert between RGB with different primaries (see colorFAQ n.20). So, if you don't add the possibility of specifying the 15 values as you suggested, it could not be done.

Another subject.
Watching the code of avisynth 2.6 file convert_planar.cpp, I think the matrix for YUV->RGB BT.709 is wrong. The values there are what came in the coloureq.pdf file, but if you calculate the values according the colorFAQ rules, the matrix is slightly different:
[1 0 1.5750]
[1 -0.1870 -0.4678]
[1 1.8558 0 ]

Best Regards
yesgrey is offline   Reply With Quote
Old 20th September 2007, 06:49   #10  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
Yes I thought they were wrong also, hence my comment about an internal routine to unambiguously calculate them. The give away is that the Blue V co-efficient is not exactly 0.5

And yes the engine is (Planar YV24) <-> (Interleaved RGB32) and as the code stands matrices A and C are mutually exclusive, i.e. you can only have one or the other.

With a small amount of hacking (Interleaved RGB32) <-> (Interleaved RGB32) would be possible.

Add a RFE on our SourceForge site for Avisynth2 to make sure this does not get forgotten, ref this thread.
IanB is offline   Reply With Quote
Old 20th September 2007, 13:44   #11  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Quote:
Originally Posted by IanB View Post
And yes the engine is (Planar YV24) <-> (Interleaved RGB32) and as the code stands matrices A and C are mutually exclusive, i.e. you can only have one or the other.
Yes, I looked at the code and noticed it. It makes sense, because you only need one at a time for the (Planar YV24) <-> (Interleaved RGB32) conversions.

Quote:
Originally Posted by IanB View Post
With a small amount of hacking (Interleaved RGB32) <-> (Interleaved RGB32) would be possible.
If you want, you could do it, but it's not necessary for what I am thinking. I only want to correct the RGB for a new RGB with a different set of primaries, and for that is enough multiplying RGB by a 3x3 matrix (colorFAQ n.20). With the current engine is already possible, i only need to pass the A and B matrices. See the example:
YUV->RGB
D = B * (S + A)
RGB->RGBdisplay
Ddisplay = T * D <=>
Ddisplay = T * B * (S + A) <=>
Ddisplay = (T * B) * (S + A)


Matrix A is the same in both situations. For calculating the matrix B in the second situation is just multiplying T and B matrices.

As you could see from above, is not necessary hacking the code for considering A and C matrices simultaneously. It's enough specifying the 12 values from A and B.

Unfortunatelly I am not very skilled at c++, I only know c, so I could not offer me to do it. Currently I am "hacking" the code simply by changing the B coefficients hardcoded with the ones I am calculating, but this is not a very friendly solution, because I need to build a custom avisynth.dll file for each combination I need, and changing between them accordingly... but it will works until somebody is able to do it. By the way, I have installed Avisynth 2.5.7 and then switch the avisynth.dll with the ones I am building. Is this the right way of doing it?

The RFE was added to your SourceForge site for Avisynth2.

Thank you very much.

Best Regards

Last edited by yesgrey; 20th September 2007 at 16:21.
yesgrey 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 13:53.


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