studio RGB, computer RGB - still not getting it

Comments

astar wrote on 8/21/2015, 2:25 PM
RE: @blazer - I believe DV was 601 and not 709. 709 came out with HD codecs.

Wiki:
"DV uses lossy compression of video while audio is stored uncompressed.[2] An intraframe video compression scheme is used to compress video on a frame-by-frame basis with the discrete cosine transform (DCT).

Closely following ITU-R Rec. 601 standard, DV video employs interlaced scanning with the luminance sampling frequency of 13.5 MHz."



+1 to @MikeLV comment - The video display chain is so screwed up with cheap displays, that expecting to see what you expect is almost impossible. It is good to rely more on what the scopes say, with an eye roughly for what you want. Unless you are in the range of 20K monitors, calibrated displays, and custom viewing environments.

While I lived in LA, I knew DPs that would get up and complain about a theaters projection setup. They would recommend seeing films in Century City's Ave of the Stars theater due to amount of entertainment people that frequent the place.

You have to let go that your rig is color accurate, unless you have spent serious bank on your color. Get things close enough, make sure the scopes agree, and own several of the most popular devices to run tests on. This may include finding a local theater that will allow you to rent during off hours, to test DCP.
balazer wrote on 8/21/2015, 2:52 PM
Yes, DV closely follows Rec.601, not Rec.709. I should have said the Rec.709 ranges, which are the same as the Rec.601 ranges. Rec.709 and Rec.601 differ in their primary chromaticities, transfer encoding matrix, and scanning format.
NormanPCN wrote on 8/21/2015, 2:56 PM
@balazer

Re: Canon DSLRs and full range capture.

The 7D mkII is very current and it still outputs full range.

Here is an independent source to DL a 7D2 video file that has a lot of very dark and light spots. Others can be found there also. Like the 5D3.
http://www.imaging-resource.com/PRODS/canon-7d-mark-ii/canon-7d-mark-ii-shooters-report-part-ii.htm
astar wrote on 8/21/2015, 3:00 PM
@ Blazer - Do you know any good books you have read on Color Theory? I would be interested reading some of the sources you are into.

I see what you are saying about 601 and 709.
balazer wrote on 8/21/2015, 3:41 PM
NormanPCN, you are right about that Canon 7D Mark II video. It is full range, and it has the video_full_range_flag. I guess I am not sure about Canon cameras. To know which range your camera records to and how you should process your videos in Vegas, I would always recommend checking for the flag using some software that can read it (like ffmpeg), and also measure the camera's black level. Quicktime introduces an additional complication, because Vegas can read some Quicktime files natively (like the 7DII file I just tried from that web site), but others are read through Quicktime for Windows. And if I remember correctly, Quicktime for Windows decodes most video formats to 0-255 RGB. But Quicktime for Windows has a bunch of other problems, so I always recommend remuxing or converting into something that Vegas can read natively.

astar, here is my recommended reading for video color.
astar wrote on 8/21/2015, 4:49 PM
Thanks for that link, I guess I missed that when I was on the site before.

Here is a link to a presentation a friend of mine here in NM gave a couple years ago. You might find it interesting, its a bit dry, but good info.


NormanPCN wrote on 8/21/2015, 6:40 PM
One thing to remember regarding DSLR MOV files. Vegas does not use Quicktime to read these files. It bypasses QT and reads the file natively with its own decoders. By DSLR MOV file I mean a MOV file with AVC video and PCM audio.

Quicktime has about the only decoder in existence that looks at the AVC VUI full range flag. Vegas just decodes the 8-bit file and gives us whatever data it has without alteration.

I'll bet Canon DSLRs are now what they always have been. Full range. The 7D2 and 5D3 are. I've not seen a 5Ds file. The GH3 was full range. The GH4 seems to have a 16 low limit but goes full range on the end. I've only see a couple of files, so big grain of salt.

Anyway I give a +1 to Musicvids suggestion about editing "full range" for the Vegas preview window. Once I learned about this levels thing in the video world I tried to maintain studio levels in Vegas and Vegas fights me all the way. Vegas only cares about 8-bit data full range, and does nothing to help us maintain studio levels. I even started a thread about possible changes to help us maintain/edit studio levels. Why swim upstream when using the Vegas preview window. It's more work, even when using the Atares preview levels extension. Just go with the flow and adjust for the encoder when doing a render as. Now if you have a studio levels preview device, like an actual video monitor then things get more complicated.
musicvid10 wrote on 8/21/2015, 7:17 PM
"

Thanks, Norman. One convert at a time.
Anyone using a prosumer camcorder that shoots 16-235 or 16-255 had better know it if they're going to edit in Vegas, and adjust the filter step accordingly. This was covered thoroughly in the aging 2011 tutorial. Those camcorders are also in the "3% of all devices" category.

Source/decoder combinations that utilize full_range flags correctly are even rarer; color that about as red as a herring can get. I've already tested the flag behavior in VLC ffmpeg using flagged x264 source and it didn't work. "Dynamic Contrast" hardware controls for viewing are the absolute biggest nightmare to come about in recent memory.

REC 709 and 601 are indistinguishable from each other save for an inconsequential shift in the green primaries. ALL of the first generation DSLRs reported "incorrect" 601 primary characteristics, even though their vertical resolutions are >=720 pixels.

Bantering about minutiae may seem like fun, but it does nothing to help those who want to learn about the principles and background of the larger issue.
"Edit RGB, Render YUV" is the only failsafe approach for manual editing in Vegas that I've been able to divine; the rest are just orders of magnitudes of ridiculous.

balazer wrote on 8/21/2015, 8:15 PM
0-255 and 16-235 are both perfectly valid ways of working. I'm not saying one way is better than the other. If Vegas decodes your camera's videos to 0-255, then it's probably easier to work in 0-255. You just have to be aware of how Vegas decodes your camera's videos. I think you are underestimating the number of cameras that record in Rec.709 levels. Two thirds of the cameras in Nick Hope's survey are Rec.709. All of the Android phones I have tested are Rec.709. while some others I know are full_range.

astar, thanks for the link.
Red Prince wrote on 8/21/2015, 11:01 PM
7.78/8*(256)^3 = 16,315,842.56 discrete colors.

Sorry, but that’s not the formula. 7.78 bits gives 2^7.78 = 219.79275... combinations per channel. Since there are three discrete channels (not counting alpha), raising that to the power of 3 gives the complete number of combinations, which is 10,617,935.890... colors.

Assuming that only an integer number of combinations can be displayed, we would round 219.79275... down to 219, and cubing that will give us 10,503,459 possibilities.

Or, if we can manage to round it up (depending on the hardware/software combination), then the total number would be 220^3 = 10,648,000. Note that this would be more than the unrounded result representing the theoretical (analog or continuous) maximum, so it would actually distort some of the colors. At any rate, 7.78 bits would result in a value from slightly more than 10.5 million colors to slightly more than 10.6 million.

He who knows does not speak; he who speaks does not know.
                    — Lao Tze in Tao Te Ching

Can you imagine the silence if everyone only said what he knows?
                    — Karel Čapek (The guy who gave us the word “robot” in R.U.R.)

musicvid10 wrote on 8/21/2015, 11:16 PM
We are agreed on one thing. 16-235 will produce ~10.6 million colors at less than 8 bits, and 0-255 will produce ~16.7 million colors at native 8 bits. So why again do I want to edit in the more confining workspace when the whole burrito is available to me? Anyone?
VidMus wrote on 8/21/2015, 11:19 PM
musicvid10 said, "My solution is simple and foolproof."

My Sony cameras record 16-255 so I prefer to set the waveform monitor to Studio RGB and let levels at 16 be displayed at zero. I could use the 7.5 setting but it makes it much more difficult to see.

I use my second monitor to preview the video so I have the settings set to convert the video from Studio RGB to Computer RGB on that monitor. I can then see the video as it should be.

All graphics and generated media that are Computer RGB are put on a track where the track settings are set to go from Computer RGB to Studio RGB.

So when it is time to render, I just simply render. I do not have to remember to change a setting. And my memory on that kind-of thing is poor at best! I am very likely to forget and end-up with a poor quality video and then have to waste time re-rendering the video. NO THANKS!

So for me and the videos I have, it is best to not have to remember things when rendering.

What is "foolproof" for one person is not necessarily foolproof for another person.

One needs to develop a workflow that works best for them.

Studio RGB = 16-235
Computer RGB = 0 to 255
My cameras = 16 to 255
Other cameras =?

It takes a whole lot more effort to explain this than to do it.


musicvid10 wrote on 8/21/2015, 11:49 PM
Yes your particular camera's considerations have been addressed -- going all the way back to 2011, and now for the third time in this thread.

The simple and foolproof solution for YOU, using my technique, is to invoke the Studio RGB filter as suggested, and drag the Output Start slider back to zero. Couldn't take anyone a full second if they tried their hardest. Then tweak the baseline if necessary and save it as a preset for the next use.

My simple and foolproof solution for those shooting compliant 16-235 is to not apply a levels filter to the output at all. Doesn't get any neater than that.

Although completely optional, filtering the preview for correct viewing levels from those sources seems highly advantageous; however the index for forgetting to remove the preview filter prior to rendering approaches 100%, in my experience.

I find circular discussions wearisome so I'll duck out of the game, but by all means, carry on!
Red Prince wrote on 8/22/2015, 12:02 AM
So why again do I want to edit in the more confining workspace when the latter is available to me? Anyone?

I can only repeat what I said before, and, IIRC, so did you: You don’t.

You should do all the editing in the full range, and preferably in 32 bits. I know someone mentioned that Vegas only uses the studio range in 8 bits. But that doesn’t make sense, as it would make its built-in filters too complex and, therefore, unnecessarily slow. Numerous effects count on the fact that many mathematical relations keep a zero a zero and a one a one. They typically work in floating point math, range 0-1 internally anyway. For example raising a zero to any value (other than 0) will result in a zero. And raising a one to any value results in a one. So these filters change all values other than 0 and 1, but keep 0 and 1 unchanged. This is the main reason why it is best to edit in the 32-bit mode, full 0-1 range.

Only as the last step before exporting should everything be converted to whatever range the output format requires. After all, someday you may want to export the same video to a completely different format with completely different requirements. All you have to change then is the final filter instead of all of them (which could possible make the result look different altogether).

It’s not because of the number of millions of colors why we should always edit in the full 0-1 range at 32-bit floating point. After all, there are only some 2 million pixels in a 1080p frame, so even if each of them was different (which is unlikely), it’s still only a fraction of the available colors. And, of course, we do not see individual pixels because our brains convert them into an image in its entirety. The main reason for using the full 32-bit range is what I mentioned about the math behind a number of filters: They just work best when using the 0-1 range.

That is also why computer graphics students are taught to think about colors as continuous values in the 0-1 range (and have been taught that way for decades). No matter what Vegas may or may not do internally, it is a fair assumption that most third-party plugins use 32 bits internally and use the 0-1 range. Besides, in these days of OFX it makes little sense for any third party to write plugins designed specifically for Vegas. Even if they may market separate versions that simply check what software they are running on and refuse to run with any other software just to make you pay separately for each software host, the core of these “separate” products will be the same.

He who knows does not speak; he who speaks does not know.
                    — Lao Tze in Tao Te Ching

Can you imagine the silence if everyone only said what he knows?
                    — Karel Čapek (The guy who gave us the word “robot” in R.U.R.)

musicvid10 wrote on 8/22/2015, 12:07 AM
"
Well said. I hope that settles it, as I trust people would value your opinion over mine.

When grading in 32 bit float or starting with 10 bit source, I also strongly recommend rendering a 10 bit YUV intermediate in Vegas for final external 8 bit encoding in x264 or another delivery format. Vegas' internal dithering algorithm is absolutely horrible and yes, I've run the tests.

10 -> 8 bit dither in Vegas (Mainconcept]


10 -> 8 bit dither in Handbrake (libav/x264)]

Red Prince wrote on 8/22/2015, 12:22 AM
I do not have to remember to change a setting.

That, unfortunately, is a major weakness of Vegas. In my experience, most quality editors convert the input files to the 32-bit 0-1 format, do all the editing in that format, and convert to the correct output format, all internally, so their users don’t even have to know about the differences (after all, a video producer/editor/etc shouldn’t have to need to understand how computers work, he should just need to know how to use the mouse and such).

Indeed, the OFX specification expects OFX hosts to use the full range internally, so OFX plugin authors do not have to deal with other ranges (as that would slow processing down).

The truth is that Vegas should have no problem working internally in the 0-255 or 0-1 range and still show it as studio RGB in the waveform monitor, if that is how you prefer to see it. This should be completely transparent to us, the users. If Vegas can’t do so, that is a major design flaw they should fix if they expect to stay competitive. Especially if they want us to buy a new upgrade every year or two!

He who knows does not speak; he who speaks does not know.
                    — Lao Tze in Tao Te Ching

Can you imagine the silence if everyone only said what he knows?
                    — Karel Čapek (The guy who gave us the word “robot” in R.U.R.)

musicvid10 wrote on 8/22/2015, 7:16 AM
"So these filters change all values other than 0 and 1, but keep 0 and 1 unchanged. This is the main reason why it is best to edit in the 32-bit mode, full 0-1 range."
Every aspiring videographer should be forced to apprentice in digital still and graphics production for five years before being allowed to pick up a video camcorder.


ushere wrote on 8/22/2015, 8:10 AM
Every aspiring videographer should be forced to apprentice in digital still and graphics production for five years before being allowed to pick up a video camcorder.

dream on ;-(

with the exception of a number of exceptionally knowledgeable people on this forum (and on some others that i follow) i would have to say the vast majority of aspiring videographers (and yes, i generalize) have no interest in anything other than shallow dof and low light resolution. and the sorry fact is their output is probably just as acceptable to their client / audience as is that produced by a pro well versed in colour space theory, etc.,

such is life....
musicvid10 wrote on 8/22/2015, 10:32 AM
Exactly the same is true of aspiring amateur still photographers, sad to say.

audio2u wrote on 4/5/2016, 8:23 PM
Hi all,
There are clearly some very knowledgeable people here, and I don't want to annoy everyone with what I DON'T know.
I AM willing to learn, but the level of conversation here is a bit beyond me right now.
So, with that said, can anyone point me to a resource which will help me get up to speed on all of this, please?

I don't have a camera in the same ballpark as any of those mentioned so far.
And I'm not a professional video shooter, or editor. I'm a pro-audio guy (29 years as a working recording engineer in commercial radio).
I shoot home movies on a JVC GZ-HD6 consumer-grade camera (the best-spec'd camera I could afford when I was in the market some years back).
Most of the time, it's actually my wife shooting footage whilst I'm capturing stills.
What I want to do is get my head around how best to process the footage I get from the JVC. Natively, the files are .TOD, but I have been simply changing the file extension to .M2TS and dropping them into SVP13.
Until last weekend, I had always had my projects set to 8 bit (the default). But the preview and renders always looked a bit washed out. So I would apply a Sony Curves filter to the video master output. And I would generally have that curves adjustment deepening the blacks, but leaving the whites flat. That's been "acceptable", but I would like to know if I can improve on the workflow/output.

Having played around with various combinations of settings last weekend, I'm currently using:

HD 1080-50i (1920x1080, 25.000 fps)

upper field first
Pixel aspect ratio: 1.0 square

Frame rate: 25 (PAL)

Pixel format: 32 bit floating point full range
Gamma: 1.0
View transform: ACES RRT

This seems to produce a better quality of output without the need for the Curves filter, although the colours DO appear to be a little over-saturated when viewed on my Sony Bravia 4k TV (I only mention the 4K to signal that it is a fairly new box... bought it early 2016).
Again, I don't expect you guys (who clearly eat, sleep and breathe this stuff) to rehash everything you've already said, but if you could point me to a "dummies guide to..." this, it would be appreciated!
Thanks in advance!
audio2u wrote on 4/5/2016, 10:24 PM
Balazer said "Frankly the easiest thing to do is to change the pixel format to 32-bit floating point (full range). Then most of the complications go away: Vegas maps 0,0,0 to the format's black point, and 1,1,1 to the format's white point, for all formats, and for the preview window, and for full-screen preview. Reading of full_range video files is the only thing that would need to be handled specially."

I'm guessing that my JVC camera would not be producing full range video, and that my current workflow is the best option?
john_dennis wrote on 4/5/2016, 11:41 PM
Why guess? Follow the steps in Nick's thread and determine for yourself. The information will be useful to you and possibly others if you report your findings for your camera.
Grazie wrote on 4/6/2016, 1:01 AM
Nick, you've only got my iPhone. How do you update to include my Canon cameras? See my specs.

Graham
farss wrote on 4/6/2016, 3:13 AM
[I]" I'm guessing that my JVC camera would not be producing full range video, and that my current workflow is the best option?"[/I]

Your JVC camera being a video camera indeed most likely does not produce "full range" image files. Still cameras that you're more familiar with do.

So, put a still image from a still camera and an identical image from a video camera on the Vegas timeline and viewing them with the internal preview window they will look different. The image from the still camera will look as it should and the image from the video camera will not. This is why as you've noted the video from your video camera looks washed out. Not the fault of the camera, it is simply not being displayed correctly.

So then you fix it and then display the wrongly "fixed" image on a device that does display video (e.g. TV) correctly and it looks contrasty and over saturated. Quite simply you fixed something that wasn't broken i.e. you broke it :(

You need to get this simple piece of knowledge very firmly into your head otherwise everything else that you read or try to do to wrangle this issue within Vegas is going to be very confusing.

Bob.