They may be slight but they are quite visible. Additionally, if I go and make the plugin, the differences created by it will be fully configurable, from slight to drastic.

For now, I am just requesting that people try it on an actual 601 fotage and watch the result on a 709 monitor, or if anyone still has a 601 monitor, try the opposite and let me know how it worked.

Adam

Checking "LUTs against real-world footage" is suboptimal way.

For the reason it's all bout mathematics. Pure math it is.
And any (non- precisely generated) footage is the thing that requres proof of being correct.
(You surely remember the fun with Canon's videos in times of 5Dm2 - they were in bt601 but every NLE was decoding them as bt709.)

======================================================================================
 

-- Naming convention: which display space is supposed to represent which source space.

You just can't get the confirmation you're on the right track from random footages.

To my mind, Vegas does really deserve it's native bt.709 <--> bt.601 converting plugin, since this operation is so... fundamental, to say so.

You just can't get the confirmation you're on the right track from random footages.

No, I suppose I can’t. But it was worth trying before getting into developing a plugin, which is much more involved than producing a LUT. At any rate, I’m not asking for random footage. I’m asking for people who have some traditional 601 footage and have both a 601 and a 709 monitor to view the footage on the 601 monitor, and to view the same footage processed by the Rec601ToRec709.cube LUT on their 709 monitor and tell me if they look the same (within reason), and perhaps do the opposite with their new 709 footage. I unfortunately moved around the world a lot and most of my footage is permanently lost 🙁, as is any of my old 609 equipment. Otherwise I’d just do the comparison myself.

As for the naming convention, Rec601ToRec709.cube takes a 601 source and converts it to 709, and Rec709ToRec601.cube does the opposite. At least the math says they do.

601 is standard def.

601 is standard def.

You might say that. The actual reason for the different recs is different monitor technology. Rec. 601 is based on the color response in the phosphors in the 1953 TV monitors. Rec. 709 is based on the color response of present-day monitors. So, even for just watching an old SD video on a modern HD monitor, converting the video from 601 to 709 should be beneficial, at least theoretically.

Well, the primaries in many dslrs, including all the early Canons and Nikon's, were flagged "incorrectly" as B.t. 601. No one made much of a fuss then.

Not sure converting SD to anything is beneficial.

Not sure converting SD to anything is beneficial.

😕 But I’m not pushing it on you. All I am asking is if someone properly equipped for it could test if it works the way I think (from the math and the theory) it does.

So far, I have only been able to test it on several photographs and on a screen cap. The 601 to 709 LUT makes everything warmer, the other one makes everything colder. That actually surprised me, so I’m wondering if that is the expected behavior, or if I’m doing it wrong. Once I have a plugin (assuming my health allows me to make one, as ever since my heart attack I’m just living from one day to the next, generally taking it easy).

What the 601-to-709 LUT does essentially, it converts an RGB image to YCbCr with the Rec. 601 factors (0.299, 0.587, 0.114), then converts that back from YCbCr to RGB with the Rec. 709 factors (0.2125, 0.7154, 0.0721). Except it does it all in one step using matrix math (well, the LUT is just a set of results precomputed that way, of course, but that is how the plugin would do it if anyone finds it useful).

I’m not even sure this technique should be properly thought of as the conversion from one standard to another, or if it is just a color effect. The plugin would then allow you to choose the three source factors and the three destination factors (even totally made up ones), and calculate the right matrix to convert from RGB to YCrCb using the source factors and from that to RGB using the destination factors, and then use the matrix to change the colors accordingly, and even animate it so the change can happen gradually over a number of frames.

http://www.belle-nuit.com/test-chart

Well, it seems I have found the answer to my question, and it is a no. That is, no, the algorithm I used was incorrect, so the LUTs do not do what I thought they were doing.

I figured it out by using a different video editor, one that allows you to convert RGB to YCrCb 601, and also allows you to convert YCrCb to RGB 709. I tried that and the result was much more subtle, just as Musicvid suggested (though I can still see that as beneficial).

So, there goes my theory, which was that if I multiply the source matrix by the inversion of the destination matrix, the resulting one matrix would allow me to do the conversion in one step. I am still puzzled why it does not work, but the observation has shown me it does not.

Thanks for everyone’s input.

Adam

http://www.belle-nuit.com/test-chart

Thanks, Nick!

OK, I think I have it figured out now, even though I find it confusing. If I swap the order of the multiplication of the matrices, that is if I multiply the inverse of the destination matrix by the source matrix, I end up with a single matrix, which seems to be doing the right conversion between the two color spaces (and yes, it is very subtle).

Here is the zip with the two new LUTs.

Here is a post I did from last year that details how to do 601 to 709 conversions. My interest grew out of the fact that Mercalli was using 601 coefficients rather than the correct 709 coefficients. AFAIK, it's still a problem, but as others have said, it's not that noticeable unless you look for it. Regardless you can use the channel converter in Vegas to make the corrections.

wwaag

https://www.vegascreativesoftware.info/us/forum/color-correct-clips-from-mercalli-standalone--101068/ 😉

I have just compared that to the matrix I calculated for my latest 709->601 LUT (included in my second Beta mentioned above), and it is:

0.9135,   0.0785804,  0.00791956
-0.105163,     1.17244, -0.0672766
0.00959559,  0.0323044, 0.9581

So pretty much the same, except not rounded.

P.S. I have just entered my matrix values into the Vegas Channel Blend. And even though it showed the numbers rounded as shown in the image here, internally it used my own values in the full precision as I entered them.

How do I know? I applied the Channel Blend to an entire track, then my (Beta 2) LUT on an exact copy of the same track (before applying the Channel Blend, of course), and I set the top one’s compositing mode first to subtract, then to difference, and finally to difference squared. In all of those cases I got a completely black composite output, indicating no difference between the two tracks, and, therefore, no difference between the use of the Channel Blend and the VisionColor LUT. But since Channel Blend is internal to Vegas, I saved it under the Rec. 709 to Rec. 601 label, so I can use it in the future.

It is 4 am here, so I’d like to go to bed. But in the morning I will do a similar comparison for the 601->709 matrices.

The more digits the better! 🙂🙂🙂

So, I did comparison within Vegas and I can positively confirm the process goes in the way I believe to be the right one 🙂
 

Tested your LUTs again.
I think your computations are perfect.
Well done, Red Prince!

And here is my 601->709 matrix:

1.0865,  -0.072433,       -0.014067
0.0966428,       0.844833,        0.0585243
-0.0141401,      -0.0277599,      1.0419

Again, it is a match, except mine has more decimal places.

Looks like you can roll out your 'Final Release' version ;-)
It seems to be not in a 'Beta' stage any longer ;-)

Cheers, Red Prince!

Thanks! I will be rather busy for the next seven days, but I will do it after that.

OK, you can download the final release from here.