who/what "decides" the look of davinci wide gamut?

I'm trying to understand the reason why everything looks at it looks. if i apply an input color space conversion to for example sony slog 3 footage in the davinci wide gamut color space, it gets a certain look depending on the output color space. But what is behind that? did someone decide that the look is "correct"? or is it purely a mathematical conversion?

Color space conversion naming lends itself to the interpretation that it's a technical/mathematical procedure of converting one set of known numbers to other set of known numbers, not artistical. LUTs can be both "look" and "technical".

The short answer is math.

The long answer is a complex interplay between the human visual perceptive system, the physical properties of light, the optical devices we use to record that light, and the limitations of the storage devices and transfer methods we use to move that information into new eyeballs. Oh, and displays.

I think in the case of DaVinci Wide Gamut, BMD needed a larger space to perform mathematical transformations accurately because camera manufacturers and display manufacturers are pushing the boundaries of what's possible there; higher bit depth recordings, and higher dynamic range and wider gamut display technology. So, BMD's mostly trying to support the math, and they're probably looking to future-proof the math, too.

Also, I think that's the big difference between DaVinci Wide Gamut and a color space designed by any individual manufacturer. Arri, Red, Sony, etc decide on their own spaces because they have insight into the manufacturing processes and sensor technology to which they have access. DWG is an intermediate space which needs to contain them all.

Now, why they need something like that when ACES is already a thing is what I wonder.

That is probably the biggest reason why i'm a little confused. Can i see it some kind of alternative to ACES? because the workflow feels very similar, just have the feeling eventually in the end result the contrast curve is slightly different, but it gets close.

It's not just the technical transforms shuffling gamuts and curves, DWG workflow contains picture rendering too, similar to RRT in ACES, which is subjective and serves the purpose of producing a "nice looking image", which obviously is beyond math. I guess they thought they can do better than ACES with proprietary system.

Yes, it can be seen as an alternative to ACES. There is also the discussion about ACES relying on a specific attitude what the RRT considers 'cinematic', whatever that might be.
Rippletraining has a nice video tutorial to explain RCM in 17, by Alexis van Hurkman himself.

Yes, it can be seen as an alternative to ACES. There is also the discussion about ACES relying on a specific attitude what the RRT considers 'cinematic', whatever that might be.
Rippletraining has a nice video tutorial to explain RCM in 17, by Alexis van Hurkman himself.

I'll definately check that out, thanks for pointing me there.

similar to RRT in ACES, which is subjective and serves the purpose of producing a "nice looking image", which obviously is beyond math

So you could say that at some point, there were people at the Blackmagic office discussing things like hey, the conversion should be more contrasty, or less color, or a different curve, or whatever, and from that point on it was a "copy-paste" from different camera profiles?

Those folks were at the academy, not at BM.

Proof is in the pudding. I’ll try adding DWG gamut and curve definitions as they are described in whitepaper to Nuke and see if it is enough to produce identical result with Resolve or not. If it does, it is a pure technical transforms system, but from what I gather currently I seriously doubt it is.

Manual that comes with v17 states about DRT-s that:

DaVinci: This option tone maps the transform with a smooth luminance roll-off in the shadows and highlights, and controlled desaturation of image values in the very brightest and darkest parts of the image. This setting is particularly useful for wide-gamut camera media and is a good setting to use when mixing media from different cameras.

To me this sounds exactly like what purpose of RRT is in ACES system. And since this smooth roll-off and controlled desaturation is not detailed, it is currently impossible to implement it anywhere outside Resolve. Preset "Davinci Wide Gamut" uses this DRT so it will be the defacto tonemapping for DWG projects. If someone decides to output DWG data into a file, results of this can't be replicated anywhere outside Resolve currently due to lack of information about it.

From what I understood there is no such thing as "pure technical". There will always be a "look" applied because we are dealing with having to convert linear light to something display referred and compensate for the way humans perceive light vs what the display can produce.

I know there has been discussion on ACES' 'default' look being to contrasty because people were used to things like the Default Arri to 709 LUT etc that was designed for a working space of 709/set monitoring.
The other story was about the film look that ACES 0.1 had which was removed after as ACES intends to be purely reference rendering based. Removing any subjectivity aside from human perception. It's still available as an LMT for people that would like to use it. It emulated some Kodak stock I think.

I think saying it's too much contrast is an overstatement, and ACES as well as Davinci Colormanaged provide great starting points to do actual grading. I think the misconception is that the output look is already final or something but working in DWG or ACEScc/cct mean you still have huge control over color and dynamic range which makes the new HDR wheels especially powerful as you'll be able to segment the actual camera's dynamic range instead of a 0-1 rec.709 (100nit) range.

DWG isn't doing anything to the look though. It's the Resolve Colormanaged output system (called DaVinci) that does this. Others are ACES' RRT, RED's IPP2, T-CAM etc. Working in DWG/Intermediate(space/gamma) just means incoming data is converted to that colorspace to work in, which is log just like ACEScc/cct, and converts back to chosen display space afterwards. Before DWG you could already do a simliar workflow with any other space.

1.png (17.31 KiB) Viewed 2718 times

This way of working exists for the same reason ACES was designed to some degree. Being able to switch the output intent to other displays/products without breaking what you have done to the content and will require minimum adjustments to optimize for those displays.

I think the main reason they created it was to provide a working gamut that incorporates ACEScg, rec. 2020 and Arri Wide Gamut as that will be all the space you need to work in and you'll never output to anything greater. (Unless we surpass rec2020 displays in the very very distant future).

Here you can see the difference in data on the input to work with in the HDR zone panel but as we're outputting for the same display there is no visual change in result. But my color decisions would be based on the small output gamut in the "traditional" workflow which imo is bad for futureproofing your work and it limits your control over the image.

2.jpg (226.87 KiB) Viewed 2718 times

3.jpg (234.02 KiB) Viewed 2718 times

There is some great content about this from Daniele Siragusano. Can highly recommend to watch these.

From what I understood there is no such thing as "pure technical". There will always be a "look" applied because we are dealing with having to convert linear light to something display referred and compensate for the way humans perceive light vs what the display can produce.

There are lots of transforms going on where both source and target are scene referred. All gamut transforms are techincal. Transfer function changes usually also. Having display referred target doesn't mean there is a look introduced. Take for example linear sRGB data from render engine. Applying sRGB transfer function on top and feeding it to monitor does not impose any specific "look" in this sense.

DWG isn't doing anything to the look though. It's the Resolve Colormanaged output system (called DaVinci) that does this. Others are ACES' RRT, RED's IPP2, T-CAM etc. Working in DWG/Intermediate(space/gamma) just means incoming data is converted to that colorspace to work in, which is log just like ACEScc/cct, and converts back to chosen display space afterwards. Before DWG you could already do a simliar workflow with any other space.

DWG itself doesn't, but none of the ACES colorspaces does anything to the look either, they are perfectly neutral and invertible. In both systems look comes from render transforms, difference is that for ACES they are open, can be customized or discarded at will, while here it is a proprietary system which can't be replicated outside. Just having a new working gamut that is a bit wider than existing ones isn't imho a very good argument, they could have just used ACES AP0. What makes me cautious is the probable underlying assumption that DWG data might "escape" Resolve and thus they limited the gamut extent to make it not fall apart in lower bit depth exports (internal 32bit float processing doesn't need this).

There are lots of transforms going on where both source and target are scene referred. All gamut transforms are techincal. Transfer function changes usually also. Having display referred target doesn't mean there is a look introduced. Take for example linear sRGB data from render engine. Applying sRGB transfer function on top and feeding it to monitor does not impose any specific "look" in this sense.

Ah, you are totally right. Transforms themselves don't apply a look. I know you can transform in and out of display spaces. That side of the pipeline is pure technical.

But simply transforming source primaries to target primaries isn't perfect in regards to resulting in a "perfectly neutral" image no?
Which is why the ACES RRT, IPP2 or Resolves system exist in the first place right? To do tonemapping in a way that makes more sense to the human eye and that best fits the intended output device.

Just having a new working gamut that is a bit wider than existing ones isn't imho a very good argument, they could have just used ACES AP0. What makes me cautious is the probable underlying assumption that DWG data might "escape" Resolve and thus they limited the gamut extent to make it not fall apart in lower bit depth exports (internal 32bit float processing doesn't need this)

Hm maybe so, but I don't think Blackmagic is expecting users to store their data in 10bit DWG/Intermediate prores or something. Or maybe they do, it's called Intermediate after all....
From what I gathered is that in general people are used to grading in log and AP0 isn't used because that would make the tools behave in unpredictable ways. DWG is just wide enough to cover all the needs in regards to output up till rec2020 whilst still feeling natural to move colors in. Then why not AP1? Well, it's Blackmagic. They want everything to be their own product and workflow, which is good in some way as long as they keep providing other industry standard options like ACES. And nothing is stopping you from choosing ACEScct as working timeline space instead but still use DaVinci as the output rendering transform. Davinci Wide Gamut has nothing to do with Resolve Colormanaged in that regard.

Maybe I'm understanding you incorrectly or lack a bit of information, I'm not a color scientist

Noted Blackmagic co-manual writer Alexis Van Hurkman has a very timely 2-1/2 hour video tutorial out on Color Management in Resolve 17, and he has a specific section on DaVinci Wide Gamut:

https://www.rippletraining.com/products ... esolve-17/

Mixing Light also has had several discussions on what the new color management options mean for colorists:

https://mixinglight.com/

[Both are not free, but I think the costs are modest, particularly if you're intent on digging deep into the intricacies of Resolve.]

I think it's fair to say there are many, many new color options for finishing in 17. New options are good, but they also give you the flexibility to work "the old way" if that's your preference. We live in a complicated world these days, where there's a lot of camera spaces, delivery spaces, and new requirements from broadcast and streaming services. I think with Resolve, it's worth experimenting, reading the manual, going through the tutorials, and finding a way to work that does what you need it to do.

I gotta say, I've never been impressed with ACES because I dislike the way the controls respond, and I feel like I have to "fight" it too much in order to get what I need done. Resolve's new RCM2 looks on paper to have addressed a lot of those concerns, giving us the benefits of ACES with much fewer drawbacks. I'm definitely going to try to embrace it once we make the switch to 17 in a few weeks.

But simply transforming source primaries to target primaries isn't perfect in regards to resulting in a "perfectly neutral" image no?
Which is why the ACES RRT, IPP2 or Resolves system exist in the first place right? To do tonemapping in a way that makes more sense to the human eye and that best fits the intended output device.

Depends on what you mean by perfectly neutral. What I mean by neutral is that you don't mess with colors because they "look wrong". But it is gray area, because "it looks wrong" is already somewhat applied when designing camera gamuts.

Hm maybe so, but I don't think Blackmagic is expecting users to store their data in 10bit DWG/Intermediate prores or something. Or maybe they do, it's called Intermediate after all....

They don't tell. I have a feeling it will become a "thing", partly due to very high number of Resolve users. Baselight users don't try to produce T-Cam prores file because most of them know very well what they are doing and it isn't actually possible either (I think..). With Resolve, it is a bit different.

From what I gathered is that in general people are used to grading in log and AP0 isn't used because that would make the tools behave in unpredictable ways. DWG is just wide enough to cover all the needs in regards to output up till rec2020 whilst still feeling natural to move colors in. Then why not AP1? Well, it's Blackmagic. They want everything to be their own product and workflow, which is good in some way as long as they keep providing other industry standard options like ACES.

AP0 isn't linear/log, it is a gamut. Just as DWG isn't log by itself, it is a gamut. Transfer function is described separately and combining them produces DWG colorspace, like combining AP0 and linear transfer function produces ACES2065-1 and AP1 and specific log curve produce ACEScc. What "feels natural to move colors in" has to do with actual gamut is questionable, DWG gamut axes don't align with rec709 or any other gamut mainly used in grading, it has more to do with log encoding than gamut itself.

And nothing is stopping you from choosing ACEScct as working timeline space instead but still use DaVinci as the output rendering transform. Davinci Wide Gamut has nothing to do with Resolve Colormanaged in that regard.

I can, but it isn't helping me. Just to outline a few problems vs ACES:
Without DRT descriptions and whole color pipeline it is not possible to produce same output image in other softrwares, meaning it is not possible to view DWG (or any other source data) the way it looks in Resolve.
Due to 1. it is not possible to apply grade LUTs in vfx for example to see what graded shot is supposed to look like.
Same problems pollute all management systems which employ specific gamut compressions and tonemapping methods but serving DWG as a substitute to ACES will probably produce a situation where people think it actually is a substitute to ACES while it isn't. We'll see, as long as it is kept inside Resolve I don't object