Sigma fp with BRAW and DNG

Here's a BRAW frame to add to this thread from the Pocket 6K Pro for reference.

Traffic Light - Extended Video with Gamut Compression

Traffic_Lights_Closer.jpg (268.36 KiB) Viewed 8539 times

https://www.dropbox.com/s/bwguin9uux3z2 ... .braw?dl=0

The preview above is just a preview.

If you want to download the frame and turn off gamut compression you'll get the traffic light to become the "painted red" or a heavy red. At least to my eye, things are looking as intended with gamut compression on.

Thanks, Ryan, for Gerald’s comments on the SIGMA fp L. He demonstrates that BRAW is unusable and it’s quite shocking. Surely SIGMA tested this feature in UHD going to the BMVA12G7.

Lots of other issues so that’s it, I’m undone.

Noel can we prevail upon you ?

Might not be needed. What's happening here? Is it the camera, uncompressed DNG's, BRAW, Resolve?

As Hook pointed out, two other DNG decoding methods produce results with BRAW that are quite similar to DNG.

1. The straight DNG decode to 709 (709 Decode) creates non-zero values for blue and green for the stoplight center: RGB 255 71 15.

2. The DNG decode to Blackmagic followed by a CST to 709 (BMD Decode) creates pure red values for the stoplight: RGB 255 0 0. How could the BMD Decode produce pure red?

At this point, all the above leads me to guess that the result is a colorspace phenomenon created by Resolve mathematics rather than specific to the camera or the BRAW codec. It's different for BRAW only because the Resolve code for decoding BRAW is not the same as that for DNG.

When I stumbled upon the decoding of the stoplight image, I was excited and delighted. I had never in two decades encountered a digital camera that could capture and accurately reproduce the color of bright, normally blown out and discolored light sources like taillights and stoplights along with everything else. The reds are usually the first to go. The effects, like jaundiced looking yellow peaking faces, are easy to spot.

The main question is why is there such a dramatic color difference between the 709 Decode and the BMD Decode. They are decoding the same DNG so should they not, in theory, be identical?

I can't answer that, and without an answer, I don't think camera/codec tests will help figure anything out.

But it’s not a perfect solution given the slow sensor readout. Or is sensor readout in half the time when it skips?

I don't share the reviewers concerns. I'm in line at B&H. The proof's in the pudding. We'll see.

Look forward to reading about your experiences with a production version of the camera.

At least to my eye, things are looking as intended with gamut compression on.

Gen 4 seems the best Color Science, but the red stoplight is still a good bit into magenta territory.

If the SIGMA fp L is line-skipping when writing video for the BRAW support when tethered to the BMVA12G7 for example, that might be considered a step backwards from the original SIGNA fp which I don’t recall hearing was line-skipping for BRAW. When a camera has nearly 61 megapixels natively, perhaps it doesn’t matter as line-skipping still can use a lot of data. But it’s not a perfect solution given the slow sensor readout. Or is sensor readout in half the time when it skips?

It's line skipping for ProRes RAW or BRAW. Seems like a stupid mistake ? (Oh, and the fact you likely can't record these codecs if you use the EVF because it blocks the HDMI)

It presumably doesn't line skip to Internal / external DNG ?

All three will have same poor rolling shutter.

JB

It's line skipping for ProRes RAW or BRAW. Seems like a stupid mistake ? (Oh, and the fact you likely can't record these codecs if you use the EVF because it blocks the HDMI)

Or they could just record BRAW internally, unless there's a patent/agreement issue.

[I had never in two decades encountered a digital camera that could capture and accurately reproduce the color of bright, normally blown out and discolored light sources like taillights and stoplights along with everything else. The reds are usually the first to go.

Don't want to presume, but is this what you're after? If you enlarge, you'll see the traffic light isn't clipped (or painted), the LED pattern is visible.

braw_1.3.1.jpg (332.95 KiB) Viewed 8443 times

Don't want to presume, but is this what you're after?

Yes.

...It presumably doesn't line skip to Internal / external DNG ?

All three will have same poor rolling shutter.

JB

Yes, I believe Gerald mentioned internal recordings did not use line-skipping.

Worst rolling shutter I’ve seen in a long time so panning needs to crawl not sweep between two subjects.

Camera looks revolutionary but let’s say it’s in need of further operational evolution in a half-dozen areas. Lots of time for BMD to get that BMPCC4K Pro or BM Cube 8K mFT to market.

It's line skipping for ProRes RAW or BRAW. Seems like a stupid mistake ? (Oh, and the fact you likely can't record these codecs if you use the EVF because it blocks the HDMI)

Or they could just record BRAW internally, unless there's a patent/agreement issue.

As far as I know bmd has offered it to all cameras and nle.

Ricardo marty

Or they could just record BRAW internally, unless there's a patent/agreement issue.

There isn't.

JB

[CaptainHook]

You can remap, but if the sensor cannot record a gamut value, it won't be there or it will be wrong.

Pretty much all photographic/cinema camera sensors respond to any wavelength from at least 400-700nm. The CFA spectral response may result in metameric failure but you will get a response for all wavelengths we care about for imagery (and often more which is why IR/UV cut filters exist).

Or as ARRI puts it:

There are no colors a camera can’t see, so it does not really make sense to talk about the gamut of a camera.

https://www.arri.com/en/learn-help/lear ... mut--44070

But the Vectorscopes tell the tale. When they say red, I see red, but with 709 conversion they say orange, I see orange.

See what I wrote before in parenthesis - "(unless the sensor is clipped in areas or gamut mapping/compression is required etc)"

So if with an 'accurate' transform to 709 the LED is turning orange instead of Red its because either potentially a channel was clipped from the bright LED, and/or because the actual colour is beyond the display gamut of 709 and needs to be remapped somehow, either by compression or some other method. But any method is a compromise because that colour/brightness cannot be accurately represented by your (709 display) gamut. That's why there are disagreements about which method is better, its subjective because it cannot be accurately displayed in 709. You either need a larger display gamut and a display that can reproduce it with more DR (hence why there is a push for HDR and 2020 displays etc), or need to make a compromise/choice of some kind to "represent" it on a device not capable of reproducing it accurately.

I think I need to show something else here since many don't consider it (this is for anyone interested), but colourspaces and their gamuts are volumes, even though for convenience often just plotted as 2D on CIE chromaticity plots. So generally as the 'brightness' increases the amount of saturation it can be reduces - this is particularly true for red.

I made this quick video to demonstrate this with your DNG - here you can see its decoded as 709, then I boost saturation and you can see the red LEDs rotate in hue a bit on the vectorscope. Then I pull down gamma and the reds rotate even more and line up with the red on the vectorscope, then I increase gamma making things much brighter and the red can no longer be represented in the gamut anymore and shifts widely into orange. No direct colour changes - just gamma - yet the colour you see on the image and vector scope is affected dramatically with these brightness/gamma changes.

(view this bigger than the embedded version in the forum to see the vectorscope trace clearer)

So Hook, why is decoding directly to 709 so different than decoding to Blackmagic and then transforming from Blackmagic to 709?

I've covered this in the thread already, but when you use Blackmagic Gen 1 with a RAW file it only describes a log curve - there is no gamut defined so you are left with 'sensor space'. In the CST plugin it assumes the BMCC/Pocket sensor at a white balance of 6000K, if you use another sensor or a different white balance (even with a BMD camera) it is no longer a 'correct' transform to any other space including 709 because it's assuming a different sensor space at a set white balance. So the result will vary per camera/sensor and be random/arbitrary as to the result. You might like the result in one particular case, but as said before its a fluke.

Gen 4 seems the best Color Science

Gen 4 and 5 use the same wide gamut, Gen 5 just has a fixed log curve for all ISO's and cameras which makes it far more convenient for a number of reasons including being able to use a single LUT for all cameras/ISOs, copy/pasting grades, etc. But you don't output a log curve so it's more a workflow/processing improvement and with correct transforms you would get identical results. Gamut compression is avail for both Gen 4/5 in the braw tab too.

2. The DNG decode to Blackmagic followed by a CST to 709 (BMD Decode) creates pure red values for the stoplight: RGB 255 0 0. How could the BMD Decode produce pure red?

That explains why I described it as "painted on" as it's unnatural for a colour from a bright LED to be pure red in an exposure like this. It also goes to what I wrote above - the true colour/brightness of that LED cannot be represented in 709 which is why in a proper 709 transform it turned orange. If you changed exposure then maybe (demonstrated above), but if you like 255,0,0 with no other detail/variation in the LED source that's a valid choice as I've said.

Or as ARRI puts it:

There are no colors a camera can’t see, so it does not really make sense to talk about the gamut of a camera.

The Arri statement is far too vague to be meaningful.

Pawel Achtel ACS has no problem talking about and measuring gamut(at ~11:30):

If you changed exposure then maybe (demonstrated above), but if you like 255,0,0 with no other detail/variation in the LED source that's a valid choice as I've said.

While a little detail would be nice, I see little of that with my eye with red LED's, and color is, for me, far more important.

I made this quick video to demonstrate this with your DNG - here you can see its decoded as 709, then I boost saturation and you can see the red LEDs rotate in hue a bit on the vectorscope.

If you do the same thing decoding to Blackmagic, the stoplights stay red due to the zero green and blue values.

Zero values are unique. As anything times zero is zero, so they do not scale. While the DNG contains all non-zero values for the stoplight, green and blue are reduced to zero in the decode.

As it turns out, Highlight Recovery is playing a part, and I have seen other examples of Highlight Recovery producing strange results. In the 709 decode, HR increases green, which shifts red highlights to orange, in the Blackmagic decode, it reduces green and solidifies red highlights.

BRAW can decode to XYZ/Linear. A DNG decode to XYZ/Linear would be terrific, but I won't hold my breath. In the mean time, Blackmagic decode it must be.

Noel this is why I asked you for an example shot dual codec.

So far I’ve learned a lot from this conversation.

I still don’t think it’s as simple as the original point you were making but it would be great to get to a conclusion.

It really seems like the workflow “math” is what’s getting you a result you’re claiming is lot possible in other codec choices and I’m wondering if that’s actually down to the camera itself you’re using, the codec or the workflow.

We’re getting into more and more subjective opinion (how red is red) and the only real way to test these theories is to have those images in front of us in our own workflows.

JB

I thought it would be interesting to see how much detail could actually be extracted from either camera. The light on the left is from Ryan's P6K the two on the right are from Noel's Sigma FP. I've included both lights so that the distortion may be recognized as real world phenonena and not a random artifact.

The Braw footage is only barely clipped whereas the 12bit CDNG is showing some cracks. If the FP is full 2020 then the P6K must be full 3030.

Incidentally the matrix coefficeients for the Sigma are hiding in the metadata. If anybody knows how to use that information to create the "proper" transform I'm all ears.

Good Luck

RL.png (373.94 KiB) Viewed 8220 times

Incidentally the matrix coefficeients for the Sigma are hiding in the metadata. If anybody knows how to use that information to create the "proper" transform I'm all ears.

Interesting to see those traffic light results Howard. I've been sorely tempted to go shoot my own, but I don't have the sigma

It's routine to see chroma clipped stop lights in almost every narrative drama series. I was just watching the beautifully shot ZeroZeroZero and it's all clipped tail lights....

Re transforms...
Isn't the embedded matrix meant to be able to tell the app how to do that transform ? Is that on sigma to do ?

JB

It really seems like the workflow “math” is what’s getting you a result you’re claiming is lot possible in other codec choices and I’m wondering if that’s actually down to the camera itself you’re using, the codec or the workflow.

We know the following:

1. BRAW decoded to 709 is the same as DNG decoded to 709. This can be confirmed with the two doll test files (Hook already did that above).

2. DNG decoded to 709 is not the same as DNG decoded to Blackmagic, followed by a CST to 709 (even though in theory it should be). This can be confirmed with the stoplight DNG file.

3. BRAW decoded to 709 is the same as BRAW decoded to Blackmagic, followed by a CST to 709. This can be confirmed with any BRAW file, including the test doll.

Therefore, if I retook the stoplight shot with both BRAW and DNG:

The BRAW and DNG would be the same if decoded to 709 (#1).

The BRAW and DNG would not be the same if decoded to Blackmagic, followed by a CST to 709 (#2).

I am at this point convinced that this phenomenon is not due to the camera, or the BRAW compression codec, but with the Resolve decode. It will likely manifest with at least a few if not all DNG's from sources other than the Sigma fp.

So I don't think a test would help. I would be happy to one anyway, but I already sent the Video Assist back.

It is highly likely that BRAW could be decoded to produce similar results. But so far, I have not found a method to do that.

Reasonable people can disagree about what looks best. I am a stickler for color. The method I outlined is not perfect, but it suggests that a better decode may be possible for both DNG and BRAW than currently exists within Resolve.

I'm not sure I should jump down that rabbit hole, but I might. Maybe an OpenFX Stoplight Transform.

I am at this point convinced that this phenomenon is not due to the camera, or the BRAW compression codec, but with the Resolve decode. It will likely manifest with at least a few if not all DNG's from sources other than the Sigma fp.

If you're satisfied with the stoplights in the shot I posted above, it's BMPCC 4K braw Q5, with RCM and two power windows. I tried the the same workflow with your stoplights. The result was highly saturated reds (as desired?), but with a bit less of the paint effect. Of course, all this is a cheat, but what else is color grading?

The Braw footage is only barely clipped whereas the 12bit CDNG is showing some cracks. If the FP is full 2020 then the P6K must be full 3030.

Different exposure levels. No doubt my stoplights are clipped, but that's going to happen all the time.

Here's two stops down without Highlight Recovery, with HR, and one stop up with HR:

Highligh.jpg (426.76 KiB) Viewed 8230 times

No animals were harmed and no power windows were used.

I was just watching the beautifully shot ZeroZeroZero and it's all clipped tail lights....

Exactly! Taillights, stoplights, purple EXIT signs. Film blew more gracefully.

We don't need Highlight Recovery. We need Taillight Recovery!

Here's a few taillights. Yes, they're a bit too much, but they're red, and the stoplights are red and green, and the little pedestrian guy on the right is white:

Taillights_1.88.1.jpg (944.12 KiB) Viewed 8214 times

[Film blew more gracefully.

Here's a screengrab from a remastered 4K bluray, 1970s 35mm film stock:

vlcsnap-8727-08-25-12h39m42s995.jpg (453.98 KiB) Viewed 8198 times

I suspect the results have more than a little to do with exposure.....

The also didn't have led taillights in the 70's either...they were tungsten based taillights.

LED's are very monochromatic and have always been a problem for any camera to record accurately.

Supersaturated out of gamut (working space) chroma is the issue no ? High chroma and towards exposure clipping...?

JB

(PS, I'm vaguely remembering that Claudio Miranda got himself banned on REDUSER for complaining about tail lights back in about 2007 !.....)

I suspect the results have more than a little to do with exposure.....

Not really. That's film negative, which adds density with exposure, but at a non-linear "shoulder" rate. It doesn't "clip" like CMOS.

The best "tell" for digital is red channel clipping, which results in yellow peaking, which makes faces, in particular, look awful.

The also didn't have led taillights in the 70's either...they were tungsten based taillights.

Yes, and even so we used quite a bit of ND on them as well.

Taillights are the holy grail of digital cinematography. That's why I brought it up.

Claudio Miranda was ahead of his time.

Noel, BMD’s wide gamut is wider than Rec.2020. Have any of your tests used their Wide Gamut?

Noel, BMD’s wide gamut is wider than Rec.2020. Have any of your tests used their Wide Gamut?

Blackmagic Wide Gamut is not a choice in Camera Raw for DNG's. While it is a choice in the CST to 709, it makes little to no difference in the result.

The Camera Raw decode seems to be where the secret sauce resides, that is when Blackmagic Design/Blackmagic Design Film is selected.

Of course, all this is a cheat, but what else is color grading?

Right. Chroma clipping is just running out of dynamic range in a color channel. Sometimes it's the camera, sometimes it's the space.

I used a qualifier here and fed the layer through at -2.5 exposure. The light is intense enough that one can grab the light and not the sign. Since the P6K is just barely clipping it's not necessary to jump through any hoops to get the color back, drop the exposure and feather in the detail to taste.

Good Luck

qualified.png (916.34 KiB) Viewed 8088 times

[CaptainHook]

I'm considering trying one more time to explain things since it doesn't seem to be getting absorbed by Noel based on his comments after my explanations.

I think I would just be repeating myself but trying to re-phrase - has any of what I've said made sense to anyone or do I need to try again?

I'm considering trying one more time to explain things since it doesn't seem to be getting absorbed by Noel based on his comments after my explanations.

I think I would just be repeating myself but trying to re-phrase - has any of what I've said made sense to anyone or do I need to try again?

Blackmagic Wide Gamut is not a choice in Camera Raw for DNG's. While it is a choice in the CST to 709, it makes little to no difference in the result.

The Camera Raw decode seems to be where the secret sauce resides, that is when Blackmagic Design/Blackmagic Design Film is selected.

How about HDR Rec.2020?

Resolve 17 Settings

Screen Shot 2021-03-29 at 8.26.00 AM.png (155.94 KiB) Viewed 7867 times

REC2020 HDR Project - REC709A Export

REC2020_REC709A_1.1.1.jpg (701.8 KiB) Viewed 7867 times

For me, the HDR Rec.2020 preset in RCM in Resolve 17 is the most like working in Photoshop's Camera Raw with the Sigma FP's DNGs.

The Sigma FP is the only Sigma camera where Adobe has said there is a matching profile available and where I get color available matching Noel's preference:

Sigma FP Adobe

Screen Shot 2021-03-29 at 10.20.46 AM.png (158.61 KiB) Viewed 7841 times

Then developing from these files: https://www.imaging-resource.com/PRODS/ ... a-fpA7.HTM

I won't post them here because of copyright but I'm finding the HDR Rec.2020 preset to have better out of the box accuracy, at least with the color chart, than Adobe Color in Photoshop Camera Raw with those samples compared to the camera JPEGs.

For Hook, could RCM and HDR Rec.2020 preset better utilize the Sigma FP DNG? Or translating it more accurately from a technical standpoint? Or not?

How about HDR Rec.2020?

I copied the Color Management and LGG settings in your post which are visible, but get a very different from the image posted. One that is very close to direct 709 decode in Davinci YRGB:

Screenshot from 2021-03-29 13-47-31.jpg (210.63 KiB) Viewed 7780 times

Perhaps I'm missing something?

Perhaps I'm missing something?

You'd have to add Saturation, maybe not 100% as I did, but the image does saturate I think in a similar way to when I develop it with the "Camera Matching" profile "Standard" or "Neutral" in Photoshop Camera Raw and avoid Adobe's own options.

I'm assuming Sigma provided the "Camera Matching" profiles for Adobe? I don't know how that might translate to a Resolve workflow other than to give a reference baseline or grade for an image to then push around by eye in one of the decode and CST options.

Ryan, with a little tweaking, your approach comes out fairly close to DNG->Blackmagic->709, and both could probably be matched. The latter requires a CST, but seems to do a bit better with yellows. The CST also has other controls in case they are needed, and I have used Luminance Matching and Saturation Preserving.

The new HDR panel seems quite powerful and could fix a number of problems. But my goal has been to find a pipeline that works well out of the box.

Noel, I’d encourage you to use the HDR scopes and the HDR colour wheels. I’ve standardized on that approach for 1000nits within ACEScct. I was trying the YRGB and RCM, but ACES is very good.

When you grade for HLG, the deliverables can be the same grades for SDR and HDR targets but you grade accordingly by keeping most of the grade within SDR limits but allowing Specular and possibly some Highlights to venture into HDR levels. It’ll make sense once you start doing the grades. Some folks don’t worry about those limits and nothing forced you to stay within the limits, but I try to do it by the book.

By the way, you can also grade for HDR PQ gamma but that’s not intended for SDR targets. There are other folks here who know more about this than I.

Noel, I’d encourage you to use the HDR scopes and the HDR colour wheels.

I plan to. You could say that the HDR panel is the most important addition to Resolve in some time.

I tend to roll my own. So not so much managed color. But HDR works in YRGB as well.
HDR reminds me of my X-18 EQ:

xair.png (141.81 KiB) Viewed 7710 times

I agree that the G1 to 709 colorspace transform works well. However, doubling down on the gamma portion is sending the footage into space. The footage is not log, clicking BMD film in the raw tab does not make the footage log.

Try this, use only the colorspace portion of the transform and leave the colorspace and gamma at 709 in the raw tab. The colors land close to where they should be. The only hidden setting is Saturation is 35 on the Primaries tab because it's not available on both raw tabs if 709 is selected.

DNG vs Braw.png (599.38 KiB) Viewed 7694 times

Here is just the CDM chart without the clutter. The Camera Raw settings are identical. The Braw has a little less noise so the vectors are smaller and more defined than the DNG. Without scopes I can't see the difference. From what is presented here I see little to indicate there's a spectacular advantage to DNG over Braw, definitely not where accuracy is conncerened.

CDM.png (142.49 KiB) Viewed 7694 times

Good Luck

[CaptainHook]

I think there's a few things going on here - one is the discussion about how colours outside of a gamut should best be 'represented', 2nd is I'm still not sure that people really understand the difference between BMD Film Gen 1 via the DNG RAW panel versus the CST plugin, and the other thing that's being struggled with here is that Sigma's matrices they provide in the DNG's (and to us for Blackmagic RAW processing) don't seem to describe a way (on their own) to transform from sensor space in a way that satisfies people. Which is why some are still trying arbitrary workflow options (fair enough). I'd say that I agree that the way that DNG's decode as 709 in Resolve using the matrices Sigma put in the DNG's could be better, and since Blackmagic RAW decodes visually the same based on similar information from Sigma then both could be better. I will get this looked into it to see if we can work with Sigma to improve this aspect but ultimately this is their decision as they define these things.

Aside from that I will further consider how I can better explain the first two aspects when I have some more time.

Aside from that I will further consider how I can better explain the first two aspects when I have some more time.

Hook I think it's FANTASTIC to have these kinds of discussions especially when it comes from such a position of true knowledge of underlying maths and science and INTENT of the developers of these codecs and platforms that even many post and final colourists don't have.

As you said, in the end if you get the result you want, does it matter how you get there ?

My only thought is that this kind of FUD is what contributes to the idea that DNG was this beautiful RAW untouchable RAW format with primacy above all, and what this thread shows is that at the very least it's a mess in terms of workflow and implementation.

The conclusion to me it isn't as simple as DNG Vs BRAW.

JB

what this thread shows is that at the very least it's a mess in terms of workflow and implementation.

As Hook clearly demonstrated, virtually identical results are achieved by simply decoding both BRAW and DNG to 709. That's as simple as it gets with any type of RAW.

But options are great. The more the merrier.

DNG has 3 Color Space options, and 5 Gamma options. That's 15 possible decode choices.

BRAW has 12 Color Space options, 13 Gamma options, and 2 Color Science options. That's 312 possible decode choices.

BRAW, then, has 20 times the possible decode choices of DNG!

If choices are a bad thing and create a "mess" then BRAW wins by a mile. But I'm all for choices, so I rate that as a great feature. I only wish DNG had more to try.

I had done a test shot yesterday in the evening with some traffic lights but only found out later that the available light had already been too low so the traffic light reds clipped anyway.

Re-shot those today in full sunlight with the URSA Mini Pro and firmware 6.0 (which has DNG and BRAW).

Setup:

• URSA Mini Pro Gen 1 @ firmware 6.0 - locked on a heavy tripod
• BRAW Q0 4.6k
• DNG lossless 4.6k
• Canon EF 100-400mm @ f/5.6 @ 400mm + active IS mode 2, manual focus
• shutter 180°
• internal ND for the first test pair set to ND3 +4stops and ISO 400
• internal ND for the second test pair set to ND4 +6stops and ISO 1600

Start/stop recording and codec switching via Bluetooth+ app - unfortunately every switch rebooted the camera and the lens, so with this specific lens I did not manage to get 100% the same framing all the time. And there is some air heat haze because of the distance.

Those reds of the traffic lights are so intense that even with ND4 +6 stops they slightly clipped in the middle.

Processed in R16.3b.011 (last version to work on Win7):

• DaVinci YRGB / Rec.709 (Scene)
• UHD 24fps
• Color Science = Gen 4
• Highlight Recovery = ON
• Gamut Compression = OFF
• White Balance 5850 / +22
• Sat = -25 (DNG) / 0.75 (BRAW)

One node with my LBK neutral LUT applied (which shifts magenta reds back a bit).

Download DNG and BRAW single frames + stills with DRX here:

https://we.tl/t-08Kv8P65qZ

DNG ISO400 f5.6 ND+4_1.1.1.jpg (861.58 KiB) Viewed 7582 times

BRAW ISO400 f5.6 ND+4_1.2.1.jpg (858.43 KiB) Viewed 7582 times

And the second test pair:

DNG ISO1600 f5.6 ND+6_1.4.1.jpg (867.75 KiB) Viewed 7581 times

BRAW ISO1600 f5.6 ND+6_1.3.1.jpg (840.01 KiB) Viewed 7581 times

Just in case anyone is wondering about the orange traffic light: in Austria and Germany it switches from Red to Red & Orange to Green and then from a blinking Green to Orange to Red.

Robert, thanks for the shots. I noticed the magenta cast on all of them, and then noticed your LUT.

The DNG decode for Blackmagic DNG's offers a few more options than the one for Sigma's (Color Science and ISO).

To me, they all decode best to Blackmagic Design, followed by a CST to 709. I also noticed Gamma Compression on the BRAW really hits the reds hard.

Lots of settings to try to get to the sweet spot.

Robert, thanks for the shots. I noticed the magenta cast on all of them, and then noticed your LUT.

Yeah, I just quickly eyeballed the WB with the LUT applied, which was not designed for the UM46k but the PCC4k. So for any other LUT or conversion workflow a lower tint value might be more appropriate.

DNG has 3 Color Space options, and 5 Gamma options. That's 15 possible decode choices.

But...I think what we've learned is that Sigma themselves aren't encoding the right matrix here...soooo that to me means anything is a guess...

Those decode choices come from a false assumption. Resolve doesn't know it's a sigma made DNG with a sigma made sensor. Any of those "choices" are prefaced by this interpretation of the DNG.

You're applying a BMD designed DNG space for a TOTALLY different sensor BRAND and getting a result you like, but it's not ever been "designed" that way, not by Sigma or BMD.

You're telling Resolve, hey interpret this as if it was shot on a BMD made camera with a differently made sensor.

Great that you're getting results you like, but it's not by design.

JB

Hook I think it's FANTASTIC to have these kinds of discussions especially when it comes from such a position of true knowledge of underlying maths and science and INTENT of the developers of these codecs and platforms that even many post and final colourists don't have.

+1

Sorry for the TL:DR post....(I did read a lot of this thread actually).

So I think my next camera will be the Sigma fp (not the fp L....I honestly don't see the point). My goal is to run it in conjunction with my Blackmagic Pocket 4K and I think the two would make for a pretty complementary ecosystem.

My main question is -- what is the bottom line on recording Blackmagic RAW from the Sigma fp HDMI feed? Is it solid? Any issues I should be aware of before I commit to it? My understanding is that the Sigma fp L HDMI output results in soft and problematic external recording. Is that an issue on the older Sigma fp?

Anything else I should know before I plunk down $1700 for the camera plus another $1000 for the Video Assist 7"

Thank you.

Kays, I’d scour the internet. I wouldn’t rely on SIGMA for complete descriptions of anything. Gerald Undone would seem to be a good place to start; there should be a good amount of reviews by actual users since the camera has been around for about 18 months.

The sensor is smaller at about 24 megapixel but that’s a good thing after all as the rolling shutter will be less and I believe the BRAW feed isn’t line-skipping. I can’t speak with any authority as I didn’t look into it deeply assuming the rumored SIGMA fp L was going to be the better choice. I was wrong about that!

I'm considering trying one more time to explain things since it doesn't seem to be getting absorbed by Noel based on his comments after my explanations.

I think I would just be repeating myself but trying to re-phrase - has any of what I've said made sense to anyone or do I need to try again?

I thought you were pretty clear.