new cie1931 scopes oddity

if i open the settings and change in the color management-timeline color space = arri logc, the image on the scope goes banana!

why? the color space in RMC declare which display you're targeting and the CIE1931 should obey, but if you don't have RMC, the timeline can be ArriLogC and a LUT is used to target P3DCi (for example).

so, in a non RMC environment, the display target for CIE13931 should choose in the scope menu as well.

why? the color space in RMC declare which display you're targeting and the CIE1931 should obey, but if you don't have RMC, the timeline can be ArriLogC and a LUT is used to target P3DCi (for example).

That is the disadvantage of using LUTs, LUTs are not color space aware.

Using a timeline colorspace, even if you do not use RCM, can be beneficial to set the right scopes and use correct metadata data on export as well.

For color space transforms there are perfectly fine colorspace transforms so why not use those why use a LUT for that?

There is obviously a place for LUTs but I would think the best usage is at the end for some final looks not to do actual color space transforms.

Using RCM or ACES has tremendous advantages over non-colorspace aware LUTs especially if you need multiple destinations. Also metadata is becoming increasingly important for video in the HDR world, using colorspace aware operations can improve workflow efficiency.

Perhaps it would be good to have the ability to declare a result output space, even when not using Resolve's color management.

Currently resolve expects the timeline working space to be the same as the output space, which is often not the case when using your own color space transformations.

This would also be useful for properly tagging renders, which in non-color managed projects currently pull that information from what the timeline space is set to.

why? the color space in RMC declare which display you're targeting and the CIE1931 should obey, but if you don't have RMC, the timeline can be ArriLogC and a LUT is used to target P3DCi (for example).

That is the disadvantage of using LUTs, LUTs are not color space aware.

Using a timeline colorspace, even if you do not use RCM, can be beneficial to set the right scopes and use correct metadata data on export as well.

For color space transforms there are perfectly fine colorspace transforms so why not use those why use a LUT for that?

There is obviously a place for LUTs but I would think the best usage is at the end for some final looks not to do actual color space transforms.

Using RCM or ACES has tremendous advantages over non-colorspace aware LUTs especially if you need multiple destinations. Also metadata is becoming increasingly important for video in the HDR world, using colorspace aware operations can improve workflow efficiency.

your argunemt feel silly to me: if Steve Yedlin for Star Wars give me a creative lut to go from LogC to P3Dci i shlould not use it because "LUTs are not color space aware"? I think he knows and I know what I'm doing even without RCM or ACES.

The issue is not how I go from the current color space to the final display: it can be a LUT, a LOOK, a divine intervention, curves, knobs, DCTL, OFX color transform, a combination of all of those plus grain , is the fact that in non RCM active the "timeline color space" setting is currently serving two conflicting purposes:

1) it declare which math to use in the color timeline, for example, when you use the OFX color space transform or if you change in a single node the color space and gamma to go to Lab.
2) it is used for the scopes and for the transformation to XYZ DCP. plus flagging export deliverables (thanks AlanLouisGordon)

and it create a lot of confusion: if you have a show with all alexa logC material in timeline, that setting must be kept at alexa logC so all the color transforms (THE IMPLICIT RCM ONES) are correct, but at the same time you break case two.
or you do the scope correct and the XYZ DCP correct but the transforms during color are all wrong.

so, my recommendation is: even when we are not in RCM, have both [timeline color space] and [output color space] active and selectable, the former will satisfy case 1 (during correction) and the latter will satisfy case two (export and scopes) like AlanLouisGordon mentioned.

so, my recommendation is: even when we are not in RCM, have both [timeline color space] and [output color space] active and selectable, the former will satisfy case 1 (during correction) and the latter will satisfy case two (export and scopes) like AlanLouisGordon mentioned.

That seems like a reasonable solution!

so, my recommendation is: even when we are not in RCM, have both [timeline color space] and [output color space] active and selectable, the former will satisfy case 1 (during correction) and the latter will satisfy case two (export and scopes) like AlanLouisGordon mentioned.

Yes, pretty please. That would be very useful.

Adding to this topic, right now, if not color managed, the project level timeline colorspace will be used for the metadata on the destination codec.

I would agree to allow the output colorspace to override this (so that another timeline colorspace could be used to reflect the scopes) even in non-managed mode.

But in addition, it may be helpful for workflow purposes, to be able to set the timeline/output colorspace at the timeline settings (Resolve 16 has new timeline specific settings), that way you can have multiple timelines with various colorspace destinations.

The cie chromaticity scope is still useless because it use the [timeline color science tag] while it MUST target the actual display color science and hence should be defined at the scope level.

I agree that this is totally useless. I don't see a case where you want to look at a giant explosion in virtual camera primaries or working spaces. You also can't even zoom out on the plot so forget about looking at something like RedWideGamut.

The plot allows you to add a second gamut but it would be better to always have the output gamut visualized and the source or custom added primaries on top of that.

Not to steal directly from them but just taking a glimpse at how Baselight does it will help a lot.
Hope they'll add improvements in newer versions.

The cie chromaticity scope is still useless because it use the [timeline color science tag] while it MUST target the actual display color science and hence should be defined at the scope level.

Don't shoot me, but is this something you can work around by using external 3rd party scopes? I know Omniscope does actually have different color/gamma spaces available for certain scopes.

Don't shoot me, but is this something you can work around by using external 3rd party scopes? I know Omniscope does actually have different color/gamma spaces available for certain scopes.

True, but the argument still holds I'd say. Just because a third party solution works properly doesn't mean that Blackmagic Design can negate it's shortcomings.

The cie chromaticity scope is still useless because it use the [timeline color science tag] while it MUST target the actual display color science and hence should be defined at the scope level.

Don't shoot me, but is this something you can work around by using external 3rd party scopes? I know Omniscope does actually have different color/gamma spaces available for certain scopes.

I do have external scopes at Company3, but I want this software to be the best possible and having a feature that does not do what it is designed for, drive me nits!!!

I do have external scopes at Company3, but I want this software to be the best possible and having a feature that does not do what it is designed for, drive me nits!!!

100 nits or 1000 nits?

I hear ya: it should just work.