Still trying to solve black level flicker in Sigma fp’s CinemaDNG output. Despite identical light conditions and processing profile, video frames randomly alternate between two shadow levels.
Since this has been happening since the beginning with every firmware version, until now I thought it’s a hardware issue—some random noise during sensor operation causes it to report raw pixel values with slight offset, perhaps.
Today’s discovery: there is ~0.03 difference in black level DNG metadata value between such frames. The lighter frame has lower black level value, which is what I would expect!
Black level differs slightly in every frame, but normal difference seems to be 10x smaller. The jump of about 0.03 seems to occur between frames in which flicker is noticeable.
Current thoughts:
What if it’s only an issue of metadata, and raw values are actually consistent? I will see if I can overwrite every file’s black level to some static value (e.g., 256), surely it can’t be so easy and it’s bound to break everything?
Can RawTherapee be instructed to ignore the Black Level in DNG’s meta? That might be a godsend in case of seemingly buggy cameras like this.
It might still be a red herring, of course… Wonder if anyone had luck resolving this issue.
Here’s how the flicker looks. Almost acceptable in case of concerts, if you can trick yourself into thinking it’s some lighting fixture making things brighter every now and then, but horrible in any other setting where you need to pull up shadows in post (as is always the case when you have bright artificial lights in the frame, to avoid them clipping).
Well, I feel like an idiot now, because that’s actually all it is, apparently. After overwriting IFD0:BlackLevel, the flicker’s gone; frames come out consistent. All these years…
I guess it’d be a separate question as to whether RT can do this on its own, without the user having to pre-process Sigma’s raws with something like ExifTool.
Curious: could there be any unintended consequence if I irreversibly overwrite Black Level meta tag with a static value in every DNG I get out of this camera? Is there any processing workflow that could benefit from the slightly-differing black level values that come out of camera?
@Peter Thanks for the pointer, I respect Darktable but unfortunately I could never reproduce my RT processing techniques in DT. I might give it another short some time.
Based on the fact that DT allows to do it, though, I have a hunch that overwriting the Black Level tag with a fixed value right in actual DNG should not have any negative side-effects? I guess I’ll make that part of my workflow. Can’t help wondering what the tag is even useful for…
And yes indeed, SIGMA claimed they fixed it but it’s an open secret that it’s still an issue. I can assure you that I went through every firmware version available.
@paperdigits unfortunately, the raw black points in RT is a relative correction only, which makes it useless in this scenario.
(Remember, the black level tag value is fluctuating randomly between the frames—adding a fixed offset to a random value is still going to result in a random value and, therefore, flicker.)
Re overwriting the DNGs, I know that ideally it is a capture artifact but there are always practical considerations as well. It is perfectly reasonable, for example, to wipe things like camera unit serial number from raw metadata for privacy purposes. And in this case, if tag value is random and an artifact of camera malfunction and irrelevant to scene capture, it seems reasonable to overwrite it to facilitate further processing.
Let’s make it irrelevant whether it is overwritten or not. I might as well incorporate this correction in my workflow without altering the raws.
How is black level tag value supposed to be calculated in the first place by the capture device, what importance does it bear, and does it record anything of use about scene light or the capture device?
In case of this camera, it is clearly always the same number repeated for all 4 pixels (and that number unfortunately fluctuates from frame to frame even under unchanging light conditions). What do other CDNG-capable cameras output?
Again, have you contacted them for support, to alert them the issue still exists? Somehow, I think the chances of Sigma engineers following discuss.pixls.us are pretty low…
It’s first and foremost a property of the sensor’s circuitry design. 99% of the time it is constant (well controlled) in modern sensors, but could drift a bit with large changes in temperature and large changes in gain (ISO), so somewhat indirectly related to scene light. Certainly not expected to change from frame to frame in a sequence.
It’s first and foremost a property of the sensor’s circuitry design. 99% of the time it is constant (well controlled) in modern sensors
This does not explain the purpose of black level tag value. What role does the tag play? Sensor is supposed to capture raw pixel values, is “black level” camera’s estimation of noise floor or something? If that’s the case, then it’s clear that it’s patently useless—in the sense of capturing factual scene data.
could drift a bit with large changes in temperature and large changes in gain (ISO), so somewhat indirectly related to scene light. Certainly not expected to change from frame to frame in a sequence.
There is no observable relation in scene, temperature, light, or ISO (happens on both native ISOs and others). It happens with roughly the same frequency with no relation to the scene, even if you leave the camera completely static with a completely static light source, and regardless of how much it was used before.
Again, have you contacted them for support, to alert them the issue still exists?
They are aware and have been contacted a number of times by many users. It’s already a giveaway that they appear to have explicitly (if mistakenly) called the issue as fixed in v2 of the firmware, as Peter noticed in his reply we fp users are way past that firmware.
Something like that. It’s an offset added in the readout stage of the circuit so no pixel value is lost - there is read noise even with no light (e.g. lens cap on), and you want to preserve (not clip) the “negative” side of that noise distribution. It’s not useless - if you don’t preserve those values, you’d actually make any potential denoising more difficult and less
accurate (e.g. actually introduce some shift in the shadows).
That’s very interesting, I’ll be curious to learn more about it.
As far as my footage so far, replacing (with ExifTool) black level with some normalized value, same for all frames of a CinemaDNG clip finally allowed me to get consistently looking results.
In this case I haven’t used denoising (except impulse noise). I rarely need it and try to avoid using it, even in small doses it leads to loss of fine detail (at least in RT) and since my raw footage tops at 2K (4K with external SSD) I don’t really have the leeway to spare.
