Sigma Fp review and interview / Cinema DNG RAW

[Thomas Hill]

I'll be very surprised if it's not 4.

[rawshooter]

It is definitely 4, since the creator of the video just wrote this on RedUser:

Quote

As these things go we were running out of time and the decision was made to let the steadicam op go and just do #4 handheld, not my preference but that camera required the most amount of "rigging" hint hint.

http://www.reduser.net/forum/showthread.php?180359-Full-Frame-Cinema-Shootout-2020&p=1884748&viewfull=1#post1884748

 

That was expected, and confirms our observations of the camera's image quality weakness when recording full-frame 4K CinemaDNG. :-((

[paulinventome]

11 hours ago, rawshooter said:

- If it's 4 indeed, then it confirms what we already observed; that the Sigma fp has rather poor Raw video quality for a full frame camera and is significantly worse than the rest. If it's not 4, it would be a pleasant surprise.

Pretty sure it's 4.

But got to argue a bit here. What did you view, the vimeo or the download? I'm just downloading the source now to have a look because viewing through compression at typical HD sizes i doubt you'd see a difference. You may have been watching the UHD 1:1 version though. Of course don't forget it you don't want any scaling then DC mode gives you 1:1 sharpness for an APS-C effect. Try it.

The log profile comment is out of place - there's no native log with any of these sensors. So i don't really understand what you mean here? The fp has a more limited dynamic range than the others, like most prosumer stuff it's capped at 12 bit off the sensor (canon, lumix, nikon all the same). Whereas the bigger cameras, are different beasts entirely. What we're seeing is that as the baseline improves across the board they're all similar capable in most scenarios. What takes the cinema cameras beyond is the more difficult high range and low light scenarios.

9 is probably 8K Red Helium, and that kind of overexposure is what i'm seeing as well. There's at least two stops better than the sigma. But the comment about moire is odd because really i have never seen moire with the Red. And blurriness. Well that's odd.

I may ask Evin to see if i can get some DNG samples from the sigma. I don't know how they workflowed it...

cheers
Paul

[Chris Whitten]

Looks like they applied the continuous auto focus on the final sequence too.

 

[paulinventome]

15 hours ago, rawshooter said:

That was expected, and confirms our observations of the camera's image quality weakness when recording full-frame 4K CinemaDNG. :-((

Okay, i downloaded the 'source' file and looked through it.

IMHO the sigma stuff is a touch out of focus. If you compare to the under test you'll see the chart is sharper there. The normal studio test feels the focus is forward (his watch is in better focus)

Even at f2.8 on full frame the DOF is pretty shallow.

If you're not running the camera out to an external monitor critical focus is difficult.

Number 9 is well out of focus as well on the chart and the suggestion is that's 8K red. 

Im not saying for a moment that the fp is in the same league as the others (my red is 10 times the cost) or that the scaling couldn't be better. But it isn't that bad. I've shot full frame UHD and can be obsessive about things and i have no issue with the footage in real life. Yes, the scaling could be better and hopefully it will be. But if you want pixel for pixel sharpness then use DC mode. You have the choice.

I'd rather people petition sigma to push this forward - more crop choices, better scaling and so on. The sensor is there, the camera is capable but i feel sigma need to know this is what we want...

Cheers
Paul

[Lars Steenhoff]

I feel noise reduction was also used, because normally the sigma fp has lots of fine noise and I don't see that on the nights shots.

[paulinventome]

22 minutes ago, Lars Steenhoff said:

I feel noise reduction was also used, because normally the sigma fp has lots of fine noise and I don't see that on the nights shots.

I dunno, i think it unlikely - i doubt any more processing was done than the barest min. It would be fairer that way. Just guessing tho!

I suspect the nights weren't super high ISO, could have been pretty bright there

cheers
Paul

[rawshooter]

14 hours ago, paulinventome said:

But got to argue a bit here. What did you view, the vimeo or the download? I'm just downloading the source now to have a look because viewing through compression at typical HD sizes i doubt you'd see a difference. You may have been watching the UHD 1:1 version though. Of course don't forget it you don't want any scaling then DC mode gives you 1:1 sharpness for an APS-C effect. Try it.

The log profile comment is out of place - there's no native log with any of these sensors. So i don't really understand what you mean here? The fp has a more limited dynamic range than the others, like most prosumer stuff it's capped at 12 bit off the sensor (canon, lumix, nikon all the same).

I watched the download.

12bit off a 14bit sensor creates problems with dynamic range if the sensor values are stored as linear values. Blackmagic, as far as I know, encodes 12bit raw values with a logarithmic function and thus preserves more dynamic range.

The Sigma fp's sensor should, by itself, have no worse dynamic range than the sensors of most other tested cameras...

[Lars Steenhoff]

Yes I hope sigma can make a firmware update with non linear 12 bit raw

[paulinventome]

9 hours ago, rawshooter said:

I watched the download.

12bit off a 14bit sensor creates problems with dynamic range if the sensor values are stored as linear values. Blackmagic, as far as I know, encodes 12bit raw values with a logarithmic function and thus preserves more dynamic range.

The Sigma fp's sensor should, by itself, have no worse dynamic range than the sensors of most other tested cameras...

Do you agree that the fp was not in focus? (like camera 9)?

If we make the assumption that the fp is using the IMX410 sensor, as is the A7III, Nikon and perhaps the Panasonic then we can see that there is no way that sensor can deliver more than 12 bits in motion. Although there is a crop mode at 14 bits. If you look at the specs for all these other cameras then you can see that 12 bits in motion is pretty much a universal given - Canon say the same for their sensors too.

So the container from the sensor to the camera is a fixed 12 bit bucket.

If we also assume that all sensors are linear (physics and hardware wise this is the case) so the native signal off the sensor is going to be linear for all of these.

Now: either the sensor response in some cases is non-linear (it's possible but i don't think it is the case) or each of these companies is doing something to get these claimed stops beyond 12. In the case of this Sony sensor, is it logarithmically compressing 14 bits down to 12? I think not, there may be a bit of non linearity in the results (there are) but i think that's a function of the sensor itself. In my testing the difference between stills and cine shows that. But i think that goes for any of these sensors.

The latest BMD don't output DNGs anymore? But the old ones compressed 12 bit linear into a 10 bit container with a 1D LUT lookup table (great approach) but the source was no more than 12 bit)

What other cameras currently output DNG? Because it is very easy to look inside those at the RAW data.

And IMHO some of these companies are using techniques like highlight reconstruction to deliver > 12 stops. If you understand that each of the RGB filters has a different sensitivity then you can see how you can take advantage of that and extend the overall range beyond that 12 bit fixed linear container.

With the fp, and being RAW, it is up to you to do that reconstruction work. With other systems that are outputting their own RAW then that work can happen automagically internally. It is true that the reconstruction work is as simple as checking a box in resolve, or as complicated as doing the math yourself. Applications like Lightroom do it whether you want it to or not - it's fundamentally part of the lightroom debayer for stills as well. So the irony is a lot of skies done through lightroom are reconstructed highlights... (ever noticed that the blues can be somewhat off?)

The only time this doesn't count is when you have a cinema camera style sensor which is designed for greater bandwidth inside the sensor itself, 14, 16+ bits are common.

So IMHO i think the fp has a similar range as the other (prosumer) cameras but the data you get off the sensor is 'RAWer' and it's up to you to make the best of it.

This is my assumption. I have no insight into what the manufacturers are doing. I know i sound like a fanboy, i'm not really, my fp is a stop gap until Komodo ships. But i do think it's a wonderful little camera! I like what sigma are doing and they don't have any cinema camera lines to protect. I think they're really well positioned to do something quite special in this market segment and i'd hate for anyone thinking about getting an fp to not do it because of these kinds of conversations!

cheers
Paul

 

 

 

[Scott_Warren]

Hello all, long time reader / lurker and recent Sigma fp buyer here.

I wanted to join into the fp conversation and ask if anyone else is experiencing black level flickering with firmware 1.01 with 12bit 4K capture?

There are a handful of quick technical tests I've done to figure out the flickering behavior, and this is the most comprehensive:

It doesn't show in the above video, but ISO 400 actually still flickers. With my own camera, 320 is the highest I can go on the low end, and the next one up without flickering is 2500. 

On the other hand, it doesn't seem to be a massive loss right now since 320 + F1.4 seems to be enough to capture a dark city road close to how it appears in person, as you can see with this clip:

Would anyone be willing to do a quick ISO test of their own camera to see if you have any flickering blacks at each ISO level? It shows up quickly, so each ISO wouldn't need more than 5 seconds of capture time to see it. It doesn't seem to matter what the light source is, either, as it happens in sunlight as well as with LED lighting. 

It may be subtle in the image if it happens, but you'll definitely see it happen in the bottom of the waveform on playback in your post software of choice. Oddly, it seems to mostly affect the red and blue channels. 

I've tried resetting the camera and re-installing the firmware to no avail. 

[paulinventome]

21 hours ago, Scott_Warren said:

It doesn't show in the above video, but ISO 400 actually still flickers. With my own camera, 320 is the highest I can go on the low end, and the next one up without flickering is 2500. 

It's not something i've noticed so far but will give it a go tomorrow. What frame rate and bit depth? It could be related to that rather than the camera. How about shutter speed?

I thought i could see some pulsing from the lights but you say you see the same in daylight?

And which ISO is causing the biggest issue for you?

cheers
Paul

[Scott_Warren]

44 minutes ago, paulinventome said:

It's not something i've noticed so far but will give it a go tomorrow. What frame rate and bit depth? It could be related to that rather than the camera. How about shutter speed?

I thought i could see some pulsing from the lights but you say you see the same in daylight?

And which ISO is causing the biggest issue for you?

cheers
Paul

Thanks for the quick response, Paul! In the vanity shot there is 60hz pulsing from the halogens, but that's stable while the flickering is more spastic, and only on the low end.

Frame rate is at 23.98, shutter at 1/50th (which seems to be the case whether I use 180 degrees or just specify 1/50th according to the DNGs). All 12bit at full 4K res recorded to the T5 1TB. 

Here's the current behavior of my camera:
ISOs 100-320 are OK, 400-2000 flicker, 2500-3200 are OK, 4000 flickers, and then 5000-12800 are OK.

All of the ISOs that flicker do it in the same way, so it would be tough to say that one is worse than the others.

It also doesn't seem to be related to how I'm treating things in Resolve as I'm doing pretty basic stuff to it via the ACEScc pipeline. Flickering is present regardless of what pipeline is used. 

It's quite the mystery!

[Lars Steenhoff]

Please send your findings to sigma so they can make a firmware update with fixes

[paulinventome]

On 2/6/2020 at 6:04 PM, Scott_Warren said:

It also doesn't seem to be related to how I'm treating things in Resolve as I'm doing pretty basic stuff to it via the ACEScc pipeline. Flickering is present regardless of what pipeline is used. 

It's quite the mystery!

Okay, so you're right - there's something going on here. Although my 800 is stable and i got a quick flicker in 400, just once at the start of recording. There was a fix to the original firmware that 'stopped' something that sounded like this. But clearly hasn't. Although it's not something i've seen in the footage i've shot - so i can't say it's always happening.

I've gone to the source of the files and i believe there's some scaling to the channels that is the cause, in which case there's hope to fix the data before debayer if it has caused a problem.

In the DNG's there is a value called black level, which is subtracted from the image. I see different minimum values for this across two DNGs and i can compensate for that in RAW Digger to see. Even doing that i believe there is a scale going on with the channels.

If it's something that can be sorted it would be best to sort this before debayer in the RAW DNG files.

I will have a word with them to add to any other reports sent.

What we should work out are the circumstances under which the camera does this...

cheers
Paul

EDIT: So i've passed on the files to sigma and see what they say. Useful for others that have similar files to do the same.

 

[MikhailA]

Here is the video illustration of a strange issue  with in camera stills preview I mentioned before: during  scrolling through  images there is about 1 second lag when your  see low res blurry  preview and only  then full res image . Still can't get used to it.

 

Again, memory card - SanDisk Extreme Pro SD Card 64GB Speed 300MBs

 

 

Shot through lvf 11 viewfinder. All stills are JPEG, not DNG

Here are 4 scenarios:

1.scrolling full size /full screen  images - lag.

2. Zoom in then zoom out to full screen- lag

3.scrolling zoomed in images - no lag.

4. full-size slideshow- no lag

 

It is not a big deal comparing to other things observed here but anyway it shouldn’t work this way. I  believe it is something that can be fixed with the update easily…

 

[Lars Steenhoff]

And the panning speed in a zoomed in image is way too slow, on a nikon camera I can quickly confirm my focus after taking a shot by zooming in and panning around the image with the d-pad,  in sigma when you hold down the d-pad to pan over you image the repeat rate is way slow. it takes like 3-4 seconds to move from one side of the image to the other.

When using the touch screen it is smooth. so its not like the camera cannot make a smooth fast pan over a zoomed in image.

Those things are simple to fix in firmware but i have never seen firmware that fixes these kind of things.

In the end it all adds up, and it slow you down

[Scott_Warren]

On 2/8/2020 at 11:20 AM, paulinventome said:

Okay, so you're right - there's something going on here. Although my 800 is stable and i got a quick flicker in 400, just once at the start of recording. There was a fix to the original firmware that 'stopped' something that sounded like this. But clearly hasn't. Although it's not something i've seen in the footage i've shot - so i can't say it's always happening.

I've gone to the source of the files and i believe there's some scaling to the channels that is the cause, in which case there's hope to fix the data before debayer if it has caused a problem.

In the DNG's there is a value called black level, which is subtracted from the image. I see different minimum values for this across two DNGs and i can compensate for that in RAW Digger to see. Even doing that i believe there is a scale going on with the channels.

If it's something that can be sorted it would be best to sort this before debayer in the RAW DNG files.

I will have a word with them to add to any other reports sent.

What we should work out are the circumstances under which the camera does this...

cheers
Paul

EDIT: So i've passed on the files to sigma and see what they say. Useful for others that have similar files to do the same.

 

Thank you for looking under the hood, Paul! I've been moving the last few days so I haven't been on the forum as much.

I did see talk related to the auto-black level issue with CDNG as a format years ago when it showed up on the older Blackmagic cameras, so it's interesting to see this show up again. 

I've sent Sigma several emails and linked them to other user videos on YouTube where the issue is happening. 

Sigma NY is curious to look at my camera to see if 1.01 didn't correctly overwrite 1.00 somehow. 

I don't mind the growing pains of a new camera system when the image is so good. The joys of technology! 

[paulinventome]

7 hours ago, Scott_Warren said:

I don't mind the growing pains of a new camera system when the image is so good. The joys of technology! 

Good you've passed it on.

I hear there is hopefully a firmware release at the end of this month/early next.

I reviewed all the footage I shot and some of it quite low light but didn't see *any* flickering. So i may have just been lucky or it's a combination of settings that brought it on.

For you does it flicker all the time or just at the start?

I see in the data that the black level can go lower than the black level adjustment, meaning that the blacks can be a bit clipped. In Resolve i don't know if it assumes the black level value in the DNG or if it adjusts it accordingly. I'm going to have a closer look because it might be there's a little more data in there sometimes.

cheers
Paul

 

[Scott_Warren]

On 2/11/2020 at 2:20 AM, paulinventome said:

Good you've passed it on.

I hear there is hopefully a firmware release at the end of this month/early next.

I reviewed all the footage I shot and some of it quite low light but didn't see *any* flickering. So i may have just been lucky or it's a combination of settings that brought it on.

For you does it flicker all the time or just at the start?

I see in the data that the black level can go lower than the black level adjustment, meaning that the blacks can be a bit clipped. In Resolve i don't know if it assumes the black level value in the DNG or if it adjusts it accordingly. I'm going to have a closer look because it might be there's a little more data in there sometimes.

cheers
Paul

 

It definitely tends to flicker all the time with the range of ISOs I listed.

I haven't tested this theory, but I wonder if it might be related to the shooting mode issue Andrew found with the incorrect exposure preview in single-shot mode? I don't know WHY it would be related, but it's another thing to test. I have the camera in manual, single-shot mode when not in Cine mode. I'll do a test putting it into continuous mode before capturing some more clips. It would be insane if there's a Goldilocks zone of settings the camera needs to have to avoid flickering 😛  That or it's just a software issue, which it well seems to be.