Took some EBU HDR colour bars - inserted them into an existing Slog3.Cine3Gamma flagged Sony XAVC MXF file (thanks to Avid insert edit export) - then put in a 709 PP timeline to see what the results of various AutoLog and ToneMap options are.
Mostly a science experiment so I could get my head around what is occuring - but maybe useful to others figuring out the workflow. The original bars are not designed for Slog3.Cine3Gamma, so the colours will not land on vectorscope targets, plus the export is to a PNG file so levels may be clipped where they wouldn't be to a YUV file.
NB the GIF shows inline when I edit - but not when message is posted, so attached as file.
I'm trying to guess what you were trying to learn ... which is what, precisely? Not to be critical, but to be precise in understanding your intent.
Using a png file embedded in an mxf file might be a source of some uncertainty as is. So I would suggest shooting with the camera itself, perhaps using a good pro level chip chart to create a file to check.
The current process within Premiere for log encoded media can be confusing for sure. As there are different things that each control does, seemingly dependent on what the media is and what other controls are set to do. Interactiveness abounds ...
So there are several ways of working with log encoded media. And I'm presuming that you have the Preferences option to auto-detect log media selected, as that's key for some things below. Such as recognizing the log format in the Interpret Footage dialog.
First ... simply use a normalization LUT in the Input LUT slot of the Interpret Footage dialog, then set the Override-To option to Rec.709. This gets a typical "old-style" LUT based normalization.
A potential problem, is you do not have any ability to 'trim' the field-produced media to fit the expectations of your chosen LUT, so you might get clipping or crushing of data.
Second ... if Premiere recognizes the log media, and has the Interpret Footage option "Use Media Color Space from File" correctly showing the log format as it should, then you can:
Third ... if the log format isn't recognized in the Use Media ... option, or you wish to apply a different choice in the list of the "Override-To" options, select the log format there.
This again, allows for two separate results ...
Fourth ... simply set the Interpret Footage dialog "Override-To" option to Rec.709.
Then you should get a straight, log-ish looking file to again normalize yourself. No matter whether auto-tonemapping is on or off.
So there's several ways to seemingly get to the chosen working place, if my testing of this is correct. And I've spent the last few weeks doing a lot of testing.
I would again emphasize that the auto-tonemapping does not involve any LUT! This will use one of several different specific mathematical algorthms they have constructed for different media types to 'normalize' the image to Rec.709.
The intent is not to create any "Ideal" image, but simply to get the most data through without loss of or harm to the file image data. The expectation seems to be, to simply to get a decent average starting place for the file image.
Dynamic range is modified to fit within Rec.709 without clipping whites or crushing blacks, tonal values are distributed as evenly as possible, and color values are transformed to the Rec.709 coordinates from any original color space.
The image will be a bit different in presentation than it would, if it had been run through a simple normalization LUT. But the data should be in good shape for you to modify to taste and need. A sort of middle-of-the-road image.
I recommend creating several Lumetri presets that would apply shifts to hues and tonal distributions in order to modify the file quickly for particular taste and/or use needs.
Thanks for the response. I presume you didn't check out the gif?
I haven't mentioned LUTs because this was a quick check of what the AutoLog and ToneMap settings do to an image. I'm interested in what PP colour space transforms (that, although not LUTs, are effectively high point count LUTs).
Inserting a PNG in an MXF is a bit cludgy, but it was the only way I could figure of getting some consistent colours flagged as Slog3.Cine3Gamma. if anyone has a better idea I'm all ears.
It's also going to help see the effect when the tone mapping adjustments are introduced.
Obviously how it affects pictures is the acid test, but any proper grading I'm still most likely to take to Resolve.
No clue why you presumed I didn't watch the gif. Of course I watched it!
Like 20 times. Because it kept changing images before I could finish reading any of them, or consider what was shown. And I am, compared to the average bear, a very fast reader.
Still, I can think of several different questions that could be asked or implied from the text plus images of the gif. Hence my request for clarity.
I don't like making assumptions. And trying to answer an assumption seems silly.
I will note that several high end colorists about handed me my head over comments I made, that perhaps seemed to be considering an algorithmic transform to be essentially the same as a high quality LUT.
Technically, LUTs are a table of values where X becomes Y. For say a 33 point LUT, there are only the 33 actual points, and between them there are "simple" extrapolated actions.
Whereas an algorithmic process is a mathematical one for every data point. With the ability to build in changing slopes and separable curves per color.
I do know they have several algorithms, designed and used for different specific media. Each different algorithm applies different processes for dynamic range and for color space transforms, specific to that media.
I've pushed quite a range of media through this process for several months now. I've also communicated about this with a noted teaching colorist who has also run this through the wringer and compared data versus his outboard scopes and Resolve.
His comment: "It all works as it should, just weird how it's presented."
From my testing, that seems both fair and accurate. I am at times puzzled because the few controls we have seem to do different things depending on the media involved and how other controls are set.
And the naming is odd. "Override-to" for instance. In some cases it may be a simple equivalent of setting a metadata or NCLC tag, but in others seems to set a transform in process.
Plus they haven't said anything about the internal processes, other than it's always in 32 bit float mathematically.
So I presume that the working color space is actually set in the Sequence setting dialog. To whatever you select.
And that Interpret Footage and Preferences settings combined with the Sequence auto-tonemapping setting are what guide Premiere on which transform to use from clip color space to Sequence space.
And I'm presuming that as before, the export process starts with original clip data, then applies the chosen effects in order from the sequence, then mathematically creates the new image frames.
Their algorithms seem designed to get all DR data transferred within say Rec.709 without clipping or crushing, and as much color data as can be smoothed into a smaller space. And seem to work.
The algorithms seem to be designed more for "safe" transport of data, and to get a decent starting point for further color work, than for "pretty". They're not there to mimic any say Arri log to Rec.709 LUT.
And that's all any of us non-staffers can really know at this time.
Adobe did a call the other day and showed the yet to be released version of the beta with the CST controls gathered together in one place on a Lumetri settings tab - with some controls for the tone mapping too. Can't remember if it was tone mapping per clip, hopefully so.
There were requests for global + individual clip CST bypass options, so hopefully they took that on board. Also there's some question over how the settings carry between projects/users in multi-user productions or team projects. This was a mess between different versions of PP when it was applying LUTs so hopefully they'll avoid that.
All in all it's looking interesting + Adobe are definitely listening.
Good to hear!