SIGMA FP with ProRes RAW and BRAW !

[Andrew Reid]

RAW files from the Fp-L that I've seen look very good, you can dig about 6 stops into the shadows and it still maintains loads of nice colour information.

This is the basis of a really cinematic image. Not just high dynamic range but high dynamic range without killing colour and skin tones.

*Cough cough* Sony

Also with the crop modes Sigma seems to have implemented full pixel readout from about 7K down!

I wouldn't mind trying 1.3x crop to see what that looks like in RAW rather than the pixel binned FF.

[Llaasseerr]

20 hours ago, OleB said:

Took the public holiday today to investigate further, results before were not good enough.

You can disregard my tables. Dead end street...

Llaasseerr you were right, if I underexpose middle grey the post production is a becoming a big headache.

Now what I did today is set up lighting (camera ISO 800) and my color checker passport. Turned on false colors and tuned the lighting so that the patch which is representing middle grey was green (44 - 47 IRE) in the Atomos. (the one marked in the picture)

False color screen showed the following values for those patches, starting with white...

93 IRE, 84 IRE, 75 IRE, 59 IRE, 46 IRE, 26 IRE

Loaded the file into FCPX, but instead of pulling the highlights down as usual I did something different this time. On import the file looks totally over...

The new idea was to create a curve to bring down the patches to their appropriate brightness.

The curve, as smooth as I could get it, looks like this for all ISO values expect for ISO 3200.

ISO 800:

ISO 3200:

Last but not least I now had to search for the correct light meter values to get the exposure matching with my middle grey patch of the color checker. 

Camera - light meter

ISO 800 - 250

ISO 1600 - 640

ISO 3200 - 2000

ISO 6400 - 2500

ISO 12800 - 5000

ISO 25600 - 10000

That's it 🙂 I am happy now. Can use the false colors now correctly and even take a meter reading which is matching the Ninja. Since I have saved my curves as a preset it is now a one double clic action to get the file in FCPX exactly matching what I saw when recording.

Basically it seems I have created my own brightness calibration file. Might take a further investigation in regards to colors, but for now the result seems pleasing. Obviously I have tested it with various of my previous recordings and it is just so much better.

Maybe this could be of help 🙂 

 

 

Just a few quick notes here. First of all, the middle grey patch (0.18) is the third from right, so it's the lighter one immediately to the left of the patch you're using right now.

Secondly, you never have to break linearity to get correct exposure when shooting raw. You just need to do exposure shifts on the whole image until the middle grey value is at 0.18 in linear spave.

Overall, without having tested the Ninja V workflow with this camera myself, I think your approach of metering based on ISO 800 is sound, and using the Atomos false color to hit the *correct* middle grey patch. It's clear that in most cases the base ISO for the Ninja V interpreting Sigma fp raw footage is ISO 800.

If you want, you can try exposing by getting the green in the false color to hit the correct patch, which we can assume for now will be based on exposing for ISO 800,  and then send me the raw image so I can check the exposure in linear space. It really should be that simple. 

 

[Llaasseerr]

3 hours ago, Andrew Reid said:

RAW files from the Fp-L that I've seen look very good, you can dig about 6 stops into the shadows and it still maintains loads of nice colour information.

This is the basis of a really cinematic image. Not just high dynamic range but high dynamic range without killing colour and skin tones.

*Cough cough* Sony

Also with the crop modes Sigma seems to have implemented full pixel readout from about 7K down!

I wouldn't mind trying 1.3x crop to see what that looks like in RAW rather than the pixel binned FF.

I just found this test from a few years back where the fp is camera #4 and it seems to hold its own pretty well, except for in the underexposure test (4:23) where it had that pre-firmware fix issue where it's flickering. But overall, except for the flickering it is holding detail remarkably well with no objectionable noise at -6 stops. This would also be before the higher base ISO 3200 was added via firmware.

 

[OleB]

2 hours ago, Llaasseerr said:

Just a few quick notes here. First of all, the middle grey patch (0.18) is the third from right, so it's the lighter one immediately to the left of the patch you're using right now.

Have taken two photos with the false color scale. If I expose for the third one from right as middle grey, there is not even white...So this cannot be the case, at least not in the way the Ninja interprets the brightness. 

My middle grey approach:

Exposed according to your middle grey choice:

It is impossible to get the patches look the same for both the Ninja and FCPX by adjusting exposure/iso only. Don't ask me why. Maybe something (Gain?) is transferring incorrectly, or a different sort of gamma curve. Which it seems you cannot change in FCPX.

Would be great if someone with a Blackmagic Assist could record BRAW and see if with DaVinci Resolve there is a better chance to get things how they should be...

 

 

 

[Ryan Earl]

1 hour ago, OleB said:

Would be great if someone with a Blackmagic Assist could record BRAW and see if with DaVinci Resolve there is a better chance to get things how they should be...

In color mode "OFF" you should get an identical result with BRAW as CDNG, that's what I'm getting. 

For example, decode the DNG to P3 D60 Linear and transform to BMD Wide Gamut Gen 4/5 - BMD Wide Gamut Film Gen 5 then do a BMD Film GEN 5 to video LUT.

Then Decode the same scene shot in BRAW to GEN 5, Blackmagic Design, Blackmagic Design Video and they should match.

ISO values should match in the metadata and both won't be editable in the RAW tab.

[Llaasseerr]

3 hours ago, OleB said:

Have taken two photos with the false color scale. If I expose for the third one from right as middle grey, there is not even white...So this cannot be the case, at least not in the way the Ninja interprets the brightness. 

My middle grey approach:

Exposed according to your middle grey choice:

It is impossible to get the patches look the same for both the Ninja and FCPX by adjusting exposure/iso only. Don't ask me why. Maybe something (Gain?) is transferring incorrectly, or a different sort of gamma curve. Which it seems you cannot change in FCPX.

Would be great if someone with a Blackmagic Assist could record BRAW and see if with DaVinci Resolve there is a better chance to get things how they should be...

 

 

 

Unfortunately without knowing all the color transforms occurring, you can't monitor the image and get the same result in FCPX.

The underlying raw image is always linear with no gamma adjustment. It's just that the Ninja V by default applies a baseline adjustment, then you are applying PQ on top, then in FCPX it allows you to select a new way to display it.

With a managed color pipeline, you do not have to do any adjustments at all. It looks the same on the monitoring device as it does when you initially import it into the editing software.

Maybe try the internal false color and see if you can get that working, then go back to the Ninja knowing what your baseline is. Also try disabling PQ. Just cut out all the variables first.

With ProRes Raw on a Sony camera, this all works very predictably and easily.

 

 

[OleB]

39 minutes ago, Llaasseerr said:

Maybe try the internal false color and see if you can get that working, then go back to the Ninja knowing what your baseline is. Also try disabling PQ. Just cut out all the variables first.

Internal false colors are not working if you have the Ninja attached. You have to unplug it and restart the camera, but then I am not sure they are measuring the RAW output...Disabled PQ already, selecting native or Rec709 mode on the Ninja does not make a difference in how the picture is represented in FCPX. Only the ISO value makes a difference. So if you select Rec709, I have to go back to ISO 100 in camera to get a clear picture. Still false colors won't change between 100-800. 

I have no idea what the Ninja is applying as a baseline adjustment, all I can say is that considering the latest research result I was never closer to have all three things matching than as I do now. (Ninja false colors, light meter and FCPX)

Before I dialed down the highlights slider, sometimes that was working, but sometimes it did not, especially if there weren't much highlights in the recording at all.

Agree though that a managed color pipeline should have been provided by Sigma, Atomos and FCPX. Seems that one party was not able to provide the necessary. 

 

[Llaasseerr]

48 minutes ago, OleB said:

Internal false colors are not working if you have the Ninja attached. You have to unplug it and restart the camera, but then I am not sure they are measuring the RAW output...Disabled PQ already, selecting native or Rec709 mode on the Ninja does not make a difference in how the picture is represented in FCPX. Only the ISO value makes a difference. So if you select Rec709, I have to go back to ISO 100 in camera to get a clear picture. Still false colors won't change between 100-800. 

I have no idea what the Ninja is applying as a baseline adjustment, all I can say is that considering the latest research result I was never closer to have all three things matching than as I do now. (Ninja false colors, light meter and FCPX)

Before I dialed down the highlights slider, sometimes that was working, but sometimes it did not, especially if there weren't much highlights in the recording at all.

Agree though that a managed color pipeline should have been provided by Sigma, Atomos and FCPX. Seems that one party was not able to provide the necessary. 

 

Right, I just mean maybe try the false colors on the camera without the Ninja for now to see if you can get a result. I did hear that it was measuring the raw value directly off the sensor, but I'm not sure if that's true.

Yes I'm not saying Rec709 mode will make a difference as to how the image is displayed in FCPX. Actually nothing on the Ninja will change it because the underlying linear raw image is the same on both the Ninja and in FCPX. It's just that they are by default displaying it differently.

You shouldn't do any direct color correction directly to the image to get it to match between devices, because the underlying linear raw image already matches and so you are making it not match. It's just the non-destructive display color pipeline that needs to be figured out. Although like you say with lots of unknown steps, it's not clear.

[OleB]

8 hours ago, Llaasseerr said:

You shouldn't do any direct color correction directly to the image to get it to match between devices, because the underlying linear raw image already matches and so you are making it not match. It's just the non-destructive display color pipeline that needs to be figured out. Although like you say with lots of unknown steps, it's not clear.

Alright, will have a look on the false colors of the camera, but I assume that they are just showing the internal preview of the camera in false colors, so not RAW data. Will revert back on that.

in regards to FCPX and the files I have tried something now which I didn't do so far. Created a new project in Rec2020 PQ setting. If I import the files now at least the visual presentation is the same as what I have seen on the Ninja. Without the need to touch files in any way. Will investigate how the waveforms of the Ninja are matching to the ones in FCPX. Guess that makes sense, because RAW means the camera is basically transferring its full dynamic range to the recorder at anytime. And therefore RAW can technically always considered as being a HDR medium(?).

What if the hidden culprit is a correct missing RAW to Rec2020/Rec709 conversion for the fp? You rightly said all data is there (in the recording) and linear. It just does not fall into Rec709 or Rec2020 without a conversion in regards to dynamic range. 

Seems what I have done by manipulating the curve is to squeeze the dynamic range of the original file into Rec709. Basically a similar approach to these HDR tools which are built in into FCPX. They by the way give some sort of okayish result, but not as good as the curve I have created. Does that make sense?

[Llaasseerr]

5 hours ago, OleB said:

Alright, will have a look on the false colors of the camera, but I assume that they are just showing the internal preview of the camera in false colors, so not RAW data. Will revert back on that.

in regards to FCPX and the files I have tried something now which I didn't do so far. Created a new project in Rec2020 PQ setting. If I import the files now at least the visual presentation is the same as what I have seen on the Ninja. Without the need to touch files in any way. Will investigate how the waveforms of the Ninja are matching to the ones in FCPX. Guess that makes sense, because RAW means the camera is basically transferring its full dynamic range to the recorder at anytime. And therefore RAW can technically always considered as being a HDR medium(?).

What if the hidden culprit is a correct missing RAW to Rec2020/Rec709 conversion for the fp? You rightly said all data is there (in the recording) and linear. It just does not fall into Rec709 or Rec2020 without a conversion in regards to dynamic range. 

Seems what I have done by manipulating the curve is to squeeze the dynamic range of the original file into Rec709. Basically a similar approach to these HDR tools which are built in into FCPX. They by the way give some sort of okayish result, but not as good as the curve I have created. Does that make sense?

Great, that's a big deal that you got the image in FCP and the Ninja the same. That's half the battle. You might just find though that the false colors on the Ninja are not changing to account for PQ. That's a guess on my part though, as I haven't used them.

Yes, raw (and film) is technically an HDR medium. Often the exposure will be adjusted to match the scene after capture because it captures integer values, so it wil transform to linear floating point raw which has values above 1.0. Then that is transformed to something like a log space or an HDR display space. All HDR is, is a way of displaying a linear raw file with more highlight range for high-nit 10-bit displays, using a custom gamma transform.

Yes, any color transform for display purposes is always transforming linear data into a viewable range. You just don't want to add to that yourself directly on the footage when you're trying to work out what your color/exposure mismatch is. There is a more fundamental issue in the color processing pipeline that is causing the mismatch and you just need to identify the inconsistency, then it falls into place.

Basically you have proven that the footage in FCPX and on the Ninja is the same with the same view transform applied on input to FCPX, but it doesn't mean you need to use it. You could just use it right now for troubleshooting while you work out the exposure issue.

What I suggest is look at where middle grey falls in Rec2020 PQ as an IRE value (look at technical documentation online). I don't have that knowledge handy. Then you can see if the false colors are working in Rec2020 PQ on the Ninja and not just Rec709. Like, does it change the false color mode between Rec709 and PQ? It needs to do that.

Basically, it should not matter what device you're viewing on (camera, Ninja, FCPX), the false color for middle grey should be green as long as the false color implementation is aware of the display space on the camera, Ninja, FCPX project.

 

 

[OleB]

51 minutes ago, Llaasseerr said:

Like, does it change the false color mode between Rec709 and PQ? It needs to do that.

thank you, good points to check. Will evaluate the internal false colors first, afterwards middle grey for PQ. However the false color mode does not change between Rec709 and PQ. It only does so if you switch to native, but there you have the issue that every ISO value has a different clipping point and middle grey is as well always in a different position.

The only time you get a matching result is if you view the file in a PQ HDR project. However the IRE values I have to evaluate.

Update on the false colors to follow.

[OleB]

Internal false colors are not measuring the RAW data...

Exposed ISO 800 with the correct patch for middle grey as per internal false colors. Switched on the Ninja and pressed record. And while recording I opened up the aperture 3 stops. In FCPX all data is still there if you pull down the exposure. So cannot be RAW data monitoring I suppose.

[Llaasseerr]

3 hours ago, OleB said:

Internal false colors are not measuring the RAW data...

Exposed ISO 800 with the correct patch for middle grey as per internal false colors. Switched on the Ninja and pressed record. And while recording I opened up the aperture 3 stops. In FCPX all data is still there if you pull down the exposure. So cannot be RAW data monitoring I suppose.

Can you send a DNG where middle grey is exposed correctly according to internal false colors? I can check it.

[Llaasseerr]

4 hours ago, OleB said:

thank you, good points to check. Will evaluate the internal false colors first, afterwards middle grey for PQ. However the false color mode does not change between Rec709 and PQ. It only does so if you switch to native, but there you have the issue that every ISO value has a different clipping point and middle grey is as well always in a different position.

The only time you get a matching result is if you view the file in a PQ HDR project. However the IRE values I have to evaluate.

Update on the false colors to follow.

When you say "matching", I assume you mean visually matching between the Ninja and FCPX. Overall it doesn't matter if they match or not, but it's useful right now while you're diagnosing the larger problem.

Maybe just email Atomos support for clarification as to how to use false colors with the Sigma FP raw capture. Also explain that you're monitoring in PQ which I think they don't recommend.

To me, the way you're describing "native" working is the way ISO changes are meant to work, so I don't get the issue. If it was more of an exposure index approach where it's recording a native ISO with no baked-in ISO change then that would be different.

 

[Llaasseerr]

4 hours ago, OleB said:

Internal false colors are not measuring the RAW data...

Exposed ISO 800 with the correct patch for middle grey as per internal false colors. Switched on the Ninja and pressed record. And while recording I opened up the aperture 3 stops. In FCPX all data is still there if you pull down the exposure. So cannot be RAW data monitoring I suppose.

Just a heads up that PQ pushes 100 IRE white in Rec709 down to 15 IRE, which is about 2.74 stops darker. 

So I don't know if that explains your exposure mismatch which you compensated for by opening the aperture by +3 stops. I'm totally guessing at this point, having not used it.

Maybe just try exposing with a light meter for ISO 800, ignore false colors and the Ninja V completely for now, then import into FCPX and do something simple like transform the raw image to Arri LogC/Arri wide gamut, then apply the default LogC to Rec709 LUT. If that looks right, then you can figure out how to get the exposure monitoring looking correct on the Ninja. The aim here is not to match anything, but just to check your exposure worked as expected like you're exposing film that you can't monitor at the time of shooting.

Middle grey should fall at about 41 IRE with the Arri Rec709 LUT, so then you'll know your light meter exposure worked. 

 

[OleB]

2 hours ago, Llaasseerr said:

So I don't know if that explains your exposure mismatch which you compensated for by opening the aperture by +3 stops. I'm totally guessing at this point, having not used it.

Sorry, seems I wasn't clear. There was no exposure mismatch. Have correctly tuned the exposure to represent middle grey, however I could overexpose the image by 3 stops, picture in the camera looked totally blown, but the data was still there. So the sensor wasn't clipping. You remember that YouTube video you saw weeks ago, where that guy described that you have to open up the aperture further for best quality.

So that was just the confirmation that the internal false colors are not representing RAW data, they are just a better visual overlay for the same Rec709 conversion which the camera shows. So ISO 800 is still ISO 100 in regards to clipping internally pushed 3 stops to appear brighter.

[OleB]

2 hours ago, Llaasseerr said:

then import into FCPX and do something simple like transform the raw image to Arri LogC/Arri wide gamut, then apply the default LogC to Rec709 LUT.

That is not possible, or at least I do not know a way to do it, all you can select is RAW to LOG, there is no Arri LogC build into FPCX, and then you can convert the LOG to a LUT. Only there you have the option to go for Arri. So basically they left out the option to convert the Sigma RAW to Arri Log...

[OleB]

3 hours ago, Llaasseerr said:

Maybe just email Atomos support for clarification as to how to use false colors with the Sigma FP raw capture. Also explain that you're monitoring in PQ which I think they don't recommend.

I tried this already twice, never got any reply to my service ticket...

[OleB]

3 hours ago, Llaasseerr said:

To me, the way you're describing "native" working is the way ISO changes are meant to work, so I don't get the issue. If it was more of an exposure index approach where it's recording a native ISO with no baked-in ISO change then that would be different.

Native monitoring gives you indeed the correct middle grey value for each ISO value of the camera, but the white point is not at 100 IRE. It is changing for every ISO setting, sometimes white is at 80 IRE, sometimes 65 IRE etc. Additionally the black point is not at 0 IRE, but most of the times at 10-15 IRE. 

All in all, despite the latest method I have described, there seems to be no way to see a picture on the Ninja V, which by any means is representing what you get in the file. And that even applies to in camera tools, if you record RAW. And to film something with no tools to visually see what will be is at least nowadays with mirrorless cameras more than just a little cumbersome. 

Seems they opened the camera for RAW recording but in the end, that workflow was never fully developed. Since most people tend to use CNDG from what I have heard, and that is running more or less smoothly, guess there is no need for Sigma to address this. 

[webrunner5]

Can you do Raw with a Blackmagic Design Video Assist 4k or is it only work with an Atomos product? Because this sounds like the biggest pain in the rear end known to mankind.