Mean/Median Stack of multiple dark frames before demosaicing.

Entropy512 · December 23, 2019, 11:44am

BTW, I did find the exiftool based flow I use often - Loading .raw images (from industrial cameras) - #7 by Entropy512

Note that your ColorMatrix will definitely be different (although for darkframe stacking it may likely not matter as I would assume RT will ignore the ColorMatrix metadata if it’s being used as a dark frame)

Waveluke · December 23, 2019, 8:32pm

I noticed that in your exiftool script the black level had four numerical entries presumingly for each channel of the bayer matrix, but in the metadata for a real BMPCC raw file, there was only one entry for the black levels. Which should I go by?

Waveluke · December 23, 2019, 9:19pm

Ok, so I went with the four value black level, inputting the value found in the metadata for the real camera raw file. When I did the dark frame subtraction, I noticed that the result was clipped black until I applied negative raw blackpoint compensation in Rawtherapee at a value of -500. However, after application, it looks like the hot pixels and amp current were fixed.

Is this behavior an inevitable result of subtracting a darkframe with a raised noise floor, or does this mean I need to fiddle with the black point setting in Exiftool a bit more? The fact that this blackpoint compensation is needed when subtracting another camera original raw file suggests that it is inherent to the dark frame subtraction, and the metadata settings I inserted were correct, and changing the black point in Rawtherapee after the subtraction is the correct workflow. What are your thoughts?

Entropy512 · December 23, 2019, 11:12pm

Hmm, I’m not sure on this one, as I’ve never used the darkframe subtraction before.

There might be a corner case/bug that occurs if a non-DNG raw file is used with a DNG darkframe, not sure. What happens if you use a single original raw file?

Waveluke · December 24, 2019, 7:50am

Ok, so I noticed the same issue mentioned with black levels when I used an original raw file, and the issue is present but hot pixels get fixed regardless of if the subtraction file is the ‘real’ one or the averaged ‘cludged raw’ file, so my intuition tells me that it is an inevitable quirk of the darkframe subtraction with the BMPCC, based on elevated effective black levels. If this is true, then I should just continue to add the negative black point compensation in the raw tab after enabling subtraction. But the other less plausible but still possible option is that the black point in metadata manually inserted for the subtraction frame is not correct and I should continue fiddling with it. I was just curious if you had any opinions any one way or the other.

Nonetheless, I got the pseudoraw darkframe effectively working, in large part thanks to your much appreciated guidance, and question posed above is more theoretical minutia about the most optimal way of doing things than technical obstacle of necessary surmountation.

Entropy512 · December 24, 2019, 12:05pm

Hmm… There might be a bug in RT regarding black level handling when DFS is performed.

heckflosse · December 24, 2019, 12:25pm

This looks suspicious:

github.com

Beep6581/RawTherapee/blob/dev/rtengine/rawimagesource.cc#L2416

    
      
              rawData(0, 0);
          }
          if (green) {
              green(0, 0);
          }
          
          
if (red) {
              red(0, 0);
          }
          
          
if (blue) {
              blue(0, 0);
          }
          
          
if (greenloc) {
              greenloc(0, 0);
          }
          
          
if (redloc) {
              redloc(0, 0);
          }

If someone can provide example files from a camera with a black level > 0 I can check what’s wrong…

Edit: iirc at this stage of RT pipeline the data is still before black level subtractions, means each file is something like BL + data. If we now subtract image1 (the darkframe) from image 2 we would get image2 - image1 (means after subtracting black level). For this reason the blacklevel is added to the result in the code I posted above).

Entropy512 · December 24, 2019, 12:48pm

For examples you’ll need to talk to @Waveluke, although at least reading that - that should be re-adding the black offset so it remains after subtraction.

Unless W/H are mismatching for some reason, in which case the black level correction wouldn’t be applied.

heckflosse · December 24, 2019, 12:50pm

But then the darkframe subtraction also would not be applied.

Entropy512 · December 24, 2019, 1:13pm

ERROR, insufficient caffeine at this time.

Good call.

ggbutcher · December 24, 2019, 2:46pm

My latest PlayRaw NEF is from a camera with metadata black > 0, Nikon Z6=1008:
https://glenn.pulpitrock.net/Individual_Pictures/DSZ_4168.NEF

heckflosse · December 24, 2019, 2:48pm

I also need a dark frame…

ggbutcher · December 24, 2019, 2:48pm

Care about shutter speed, ISO, etc?

heckflosse · December 24, 2019, 3:04pm

shutter speed and ISO should be the same as the other image. Lens and aperture should not matter in this case.

ggbutcher · December 24, 2019, 3:15pm

Here’s one, 1/3sec, ISO 400, same as DSZ_4168.NEF:
Lens cap on, dark room, camera wrapped in a black towel to avoid leakage…

https://glenn.pulpitrock.net/Individual_Pictures/DSZ_4437.NEF
This file is licensed: Creative Commons, By-Attribution, Share-Alike.

I call it “Black Cat Eating Licorice in a Coal Mine”. As a PlayRaw, I’d be interested to see what folk can do with it…

heckflosse · December 24, 2019, 6:09pm

About dark frame subtraction in RT:

Waveluke · December 24, 2019, 7:07pm

Love that…

Waveluke · December 24, 2019, 7:49pm

OK, here are some tests of the issue. Linked below are three raw files, from or derived from the Blackmagic Pocket Cinema Camera OG. According to the metadata, the black level on them is supposed to be 256.

The raw files include a raw file with image content but exposed near the noise floor, and thus has prominent hot pixels and amp glow, named “Image in need of dark frame subtraction.dng”. Then there is an authentic BMPCC dark frame, labeled “Authentic camera dark frame.dng”. Then there is a fake dark frame with less random noise, created following the advice of @entropy512 as seen earlier in the thread, with the metadata imported from a real BMPCC raw file, including the black and white levels, and all relevant raw interpretation metadata.

Also included is the output of Rawtherapee with various permutations of dark frame subtraction. One with no dark frame subtraction and two with the real dark frame, and two with the kludge dark frame with consistent black levels in metadata. Each darkframe output set has one as is, showing the bug with near complete blackness, despite excessive exposure comp, and the other shows that -512 black point compensation, not so coincidentally, twice the value as found in the metadata, seems to fix the problem.

https://drive.google.com/open?id=1sHx5F0WFi1-jyifwxTDFLx6x1E-IbX6v

Waveluke · December 24, 2019, 7:55pm

Just posted below, some details of the problem with more test raw files. Anywhere else I should post the writeup and Google Drive link, ie, did you open an issue for the bug on github? The github link you posted looks like an optimization, not bug issue, so I wanted to ask your thoughts.

Waveluke · December 24, 2019, 8:05pm

Some of you may squawk that I was using an out of date version of Rawtherapee, so I quickly downloaded and installed 5.7, the latest stable release, straight from https://rawtherapee.com/, and noticed the results were the same with the update, with the pure black result from just the dark frame, and the expected result from -512 black point compensation, so no point in re-export of example jpegs.