studio RGB, computer RGB - still not getting it

Comments

audio2u wrote on 4/6/2016, 7:29 AM
@johndennis Thanks for the link. I had a quick look. No one else has submitted details for my camera, so when I have a moment of free time (won't be until next week, sadly), I WILL attempt to create the files as specified in the first post on that thread, and submit my findings.

@farss Thanks for the info. I was concerned that that was indeed what was happening (i.e. my breaking something in my workflow which might not have BEEN broken). And that's why I asked if anyone could point me to a "dummies guide" on all this colour space stuff. More to learn... :)
farss wrote on 4/6/2016, 7:49 AM
[I]"that's why I asked if anyone could point me to a "dummies guide" on all this colour space stuff."[/I]

I'm not going to even attempt to type a "dummies guide" other than a few simple tips.

1) Using any variant of Vegas's 32bit float modes is just a waste for what you're doing.

2) You really only need to just use Vegas as it comes out of the box for video. Yes, what you see on the internal preview monitor isn't what you get. There's ways around this but when you find how to do it you'll also find that if you're not careful you'll mangle your renders.

Bob.
ushere wrote on 4/6/2016, 7:59 AM
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.

bob - wonderfully, yet so simply explained...
wwaag wrote on 4/6/2016, 10:22 AM
@audio2u

And that's why I asked if anyone could point me to a "dummies guide" on all this colour space stuff. More to learn...

There were some excellent color space articles written by Glenn Chan some years ago that are still very useful. Here are a few links.

http://www.glennchan.info/articles/vegas/colorspaces/colorspaces.html

http://www.glennchan.info/articles/vegas/v8color/vegas-9-levels.htm.

http://www.glennchan.info/articles/technical/hd-versus-sd-color-space/hd-versus-sd-color-space.htm

http://www.glennchan.info/articles/articles.html

wwaag

AKA the HappyOtter at https://tools4vegas.com/. System 1: Intel i7-8700k with HD 630 graphics plus an Nvidia RTX4070 graphics card. System 2: Intel i7-3770k with HD 4000 graphics plus an AMD RX550 graphics card. System 3: Laptop. Dell Inspiron Plus 16. Intel i7-11800H, Intel Graphics. Current cameras include Panasonic FZ2500, GoPro Hero11 and Hero8 Black plus a myriad of smartPhone, pocket cameras, video cameras and film cameras going back to the original Nikon S.

audio2u wrote on 4/6/2016, 4:09 PM
Thanks wwaag! I'll check 'em out!

And thanks again Bob for your input, too. I know you said "just use Vegas as it comes, out of the box", but just to help ME understand this better, is the bigger picture here (no pun intended) one of: you need different output transforms for different viewing devices?
Have I got that part right?
So, in a perfect world, you'd render one version for viewing on the tv, and a different version for viewing on a computer monitor/web/phone etc?
audio2u wrote on 4/6/2016, 7:37 PM
Wwaag, just so you know, that second link is now dead.
I've read the first one (great info, and very helpful!), and am working my way through the 3rd link now....
Thanks again!
Red Prince wrote on 4/7/2016, 10:44 AM
So, in a perfect world, you'd render one version for viewing on the tv, and a different version for viewing on a computer monitor/web/phone etc?

No. It all depends on the type of file you’re creating. If it is of the MPEG variety, such as .mpg, .mp4, the output should be of the studio RGB type. If they are of the AVI variety, the output should be of the computer RGB type.

To complicate matters further, certain codecs expect you to send them data in the computer RGB type and they convert it to the studio RGB internally, but I don’t think any of the codecs that come with Vegas do that. At least not the ones I have been using.

At any rate, the software players used on computers know about the two different standards, and they know to expect studio RGB (which they convert to whatever the device expects) with the MPEG family.

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 4/7/2016, 12:31 PM
Red Prince,
+1

To expand a bit, Some AVI files are RGB, some are YUV. Same with MOV files.
All WMV are RGB afaik.
A few MP4 files are RGB, but this is an exception, mostly cheap eBay pocket cameras. Those should be flagged juvj420 (fullrange=on), but often they're not.
MediaInfo will "usually" disclose the color space, but there's no substitute for experience and a set of scopes to match the video levels to the proper color space.

The one "gotcha" that messes everything up are so-called "Dynamic Contrast" controls on graphics cards, some monitors and teevees. 99% of consumers misuse it, because it looks like a cool setting. In reality, it is for misflagged video, and nothing else, and will make properly-conformed video look ridiculously flat. So raise the chances of operator error by ANOTHER power of ^2.

A slightly tongue-in-cheek take on this whole mess can be found here:
http://forum.handbrake.fr/viewtopic.php?f=14&t=33111
. .

farss wrote on 4/7/2016, 3:14 PM
[I]" So, in a perfect world, you'd render one version for viewing on the tv, and a different version for viewing on a computer monitor/web/phone etc?"[/i]

NO!

On a computer sitting between your video file and the computer monitor is two pieces of software that can change how the video is displayed. There's the player and then there's the video card driver. Both may have settings that adjust how the video's levels are mapped to what the physical display expects. You simply end up chasing your tail endlessly.

Actually make that THREE, a computer's monitor may also have controls that'll change how the video is displayed.

Bob.
Grazie wrote on 4/7/2016, 4:23 PM
Oh, go on Bob, you know yer wanna do a Flow Diag . . . .

G
Rich Parry wrote on 4/8/2016, 1:10 AM
It has been said ... Just prior to YUV rendering (most of it is), apply the Computer RGB ->Studio RGB Levels filter to the output.

When I add the "Levels" plug-in FX as outlined above, it does reduce the video range, values above 235 are reduced and values below 16 are increased so the video is within the 16-235 range.

However, if the event is already within the 16-235 range, adding adding Levels further restricts the range.unnecessarily, 16-235 becomes 32-220 (approx).

In fact, the levels command ALWAYS reduces the "range" at both ends. As an extreme example, if the range is 64-128 it doesn't need to be changed, but adding Levels to the output reduces the range even more.

Unless I am missing something (entirely possible), it seems crazy to me to add the Levels plug-in at the output and change all CC whether the events need changing or not.

Happy to be proven wrong,
Rich

CPU Intel i9-13900K Raptor Lake

Heat Sink Noctua  NH-D15 chromas, Black

MB ASUS ProArt Z790 Creator WiFi

OS Drive Samsung 990 PRO  NVME M.2 SSD 1TB

Data Drive Samsung 870 EVO SATA 4TB

Backup Drive Samsung 870 EVO SATA 4TB

RAM Corsair Vengeance DDR5 64GB

GPU ASUS NVDIA GeForce GTX 1080 Ti

Case Fractal Torrent Black E-ATX

PSU Corsair HX1000i 80 Plus Platinum

OS MicroSoft Windows 11 Pro

Rich in San Diego, CA

musicvid10 wrote on 4/8/2016, 1:29 AM
The precursor to adding the Studio RGB at the end of the chain is that the video was shot and edited in 0-255 range, as most phone and device video is.

Folks who have and know how to use their zebras and scopes are but a spit in the ocean, probably way less than 5%.
But those few should not be adding a stock output level correction, agreed.
It's a fix for the billions, not the profoundly conscious.
dxdy wrote on 4/8/2016, 7:48 AM
I think Bob's ("farss") explanation above at 4/6/2016 4:13:23 AM finally brought it home to me. I understand, I understand.

Fred
concept wrote on 10/3/2016, 6:41 AM

Hello to all. This is my first post. I am an amateur. Have only made a few videos so far in my whole life, so be lenient. I have read this and many other threads trying to comprehend what's going on. So far, this is my understanding. Please confirm me, or correct me and forgive me for the lengthy post.

When importing videos inside NLEs the values are interpreted depending on the codec.
YUV-encoded files may have superblacks and superwhites (typical when coming from a camera that records in a 0-255 or 16-255 range).

Here is what is happening in the various workflows:

VEGAS 8-bit workflow:
Step 1: Digesting (importing)    
RGB files (codecs):

  • 0-255 RGB --VEGAS decoder--> 0-255 RGB

YUV files (codecs):

  • 0-255 YUV --VEGAS decoder--> 0-255 RGB
  • or 16-255 YUV --VEGAS decoder--> 16-255 RGB
  • or 16-235 YUV --VEGAS decoder--> 16-235 RGB

Step 2: Editing
During editing in RGB, values may change and increase to superwhites and superblacks even if those were not there in the first place. The final RGB output must be examined to evaluate range of RGB values. So, during editing:

  • 0-255, 16-255, 16-235 RGB --editing tools, plugins--> 0-255 RGB

        
Step 3: Encoding (exporting)
to RGB files (codecs):

  • 0-255 RGB --> 0-255 RGB
  • 16-255 RGB --OutputFX, Levels Plugin, StudioToComputer preset, Set Input end to 1 or, alternatively, Set Output Start to 1--> 0-255 RGB
  • 16-235 RGB --OutputFX, Levels Plugin, StudioToComputer--> 0-255 RGB

        
    to YUV files (codecs, YouTube, mp4 etc):

  •  0-255 RGB --OutputFX, Levels Plugin, ComputerToStudio preset--> 16-235 YUV
    this will change the video preview (washed out effect) but the player will stretch back this range and it will appear correct.
    Also, when editing in this mode, and files are between 0-255 RGB, the preview window's output (before applying the Levels filter) will coincide with playback output.
  • 16-255 RGB --OutputFX, Levels Plugin, ComputerToStudio preset, SetInput start to 0.060--> 16-235 YUV
    While editing, the preview window's output is not the same as the resulting playback output. To preview playback, set temporariy a Studio RGB to Computer RGB Levels filter and set Input end to 1.000.
  • 16-235 RGB --No Levels FX required--> 16-235 YUV
    In this case there is one to one mapping and no Levels FX is required. To preview playback, set temporarily a Studio RGB to Computer RGB levels filter.

 

VEGAS 32-bit workflow (Video Levels):
Nothing really changes from the VEGAS 8-bit workflow, except that all the plugins calculations are more precise.

 

Adobe Premiere Pro workflow:

Step 1: Digesting (importing)
RGB files (codecs):

  • 0-255 RGB --Premiere decoder--> 0-255 RGB

YUV files (codecs):

  • 0-255 YUV --Premiere decoder-->maps to 0-255 RGB
    No distortions. I would have expected Premiere here to map 16 YUV to 0 RGB and 235 YUV to 255 RGB and clip all superwhites and superblacks, but it seems to map 0-255 to 0-255 just like Vegas.
  • 16-255 YUV --Premiere decoder-->maps to 0-255 RGB
    Histogram is stretched. I believe this is where Premiere does it wrong. It basically maps 16 YUV to 0 RGB correctly and then clips the whites from 236 to 255 by mapping 235 to 255 RGB)
  • 16-235 YUV --Premiere decoder-->maps to 0-255 RGB
    Histogram is stretched again, but on both sides, so no distortions.

Step 2: Editing

  • 0-255 RGB --editing tools, plugins--> 0-255 RGB (straightforward)

Step 3: Encoding (exporting)
to RGB files (codecs):

  • 0-255 RGB --> 0-255 RGB

to YUV files (codecs, YouTube, mp4 etc):

  • 0-255 RGB --> 16-235 YUV

And for the end,

 

VEGAS 32-bit workflow (Full Range):
This mode confuses me. It appears to work similar to Premiere Pro. It also seems that if I have the Computer RGB to Studio RGB output FX on, the preview window displays the correct output (playback output). But this only happens when Gamma is set to 2.222. Should gamma be set to 2.222 or set to 1.000?

What exactly is happening in this mode? Can someone shed some more light for complete novices like me?

Thank you for reading.

NickHope wrote on 10/3/2016, 6:58 AM

A couple of things before this discussion gets going again...

  •  0-255 RGB --OutputFX, Levels Plugin, ComputerToStudio preset--> 16-235 YUV
    this will change the video preview (washed out effect) but the player will stretch back this range and it will appear correct.

When I tested this a long time ago I found it to be true in the vast majority of cases, but not all.

  • To preview playback, set temporarily a Studio RGB to Computer RGB levels filter.

In VP12 and VP13 you can also use the Preview Levels extension in SeMW Extensions. (which has some other nice features too). In VP14 you can use the DLL linked to in this post.

concept wrote on 10/3/2016, 7:17 AM

I meant "...the player will stretch back this range..." but for some odd reason the spell checker of the forum is changing "stretch" to strange? I cant seem to correct it no matter how many times I edit the original post.

NickHope wrote on 10/3/2016, 7:20 AM

There is no spellchecker on the forum yet. What device are you using? It might be your phone's spellchecker or it might be a spellchecking extension in your browser. I'll see if I can edit it for you. p.s. I knew what you meant :)

concept wrote on 10/3/2016, 9:03 AM

It probably was neither. I tried editing strange to stretch but whenever I was saving the post it was giving me a crash error message and was not changing it. Well, you did it for me, so it is fixed now. Thanks.
If and when you have the time, I was wondering if you agree with the rest of my conclusions from my first post or if something is way off. Looking also for feedback from some of the other experts in here, if possible.

Musicvid wrote on 10/3/2016, 9:13 AM

This discussion has changed considerably since it began as a naive question in 2010. In addition to levels and colorspace, we now have decoder flags and graphics  / player / monitor switches that flip the levels back and forth because most cameras now shoot noncompliant levels. 5 billion smartphones can't be wrong, right? Only 4 out of 32 possible combinations now view correctly, and only 2 out of 32 will do so without decimating bit depth, if memory serves correctly. Only 1 out of 64 gaming afficianados will have a clue about any of this.

Here is a light-hearted look at the spiders' nest, keeping in mind that the only viable workflow is a door-to-door set of instructions for one's particular millieu, a set of scopes, and a set of trained eyes to go with them.

Only play and upload 16-235 mp4 yuv420 unless you are doing so for other hobbyists, not consumers. The rest is all quicksand if distribution is the goal.

http://forum.handbrake.fr/viewtopic.php?f=14&t=33111

concept wrote on 10/3/2016, 11:07 AM

So I understand I might have only touched a small part of possible cases in the workflows I outlined. And keeping on reading about these things I think I am eventually getting it.

But what about the very last part of my question regarding vegas 32bit full range. Especially the issue with gamma 1 vs 2.2. Anybody has any helpful links/articles/explanations on how to work in this mode?

Musicvid wrote on 10/3/2016, 4:44 PM

The job is to deliver 16-235 yuv420 and let the downstream consumers make their own mistakes. That is the very best anyone can do, sorry to say. If the producer is the clueless one, there is no hope of anything resembling compliant video getting through

Gamma 2.2 for compositing. That is a project setting, and has nothing to do with output levels when the correct (matched) project settings are chosen.

With 8 bit source, DO NOT use a 32 bit float project. Then you won't have to worry about a whole bunch of insane stuff.

Needing to know what each control does in perfect detail is not necessary in order to make correct choices. That is what the defaults, written by someone who is far smarter than you or me, are there for, and unless they are causing errors, should be overlooked for all things relating to production. Usually, when you follow directions on the internet, if something isn't specifically mentioned, it is a default that should be left alone. The more you render, the more sense your reading will make, not necessarily the other way around.

Make some renders, make some awful mistakes, and get back to us with your questions and some examples to go with them. That's where peer assistance is at its best. There are books to tell us the rest.

Musicvid wrote on 10/3/2016, 6:33 PM

Oh, save some more brain cells and never compare Premiere's preview and output with Vegas. The secret, it appears, is that Premiere reacts to the VUI flags and Vegas, a Windows-centric program, does not. You really need scopes if you plan to remain serious about this.

NickHope wrote on 10/4/2016, 12:19 AM

For testing this stuff, download the Belle Nuit 1920x1080 .tif test chart from http://www.belle-nuit.com/test-chart and Musicvid's own Grayscale charts from https://www.vegascreativesoftware.info/us/forum/new-hd-grayscales-for-vegas-editors--83243/ e.g. You can render these out to various codecs then bring them back in to Vegas/Premiere to compare how levels are handled and to see what's clipping and what's not (look at which of the lightest and darkest bands become the same colour "black" or "white"). You can also take them right through to your delivery medium (e.g. YouTube) to help understand how the player handles levels.

concept wrote on 10/4/2016, 3:06 AM

Thansks for the feedback Musicvid and Nick Hope.

@Musicvid:

Gamma 2.2 for compositing. That is a project setting, and has nothing to do with output levels when the correct (matched) project settings are chosen.

I am asking about Gamma because I read Glenn Chan's tutorial about linear light (http://www.glennchan.info/articles/vegas/linlight/linlight.htm) and was wondering whether in some cases it may be advantageous to use gamma of 1.0. I did notice though, that in some plugins the output was considerably diffirent between gamma 1.0 and 2.2.

With 8 bit source, DO NOT use a 32 bit float project. Then you won't have to worry about a whole bunch of insane stuff.

Does this advice apply also to 10 bit intermediate files that were produced from 8 bit camera source files?

Oh, save some more brain cells and never compare Premiere's preview and output with Vegas. The secret, it appears, is that Premiere reacts to the VUI flags and Vegas, a Windows-centric program, does not. You really need scopes if you plan to remain serious about this.


The only case that interests me to compare between Premiere and Vegas is how they open a 16-255 YUV 8 bit camera source file with the "Limited" flag in the metadata because it is there where I see differences. I believe Premiere looks at the flag here, maps 16 YUV to 0  and 235 YUV to 255 thus clipping highlights. If I follow recommended standard practices about VEGAS mentioned in this thread, the output from VEGAS seems better, with a bit more detail in the highlights. Is it possible that the "limited" flag throws Premiere off in such cases?

@Musicvid and Nick Hope

and Musicvid's own Grayscale charts from https://www.vegascreativesoftware.info/us/forum/new-hd-grayscales-for-vegas-editors--83243/

This link appears broken, but got the first one. Thanks!