FS700 Slog2 PP Reds look Orange

[sandor82]

I've been shooting with the FS700 Slog 2 PP so I can record onto my Odyssey 7Q.
I've started to notice the reds in my footage appear very orange. I figured this was due to the flat image of the S Log2 settings. However, when I take the footage into post, I run into the same issue. I'll put a curve, mess with the saturation, and what's suppose to be the reds turns into an even contrasted orange. Not good when shooting for a client that has a red logo.
Have any of you run into this and resolved this?
I've take this issue with a tech from Sony in Jersey. He said he noticed the red looking orange on Slog2 on his end too. He took a few weeks to research and finally got back to me and said the techs in japan said to add a LUT in post and that should solve the inaccurate colors.
This is definitely a Picture Profile setting and not the 7Q. Even the other Picture Profiles I used on the FS700 render out he color red accurately. Has anyone else run into this?

 

[nyvz]

Nothing is wrong with your camera, that's S-Gamut. It's a wide color gamut storage container, not a color-accurate rec709 monitoring colorspace. Just drop the appropriate Sony 709TypeA LUT on your footage and suddenly your reds are redder than you'd ever want.

I had the opposite problem on a job before the 7Q had real LUTs and was using primary red gels on some lights and really liked how they were looking on camera in SLOG2 and then in post most of the appropriate LUTs restore the red to a much much too red color and I just had to qualify them in the grade and push the hue more orange the way I saw on set.

 

[paulcurtis]

+1 to Noah.

SGamut has different primaries for RGB, meaning that it's definition of what Red is is quite different to what your monitor (sRGB) definition of Red is. This allows the SGamut colorspace to store a wider range of possible colours. It's an acquisition colorspace.

In order for you to be able to grade that you have to convert from one colorspace to another.

The easiest way is to use a LUT to do this, or the more accurate way is to use a matrix (but that largely depends on what you're grading with).

The only downside with SGamut conversions are that Sony bake the white balance in and therefore any LUT you use should be based around the white balance you are using. Of course in actual practical reality does this make such a difference? Well, not really. That's one reason why SGamut3 is better.

cheers
Paul

 

[brazzam]

Excellent info, Noah and Paul.

Paul, might I inquire what your workflow is to convert from SGamut to sRGB? Do you have a specific LUT or matrix you use?

Thanks!

 

[paulcurtis]

Excellent info, Noah and Paul.

Paul, might I inquire what your workflow is to convert from SGamut to sRGB? Do you have a specific LUT or matrix you use?

Thanks!

Depends what i need. If it's vfx bound i would use a matrix in Nuke to do the conversion, i can change colour temperatures at the same time and maintain scene linear light, i would generally move SGamut into BetaRGB space because it pulls in the reds nicely. So that's SGamut capture -> BetaRGB but being displayed in sRGB. Yes, colorspaces are a pain sometimes!

If in PPro or something for eyeballing i'm finding LUTCalc an awesomely easy way to take an input colorspace and generate something in the ball park, so a simple LUT that takes SLog2/Samut to Rec709A/Alexas709A can look really nice. In PPro pop that in the InputLUT of the Lumetri panel and adjust to taste.

PPros working space is sRGB/709 primaries and gamma 2.2. There's little point in trying to work in anything else than 709 at the moment. I find Arris version of 709 nicest. The 709A tone curve has a better roll off than normal 709 and the specific primaries of their 709A space just seem a little more organic than Sonys version...

hope that helps

cheers
Paul

 

[Tom Roper]

I would not use an input lut before grading based on what Alister Chapman has said previously. It was my understanding if you did that, you would be grading in a lut truncated/reduced 709 color space. He recommends putting the lut on the *output* so that the grading is performed within the larger YRGB DaVinci space or ACES. In fact, I use the latter.

 

[nyvz]

Yes I think it is certainly the prevailing wisdom that most LUTs should go at the end of your order of operations. Another benefit of that is it's easier to do logarithmic corrections to your log footage as well pre-LUT.

 

[Razz16mm]

Resolve provides a two step input/output lut method that does a mathematically correct conversion between any of their supported color spaces. Under the project settings lookup table menu you pick either a 1D or 3D lut that matches your camera color space and converts it to Resolves internal linear YRGB32 color space. So you would want the Slog2 to linear input lut. The output lut for your destination display color space would be the linear to sRGB/REC709/DCIP3 display color space as appropriate. I use this process to convert from BMDfilm to sRGB for web videos. If you monitor is properly calibrated for the destination color space, Resolve's internal monitor screen should look virtually identical with your graded export footage on your own monitor, and should be pretty close on other monitors in the same color space.
The beauty of this two step approach is that a single camera input lut can deliver accurate finished grades to different color spaces from one grade in your monitor color space. If you lined up three displays calibrated for each of the above color spaces, your sRGB grade should look pretty much the same on all three from color space appropriate delivery source formats.
Note that this is just for correct color space conversion, and is independent of any luts or adjustments you may apply in grading nodes. By default Resolve monitors in the output lut color space and the scopes are calibrated for that too. But if you are grading on a monitor calibrated in one color space for delivery to another, you can set a separate monitor and scopes output lut while leaving your primary output lut set to the delivery color space.
Resolve settings screen sample from one of my workflow tests:

And the Vimeo H.264 export of the above grade:

The only issue I have had with this approach is that third party grading luts applied in nodes may not play well if they were made with some other color workflow process.

 

[pythonman]

The issue seems to be that SLog2 on the FS700 does not render colours in the same way as SLog2 on other cameras. I agree that by default the colours are just plain wrong with SLog2 on the FS700, including making reds appear orange. If I shoot SLog2 on the A7S for example, the colours are far more accurate.

All the standard SLog2 LUTS (including the ones supplied by CD with the Odyssey) do not convert the FS700 Slog2 colours accurately as they don't appear to be customised to the FS700's specific version of SLog2 (or the peculiar colour space of the FS700 when in SLog2).

Take a look at the thread "Better LUT for good skin tones - for Odyssey 7Q+ & FS700 ?" where if you wade through the posts you'll see myself and jonbetzfilms have been trying to figure out a solution, utilising a Spydercheckr 24 colour card. We seem to be cracking it.

I will state again, I am no expert at this, and certainly don't really understand all the technical gobbledegook that surrounds colour grading, but all I want is a colour-accurate result!

 

[paulcurtis]

I would not use an input lut before grading based on what Alister Chapman has said previously. It was my understanding if you did that, you would be grading in a lut truncated/reduced 709 color space. He recommends putting the lut on the *output* so that the grading is performed within the larger YRGB DaVinci space or ACES. In fact, I use the latter.

It depends what the LUT is doing.

A creative LUT, a film look or emulation then sure - right at the end of the chain

But a technical LUT - to change exposure, to colorspace convert, to change gamma - that should be first in your chain.

The working space you are grading in depends on the application. So in resolve that's a 32 bit float environment AFAIK. You should never truncate or loose anything within that space. I also presume that Resolve is internally in linear space as well.

Whereas PPro is a 2.2 gamma space and all the effects have to convert from that to their own space and back again, depending on what the plug-in is doing. i.e, Lumetri goes from 2.2 gamma, via an Input LUT into linear, does it's thing, then reverses back into 2.2 space at the end of the chain.

cheers
Paul

 

[paulcurtis]

The issue seems to be that SLog2 on the FS700 does not render colours in the same way as SLog2 on other cameras. I agree that by default the colours are just plain wrong with SLog2 on the FS700, including making reds appear orange. If I shoot SLog2 on the A7S for example, the colours are far more accurate.

All the standard SLog2 LUTS (including the ones supplied by CD with the Odyssey) do not convert the FS700 Slog2 colours accurately as they don't appear to be customised to the FS700's specific version of SLog2 (or the peculiar colour space of the FS700 when in SLog2).

Take a look at the thread "Better LUT for good skin tones - for Odyssey 7Q+ & FS700 ?" where if you wade through the posts you'll see myself and jonbetzfilms have been trying to figure out a solution, utilising a Spydercheckr 24 colour card. We seem to be cracking it.

I will state again, I am no expert at this, and certainly don't really understand all the technical gobbledegook that surrounds colour grading, but all I want is a colour-accurate result!

That's the great thing about standards - there are so many to choose from

You are right, the Slog2 out of the FS700 is not in SGamut as far as i can tell. Although i'd also argue that the A7s isn't much better - it was the A7sII that finally sorted all the colour stuff out.

Don't forget to not mix up Slog2 (which is a gamma curve) and SGamut (which is the colour gamut). Those two together make up a colorspace.

The Slog2 gamma curve is non standard too (it's has a bit of an S curve on top) but that's fine, because it's just maximising the range from the camera.

The gamut that the camera is outputting is non standard though, it's not SGamut.

The problem is more complicated because those 7Q+ LUTs are someones conversion from the FS700 native raw space to match the SLog2 out of the FS700 rather than match a standard Slog2. The FS700 does not output SGamut in RAW, by the very nature of it being RAW it has it's own colorspace.

It's all a mess. It always has been and drives me nuts.

The best route for FS700 stuff is RAW -> SLog2 so long as your RAW work is done in a colorspace that doesn't clip the reds. My personal RAW workflows involves using a beta of a plug in that's not release yet (but i hope would be soon).

I'll have a look at that thread.

cheers
Paul

 

[paulcurtis]

Resolve provides a two step input/output lut method that does a mathematically correct conversion between any of their supported color spaces. Under the project settings lookup table menu you pick either a 1D or 3D lut that matches your camera color space and converts it to Resolves internal linear YRGB32 color space. So you would want the Slog2 to linear input lut. The output lut for your destination display color space would be the linear to sRGB/REC709/DCIP3 display color space as appropriate. I use this process to convert from BMDfilm to sRGB for web videos. If you monitor is properly calibrated for the destination color space, Resolve's internal monitor screen should look virtually identical with your graded export footage on your own monitor, and should be pretty close on other monitors in the same color space.
The beauty of this two step approach is that a single camera input lut can deliver accurate finished grades to different color spaces from one grade in your monitor color space. If you lined up three displays calibrated for each of the above color spaces, your sRGB grade should look pretty much the same on all three from color space appropriate delivery source formats.
Note that this is just for correct color space conversion, and is independent of any luts or adjustments you may apply in grading nodes. By default Resolve monitors in the output lut color space and the scopes are calibrated for that too. But if you are grading on a monitor calibrated in one color space for delivery to another, you can set a separate monitor and scopes output lut while leaving your primary output lut set to the delivery color space.
Resolve settings screen sample from one of my workflow tests:

Hi Razz,

That confirms that resolve is linear space, good to know.

And you're right, you need to convert that source footage into resolves internal primaries to be able to work with it properly. And you decouple the output from the input.

BMDFilm is a special case, because (from other threads about this) it's not a colorspace per se, but the original camera RGB and that conversion is all internal in Resolve, being what it's for. It's my understanding that these conversions are not public knowledge and are tuned to their cameras, which makes perfect sense.

But in the case of Slog2, you need to linearise the tone curve (that's the Slog2 to linear LUT) and also to convert from what gamut the footage is in, into resolves internal primaries (probably Rec709). I believe that Slog2 to Linear LUT is just a 1D LUT for the gamma conversion). Ideally you'd need something else to turn SGamut into a known space. You wouldn't really want to just suck in SGamut colours and pretend they were sRGB, because as we all know it's too yellow)

The issue here is that the Slog2 footage being talked about is not a standard colorspace and that conversion is not ideal.

cheers
Paul

 

[Razz16mm]

Hi Razz,

That confirms that resolve is linear space, good to know.

And you're right, you need to convert that source footage into resolves internal primaries to be able to work with it properly. And you decouple the output from the input.

BMDFilm is a special case, because (from other threads about this) it's not a colorspace per se, but the original camera RGB and that conversion is all internal in Resolve, being what it's for. It's my understanding that these conversions are not public knowledge and are tuned to their cameras, which makes perfect sense.

But in the case of Slog2, you need to linearise the tone curve (that's the Slog2 to linear LUT) and also to convert from what gamut the footage is in, into resolves internal primaries (probably Rec709). I believe that Slog2 to Linear LUT is just a 1D LUT for the gamma conversion). Ideally you'd need something else to turn SGamut into a known space. You wouldn't really want to just suck in SGamut colours and pretend they were sRGB, because as we all know it's too yellow)

The issue here is that the Slog2 footage being talked about is not a standard colorspace and that conversion is not ideal.

cheers
Paul

You still need to do apply the linear to SRGB/REC709 output to finish the conversion. Resolves internal space is linear 32 bit YRGB, not a display color space. At least from the published graphs I've seen S-log is just a gamma compression curve. Resolve applies the correct LUT to linearize it whether it is 1D or 3D.

BMDfilm is a very broad color gamut that seems to be camera agnostic. It ignores the camera's color matrix meta data and substitutes its own matrix values. It corrects the internal color matrix issues with the current D16 firmware and eliminates the out of gamut chroma issues that occur if you try to grade it directly in REC709/SRGB color spaces. I use it as sort of an ACES like workflow

Sony to me has always been capable of decent reds. Canon's color matrix on the DSLR's and on my old GL2 tends to bias reds toward orange as do the BM cameras. I don't know if the C-series is similar. I think it is done to produce better skin tones.

 

[paulcurtis]

You still need to do apply the linear to SRGB/REC709 output to finish the conversion. Resolves internal space is linear 32 bit YRGB, not a display color space. At least from the published graphs I've seen S-log is just a gamma compression curve. Resolve applies the correct LUT to linearize it whether it is 1D or 3D.

BMDfilm is a very broad color gamut that seems to be camera agnostic. It ignores the camera's color matrix meta data and substitutes its own matrix values. It corrects the internal color matrix issues with the current D16 firmware and eliminates the out of gamut chroma issues that occur if you try to grade it directly in REC709/SRGB color spaces. I use it as sort of an ACES like workflow

Sony to me has always been capable of decent reds. Canon's color matrix on the DSLR's and on my old GL2 tends to bias reds toward orange as do the BM cameras. I don't know if the C-series is similar. I think it is done to produce better skin tones.

Slog2 is thrown around meaning lots of things, i think definitions need to be more precise.

What we've got here is SLog2 gamma curve. That's fine, there is a LUT to linearise that. (I could go off on one about how the FS700 Slog2 isn't quite the same as the 'official' version but that's minor)

Then we've got the question what gamut is the footage in. And that's where it gets tricky. If we're talking FS700 Slog2 off camera, then there is a general belief that it is SGamut, but i'm not so sure. Then we've got the Slog2 created by the O7Q from the RAW signal. We don't know what colorspace this has been converted in. It could be sRGB, Rec709 or SGamut - either way the LUT within that space is attempting to generate the kind of colours the internal SLog2 is showing.

But if the internal SLog2 is actually SGamut and the Slog2 LUT out of the O7Q is sRGB then that just confuses things further because you end up with a matching image but in two different spaces.

To clarify : i am talking about the primaries that are being used in each of these cases. The primaries that dictate the colour math. In other words you have an RGB value of say, 255,0,0 which is red right? But what does that full red actually look like? And that's what the primary tells us. This allows us to compensate for display and capture.

More recently the A7x range of cameras has been a lot more explicit in allowing mix and match gamuts and gammas. So Slog2 with sRGB primaries is easy. So you can side by side Slog2/Rec709 with Slog2/SGamut3 - if you take both into Resolve and apply the appropriate colour transform then they should both look the same on screen.

TBH even allowing for changing gamut on the A7x series is sort of pointless because i don't believe the camera can see anything outside 709 anyway. But the choice is there to aid in post workflows but also serves to confuse things no end.

The BMD Film shouldn't ignore the cameras own matrix because then nothing would look right?

And yes, the Reds on Sonys are wonderful actually, almost CCD like when done properly but that's the problem, the Reds are out of gamut of lots of workflows. It took Sony until SGamut3 and the FS7 to provide an off the shelf solution.

cheers
Paul

 

[Razz16mm]

If the O7Q raw recording is 12 bit CinemaDNG, then the default color space would be CIE, essentially the native spectral response of the sensor color filters, not a defined color gamut. Sensor native gamuts are in general much broader than encoded video gamuts. Don't know what kind of color matrix metadata the O7Q would apply to that. Maybe Mitch Gross could help us out with that one.

 

[paulcurtis]

If the O7Q raw recording is 12 bit CinemaDNG, then the default color space would be CIE, essentially the native spectral response of the sensor color filters, not a defined color gamut. Sensor native gamuts are in general much broader than encoded video gamuts. Don't know what kind of color matrix metadata the O7Q would apply to that. Maybe Mitch Gross could help us out with that one.

The camera has it's own physical colour space defined by the sensor filter dyes, but this space is converted into XYZ and then back out as part of the debayering process. The XYZ takes an illuminant as well, because XYZ is abstract and this is where the white balancing happens. The DNGs direct out of the FS700 are not XYZ space, but the matrices inside allow that conversion to happen, they contain the camera matrices and the illuminants (white balance settings)

Yes the camera space is larger than Rec709 and it's the conversion between that which seems to cause a lot of these issues.

However even in RAW it doesn't mean that the colours provided are camera space. Depending on the manufacturer there would be various colour science stuff going on before RAW is written. AFAIK Arri process to their wide space before RAW output. BMC cameras push the native sensor RGB out.

cheers
Paul

 

[Mitch Gross]

I can tell you that every manufacturer does this differently. And I mean every single one. Sometimes -- no, actually just about always -- differently for each camera model. I don't think I can speak to the specifics on the FS700 as it would likely fall under our general NDA with Sony.

 

[paulcurtis]

I can tell you that every manufacturer does this differently. And I mean every single one. Sometimes -- no, actually just about always -- differently for each camera model. I don't think I can speak to the specifics on the FS700 as it would likely fall under our general NDA with Sony.

+1

That's why a canon is a canon, sony a sony and so on.

The actual physical sensors between them aren't *that* different - the physics are the same. In some cases the parts are the same.

All we can do as end users is to reverse engineer the images we see and try to go as far back up the chain as possible. Right now RAW is the closest up that chain and is one reason why the colours you can pull from RAW IMHO are still better than any other format.

Even so, those workflows can quickly get complicated.

Unless manufacturers sometimes just do the right thing. As i mentioned i think the FS7 was the first time that out of the box, it produced great images. The A7sII produces good images by default.

cheers
Paul

 

[Razz16mm]

I can tell you that every manufacturer does this differently. And I mean every single one. Sometimes -- no, actually just about always -- differently for each camera model. I don't think I can speak to the specifics on the FS700 as it would likely fall under our general NDA with Sony.

What about the Odyssey 7Q recording raw?

 

[paulcurtis]

What about the Odyssey 7Q recording raw?

Mitch may be able to add more but the O7Q records the compressed RAW output from the FS700. It decompresses and writes uncompressed DNGs (complete with any lossy data that the original compression had)

We have no way of knowing what processing steps that RAW signal went through before being output by the camera.

You can side by side the RAW from the FS700 and FS7 though and see lots of differences. The FS7 has white balanced baked into the RAW so switching temperature on the camera *does* affect the RAW image whereas it doesn't on the FS700. IMHO that immediately technically means that FS7 can't be RAW but definitions are always a moving target. I can see the output of the FS700 RAW is linear with a small S curve on. It's certainly not a log signal. Same for FS7.

In the same way you can reverse engineer a BMC DNG by looking at the matrixes inside, you can do the same for the DNGs from these cameras.

cheers
Paul