Premiere Pro 2022 and Issues With S-Log3 – It’s Not A Bug, It’s A Feature!

This keeps cropping up more and more as users of Adobe Premiere Pro upgrade to the 2022 version.

What people are finding is that when they place S-Log3 (or almost any other log format such as Panasonic V-Log or Canon C-Log) into a project, instead of looking flat and washed as it would have done in previus versions of Premiere, the log footage looks more like Rec-709 with normal looking contrast and normal looking color. Then when they apply their favorite LUT to the S-Log3 it looks completely wrong, or at least very different to the way it looked in previous versions.

So, what’s going on?

This isn’t a bug, this is a deliberate change. Rec-709 is no longer the only colourspace that people need to work in and more and more new computers and monitors support other colourspaces such as P3 or Rec2020. The Macbook Pro I am writing this on has a wonderful HDR screen that supports Rec2020 or DCI P3 and it looks wonderful when working with HDR content!
 
Color Management and Colorspace Transforms.
 
Premiere 2022 isn’t adding a LUT to the log footage, it is doing a colorspace transform so that the footage you shot in one colorspace (S-Log3/SGamut3.cine/V-Log/C-Log/Log-C etc) gets displayed correctly in the colorspace you are working in.

S-Log3 is NOT flat.
 
A common misconception is that S-log3 is flat or washed out. This is not true. S-log3 has normal contrast and normal colour.
 
The only reason it appears flat is because more often than not people use it in a miss matched color space and the miss match that you get when you display material shot using the S-log3/SGamut3 colorspace using the Rec-709 colorspace causes it to be displayed incorrectly and the result is images that appear to be flat, lack contrast and colour when in fact your S-Log3 footage isn’t flat, it has lots of contrast and lots of colour. You are just viewing it incorrectly in the incorrect colorspace.

So, what is Premiere 2022 doing to my log footage?
 
What is now happening in Premiere is that Premiere 2022 reads the clips metadata to determine its native colorspace and it then adds a colorspace transform to convert it to the display colourspace determined by your project settings.
 
The footage is still S-Log3, but now you are seeing it as it is actually supposed to look, albeit within the limitations of the display gamma. S-log3 isn’t flat, it just that previously you were viewing it incorrectly, but now with the correct colorspace being added to match the project settings and the type of monitor you are using the S-Log3 is being displayed correctly having been transformed fro S-Log3/SGamut3 to Rec-709 or whatever your project is set to.
 
If your project is an HDR project, perhaps HDR10 to be compatible with most HDR TV’s or for a Netflix commission then the S-log3 would be transformed to HDR10 and would be seen as HDR on an HDR screen without any grading being necessary. If you then changed you project settings to DCI-P3 then everything in your project will be transformed to P3 and will look correct without grading on a P3 screen. Then change to Rec709 and again it all looks correct without grading – the S-Log3 doesn’t look flat, because in fact it isn’t.

Color Managed Workflows will be the new “normal”.
 
Colour managed workflows such as this are now normal in most high end edit and grading applications and it is something we need to get used to because Rec709 is no longer the only colorspace that people need to deliver in. It won’t be long before delivery in HDR (which may mean one of several different gamma and gamut combinations) becomes normal. This isn’t a bug, this is Premiere catching up and getting ready for a future that won’t be stuck in SDR Rec-709. 

A color managed workflow means that you no longer need to use LUT’s to convert your Log footage to Rec-709, you simply grade you clips within the colorspace you will be delivering in. A big benefit of this comes when working with multiple sources. For example S-Log3 and Rec-709 material in the same project will now look very similar. If you mix log footage from different cameras they will all look quite similar and you won’t need separate LUT’s for each type of footage or for each final output colorspace.

The workaround if you don’t want to change.
 
If you don’t want to adapt to this new more flexible way of working then you can force Premiere to ignore the clips metadata by right clicking on your clips and going to “Modify” and “Interpret Footage” and then selecting “Colorspace Override” and setting this to Rec-709. When you use the interpret footage function on an S-Log3 clip to set the colorspace to Rec709 what you are doing is forcing Premiere to ignore the clips metadata and to treat the S-Log3 as though it is a standard dynamic range Rec-709 clip. In a Rec-709 project his re-introduces the gamut miss-match that most are used to and results in the S-Log3 appearing flat and washed out. You can then apply your favourite LUTs to the S-Log3 and the LUT then transforms the S-Log3 to the projects Rec-709 colorspace and you are back to where you were previously.
 
This is fine, but you do need to consider that it is likely that at some point you will need to learn how to work across multiple colorspaces and using LUTs as colorspace transforms is very inefficient as you will need separate LUTs and separate grades for every colorspace and every different type of source material that you wish to work in. Colour managed workflows such as this new one in Premiere or ACES etc are the way forwards as LUTs are no longer needed for colorspace transforms, the edit and grading software looks after this for you. Arri Log-C will look like S-Log3 which will look like V-Log and then the same grade can be applied no matter what camera or colorspace was used. It will greatly simplify workflows once you understand what is happening under the hood and allows you to output both SDR and HDR versions without having to completely re-grade everything.

Unfortunately I don’t think the way Adobe are implementing their version of a colour managed workflow is very clear. There are too many automatic assumptions about what you want to do and how you want to handle your footage. On top of this there are insufficient controls for the user to force everything into a known set of settings. Instead different things are in different places and it’s not always obvious exactly what is going on under the hood. The color management tools are all small addons here and there and there is no single place where you can go for an overview of the start to finish pipeline and settings as there is in DaVinci Resolve for example. This makes it quite confusing at times and it’s easy to make mistakes or get an unexpected result.  There is more information about what Premiere 2022 is doing here: https://community.adobe.com/t5/premiere-pro-discussions/faq-premiere-pro-2022-color-management-for-log-raw-media/

15 thoughts on “Premiere Pro 2022 and Issues With S-Log3 – It’s Not A Bug, It’s A Feature!”

  1. Alister,
    Thanks for a good explanation as usual . I’m in Resolve but have begun using CSTs and the overview still helps. How does all this apply to the LUT’s you’ve posted recently though – the New LUTs from Sony and the Arri LUT. Are those designed for the old way of working without CSTs, Or are they meant to applied after the CST is applied? Is it harder to make a “look LUT” for a world in which the CST has already been applied?

    1. Most of the LUT’s I and others provide include the colorspace transform from Log to 709, so only work directly in older workflows. However because you can still either force the log to be treated as 709 or include a CST node that reverts to 709 you can normally still use legacy LUTs. At the moment producing LUT’s for CST workflows is a mine field because each manufacturer is doing their own thing. The only “universal” workflow is ACES and I intend to start producing LUTs for ACES users in the coming months.

  2. This somehow doesnt happen to my timeline. (My Premiere Version is correct).
    When slog3 files imported it shows, that it detects “Rec. 709” in the footage, which obviously is not correct. I can change it to some sort of Rec. Formats (601, 2020, 2100), but none that would say slog3. What am I missing here?

    Thanks and greets from Germany.

    1. Are you on an intel Mac, an M1 Mac or a PC? I think there is different behaviour depending on the operating system you are using.

  3. Benjamin,

    As you have discovered, Adobe Premiere Pro 22.1.2 does not recognize S-Log3/S-Gamut3.cine, but it does recoginize S-Log3/S-Gamut3. Adobe Premiere Pro 22.2 Beta and 22.3 Beta recognize S-Gamut3.cine as well.

    Color Management in Adobe Premiere Pro is clearly at a very early stage. To be completely honest, it almost seems like this was a beta feature put into the production release on accident, considering how little official documentation there is about it and how it is implemented. As Alister says in the last paragraph in the initial post above.

    “Unfortunately I don’t think the way Adobe are implementing their version of a colour managed workflow is very clear.”

    Thanks for writing about this, Alister! Let’s hope Adobe will clarify and improve their color management implementation soon.

  4. Thank you Alister for this post. It honestly is very frustrating how Premiere is dealing with color management. I agree that these settings (project settings, timeline settings, monitor settings and scope settings) need to ALL be in same place and very straightforward.

    I do understand the current workaround but I am getting different results.

    A little background:
    I just got done going through the rabbit hole of fixing the previous color “issue:” videos from premiere looked washed out upon export. I found out that this was actually not an adobe issue but an apple one (apple uses a different color space and gamma that departs from all previous standards) and Premiere uses Rec709 Gamma 2.4.
    Accepting this reality (and that most of my videos will be consumed on YouTube etc on Apple products) the workaround becomes to simply compensate for this color/gamma change with a LUT. Fine. I found the QT gamma compensation LUT to not work, but the LUT made by the YouTube Axia to be excellent for those that are curious.

    However, now, with the latest Premiere 2022, even after I modify footage and force it to Rec709 color space, and then apply my Logto709 LUT like usual, the footage *inside* premiere looks like the washed out export (whereas before the footage looks beautiful inside premiere then washed out when viewing outside of adobe).

    And so when I apply the correction LUT, it looks like what it should without the LUT, and again upon export is washed out again (because the compensation LUT is supposed to make it look ultra saturated etc inside premiere to compensate for the export).

    So it seems to be applying the wrong curve now when you force it back into Rec709 via this new method? It just throws a wrench into the previously functional workaround.

    Does this make sense to you all? I can provide screenshots if desired.

  5. Thank you Alister,

    Personally, I don’t mind tweaking the interpret footage settings. What’s really frustrating to me is that not only there is no way to have default settings that would automatically set the color space, but also there is absolutely no way to change the viewing color space of the proxy media as the interpret footage settings only apply to full resolution clips. So I’d have to deal with blown-out footage as I edit.

    I hope Premiere addresses this issue in the next release.

    1. The issue is that in a colour managed workflow the process has to rely on the metadata for each individual clip as different content will have different gamuts. The viewing colourspace is determined by the project settings and type of monitor being used. Using “interpret footage” is breaking a workflow that is working correctly and that’s why you get a miss-match between the proxies and original media. The proxies match the original media, but by interpreting the original media as something it is not, you break the link. Premiere is working as expected, Log should never look flat, it only looks flat in a broken workflow. Interpreting Log as 709 breaks the workflow again and that’s why your proxies no longer match the log. The footgae is blown out, because it was shot over exposed.

      1. I totally understand what it is meant to be doing, and initially, I thought it would be a great feature to have.

        The issue is that at least with S-Log, the footage is supposed to be over-exposed by a stop or two in order to get the best quality from the sensor, but there is no way to have Premiere under-expose that footage to show you the correct look. Yes, it’ll be graded eventually, but that doesn’t happen until the editing is over.

        The other problem is that when you are viewing proxies, Premiere assumes that your proxies are also Log (they’re not), so what it shows you is like adding two LUTs on top of each other.

        So I’m forced to use the interpret footage settings anyway in order to work with proxies, which renders the feature not only useless but conflicting, to say the least.

        1. S-log3 footage is not “supposed to be over exposed”. But it is sometimes true that exposing a bit brighter can help reduce noise, especially with the older cameras. But even in a conventional workflow, if the log has been exposed more brightly it will appear brighter than normal, this behaviour is not different. For proxies it is now normal to allow the edit or grading application to generate it’s own internal proxies as these will be in the correct colour space, have the correct number of audio tracks and relinking is almost never an issue.

          Unfortunately you will need to learn how to use colour managed workflows as this is where all edit applications are heading because it won’t be long before you will need to deliver in colourspaces other than Rec-709. The days of working in and delivering for a single colourspace are coming to an end.

  6. you just saved my life, nobody knows wtf they’re talking about on forums, thank you for the clear and concise solution!

  7. Had this issue sprung on me with no warning after upgrading to 2022 and was quite impressed with myself when I figured out after a couple of minutes the way to ‘fix’ it was to interpret the footage to 709… Now I discover my ‘fix’ is actually incorrect. Of course it is!

    Take your point that we are going to have to learn colour managed workflows. Are there any good resources you can point us in the direct of?

  8. This is just about the dumbest workflow I’ve experienced… I have apparently been doing everything wrong for 10 years and now I have to change my ways…

    I really don’t like it… Especially because all my projectfiles are fucked now :/ everything is double graded… and everything I’ve used cinematch on is bunked as well…

    So here’s to me comitting sepuku over premiere…. fml

    1. Colour managed workflows are going to become essential in the future as we will need to work in more than one colourspace. So it is more or less inevitable that most professional edit and grading applications will move to them.

      But – when BlackMagic added colour managed workflows to Resolve they gave users the option to choose between a colour managed workflow or a conventional workflow, so you can continue to work conventionally or to take advantage of the many benefits that good colour management brings.

      Adobe haven’t done this and they didn’t document or properly explain the changes they have made, which for a business that is supposed to be one of the best for managing images and digital colour is awful. Adobe seem to take one step forwards, two steps back these days.

      My advice is forget Adobe. Try DaVinci Resolve. You pay once for the full studio suite and it is fast, very, very powerful and a much better colour grading tool than Premier.

Leave a Reply to Anders Dall Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.