or open with Wordpad - that can help.

Here is another matrix that may become quite useful soon:

Convert 709 (HDTV) to 2020 (UHDTV):

    0.9498, 0.0456039, 0.00459609
    -0.0543343, 1.03836, 0.0159787
    -0.00293135, -0.00986865, 1.0128

Though I have to say, I haven’t really tested it yet because I have no idea what UHDTV looks like. But theoretically, it should be the right matrix.

or open with Wordpad - that can help.

It will help him to see the proper line endings, but will display UTF-8 characters as junk. I’m surprised not every Windows user has Notepad++. It is a free replacement for Notepad and is what Notepad should be in this century.

I use Notepad++ (although I tend to use SciTE for coding), but if I'm just opening a .txt to read I still let it open in regular Windows Notepad for minimal chrome and overhead.

Well, then, open this one in N++. 😄

Here is another matrix that may become quite useful soon:

Convert 709 (HDTV) to 2020 (UHDTV):

    0.9498, 0.0456039, 0.00459609
    -0.0543343, 1.03836, 0.0159787
    -0.00293135, -0.00986865, 1.0128

And its inverse:

Convert 2020 (UHDTV) to 709 (HDTV):

    1.0502, -0.0461625, -0.00403752
    0.054899, 0.960504, -0.0154028
    0.00357453, 0.00922547, 0.9872

The difference between 709 and 2020 is barely noticable, it, however, is clearly seen when applied to the Belle Nuit Test Chart that Nick Hope had kindly brought to my attention.

Woah!

Great supplementary text!

Thank you, Sir Adam!

You’re welcome. 😁

FYI, this year yet another Recommendation came out, Rec. 2100. Since it uses the same luma cofficients as Rec.2020, the exact same matrices apply to Rec.2100 as to Rec. 2020.

May I propose something to the Vegas programming team? Specifically for the Channel Blend VFX?

While this is not always the case, many matrix effects can be reversed by inverting the matrix (i.e., by calculating the inverse of the matrix).

So,for example, we have seen the 709->601 matrix is the inverse of the 601->709 matrix (and vice versa). And the 2020->709 matrix is the inverse of the 709->2020 matrix.

My proposal then is, add an option in the Channel Blend to calculate the inverse of what the current matrix is. And even allow us to save the inverse as a new preset, so we only need to calculate it once. That would an extremely valuable feature.

Yes, I’m well aware that not every matrix is invertible. Specifically any matrix whose determinant equals zero is non-invertible (unless we want to use complex numbers, which, in this case, we usually don’t).

Now, I certainly can calculate the inverse of just about any invertable matrix. But not everyone can, nor should they have to. That said, surely Vegas programmers know how to test whether a matrix is invertible, and how to invert it if it is.

Everybody else can read about it here. 😎

Here is another matrix that may become quite useful soon:

Convert 709 (HDTV) to 2020 (UHDTV):

    0.9498, 0.0456039, 0.00459609
    -0.0543343, 1.03836, 0.0159787
    -0.00293135, -0.00986865, 1.0128

Though I have to say, I haven’t really tested it yet because I have no idea what UHDTV looks like. But theoretically, it should be the right matrix.

BT.2020 uses different primaries from BT.709. You can't convert with just a matrix. First the OETF needs to be inverted to get linear values.

Vegas converts YCbCr-encoded video to RGB using either the BT.601 matrix or the BT.709 matrix based on several factors, including the format of the video and its resolution. The project properties might also factor in. My tests were all based on a 1920 x 1080 project.

• .MP4 H.264 files, for example, are always read with the BT.709 matrix.
• .MPG MPEG-1/2 files are read with the BT.709 matrix when the resolution is higher than 1358 x 764, and with the BT.601 matrix when the resolution is lower.

My findings for Vegas Pro 10 are summarized in a table at this page: http://www.personal-view.com/faqs/software/sony-vegas-pro I believe most of those findings still apply in Vegas Pro 14, with the possible exception of .MOV files, now that Vegas can read many of them natively.

These matrices are only for how conversions between YCbCr and RGB are performed. BT.601 and BT.709 also differ in the display primaries used. You can't convert between primaries with just a matrix. To correct for the different primaries, the OETF must first be inverted to linearize the color space.

709 matrix should kick in when the rez = 720 width not 764.

. You can't convert between primaries with just a matrix.

Oh. Yes. I. Can.

Above are two samples of matrices performing conversions between sRGB gamut and Adobe RGB 1998 gamut which was born SMPTE-240M back then as a projected colorspace for "future HD television". But the price for wide-gamut displays was high, so HD television ended up with sRGB gamut (plus different gamma) and SMPTE-240M was given to Adobe, who did happily call it the brand-new marvelous Adobe RGB 1998.

(No, I don't feel like willing to give away the maths behind the construction of those matrices right now, but it is published in the internet, where I found it years ago.)

_______________________________________________________________________________
( 😂 Want to start understanding the Color Management? - Buy yourself a wide-gamut monitor! 😂.)

First the OETF needs to be inverted to get linear values.

Conversion to linear values should be done automatically for you if you edit in 32-bit floating point (full range) linear mode, which is the only mode it makes sense editing in (unless you’re a glutton for punishment).

If you don’t edit in straight linear 32-bit floating point mode, you really cannot use matrices for anything at all.

First the OETF needs to be inverted to get linear values.

Conversion to linear values should be done automatically for you if you edit in 32-bit floating point (full range) linear mode, which is the only mode it makes sense editing in (unless you’re a glutton for punishment).

If you don’t edit in straight linear 32-bit floating point mode, you really cannot use matrices for anything at all.

Your 709->601 matrix undoes an improper YCbCr to RGB conversion and then re-does it with the correct YCbCr to RGB matrix, right? That's only going to work correctly with the project compositing gamma set to 'video'.

Yes, for converting between primaries you can set compositing gamma to 'linear' and Vegas will linearize the color values before applying the filter. But it does so assuming the video uses a 2.222 gamma OETF, and that's almost never a valid assumption. It might be a close enough approximation depending on what your goal is.

Tonight's episode: Converting gamuts between sRGB and Bruce RGB spaces.

1)

2)

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

P.S.:
Dear Vegas Creative Team! If you read these words...

• know, I (ignorant?) do not actually get the idea of partial "localization" of the UI.
• be assured, I would prefer to see the user interface in one consistent language (here, English).

Merry Christmas! 🙂 🌲🎆

Tonight's episode: Gamut conversion between sRGB space and EktaSpace PS 5 by J.Holmes.

1)

2)

_______________________________________

About Joseph Holmes and his color profiles:
http://www.josephholmes.com/profiles.html

Your 709->601 matrix undoes an improper YCbCr to RGB conversion and then re-does it with the correct YCbCr to RGB matrix, right?

First of all, I just came home from the hospital where I underwent an emergency amputation, so right now I’m not thinking clearly, so I may be misunderstanding the question. If so, I apologize.

Anyway, I don’t really think any of it as being improper, just a conversion from RGB to YCbCr using one color space, then a conversion from YCbCr to RGB using a different color space, though combined into a single step by using matrix multiplication. Or, actually R’G’B’ and Y’Cb’Cr’, as in a linear version of the color space.