Functional equivalent to HDRAGC with dithering for clean HD

[fvisagie]

I've been using HDRAGC() to automatically improve mid-range contrast and do configured colour correction with somewhat noisy SD video where it works really well. Unfortunately, with cleaner 8-bit HD video it introduces visible banding.

Instead of trading off noise reduction vs. banding once that has been introduced, I'm looking for a functional equivalent to HDRAGC() that avoids banding, likely through dithering. Because much of my HD material comes from lower-end devices like mobile phones and action cameras, colour correction is still necessary. Also free of banding, needless to say.

Avoiding banding in HD is a new field for me and I would appreciate some pointers. To recap, the ideal solution would
automatically improve mid-range contrast,
correct colours according to preconfigured settings (or automatically if that works well) and
avoid banding.
Preferably within one tool, but all requirements need to be addressed one way or another. What options come to mind?

Thanks,
François

[feisty2]

Auto/smoothadjust

[fvisagie]

That definitely seems to be an option to try, thanks.

[Reel.Deel]

A while back I came across this article - Color High Dynamic Range (HDR) Imaging: The Luminance-Chrominance Approach.pdf (http://www.cs.tut.fi/~hdr/IJIST_ACIP-Pirinen-Foi-Gotchev-2007.pdf)

It'd be nice to have something like this for AviSynth. Maybe a proof-of-concept can be made with MaskTools and company? I would try but the math is out of my league. :o

[fvisagie]

Interesting, although I think the approach described is aimed more at compiling HDR images from multiple LDR source images, whereas tools like HDRAGC() attempt to synthesise HDR images from corresponding individual LDR images, effectively trying to invert tonal compression in the camera with tone mapping.

[martin53]

hdragc (http://forum.doom9.org/showthread.php?t=93571&highlight=hdragc) helped me to improve dark images for quite a time, but missing new colorspaces (YV24) and 16 bit, it is definitely outdated.
Unfortunately, all attempts to contact paviko failed and he kept most sources closed.
Because he referenced a publication (Adaptive Gain Control for High Dynamic Range Image Display) (http://www.cs.ucf.edu/~sumant/publications/SCCG2002.pdf) as being his inspiration, I read that publication to see if I could imitate the plugin behaviour.

But the publication leaves me with questions, and maybe other forum members might like to contribute understanding, so the plugin can one day be replaced.

The first topic I'd like to exchange thoughts about, though not being essential for the algorithm itself, is that the publishers work with the logarithms of he luminances and reason that this better depicts reality. To my knowledge, the gamma concept of sRGB etc. is already such a concept (i.e. for each increment in luma, the display gets brighter by a small factor), so this seems double compensated to me?

The other thing is really essential - it's the GainControl() function. I guess that when yAmbient is low and y is a bit higher, then y is amplified; and maybe if yAmbient is very bright and y is a bit more dim, y is attenuated. This would give a local contrast amplification as it is usually desired and achieved with all similar tools. The paper states in chapter 4 that it is the algorithm from [Patt00].
This, however, is a paper on time related adaption of human brightness perception with a rather complex 'operator'. The words 'gain control' only appear as reference [27] and to my understanding, the primary task (hdr tone mapping of a frame) is not time related. This is emphasised by the fact that the primary paper uses stills (not image sequences) as examples. Maybe it is a typo, and the meant reference is [Patt98]? In this case, the gain control model seems complex and not sufficiently explained to be coded from the paper.

[Reel.Deel]

Hi martin53,

Here's the really old hdragc with source code: hdragc_5F25_dll_20050521.zip (http://www.avisynth.nl/users/warpenterprises/files/hdragc_5F25_dll_20050521.zip)

Hope it's somewhat helpful :).


Because he referenced a publication (Adaptive Gain Control for High Dynamic Range Image Display) (http://www.cs.ucf.edu/~sumant/publications/SCCG2002.pdf) as being his inspiration, I read that publication to see if I could imitate the plugin behaviour.


He reference a few publications here (http://forum.doom9.org/showthread.php?p=917911#post917911) but ultimately said that the latest hdragc used its own algorithm.
There's a few more to hdr related papers in the avs wiki: http://avisynth.nl/index.php/Image_Processing_Algorithms#High_Dynamic_Range_.28HDR.29

[martin53]

You might like to read this post (http://forum.doom9.org/showthread.php?p=1798635#post1798635) in the context of this thread.

[martin53]

Thanks to pinterf, we can now experiment (with standard script means) with an idea Pattanaik et al. proposed: (http://www.cs.ucf.edu/~sumant/publications/SCCG2002.pdf) apply local contrast gain by amplifying the difference between a pixel's luma and the average luma of its environment not in a usual manner, but restrict the pixels taken into account for the environment average to those pixels that have not too different luma from the center pixel.
Reason: very contrasty pixels make for a great difference between the center pixel and the average, so they amplify the difference too much, and such pixels are present at high contrast edges, producing commonly known halo effects.

To reproduce the experiments, you may download Greg Ward's Memorial Church HDR images (http://www.pauldebevec.com/Research/HDR/SourceImages/Memorial_SourceImages.zip) or use any other high contrast image.

Load it with the attached script. It is prepared to show different operations in different frames.
In frames #0 and #1, it shows a grey image that can be used as a factor to be applied to the luma (and in order to retain the tint of the pixel, to the U and V planes, too), and the input image after application of the factor. The factor is calculated from the original luma, in order to 'move' the pixel's luma towards center luma in a transposed 'S'-shape when output is drawn as a function of input. This is on one hand a finger warm-up to get acquainted with the 'calculate and apply a factor' operations and how they look. On the other hand it unveils some picture details in previously very dark or bright areas for the following comparisons.
Frame #2 is left original for comparison.
Frame #3 shows the proposed operation. You may of course play with all settings to learn about their effects. In case of the Memorial Church image, it increases the visual 'presence' of the spokes of the roof window as well as the wall and roof paintings, the wooden roof beams, the steps etc.
Frame #4 is a usual local contrast gain with a standard average with identical settings. It demonstrates how the windows and other bigger high contrast objects suffer from over-amplification.
Frame #5 is the original image again, for comparison.

Prerequisites
- AviSynth+ e.g. r2420 MT (high bit depth)
- MaskTools2 - pfmod as of 02/28/2017, see 1 post above or Avisynth development subforum (mt_luts() with wexpr parameter)
- GRunT plugin
- maybe other plugins, not sure

Meaningful comments appreciated :D

[StainlessS]

Thanks muchly M53, any chance that it might work in 8 bit ? (have not examined script, just on way to pub for an hour).

I'll D/L links anyway to take a peek. Thanx again :)

Off to a care free life (well hour or so) in the boozer. Bye.

[martin53]

any chance that it might work in 8 bit ?
Just checked, the script works in 8 bit. Looks identical at 1st sight.

You must change the value of constant _one_ to e.g. 100 before, in order to have a sufficient headroom 0...2.5 for the factor inside only 0...255 increments, and the constant contrast_window to 40 or so.

[StainlessS]

Magical kind sir, I'll have a play at some point soon :)