There are IDTs for S-Log3. To integrate the IDTs into Vegas's OpenColorIO configuration, I just need test footage to make sure levels are mapped correctly for the way Vegas reads the camera's files. Please send me an e-mail.

[I]"Please send me an e-mail. "[/I]

Done

Bob.

Jacob, that was incredibly useful information! Thank you VERY much.

Thanks a lot that was one of the most interesting posts and vids I've seen in a while, I need to go back and look at open exr Vegas workflow again in light of this I had not been able to get it working in Vegas before but this has given me some ideas as to what I was doing wrong!

Thanks for all of the feedback. :)


Here are two test videos from the Panasonic GH2.

This test uses a custom GH2 IDT:


This test uses a generic Rec.709 IDT:


The Rec.709 input transform is the inverse of the Rec.709 output transform. So when you use Rec.709 as the input color space and as the output color space and you don't make any adjustments to the video in ACES, the video's color values are passed through without modification. That's what you see in the second video when the exposure setting is +0. When exposure compensation is applied, it amplifies the differences between the camera's output curve and the Rec.709 color space curve, showing greater differences as more compensation is applied. These differences depend on which camera you're using. At least with the GH2, the two curves seem to be fairly close to each other, allowing for about one stop of adjustment in either direction before the differences become too large. One stop is about all you need for real-world shooting. It's fairly easy to get the exposure within one stop of ideal just by looking at the camera's display while you shoot. And you can easily get the camera's white balance setting within one stop of the ideal in each channel just by eyeballing the image.

Of course it's desirable to have an IDT made specifically for your camera. A custom IDT removes the uniqueness of your camera's contrast curve, giving you the ACES RRT contrast curve consistently in all your output. A generic IDT doesn't do that. A generic IDT preserves the look of your camera's video, for good or for bad.

Here's the bottom line: it's worth it to use ACES even when you don't have a custom IDT, because exposure compensation and color balancing are far easier to do in ACES than to do directly on the Rec.709 color values. In ACES, you just drag some sliders. It's almost as easy as setting the exposure and color balance in the camera, and the results are almost as good. Working directly on Rec.709 video, you'll spend lots of time with color curves and high/mid/low color correction filters, and still your results won't be as good. When you get the midtones to look right, the highlights and the shadows will be off. When you finally get one scene looking the way you want, it won't be right for another scene. Rec.709 is optimized for the transmission of display-ready visual information. It just isn't the right color space for making adjustments that correspond to the physical world.

But don't take my word for it. Try it for yourself.

That was a GREAT tutorial. Thanks for that effort.

Now I feel dumber and smarter at the same time.

Put simply many cameras today can capture more of what's in front of the lens that can be usefully displayed by our viewing devices or may even make for pleasing images. This does afford us more opportunity to adjust the "look" of the image in post but that involves more work ... in post.
This is not for everyone in every shooting scenario, for a lot of what we do simply shooting Rec 709 so the footage can go straight from the camera to air makes a lot of sense.

To put this another way, were finally entering the age where what comes out of our cameras can honestly be described as a "digital negative". All that's missing is the smell of bromine :(

Bob.

"With help from forum members, I can create color spaces for additional cameras"

Does that help come in the form of sample media from the various cameras?

This concept appeals to me because of the potential to fix some of the ills of shooting where we have less control over the lighting or timing of the action (a fact of life for us gitswac*)

* grandpa in the stands with a camcorder

Okay, I get that ACEScc would be most preferred. What I fail to understand is the exact workflow anticipated.

Please define what preserves the corrected workflow:
1) Typical camera source? could it be 4:2:2 in 8bit at the higher prosumer end of the line?

2) Mode of VegasPro? Default 8bit? or Is it required 32bit video level?

3) Digital intermediates can be? 8bit MagicYUV? XDcam? 10bit Cineform?

4) Do we clamp 16-235 levels as typical for REC 709? or more lattitude ok?

john_dennis, what I need for building an IDT depends on the camera. For some cameras I just need test footage to confirm the level mapping. For others I need a very specific set of shots to carefully measure and profile the camera's response. But don't let the lack of a camera-specific IDT stop you from experimenting with ACES or ACEScc. I think you'll find that the Rec.709 IDT does a fine job most of the time, and makes basic color correction vastly easier than trying to work with Rec.709 color values directly.

videoITguy, you can use any camera you like so long as it records in one of the supported color spaces. That includes plain old 8-bit Rec.709. The ACES and ACEScc workflows use Vegas's 32-bit floating point processing, but the input and output level mappings don't correspond to Vegas's "full range" or "video levels" modes. It's using color space input and output transforms. You can use any format you want for digital intermediates. For both input and output you can choose Rec.709 color spaces for either the 16-235 range or the 0-255 range.

"ACES and ACEScc workflows use Vegas's 32-bit floating point processing, but the input and output level mappings don't correspond to Vegas's "full range" or "video levels" " ...

So, we know 32bit processing ticked off in the project settings mode for VegasPro can either be set to "full-range" or "video levels" both of which are terribly problematic and cannot be used successfully with many common codecs.

What are you proposing to set this dialogue box to in order to engage 32bit processing?

Please watch the video before you ask questions.

Your point well taken balazer! I seldom watch any uploaded videos because 99% of them are so poor in presentation design.

Let me say I applaud your contribution in several ways - first your presentation is absolutely first class - your summation in power-point style is a real bonus and something I did appreciate to begin with.

Here is a nutshell of my problem - I have Canon XHA-1 cameras that are nearly 10 years old but in near perfect working condition. When I use such cameras in a multiple shoot with these as the common camera - the match -up, timecode, etc are in perfect sync which is most desirable. These shoot HDV 8bit 4.2.0 and after firewire transfer lay down on the VegasPro timeline perfecty well.

Now I want to introduce newer tech in cameras like the JVC HM200 which shoot upto 4k in 8bit 4.2.2 such that I can lay in shots from both the JVC and the Canon concurrently. The Canon allows considerable profile tweaking to set a look, but no matter what setting it looks very different from the default JVC profile. How can I use the ACEScc structure to bring this production hardware together?

[I]"Now I want to introduce newer tech in cameras like the JVC HM200 which shoot upto 4k in 8bit 4.2.2 such that I can lay in shots from both the JVC and the Canon concurrently. The Canon allows considerable profile tweaking to set a look, but no matter what setting it looks very different from the default JVC profile. How can I use the ACEScc structure to bring this production hardware together?"[/I]

I doubt using the ACES structure is going to yield much benefit in this scenario.
The cameras you're using are recording Rec 709 so the Look is pretty well baked in. Technically you'd get better results fixing the problem in the camera(s) before the Look was baked in.
Most cameras use 14bit (or more) ADCs and work their magic with that amount of data. They then may throw a lot of the data away to fit the image into Rec 709 and 8bit codecs.

Bob.

The text file in the installation instructions says:

"1. Make a backup copy of C:\Program Files\Sony\Vegas Pro 13.0\configs\aces\config_1_0_3.ocio
2. Extract the contents of this .zip file to to C:\Program Files\Sony\Vegas Pro 13.0\configs\aces,overwriting the config_1_0_3.ocio file."

It should read:

"1. Make a backup copy of C:\Program Files\Sony\Vegas Pro 13.0\OpenColorIO\configs\aces\config_1_0_3.ocio
2. Extract the contents of this .zip file to to C:\Program Files\Sony\Vegas Pro 13.0\OpenColorIO\configs\aces, overwriting the config_1_0_3.ocio file."

One must make hidden files visible under Folder Options in the Control Panel.

I very much appreciate your thoughtful effort on this subject. I'm currently working with ACEScc following your tutorial. It's possible that I chose a sows ears video to start my foray into this subject. Some of my video is beyond repair.

Thank you Bob (farss) for your strategic comment. I can understand from where you are coming from. I really like the profile manipulation that I can manage in the Canon XHA-1 camera. It is superb and very extensive. I just feel that pushing it toward the default JVC HM200 is not necessarily the look that I want for the whole combination. I have yet to learn what I can do about the JVC otherwise.

Jacob, thanks very much for this. It has really opened my eyes to a different way of working.

I am currently shooting with 2 Panasonic GH4 cameras. At the moment I use the "Natural" photo style with -2 contrast and usually color correct with a single Sony Color Curves FX, for delivery to YouTube and DVD. I shoot mostly underwater, so my stuff tends to need a lot of adjustment in post.

I would be very interested in using your workflow, and would be very happy to assist you by sending GH4 test footage, in particular when V-log comes out in (allegedly) the next firmware update.

One question I have, as I get my head around this... In a more typical 8-bit workflow, the Vegas Preview window is not WYSIWYG. We either have to a) rely on a secondary display and ensure that "Adjust levels from Studio RGB to Computer RGB" is checked in the Preview Device preferences, or b) Apply a temporary "Studio RGB to Computer RGB" FX preset and remember to remove it before rendering. In your ACES/ACEScc workflow, is the Preview window WYSIWYG in relation to web/DVD delivery?

Another thing that crosses my mind is that it might be very possible for a scripting/plug-in programmer to combine those plug-in chains into a nice, user-friendly interface with all controls visible at once (c.f. the discussion on Satevis' recent Graide Color Match plugin).

john_dennis, thank you for pointing out the error in the installation instructions. I have corrected it. I'm glad someone is finally trying the workflow.

videoITguy, a proper camera IDT will "unbake" the camera's baked-in look. The generic Rec.709 IDT does not: it simply passes through the camera's look as-is, though giving you better tools for color adjustment. The kinds of custom IDTs that I can make can unbake the camera's luma response. Luma response is highly variable from camera to camera, so unbaking it helps a lot for matching between cameras. But at this time I don't have the tools to profile the camera's color response. In theory the color should conform to Rec.709, and in my experience the cameras conform fairly well. But that really depends on the camera, and we'd just have to try it to see. Even with proper IDTs, ACES can only do so much to help match between cameras, because every camera sees colors differently. For now, as Bob suggested, I would try using the in-camera adjustments as much as you can to try to match the two cameras. You can then adjust the look in ACEScc.

Nick Hope, thanks for your feedback. I'll contact you about possibly building a GH4 profile. ** It was one of my highest priorities that all color space input and output be mapped correctly and consistently. I have the sRGB and Rec.709 view transforms generating output with levels properly mapped to the 8-bit 0-255 range expected by the Windows graphics subsystem. Video will look correct both in the preview window and in a full-screen preview when "Adjust levels from studio RGB to computer RGB" is disabled in Preview Device preferences. The preview image will perfectly match file output using the Rec. 709 video file color space when the video file is properly decoded according to Rec.709. ** It is certainly true that some new color correction filters tailored to ACES or ACEScc could simplify the color correction process. Right now Vegas is giving us just barely the filters we need to perform the most basic color correction in ACES and ACEScc. But those basic corrections work extremely well in ACES and ACEScc.

Thanks for the awesome tutorial!!
I love everything about this, except my results. Granted, I am working with GH4 and slapped the GH2 color setup on the clips... maybe that is the whole problem. AND I can't say I understand all back-end tech stuff, but it is cool Vegas can do this. When I set up the work flow per the video, it blew out the highest parts and I was unable to reel them back in to be usable - again, probably the GH2 setup

Confused on how one can expand the color gamut (32-bit full), but visually edit it through 8-bit vegas output on a pseudo-10-bit screen? Is ACES made for a much more advanced monitor and playback?

Yes, different color spaces handle the highlights differently. The Panasonic GH2 color space isn't necessarily the best one to use with the GH4. For now try using the Rec.709 video file color space. Hopefully Panasonic will give us some V-Log soon.

Note that using the Rec.709 video file color space for your input files may show some weirdness in the highlights when you preview using the sRGB view transform, due to some differences between Rec.709 and sRGB. That goes away when you render to Rec.709. Try switching the view transform between sRGB and Rec.709 to see this. But sRGB is probably still the better color space to use as your view transform if you are using a computer monitor, because sRGB and Rec.709 have some bigger differences in the shadows and the midtones. It's not an issue when you have a camera-specific IDT: then you can use the correct view transform for your monitor, and everything looks correct.

If your target format is Rec.709, ideally you would use a Rec.709 HDTV monitor as your preview device. Then you would have a true WYSIWYG workflow, for any type of input.

In the ACES workflow, Vegas is working internally with 32-bit floating point values. But you never see those values directly. Everything you see is transformed through the RRT plus an ODT, so that it looks correct for the type of display you're using. ACES doesn't require an advanced display. Any type of display is suitable, so long as you have an ODT for it.

If you want to see the color values that Vegas is working with internally, try changing the view transform to Log (ACEScc). The preview won't look right anymore. It will be showing you the 0-1 ACEScc range of color values and the full ACEScc gamut, mapped to your display with no transformation.

Hello Jacob,

Thanks for making the tutorial for ACES.

Just watched it, and I try figuring out around ACES, grading A7s default PP7 SLog2, and make grading comparison with 'default standard PP1' of A7s.

Whether I did the workflow correct or not, here's some screenshots I got:
Outdoor Scene:

https://dl.dropboxusercontent.com/u/29342552/VegasPosts/ACESScene01-PP1_normal2.jpg
A7s PP1 - default 8bit - no grade.


https://dl.dropboxusercontent.com/u/29342552/VegasPosts/ACESScene01-PP7_SLog2.jpg
A7s PP7 Slog2 - 1/125, F22, exposure compensation +2 - ACES workflow


Indoor scene:

https://dl.dropboxusercontent.com/u/29342552/VegasPosts/ACESScene04-ACEScc-PP1_normal2.jpg
A7s PP1 - 1/50, F4, iso800 - default 8bit - graded with NBFX ColorFast, for comparison purpose, I extend the level to 0-255 range


https://dl.dropboxusercontent.com/u/29342552/VegasPosts/ACESScene04-ACEScc-PP7_SLog2-pic1.jpg
A7s PP7 Slog2 - 1/50, F4, iso3200 MM+2.0 (Manual mode, detected compensation) - ACEScc grading workflow


https://dl.dropboxusercontent.com/u/29342552/VegasPosts/ACESScene04-ACEScc-PP7_SLog2-pic2.jpg
A7s PP7 Slog2 - 1/100, F4, iso3200 MM+1.0 (Manual mode, detected compensation) - ACEScc grading workflow


I try in extreme contrast scenes:

https://dl.dropboxusercontent.com/u/29342552/VegasPosts/ACESScene05-ACEScc-PP1_normal_nograding.jpg
A7s PP1 - 1/50, F4, exposure compensation +2.0 - default 8bit color space, not yet graded.

https://dl.dropboxusercontent.com/u/29342552/VegasPosts/ACESScene05-ACEScc-PP7_SLog2_nograding.jpg
A7s PP7 Slog2 - 1/50, F10, iso3200, MM+2.0 - ACEScc workflow, not yet graded.


https://dl.dropboxusercontent.com/u/29342552/VegasPosts/ACESScene05-ACEScc-PP1_normal.jpg
A7s PP1 - 1/50, F4, exposure compensation +2.0 - default 8bit color space, try brighten the dark part using Fill Light and Color Curves.

https://dl.dropboxusercontent.com/u/29342552/VegasPosts/ACESScene05-ACEScc-PP7_SLog2.jpg
A7s PP7 Slog2 - 1/50, F10, iso3200, MM+2.0 - ACEScc workflow, try brighten the dark part.


Set

That looks decent to me. :) Thanks for sharing.

Do you have any thoughts or tips on the workflow so far?

From my personal experience with S-Log2 on the a7S, when you aim to brighten the shadows a lot, you'll reduce the noise by exposing closer to +3.0 than +2.0. The shadows in S-Log2 are quite noisy compared to a standard picture profile, so you really need the higher exposure. S-Log2's highlight range is about 3.3 stops greater than in a standard picture profile, so you can safely go that high before you have to worry about clipping. It's a shame, though, that the exposure meter only reads up to +2.0. You just need to dial an exposure of +2.0 or below, and then make the adjustment in the camera to reach +3.0.