RAW subtract

[DBgit]

Hi,

I would like to have the possibility to perform manually a dark frame subtraction between two raw files already stored in camera. In other words, I want a "raw subtract" feature along with "raw merge" and "raw average".

Here is why I think it could be useful:
Let's say I take several long exposures with the automatic dark frame subtraction off. Later on, I could then manually take a few dark frames (with the lens cap on). I then merge all the raw exposures together in a new raw file and all the raw dark frames in another raw file with "raw merge".  With a "raw subtract" feature, one could then subtract these two raw files one from the other to get a high quality raw file with minimal noise!

The big advantage would be to perform the dark frame subtraction at the RAW level (i.e. before the demosaicing process). This can theoretically eliminate the presence of artifacts that can appear when the dark frame is subtracted after the demosaicing process. Another advantage would be to have a single raw file to post-process (and store on our HD) instead of two (or more).

I took a rapid look at "raw_merge.c" and it think this "raw subtract" feature could be implemented by simply changing a few "+="to "-=" in the 8 lines beginning with "row[i+XX] += ...". It might also require a few other minor changes like (i) limiting the number of raw files selected to two, (ii) adding back the BLACK_LEVEL instead of removing it, and (iii) a final verification to ensure that no intensity values are negative or exceeding 1023.

What do you think?

[LjL]

This is related, though not in itself similar, to the various requests for automatic dark frame creation (search for "creation of darkframes").

But there's certainly no problem, as you say, implemention subtraction even without yet having automatic dark frame creation.

The best thing, I think, would be to just have a new option "Deferred" in the "Noise reduction" / "Dark frame subtraction" selection, which will do your shot(s) and then, later, shoot the same number of dark frame, with the same shutter speed, merge them, and subtract them from your shots.

[fe50]

Wouldn't this (shooting a dark frame later) bring more noise ?
I thought that the intensity and the arrangement of the noise is more or less dependend from things like the temperature of "hot" parts near the sensor, so a dark frame shot under other circumstances (cold camera) couldn't bee as good for noise reduction as a "direct" DF shot, or do i misinterpreting this ?

[fudgey]

Yes an older (or more in the future) dark frame is not as good as one shot right before or after each shot. Useful and probably better than nothing, but worse.

Btw, would it be a good idea (for long exposure shots, that is) to shoot a dark frame before and after each shot, and then do some cunning processing (or less cunning like averaging each pixel) to join the two dark frames so that the result would better represent the camera's state during the actual shot instead of before or after the shot? For instance would this further reduce purple fringing, some of which is always visible even after dark frame reduction in long exposures?

[LjL]

Sure, it's theoretically better to shoot a dark frame after (or even before, too) each actual shot.

But hey, I'm sure you see the convenience of shooting a one-hour-long exposure that actually lasts one hour, and then going back home while your camera shoots the dark frame. It's still generally much better than shooting them the following day, as far as temperatures go!

Besides, there are times when you just want to emulate a single, long exposure, and you really don't care for having a long gap after each exposure.

Also, don't be mistaken thinking that, if the dark frame is shot shortly after the exposure, then the noise will be more "similar" in the sense that the same pixels will have noise. It won't.
It will be similar on average, that's all that the temperature changes can modify! You're still not removing any noise (except for the hot pixels), you're just subtracting some spurious brightness from the image - on average.

Another interesting thing to mention is that a dark frame can be simulated if you have a bias frame. A bias frame is a frame that only records electronic noise from outside the sensor. If you have that and a dark frame for any exposure / temperature, you can approximate the "right" dark frame for your exposure time and temperature.
See Wikipedia about this.

[DBgit]

[fudgey]

Ah yes amp glow, that's what I meant obviously.

[reyalp]

Dark frame control

Note that the cameras have temperature sensors (it uses that as part of the decision whether to do a raw subtract or not in the original firmware) so it may be possible to have it alert you to the need for a new dark frame. Or automatically create one whenever the temp or exposure settings change by more than a certain amount.

[reyalp]

Back to the original topic:
FWIW, I now have raw subtract working on the camera, and pre/post darkframe raw writing controlled by options and available from ubasic.

Still to do:

• write a proper UI for raw subtract. I have in mind two options:
  • create darkframe. Takes the pre and post darkframe raws of a given exposure (which in my current code have the same number but different names) and creates a darkframe.
  • apply dark frame. Takes a darkframe, generated above, and subtracts it from a list of files.
• clean up the mess mess in raw_savefile. It current does a lot of stuff that doesn't actually have to do with saving files, like bracketing, save first raw only and bad pixel removal. Calling raw_savefile twice makes this much worse. I have it working with those options (I think...), but it's a mess.

If any coders want to look at the code, I'm happy to post a diff, but it's pretty raw  at the moment so unless someone wants to work on it, I'll hold off until it's a bit nicer.

If anyone has feedback on how they'd like it work, please speak up.

[DBgit]

FWIW, I now have raw subtract working on the camera, and pre/post darkframe raw writing controlled by options and available from ubasic.

Cool! Thanks for your work reyalp. I'll certainly take a look at it once you are ready.

The UI you suggest looks OK to me. However, it would be much better (and faster) if we could get a real control of the shutter to create directly a dark frame (i.e., without taking a pre and post raws of a given exposure...). If I remember correctly Dataghost already found a way to close (or open) the shutter during an exposure.

Anyway, if this type of control is not possible, your approach to create a dark frame is certainly useful. Of course, another solution would be to put the a cap in front of the lens! 

[reyalp]

The UI you suggest looks OK to me. However, it would be much better (and faster) if we could get a real control of the shutter to create directly a dark frame (i.e., without taking a pre and post raws of a given exposure...). If I remember correctly Dataghost already found a way to close (or open) the shutter during an exposure.

That would be ideal. If you have a link where that was discussed, I'd appreciate it.

FWIW, what I have should just mean that 1 exposure will take longer, which is the same as if you manually took the picture and then did a darkframe shot. Of course how inconvenient that is depends on what you are doing. If you want to avoid fiddling with the options, you could script it so that the first frame has camera NR on and the required raws grabbed, and then turns those options off.

Anyway, if this type of control is not possible, your approach to create a dark frame is certainly useful. Of course, another solution would be to put the a cap in front of the lens! 

Annoying on P&S cameras that have a bunch of delicate moving bits and no thing to attach a cap to

[fudgey]

That would be ideal. If you have a link where that was discussed, I'd appreciate it.

http://chdk.setepontos.com/index.php/topic,1365.msg16080.html#msg16080

[DBgit]

FWIW, what I have should just mean that 1 exposure will take longer, which is the same as if you manually took the picture and then did a darkframe shot. Of course how inconvenient that is depends on what you are doing. If you want to avoid fiddling with the options, you could script it so that the first frame has camera NR on and the required raws grabbed, and then turns those options off.

Hum... I'm not 100% sure I understand correctly your technique to get a dark frame.

What I would like to do : shot several frames in a row with the dark frame subtraction off (for e.g.,  it is not possible to get continuous star trails if a dark frame is taken after each shot). After I took these shots, I then need to take the dark frames that were not acquired during the shooting session. To do so, I would ideally tell the camera to close the shutter and take the same shots with the exact same conditions (or alternatively, I can put a cap in front of the lens, put the camera in a black box, etc.). Once everything has been shot, I simply subtract manually the exposures and the dark frames.

If I understand properly the technique you developed, you obtain a dark frame by recording the raw buffer both (i) just after the exposure and (ii) after the exposure has been corrected with a dark frame. You then subtract the two raw files to get the raw dark frame. Although this technique seems to work perfectly, the problem is that you need twice the time to collect the dark frames (and you also need to perform quite a lot of calculation). This can be a problem if one needs to collect the dark frames for several 65 s exposures...

[LjL]

Yes, that is indeed the drawback of his approach. If you want to save that time, you have to play with DataGhost's build and its functions to take shots with the shutter closed.

[reyalp]

The big advantage would be to perform the dark frame subtraction at the RAW level (i.e. before the demosaicing process). This can theoretically eliminate the presence of artifacts that can appear when the dark frame is subtracted after the demosaicing process.

Unless you do further processing, you actually just end up with different artifacts. Wherever your dark frame had a near max value pixel, you end up with a corresponding dark pixel in subtracted frame (the noise swamped whatever was there, so you can't actually recover the "right" value) Since it is typically only one color lit, what you see after you demosaic an image like this is a still a bunch of colored spots, they are just darker and the opposite color from the original noise. If your subject was very dark, this actually looks pretty OK, but the brighter it was, the worse it will look.

What you really want to do is interpolate a value for that dark spot from the neighboring, non-zero pixels for the same color, before you demosaic. dcraw (and relatives) will do this for you under some circumstances.

You can actually see these holes with the canon firmware noise reduction, although they seem to do something to keep them from getting too saturated and jpeg smooths it out a bit.

I have raw subtract on the camera basically done, but I'm starting to think it's not that useful. Unless you don't have access to the PC, the camera is just the wrong place to do image processing. It's slow, you can't see what you are doing, and from a programmers perspective, it's far more limited. Processing before demosaicing may be useful, but in that case the right way to do it is still on the PC. Porting the raw handling code to the PC is trivial (i've already done it because it was more convenient than testing on the camera) and once you are there you have gobs of memory, CPU and libraries at your disposal.

This isn't the answer I wanted to come to, given how much time I put into this, but so it goes  I'll still post the code for whoever may want it, but IMO the value is limited.

edit:
posted here http://chdk.setepontos.com/index.php/topic,2099.new.html