Denoising high-ISO images: a sourdough bread

[alpinist]

@Timur

There is another approach to noise reduction — contrast equalizer module with quite good module presets. It allows good separation between high and low freq. noise. This is how I removed that pinkinsh color cast.

Thanks for the hint, would you mind sharing your xmp file?

@Timur

@alpinist sensor cooling and low ISO are the best ways of noise reduction Still wonder why they don’t use sensor cooling in consumer grade cameras like astronomers do…

Sensor cooling helps with long exposures, where noise from the electronics accumulates. The noise that we see here is mostly shot noise - noise that exists because light comes in discrete packets (=photons).

I guess that introducing sensor cooling in portable consumer grade cameras would significantly increase their energy consumption and weight, and introduce condensation problems. All that for no real benefit unless you shoot a lot of multi-second (or longer) exposures.

If, for a given scene, you are bound to a certain field of view and depth of field, the real world diameter of the aperture that you must use is fixed. Then, if there is some subject movement, you are bound to some maximal exposure time as well.

Together, the product of the exposure time and the aperture cross-section determines the number of photons that you may harvest for a given scene. This is independent of the camera. Even the latest and greatest full frame sensor camera will produce essentially the same amount of noise (unless it uses some revolutionary non-Bayer sensor technology that does not exist, Faveon is not really better I believe).

@Timur

Don’t expect a lot from software. This camera made very noisy picture at ISO 6400 with some totally black pixels (dead?) and big pinkish artifacts. There is little real information behind that random mess.

This was shot with a new Olympus E-M5 Mark III, a decent camera with a modern sensor. I do not see the black points in the unprocessed RAW file. Are they an artifact of Olympus’ JPEG engine?

@Timur

Even more, adding little noise can improve perceived image quality (especially printed) just like they add noise in lossy sound codecs to hide artifacts.

P.S. I don’t like builtin JPEG result. Those black pixels are very visible, no matter what picture scaling algorithm you use to see final picture on your display.

Sure, it’s not perfect, but it does avoid the excessive grain and discolorations that I got when using denoise (profiled) as recommended in the darktable manual. And I do not see any real detail that is destroyed by the camera JPEG engine processing as compared to the more conservative darktable noise processing. The black dots are ugly, that’s for sure.

[Jade_NL (Jacques)]

@alpinist

Thanks for the hint, would you mind sharing your xmp file?

You can use @Timur’s jpg as sidecar.

[alpinist]

Could you give me a hint on how to do that? I searched the manual and the web but did not find an explaination.

I tried saving his file as bread_01.jpg and then re-importing the raw file. I also tried importing his jpeg file directly.

[Jade_NL (Jacques)]

@alpinist

Could you give me a hint on how to do that?

From within lighttable view:

• select the raw file,
• activate the history stack module,
• click on load sidecar file…,
• on the bottom right click on XMP sidecar files and change it to all files
• search for and select the jpg.

This doesn’t always work, it does depend on the settings in the preferences that accompany the export module (check the hamburger → preferences). develop history is turned on by default, but it can be turned off.

EDIT: The preferences for exporting are still next to the export button (the gear icon) in version 3.4.1. It will be moved to the hamburger thingy in the upcoming stable version.

[Timur (Timur Davletshin)]

@alpinist

I do not see the black points in the unprocessed RAW file. Are they an artifact of Olympus’ JPEG engine?

They do exist even in my processed file. But they are significantly reduced by demosaic parameters. There are some dead pixels too. Look closer and you will notice them even on my first pinkish JPEG.

[alpinist]

Certainly, there are some black points in the RAW file that may be dead pixels. But nearly not as many as there are in the Olympus JPEG.

[Timur (Timur Davletshin)]

@alpinist

Sensor cooling

That was a joke actually )))

[alpinist]

I would have understood if you had used a twinkling smiley…

It also did not help that you seemed to seriously blame the camera where as I explained it does not matter much.

[Timur (Timur Davletshin)]

@alpinist

Sure, it’s not perfect, but it does avoid the excessive grain and discolorations that I got when using denoise (profiled) as recommended in the darktable manual.

Don’t know what they recommend these days (documentation was significantly improved last year), but before they recommended two instances, one for color and another for luminance channel. Personally I don’t try to eliminate it completely. I have never seen perfect results of noise reduction without introducing blurriness. I just use blending at ~50%. There is no way to remove it completely if noise is already there — so, why bother?

[Timur (Timur Davletshin)]

@alpinist come on, dude! I just judge by result and the picture is very noisy. All cameras have their limits, you pushed limits of your camera too far if your are not satisfied with amount of noise it made.

Check this file out and see how many dead pixel that super expesive camera made
[x1d-xcd45-02.dng | oh no! file has been deleted due to copyright issues] (51.6 MB)

[Jade_NL (Jacques)]

@Timur

Check this file out and see how many dead pixel that super expesive camera made

That sensor needs a cooler

[Timur (Timur Davletshin)]

@Jade_NL funny fact, that is actually a sample shot from camera producer. All their files are full of sensor dust and noise.

[alpinist]

@Suki2019

my attempt

Thank you, @Suki2019, your result is excellent. You even manage to reduce the purple decoloration very significantly. I have the impression that the essence of your approach is captured in the following style that applies only three modules (2x denoise (profiled) and contrast equalizer):

suki’s denoise.dtstyle (1.5 KB)

I see that you use blend mode “average” for non-local means. What does it do? I could not find any documentation for it. It does not seem to simply take a pixel-by-pixel average between the output of the module and the input - that would be blend mode normal at 50% opacity, wouldn’t it?

Applying the above style to other high-noise test images produces very good results for me, clearly better than the camera’s JPEG engine.

@Suki2019

i also don’t see the area you are focusing on in the image as meaningful, since it is the blur area in the image.

I focused on the bread dough, more or less where the biggest hole is.

[Timur (Timur Davletshin)]

@alpinist

Thank you, @Suki2019, your result is excellent.

Colors are good, but zoom 100% and you will see lots of white and black specks.

[priort (Todd Prior)]

I wonder if any hint to be had here https://www.youtube.com/watch?v=RMbbLyKqdLY

1 Around 10-11 min …per channel wavelet adjustments
2. Around 18 min …this one I found really powerful…at about the 18 min mark …again its a per color channel application but it is very effective…and bumping the radius in the bilateral filter now surface blur was great for the blotches in this image…I fine the whole video a really good background for understanding DT denoising…it has been updated but the parts here on the alternate methods of denoising are still relevant I think

[priort (Todd Prior)]

[alpinist]

@alpinist

I see that you use blend mode “average” for non-local means. What does it do?

Answering to myself.

After all, “average” with opacity N% is the same as “normal” with opacity N/2 %. (I checked the source code.) No idea why it’s even there.

[Thomas_Do (Thomas)]

Tried something different. Denoise with dt 3.4 plus a little post-sharpening with GIMP.

bread.orf.xmp (8.5 KB)

[Suki2019]

@alpinist

Answering to myself.

After all, “average” with opacity N% is the same as “normal” with opacity N/2 %. (I checked the source code.) No idea why it’s even there.

if i remember correctly, “average” should actually be an average of surrounding pixels.
the half opacity of normal is also an average but always in the overlaid pixel.
whether what i write here is correct in relation to darktabel i don’t really know

but average helps me very often not to exaggerate things

(translatet by…)

[alpinist]

Here are the actual lines of code (taken from the file src/develop/blends/blendif_raw.c):

“normal” blending:

    b[j] = clamp_simd(a[j] * (1.0f - local_opacity) + b[j] * local_opacity);

“average” blending:

    b[j] = clamp_simd(a[j] * (1.0f - local_opacity) + (a[j] + b[j]) / 2.0f * local_opacity);

The above lines are the only difference between both blending methods. And as you can see, setting local_opacity with “normal” blending to half the value of “average” blending yields the same result.