Denoising HDR sources

[Boulder]

Are there any specific things to keep in mind when denoising HDR sources with filters like MDegrain? What I'm wondering is that as the filter only seems the non-graded pixels, is there any recommended special pre- and post-processing to do? As far as I've understood, resizing should be done in linear light, for example with ResampleHQ.

[MonoS]

Are there any specific things to keep in mind when denoising HDR sources with filters like MDegrain? What I'm wondering is that as the filter only seems the non-graded pixels, is there any recommended special pre- and post-processing to do? As far as I've understood, resizing should be done in linear light, for example with ResampleHQ.

Quite an interesting question.
In the past i've denoised an HDR clip without questioning too much using MVTools giving me the results i expect, so maybe it doesn't need any particular pre-processing?
But I'd expect that passing a tonemapped clip to the analisys part of MVTools may be better? I really don't know.

[johnmeyer]

Once the HDR still or video has been created, it is just pixels, like any other video. Yes, it has a certain "look" because of the gamma mapping, but I don't think the denoiser would "care" about how those noise pixels got there.

The only thing I can think of that might be a little different is that HDR photos and videos seldom have any totally black areas because the overexposed image (which gets mixed with the underexposed image to achieve the HDR effect) provides detail in areas that would otherwise be black. Therefore, if any of the denoisers include algorithms for denoising near-black areas more aggressively, that feature might want to be turned off or diminished.

[StainlessS]

For any kind of MC denoise on any Hi Def, I think maybe that a Blur prefilter on clip to MSuper (for MAnalyse) would be a good idea.
(although I dont do much in any HiDef, and non at all on HDR).

EDIT: Maybe something like this (totally untested, might crash)


# Mod from, McDegrain/McDegrainSharp, From:- http://forum.doom9.org/showthread.php?p=1737045#post1737045

Function MCDegrainHD(clip c, int "frames", float "bblur") {
frames = default(frames, 2)
# bblur = default(bblur, 0.6)
defbblur = (c.width>1920) ? 0.75 : (c.width>1280) ? 0.7 : (c.width>960 ) ? 0.65 : 0.6
bblur = default(bblur, defbblur)
bs = (c.width>1920) ? 32 : (c.width>1280) ? 24 : (c.width>960 ) ? 16 : 8 # EDIT: Added block size 32
superFilt = c.blur(bblur).MSuper(pel=2, sharp=1) # EDIT: Make MC block matching easier for MAnaylse & 'gritty' source, using blur.
super_rend = c.MSuper(pel=2, sharp=1,levels=1) # Only 1 Level required for render Super (not MAnalyse-ing)
backward_vec3 = MAnalyse(superFilt, isb = true, delta = 3, blksize=bs, overlap=bs/2)
backward_vec2 = MAnalyse(superFilt, isb = true, delta = 2, blksize=bs, overlap=bs/2)
backward_vec1 = MAnalyse(superFilt, isb = true, delta = 1, blksize=bs, overlap=bs/2)
forward_vec1 = MAnalyse(superFilt, isb = false, delta = 1, blksize=bs, overlap=bs/2)
forward_vec2 = MAnalyse(superFilt, isb = false, delta = 2, blksize=bs, overlap=bs/2)
forward_vec3 = MAnalyse(superFilt, isb = false, delta = 3, blksize=bs, overlap=bs/2)
(frames<=0) ? c :\
(frames==1) ? c.MDegrain1(super_rend, backward_vec1,forward_vec1,thSAD=400) :\
(frames==2) ? c.MDegrain2(super_rend, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400) \
: c.MDegrain3(super_rend, backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=400)
return(last)
}


EDIT: At least it dont crash.
EDIT: Where good MC match on blurred clip (src for superFilt), uses MC matched from degrained super_rend, where not good MC match, uses original non degrained bits from original clip c.
HiDef tends to be 'gritty', and so harder to match using MC, blur should make it easier to MC match blocks. HDR is likely HiDef too.
EDIT: A higher default bBlur might also be a good idea, perhaps about 0.75->1.0 for full HD+, Didee tended to always use 0.6 for pretty much everything [StdDef].

Maybe something like

# bblur = default(bblur, 0.6)
defbblur = (c.width>1920) ? 0.75 : (c.width>1280) ? 0.7 : (c.width>960 ) ? 0.65 : 0.6
bblur = default(bblur, defbblur)

[Boulder]

I already apply some blurring on the analysis clip similar to this snippet stolen from QTGMC:

w = clip.Width()
h = clip.Height()
srchClip = clip.RemoveGrain(12,12).GaussResize(w,h, 0,0, w+0.0001,h+0.0001, p=2).MergeLuma(clip, 0.1)

I was just thinking if the whole process needs to be tuned because the image the filters and functions see is so flat compared to an SDR one. But maybe it's just the case of limiting the amount of change which I already do with SDR sources anyway, depending on the amount of noise and actual detail.

[StainlessS]

Well it seems to me that HD tends to be 'gritty', ie pixels representing a small object seem to have a bit of a 'random' component whereas for stddef same object, is less 'random'.
Same small object in next frame not necessarily 'random' in the same way, so is a bit less easy to match blocks in HD (reason for blur).
Maybe the 'amount of change limiting' should be on the final result frame, and not on the analysis frame, you can just use a lesser blur arg for change limit on analysis frames.
EDIT: I aint ever seen an 8K frame, I'm assuming the 'girtty-ness' is even more pronounced therein.
Perhaps the tiny optical sensors are a little susceptible to electrical noise, or some other miniscule phenomena.

[Boulder]

Maybe the 'amount of change limiting' should be on the final result frame, and not on the analysis frame, you can just use a lesser blur arg for change limit on analysis frames.
That's what I meant, I simply use the limit and limitc parameters of MDegrain to dampen the effects in the final image. The analysis clip gets blurred normally. When processing in 16 bits, you get more granularity in the limits (in Vapoursynth at least) as the values need to be scaled manually.

From what I've seen, the high frequency grain (often artificial) in UHD is much more apparent than with regular HD so blurring is even more useful.

[StainlessS]

I had forgotten bout limit and limitc, thanks for the reminder.
From what I've seen, the high frequency grain (often artificial) in UHD is much more apparent than with regular HD
I say again
Those with "trained eyes" see grain as detail, my untrained eyes just see noise :)

[Boulder]

Well, I have to admit that I do like grain even if it is artificial. I just try to suppress it a bit to increase compressibility. The important thing is the subjective experience; if the added grain can fool my poor brain into thinking that there's real detail and sharpness there, I'm happy :) A wax-like, oversmoothed video with floating denoised backgrounds is much worse because it will start catching your eye quite easily. Upscaled, blocky and noisy mess of a transfer is a whole new deal though..

[Forteen88]

MCDegrain's default "frames" is 2. I wonder, do I get better picture quality degraining by increasing "frames" to 3?

[StainlessS]

increasing "frames" to 3?
More grain removed, smoother result. [I prefer 1, although I kinda use it on everything, 2 if bad grain, very occasional 3].

[Forteen88]

@StainlessS. Thanks.
MCDegrainHD degrains quite much compared to the original MCDegrain, so I'll probably use MCDegrainHD(1) most often too.

[tormento]

I'll probably use MCDegrainHD(1) most often too.
Give a try to SMDegrain too. Once you set correct parameters, it gives you good results.

Or, if you would like, give a chance to the porting of BM3D, as it's really fast under CUDA.

[Forteen88]

Give a try to SMDegrain too
....
as it's really fast under CUDA. Thanks, I'll do that.
The shortage and high price of graphicscards made me unable to get a CUDA-card :P

[kedautinh12]

Thanks, I'll do that.
The shortage and high price of graphicscards made me unable to get a CUDA-card :P

If you catch higher CPU same i7/i9, r7/r9 you can get high fps in BM3DCPU ver with prefetch()

[Forteen88]

If you catch higher CPU same i7/i9, r7/r9 you can get high fps in BM3DCPU ver with prefetch()I already have a newish Ryzen 3000-series CPU. Thanks for the advice though.

[DTL]

As far as I've understood, resizing should be done in linear light,

I think it is better to test both ways. The older the source the less probability it is designed to resize in linear form. But the new sources like HD and UHD may be already prepared or will be prepared for resizing in linear form.

The main argument about old sources - it very likely was produced with analog chains and was DAC to get analog form. And I hope many or any of DAC perform conversion with pre-converting to linear and converting to system OETF in analog form after DAC. Because analog signal typically or in most chains after source internals exist in OETF-ed form.

So sources like DVD designed to be fed to simple DAC at home comsumer DVD-player possibly designed to be scaled (and DAC'ed as scale to invinity op) in system OETF form, not in linear.

HDR typically come with UHD and possibly mostly designed to scale in linear form (if the source designer knows about this at all).

Because I see there is no any standards about this process it is better to test both ways and select the way with better quality.