112
Replies
Kudos for finally putting in the hard work to make managing color in Premiere much more robust!
I also think it's a practical choice to incorporate ACEScct (initially) as a working space rather than design your own 'propriotary'.
- There's a lot to unpack here but from my first rounds of testing there seems to be an issue with working in ACEScct where the appearance doesn't match direct 709 conversion. ACEScct makes a squish of the information above ~0.42 float in all tone mapping models but especially By Channel. This squish is even visible in the scopes.
- Checking Input Tone Mapping seems to clip scene referred data and I wonder why since ACEScct is able to cover a much larger range than a camera encoding. To what is it tonemapping to? Feels like 100nits.
- I notice that when dealing with negative values, output gamut compression Luminance Preserving still retains negative values and Saturation Preserving seems to lock down/clip black. Any info/recommendation as to when which should be used?
- It took me a while to understand all the settings, mostly what is where/when override what etc. Not because of lack of knowledge but plain placement and order. Especially the fact that a clip (source) has a different set of settings than it's instance (sequence clip) in a timeline.
From a perspective of higher end productions sequence clip doesn't make any sense at all and the properties of the sequence clip should be hardwired to the source clip instead but I understand where this came from. But I hope this can be heavily streamlined somehow because trying to explain the processing chain and settings to a beginner in this state would be much more difficult over mechanisms like that of OCIO/ACES/Resolve/Baselight.
^ This is particularly confusing because effects applied to the clip are in ACEScct and not Rec.709. It feels like a 'redundant' piece of information in the wrong place. Perhaps have a look at the way Baselight presents it's settings as information to the user. I think theirs is well defined.
- Looks like nearly all commonly used camera log encodings are finally in the list, however:
1. For Fuji users out there, F-Log2 is probably more present than F-Log. Would recommend adding that soon.
2. EXRs are not yet compatible due to missing Rec.709/Linear, ACEScg and ACES 2065-1 color spaces.
- Thinking ahead, for advanced users, it would be really cool if custom LUTs could be loaded as 'Output Color Space' where we say work in ACEScct and apply the LUT instead. The only challenge is how to manage a split mechanism where your graphics etc can still be managed as Rec.709 but selectively all camera based material gets converted and recieves a LUT.
It would help greatly with applying custom looks to projects without the hassle of using adjustment layers or applying Lumetri to every clip which manage wise is hell. But haven't given how it exactly should work great thought yet.
- I think eventually it would be good to give users freedom of choice for the working color space (if possible with the way the DRTs are designed). Nice to have ACEScct as option, but some may want to grade/work on their native camera space like AWG3/LogC3 or work with CGI only in ACEScg. Perhaps not present it as a full list but some sort of show more option within the dropdown menu would be elegant.
- OCIO should also arrive at some point to help with parity with AE and enable the use of ACES without the need to natively implement it. Although given this new management framework, full native implementation can actually happen now... but it means you also get the responsibility of maintaining it.
I need more time to test interopability with AE etc. Will keep reporting what I find.
That's all I have for now! Keep it up!
Hi Shebbe, here's the detailed response I promised...
- There's a lot to unpack here but from my first rounds of testing there seems to be an issue with working in ACEScct where the appearance doesn't match direct 709 conversion. ACEScct makes a squish of the information above ~0.42 float in all tone mapping models but especially By Channel. This squish is even visible in the scopes.
Here's my response from an upcoming FAQ (still in editing). Whenever you configure a sequence to use output tone mapping to convert from a wide gamut working color space (as set up by the Wide Gamut presets), this can slightly darken the highlights of the SDR source media you’re editing into that sequence. The reason is that on input, both wide gamut and SDR source media are converted to the same single wide gamut working color space (which is ACEScct); at that point, all media is in the same format, and the same tone mapping that compresses the highlights of wide gamut media to fit within Rec.709 output ends up also compressing the highlights of SDR media.
This isn’t a problem for camera original SDR media that needs to have its color adjusted anyway, keeping in mind that all color adjustments happen before the output tone mapping is applied, so you’re always adjusting the source levels. Just grade these clips as you normally would, and you’ll find plenty of latitude and a smooth roll-off in the highlights as you work. However, this can be a problem for mastered SDR media that’s been previously graded and now looks different. This issue can be minimized using the Wide Gamut (Minimal Tone Mapping) preset, which limits tone mapping to only the highlights of SDR clips and has the added benefit of tone mapping out-of-gamut highlights.
What I'll add in this conversation is we're aware this could be improved upon, and we're examining how to address this in the future. Additionally, this is one of several reasons we make the "Direct" presets available, so that projects that need to pass those formats through without alteration have the traditional Premiere Pro workflow. The Wide Gamut presets are, as we describe, ideal for projects consisting primarily of wide gamut material, or ungraded SDR that you intend to grade to a peak of 100 nits from the get-go.
- Checking Input Tone Mapping seems to clip scene referred data and I wonder why since ACEScct is able to cover a much larger range than a camera encoding. To what is it tonemapping to? Feels like 100nits.
Input tone mapping, as the name implies, tone maps on input. As designed currently, this is meant to be an option when the working color space is Rec.709, and to support color fidelity for older projects being imported that used this order of operations. However, being applied on input means that the highlights are compressed before all color and effects adjustments, and image data being squeezed prior to your operations can make further detail difficult to retrieve. This is why we have Output tone mapping and gamut compression available, and in wide gamut workflows Output tone mapping is recommended instead of Input tone mapping, the two aren't meant to be used simultaneously at this time. (for a variety of reasons, Gamut compression is applied, in our presets, on both input and output, and that's fine).
And to further elaborate, Input tone mapping maps to the working space (and Rec.709 corresponds to 100 nits), while Output tone mapping maps to the output color space (100 for 709, or your choice for the HDR formats).
- I notice that when dealing with negative values, output gamut compression Luminance Preserving still retains negative values and Saturation Preserving seems to lock down/clip black. Any info/recommendation as to when which should be used?
Regarding the different tone mapping algorithms, it's horses for courses as different algorithms will provide different handling for different source images. We have no specific guidance to give at this time other than that, and we're looking for feedback from users during public beta about what seems to be working best and worst for them to guide our continued development efforts.
From a perspective of higher end productions sequence clip doesn't make any sense at all and the properties of the sequence clip should be hardwired to the source clip instead but I understand where this came from. But I hope this can be heavily streamlined somehow because trying to explain the processing chain and settings to a beginner in this state would be much more difficult over mechanisms like that of OCIO/ACES/Resolve/Baselight.
We understand there are a lot of controls being exposed. Some of these are a legacy of Premiere Pro's history of development, and for a variety of reasons must be maintained to maintain compatibility with older projects. If it helps, the primary mechanism of color management is found within the Sequence controls, and those are the settings affected by which Color Management Preset you choose.
Regarding Sequence Clip settings, this is a concept introduced previously that we need to maintain compatibility, but it enables sequence-clip-specific gamut compression and tone mapping settings, which are valuable for input tone mapping workflows.
^ This is particularly confusing because effects applied to the clip are in ACEScct and not Rec.709. It feels like a 'redundant' piece of information in the wrong place. Perhaps have a look at the way Baselight presents it's settings as information to the user. I think theirs is well defined.
We appreciate the feedback. We've been trying to find ways of presenting information about what's happening in a space-efficient manner. We'll take this into consideration.
- Looks like nearly all commonly used camera log encodings are finally in the list, however:
1. For Fuji users out there, F-Log2 is probably more present than F-Log. Would recommend adding that soon.
2. EXRs are not yet compatible due to missing Rec.709/Linear, ACEScg and ACES 2065-1 color spaces.
Good to hear there's interest in F-Log2, we'll take that under consideration.
Regarding OpenEXR, that format is not color managed at this time, but we're well aware this is something many customers want, and plan on addressing this in the future.
- I think eventually it would be good to give users freedom of choice for the working color space (if possible with the way the DRTs are designed). Nice to have ACEScct as option, but some may want to grade/work on their native camera space like AWG3/LogC3 or work with CGI only in ACEScg. Perhaps not present it as a full list but some sort of show more option within the dropdown menu would be elegant.
We're being very deliberate about the working color spaces we're exposing as we're trying to keep things streamlined, but are open to feedback about which specific working color spaces would have the most value to the most people.
- OCIO should also arrive at some point to help with parity with AE and enable the use of ACES without the need to natively implement it. Although given this new management framework, full native implementation can actually happen now... but it means you also get the responsibility of maintaining it.
We're aware of customer interest in OCIO. As you mention, we had work to do overall to support more detailed color management in any event, and we've prioritized improving upon Premiere Pro's own color management pipeline as the way to deliver the most value to the most people with the least complexity. As you can imagine, since OCIO has appeared in Ae, the chances of it appearing in other Adobe products in the future are not poor.
I need more time to test interopability with AE etc. Will keep reporting what I find.
That's all I have for now! Keep it up!
We look forward to your feedback on Ae interop, and as always appreciate the detailed feedback and the time you took to give it. Cheers!
Hey Alexis, thanks for touching on all my points!
One important thing I need to clarify is that my input image was an ARRI clip.
Re: Appearance
I think there is a design/mechanical issue when converting scene to scene to display presents a wildly different appearance than direct scene to display.
I'm also not entirely sure what is going on but the precieved 'squish' I was talking about now actually appears in SDR as 'unsquish' rather than ACEScct working space. But in ACEScct now the entire contrast/tonescale gets 'squished' whereas before it was only everything above ~0.41float. The visible line I talked about in the scopes is now seen in SDR as more streched instead of the squished line in ACEScct...
I'm also slightly concerned about the overall rendering/tonescale of the DRT as it seems to be heavily lifted in the shadows. Almost like there is no (preferrential) rendering of the image. Is this desireable/by design? The direct AWG3/LogC3 to Rec.709 conversion also looks more like a rendered image than that of going to ACEScct first.
Re: Gamut compression algorithms
I understand their differences and usecases. I'm actually concerned about managing the image and remaining negative values since Premiere Pro does not offer any export levels management. AFAIK exporting to h264/5 or prores will always scale full to video levels without clipping. So these 'superblacks' would come out in broadcast as illegal. This would necessitate the addition of a Video Limiter in your pipeline which is far from ideal imo. But perhaps this is more a matter of implementing proper video levels input and output scaling management which Premiere really lacks at the moment.
Re: Input tonemapping in ACEScct clipping
Again something seems to behave different now that I booted the project up again. Checking input tone mapping for an Alexa clip now does not alter the image with the working space set to ACEScct as I would expect. It must have been a bug.
Re: Offering choice of working space
I appericiate the caution, but there are also technical reasons to why one would like to have access to the data before converting to another space but still utilize integrated colormanagement. Hope to see it being considered in the future.
Now some new concerns I'd like to express regarding the DRT:
There seems to be no inverseDRT options am I correct? This means we cannot work in ACEScct or any other scene-referred space (if more are added in the future) and use display referred imagery for which the appearance should not change (other than possibly sRGB->Rec.709 gamma change). This makes working in 'wide gamut' a really hard sell. I can't imagine anyone working in Premiere doing only log camera based editing and colorgrading with no addition of text or graphics anywhere.
Mechanically we need to have an option to do Input Tone Mapping on a per clip (at source clip level ideally) basis. But by default preferably that the sequence based Input Tone Mapping checkbox does HDR to SDR tonemapping but also inverseDRT for SDR to HDR so the forward transform nullifies it enabling the use of graphics in a scene referred workflow.
Any plans to make this work?
After Effects Dynamic Links:
Looks like it's being hooked up to the Adobe Managed environment. Surprisingly it automatically adjusts the used working color space as the input color space on Premiere's end. Very nice. But it's also clear that After Effects needs to get away from this legacy ICC based workflow and hopefully implement the exact same mechanism as Premiere has now so we can also get away from that 'scary' list of profiles from the OS that should not be used in almost all cases. And mostly to get parity with appearance so we can make better informed decisions.
I did notice a discrepancy in this current implementation when using ACEScct as working space. All available camera log spaces in After Effects resulted in a white balance shift on Premiere's end. You may want to verify the same chromatic adaptation is used and if even used at all since ACEScct has a different white point. The appearance inside AE did not change when switching the working space there.
All my testing was done on the ALEXA LF sample footage which you can grab here if you'd like to do the same.
I really appreciate this massive overhaul to the color management system as it definitely streamlines the whole color issues people have complained about in Premiere forever... for the most part. However I have two main issues with the new system.
For context I shoot and edit documentaries for businesses and nonprofits. I go through hundreds of Canon MXF files in Clog2 and color grade everything myself. My workflow requires exporting graded interviews, chopping them up in transcription software, and importing back into premiere with an XML, then layering raw B-roll on top of that. I am by no means an expert in the color science field but I understand how it works.
The first issue is that when using the "Direct Rec.709" color management option for my sequence, the automatic conversion for Clog2 built in has a noticeable color shift compared to the official Clog2 lut. Both photos are ungraded.
Top: Official Clog2
Bottom: Premiere Clog2 Conversion
This brings me to the second issue. The obvious workaround is to just choose "Disable Color Management" for the sequence and convert the clips in lumetri, as I've done for years. Before this update, the infamous "Display Color Management" setting was the solution for making premiere display the correct gamma. This option still exists but when the color management is disabled for the sequence, "display color mgmt" has no effect on the picture. This means when I do my standard correction and grade, I crush the shadows too far because the image appears to have less contrast.
I'm not complaining, I think it's great premiere is getting all these updates, however I am just a little confused by all of the different settings. My overall issue is that I'm having trouble knowing what are the correct settings to use. Should I disable color management for all my sequences for consistency? I can't use the Direct Rec.709 option because of the skewed LUT, which would force me to go to each clip by hand and check the "Preserve RGB" option, which I don't have time to do. I have already read through the entire article they posted for the color management update and while did help a lot, It didn't make it clear the right settings to use.
I hope this made sense. Please if you have any advice or information that would be helpful I would love to hear it. I've spent a long time building an efficient workflow and this update has set me back. I'm willing to change my ways though I just want to know the proper solution to color management before I start frantically experimenting. Thanks.
Thank you for the response, Alexis! To answer your question I was only using the Canon supplied transform lut which I downloaded over a year ago from the Canon website. I actually found the solution to my issue though, after perusing that HelpX article again there was one paragraph that said to use "By Channel" for the Input Tone Mapping instead of "Hue Preservation" to avoid color shift and that worked!
Here is a sample with scopes and settings: (The sequence is set to Direct Rec.709 with no settings changed except the input tone mapping under "Sequence Clip" settings, so it's using the premiere default conversion. Is there a way to batch change this settings for selected clips? When set to auto input tone map it just uses hue preserve.)
Hue Preservation
By Channel
The difference is subtle but very obvious looking at the orange vest. I'm sure some people might not see any difference at all. I did hear from Neil Haugen and he mentioned that with color grading there is no right answer since these are just different starting points. However, the bottom photo is accurate to how the scene looked in person and looks just like all other footage I've shot with the C70. My grades tend to be more natural and not overdone so I like to get the most neutral look possible in camera and just make light adjustments in post. Less is more in my opinion.
Here is the same tone map difference on that original clip (using the new built in transform):
Hue Preserve
By Channel
If you still want the source media and the original lut I used here is a dropbox download (790 MB):
I really appreciate you taking the time to respond and I hope this was a meaningful contribution. I've only used Premiere for 8 years but I truly believe it's back on the upswing now with all the new tools and updates. Thank you.
Hey @Grady Foster @Alexis Van Hurkman
I looked into the file and various options
Also compared in Resolve.
Here are a few notes
Grady:
1. Canon recently updated their (official) LUT - not sure it makes a difference but worth checking
2. regardless of the CM used in both systems - your shot seems to look more like the hue-preserve result you posted and less like the by-channel
this is from Resolve when setting for Canon Log 2
in ACES:
in RCM (Resolve Color Management)
Unmanaged with LUT
Compared to PPCM with By Channel
And PPCM Hue Preserve
Lastly - PPCM - unmanaged with LUT in Adj layer
Here are a few thoughts on these results.
1. I wouldn't use the "by channel" tone mapping - as mentioned here it will reduce chroma information from your file and you'll have little control over how - might work differently on different shots - especially with bright saturated colors.
2. your instinct wasn't wrong though - it seems there is a certain heu-shift-thingy happening in other options
3. Gut feeling tells me I'd go with the LUT option - but I need to test more
4. Alternatively - if you interpret the file as C Log 3 (or use the Clog 3 LUT), the results are more tamed & closer to the "natural look" you aimed for. and regardless of how you shot this - both in DVR and PP I preferred that starting point
PP CLog 3 lut
Hey 🙂 long time. hope you're well
Firstly I'd like to say - Thanks! regardless of any early hiccups. its amazing to see such an attentive and professionally conceived addition - it's been too long that PP is "incomplete" in that aspect, and I feel it every time I teach advanced Premiere Color classes
as for the tool
1. I think something is going on with the tone-mapped ACES workflow
A. the Heu preserve options (both) introduce a hue shift - I didn't get that shift when managing with ACES in DVR nor when I used the LUT
PPCM ACES - Hue Prs - shift is on orange towards red
PPCM - LUT - no shift
DVR ACES - no shift
Ref - PPCM ACES - no tone mapping at all (I couldn't replicate this result later)
Ref - PPCM ACES - only automatic input mapping - no shift and slightly resembles DVR ACES
I used ACES for quite a long time on different projects, and I feel the PPCM implementation is different - Does it apply the ACES RRT? It seems a bit less "punchy" than you'd expect from ACES
the ACES IDT list in DVR is quite more generous on the Canon category - why is it so skim in PPCM?
Also -
there seems to be a bug when selecting Auto-Input-Tone mapping then choosing output mapping.
the order in which items are selected (starting from blank) can yields different results - slightly, but different - it's not consistent but drove me crazy -
My gut feeling tells me the Auto-Input and no output tone mapping gives the most "accurate" result
I Agree with @Shebbe - having the possibility to work in native color space - or at least have a few options other than ACES - will be a much welcomed and needed addition
Unrelated directly to the new CM but long-time PITAs in Lumetri that may finally be adressed
1. the comparison window is broken - it works but doesn't update - and in frame/shot mode its buggy and works badly
2. the RGB curves clip luma - even within one Lumetri effect pipeline
3. still no decent camera manufacturer LUT-list
4. the slider ranges are in general not very generous - and dramatically limiting in the color wheels
5. will there ever be an RGB picker?
And again,
Thanks Alexis
This is one of the most pro, relevant and needed updates to PP in a very long time
Best Regards
Hector
Hi Hector,
Appreciate the testing. I'd like to clarify some aspects.
1. I wouldn't use the "by channel" tone mapping - as mentioned here it will reduce chroma information from your file and you'll have little control over how - might work differently on different shots - especially with bright saturated colors.
This is not entirely true. If you work in scene-referred which you do if choosing ACEScct as working space you don't lose information in the file/working space. It's just that the display tonemapping which happens after all your editing and effects will desaturate bright colors faster. In almost all scenarios this behavior is preferred. When you'd want to retain more color information you would grade it to lower it's luminance. As general rendering, by channel looks the best out of the box for most scenes, especially with people.
Here's a simple example with Resolve's hue(sat) preservation(left) vs per channel(right) where you can see that skin doesn't look that preferential on the left.
And another example with Premiere Hue Preserve/PerChannel/ARRIClassicLUT. You do have some degree of control but when adding contrast and saturation, by channel is usually the most natural responding to skin and very bright colors.
...the Heu preserve options (both) introduce a hue shift - I didn't get that shift when managing with ACES in DVR nor when I used the LUT
...PPCM ACES - Hue Prs - shift is on orange towards red
You actually have it backwards. The captured color is more red-ish and stay hue linear in Hue Preserving models. By channel tonemappers skew these tones towards yellow (by consequence of math, not by purpose/design) which is evident by the vectorscope. ACES 2.0 which will release very soon actually has hue preservation aspects as one of the characteristics of it's DRT which is generally an improvement eventhough you sometimes might actually want these artificial skews. Getting into SDR vs HDR matching you'll quickly see why not having skews is more desireable in most cases. In wider gamut displays skewing happens less often because then most colors don't quite reach the end of the gamut. When a skew is artistically built underneath a DRT this adjustment will remain consistent between SDR and HDR rather than suddenly look different.
Here's a typical example of very hot fire (CG explosion) where we take the left (ACES 1.3) for granted in it's appearance because we are so used to presenting fire core as yellow. On the scope you see the heavy curving bend towards yellow. It's true color is actually orange/red which in SDR looks like the right (ACES 2.0).
In this instance we would also prefer the per channel look however in practice this would not match well in HDR whereas with ACES 2.0 in grading the skew could be artistically placed and remain consistent.
Ref - PPCM ACES - no tone mapping at all (I couldn't replicate this result later)
Because you don't apply any added compression or other tweaks of the data you can in fact clearly see that the source colors are more redish and remain linear rather than bending towards yellow.
Ref - PPCM ACES - only automatic input mapping - no shift and slightly resembles DVR ACES
The colors do shift due to clipping. ACES 1.x also does not have any gamut compression or hue preservation hence you may think it behaves the same. You shouldn't use no output tone mapping at all though as everything above 100nits will be clipped rather than rolled off.
the ACES IDT list in DVR is quite more generous on the Canon category - why is it so skim in PPCM?
It's actually the opposite. In the beginning of ACES, Canon provided separate IDTs for different cameras but almost all of them were the same transform. They updated their provided IDT to be just a single one for each log variant just like all other camera vendors do. Resolve hasn't implemented this change and it's actually a bad thing. It makes the list too long and unnecisarily complicated since not all models are shown. Furthermore, the IDTs you see in ACES are not really the official transforms everyone uses. They are separate documents provided for ACES specifically. The general camera color space defenitions come from either the log encoding white paper, which often is publically available, or is provided directly to implementors.
3. still no decent camera manufacturer LUT-list
This is not desireable. Camera vendor created LUTs are a total wild west and the amount of them is crazy at this point. They are also not standardized. You cannot verify it's rigidity, intent or expected input and resulting output. They are just files with a bunch of numbers. Fun fact: The ARRI LogC to 709 LUT shipped in Resolve is actually a monitoring LUT that was scaled to legal levels which makes blacks lifted when used in post. And colorists unknowingly actually liked this appearance despite technically being wrong. Single camera vendors create multiple LUTs for multiple cameras, looks, displays and camera settings. So as you can understand there's simply no point getting into that mess from Adobe's perspective.
What Adobe can do however is as I suggested in another post, offer some mechanic to make the use of LUTs easier. Something integrated into their color management system so it doesn't need to be loaded onto a Lumetri effect per clip or Adjustment Layer.
Hey @Shebbe Thanks for the time you took to answer.
I know how time-consuming this can get. Appreciated
1. I definitely didn't phrase myself well - and did not mean information will be lost from any file 🙂
I also mentioned that this will be more limiting when dealing with brighter, more saturated captured hues
I Graded different safety reflective jackets over the years, and they tend to be a PITA regardless of workflows.
Don't get me wrong... I can see myself relying on a by-channel workflow as implemented in PP just for the sake of going safe(er) and I agree with you that in most common cases it will look just fine as a starting point.
but also... if I have the luxury to be picky - setting up my CM this way isn't optimal - and I prefer choosing one where I'm more aware of my captured highlights saturation - furthermore, I find per-channel a tad aggressive in its treatment - especially from the vectorscope trace in this example, even with the slider at minimum (max sat)
and at least it doesn't shift hues 😉
2. with the utmost respect to your knowledge and passion - I must stay doubtful on this one.
the OP stated that these jackets were more to the orange-yellow hues and most tests in different workflows suggest so too (that regardless of real-world common sense - there are many more orange-yellow safety jackets than orange-red ones... at least to my best recollection)
Furthermore, in your ARRI Isabella test - the Hue Preserve example clearly shows the same reddish hue shift (i'd estimate it at about 3 degrees) on the orange chip, but also on the pink, yellow and warm-yellow ones - not mentioning her skin that appears shifted too. the 2 other examples seem fine - on a test shot I've used and evaluated countless times.
measured on your stills - adding this to the previous test (neither Resolve's ACES or RCM shifted) hints that maybe there is a minor shift involved in the HP tone mapping algorithm
Here's a simple example with Resolve's hue(sat) preservation(left) vs per channel(right) where you can see that skin doesn't look that preferential on the left.
3. by Resolve's hue preserve - you mean Sat Preserve? I don't find is similar to HP in PPCM at all
firstly its part of RCM not ACES
Secondly - it offers superior control over the outcome
and...
😉 it doesn't shift
I guess "by channel" would be somehow the Davinci DRT - which I again find superior in control and its extent.
both don't display the "maybe a hue shift"
In Resolve ACES CM - I have no control over tone mapping (expert checking the ref gamut compress on or off) - unless I use ACES Transform OFX where I get the Parametric Gamut Compress (which I rarely need)
and I'm aware of hue skewing - I think it's not the case here.
I'll run some more tests on my side. but this should maybe be looked into
3. you mention ACES 2.0 - I assume you're using the candidate version? I admittingly didn't get a chance - in what tool/software did you test it?
I'll find time to check out the latest version - I saw Nick Shaw posted a DCTL for release candidate 1 last month
4. I do find some value in the simplicity and direct approach of Camera LUT based Color Management - especially in the very vast world of PP users - sometimes (and up until last week... lol) its just easier to throw the manufacturer LUT on an adj layer - and move on. I agree the current state is messy and cluttered - but it isn't hard to narrow down to the most relevant and recent.
and YES - a new, better lut implementation workflow will be pure bliss! - and a fair alternative to a pre-installed list.
again, thanks for your time 🙂
and knowledge
regards
hector
You totally may prefer the characteristics of a hue preserving model over per channel. 🙂
by Resolve's hue preserve - you mean Sat Preserve? I don't find is similar to HP in PPCM at all
firstly its part of RCM not ACES
Think I lost you here. In which context does it matter if it's RCM or ACES? Premiere doesn't use/implement ACES at all. They just made ACEScct available as an option to use as working/grading space. Their tone mappers are their own.
I guess "by channel" would be somehow the Davinci DRT - which I again find superior in control and its extent.
Yea correct, the DaVinci DRT is a per channel style DRT. Regarding superior in control I'm not sure if anyone ever felt the need to mess with settings of a DRT itself. On probably 99,99% of content you can leave it at default. You typically need to manage negative values from 'clipping' that happens when you convert from input to working space but not always from working to display space.
About the hues... I think we are mixing up two different things in the discussion. Also a bit hard to clearly express with the used words... I'll put it like this:
- Hue shift, where the claim is that the color points to a different hue than the expected one from seeing the object in real life vs the result on the display.
- Hue skew/bend, where object start at a certain hue angle but skews towards another the more saturated and bright it becomes.
The latter is a 'side effect' of per channel tone mappers which hue preserving models try to, well.. preserve.
The former comes more down to Color Appearance Modelling which is a much larger topic than just the tone mapping to a display. There aren't many DRTs out there that use CAM as a foundation. ACES 2.0 does. And it also tries to be hue linear as good as possible. This doesn't necisarily mean everything will have the exact expected hue angle wise, but the presented data will not bend quickly.
Many surface colors tend to be outside of Rec.709 gamut and/or SDR range. There is no mathematically correct way to represent them so in the design of a DRT you need to decide in what way you want to project them back in while maintaining correct appearance balance between those and the tones that do actually fit. Take colors from neutral axis towards Rec.2020 green primairy as an example. These colors are a lot more blue than Rec.709 primairy green. But presenting them as more blue in Rec.709 means it appears less saturated than the primairy of Rec.709 itself. Should it just bend towards 709 green? Do you just let it clip and ride the gamut boundary towards green? Do you keep it hue linear and compress saturation and/or luminance? At the end of the day there is not really a definitive answer, only a preferred rendering apperance.
I currently have the release candidate of ACES 2.0 installed for Resolve yes, but have been keeping an eye on development since the beginning of 2.0 pretty much. Super interesting to follow:)
You totally may prefer the characteristics of a hue preserving model over per channel. 🙂
by Resolve's hue preserve - you mean Sat Preserve? I don't find is similar to HP in PPCM at all
firstly its part of RCM not ACES
Think I lost you here. In which context does it matter if it's RCM or ACES? Premiere doesn't use/implement ACES at all. They just made ACEScct available as an option to use as working/grading space. Their tone mappers are their own.
I actually said I preferred the "By Channel" option, though found it a bit agressive
In DVR - you have 2 seperate CM models: ACES & RCM (Resolve Color Management) - you either work in one or the other, and wether you do it project/timeline based or node based (with Color Space transform or ACES Transform) - you should (and in some case, are limited to) use one of the models
ACES in resolve is generally set on a project or timeline level - and assumes a closed pipeline in terms of user control - you can set IDT and ODT, the ACES reference gamut compression on/off switch and a few minor tweaks.
Do I understand correctly from your answer that in PPCM, ACES is more a "working color space" than a CM pipeline?
RCM is less strict (like android to IOS... lol) - and where all the tone mapping, gamut jugling and working spaces browsing happens - wether Project based, or node based using the fantastic Color Space Transform OFX
Both the Davinci and Sat Preserving DRTs are part of the RCM toolset
guess "by channel" would be somehow the Davinci DRT - which I again find superior in control and its extent.
Yea correct, the DaVinci DRT is a per channel style DRT. Regarding superior in control I'm not sure if anyone ever felt the need to mess with settings of a DRT itself. On probably 99,99% of content you can leave it at default. You typically need to manage negative values from 'clipping' that happens when you convert from input to working space but not always from working to display space.
i don't know if it's 99% and believe its maybe a bit less 🙂
But wider, more sensitive sliders are one thing
and the (unfortunally quite unknown) "Adaptation" slider - which I think most pro colorists would appreciate grately - but I don't mind to be the only colorist on earth to use it - 😉
About the hues... I think we are mixing up two different things in the discussion. Also a bit hard to clearly express with the used words... I'll put it like this:
- Hue shift, where the claim is that the color points to a different hue than the expected one from seeing the object in real life vs the result on the display.
- Hue skew/bend, where object start at a certain hue angle but skews towards another the more saturated and bright it becomes.
The latter is a 'side effect' of per channel tone mappers which hue preserving models try to, well.. preserve.
The former comes more down to Color Appearance Modelling which is a much larger topic than just the tone mapping to a display. There aren't many DRTs out there that use CAM as a foundation. ACES 2.0 does. And it also tries to be hue linear as good as possible. This doesn't necisarily mean everything will have the exact expected hue angle wise, but the presented data will not bend quickly.
I know what's the differnce 🙂 I teach advanced visual math workflows in Resolve and am very experienced in and "fluent" in everything chroma.
Yes - I mean I suspect that something in the Heu Preserv tone mapping algorythm (and not in the "By Channel" one) creates a very slight hew shift - which is totally "different hue than the expected"
Many surface colors tend to be outside of Rec.709 gamut and/or SDR range. There is no mathematically correct way to represent them so in the design of a DRT you need to decide in what way you want to project them back in while maintaining correct appearance balance between those and the tones that do actually fit. Take colors from neutral axis towards Rec.2020 green primairy as an example. These colors are a lot more blue than Rec.709 primairy green. But presenting them as more blue in Rec.709 means it appears less saturated than the primairy of Rec.709 itself. Should it just bend towards 709 green? Do you just let it clip and ride the gamut boundary towards green? Do you keep it hue linear and compress saturation and/or luminance? At the end of the day there is not really a definitive answer, only a preferred rendering apperance.
This goes both ways (is a way of speaking) - One of the roles of a colorist is to understand real world colors and how they look and behave to our visual system (Pointer's Gamut) in order to adjust and sculpt both "realness" and "believability" and "fidelity" into the final look, of course, dealing with its technical limitations.
I like to teach that appreciation and sensibility to the subtractivness, absorption(ess), reflectiveness, iridicense, shine, and other aspects of "the colors of things" is a way to become more than a "tool-colorist" crunching values, ranges and thresholds - and become a bridge between realms - we forget sometimes that our additive systems are an impressive yet fairly faint metameric simulation of the "real" spectral colors - the ones in front of the lense.
so regrdless if a color space can deal with certain colors - I aim to at least be aware of what they looked like IRL when I work out how they'l end up looking - while in other projects its not even an option, from "brand colors" in ads and corporate videos - to proud Art-Directors, that insist on their initial vision and all the way to DPs and Directors - who generally are quite demanding in these aspects.
and that's also (partly) why hue shifts are bad - and should be examined.
🙂
good night
Hector
AdChoices