Hdr Agc 1.8.7 - 10.09.2006

[DVDBob]

Where can i enable HGRagc box in AvsP, so i get all the sliders??

[Gavino]

It looks like information about HdrAgc is not built-in to AvsP. You will have to add the required information for the sliders, etc, yourself under Options->Avisynth function definition->Plugins.

[WBL]

Hello Paviko,

is there any chance that you port the HDRAGC filter to Sony Vegas? - If you dont know how to do this for Vegas you might contact a programmer which already did port other filters like the SmoothDeinterlacer to Vegas - his mane is Mike Crash (see: http://mikecrash.com/ )

thanks
Werner

[Didée]

If you klick on Paviko's username, you'll see that his last activity on this board was in March 2007. He's not been here for almost 4 years.

[DoctorM]

I've been tinkering with this on some video that is supposed to be moody dark, but is almost pitch black at times.
Hdr agc really fixes that but I feel like it needs some better fine control.

According to the debugger, no matter what I do, all gain starts at 1 and then the coef effects it as a multiplier. That is, all frames seem to be processed no matter how bright they are.

Max_gain is all well and good, but fairly useless (at least in this case). I've been forced to set Coef_gain to .1 which isn't ideal either but less aggressive.

What I'd like to be able to do:

According to the manual, the calculation is (1.0 + ((calculated gain) - 1.0) * coef_gain).
It would be nice to be able to adjust the base gain: (base_gain + ((calculated gain) -1.0) * coef_gain.
This way the gain can reach numbers <1. (I would have thought that number would be the min_gain, but it doesn't seem to be).

Second, it would be nice if there was a maximum threshold so if a frame is already above a certain brightness, it is not processed.
I'm finding already bright scenes getting VERY bright when they didn't need processing at all.
avg_lum doesn't make a difference because ALL frames still get a minimum gain of 1!

Actually, just being able to adjust the base gain to 0 would have the same effect. So really it's just one request after all.

My current script is using merge() between the original video and the processed video just to keep things under control.

Anyway, suggestions or tweaks to the filter would be great.

[martin53]

Because it seems unlikely to me that the author responds, I contribute my 'gain control' toolbox to stimulate your own experiments with merge, invert etc. Remove only one comment sign at a time.
SGradation (http://avisynth.org/mediawiki/SGradation) is a non-automatic contrast-like user function I once published in the wiki.



function AutoExpose(clip c,float "strength") {
strength= default(strength,0.7)
c
#Overlay(AutoLevels().hdr().hdr_inv(),opacity=strength)
#invert().hdr().invert()
#SGradation(0.8)
#merge(c,last.AutoLevels(midpoint=0.45),weight=0.5*strength)
#hdr()
}

function hdr(clip clp, float "gain", float "sat") {
clp
gain= default(gain, 1.0)
sat= default(sat, 1.0)
merge(clp,hdragc(coef_gain= gain, coef_sat= sat, mode=2, protect=1, reducer=0.0, shadows=true, debug=0),weight=0.5)
}

function hdr_inv(clip clp, float "gain", float "sat") {
clp
gain= default(gain, 1.0)
sat= default(sat, 1.0)
invert().hdragc(coef_gain= 1.0*gain, max_sat=3.0, min_sat=1.0, coef_sat= 0.6*sat, mode=2, protect=1, reducer=0.0,debug=0).invert()
}

[DoctorM]

@martin52: I appreciate your response... but I'm not sure I understand it.

Is this supposed to cause hdragc to work without a minimum gain?
And by 'remove one comment at a time' do you mean each is a different method that should be tried individually and separately?

[martin53]

@DoctorM,
user function AutoExpose is to be used in a clip script, the two other just encapsule hdragc for AutoExpose.

You might try the lines in AutoExpose to watch their effect one by one. But you might as well just read the hdragc settings I once found useful, use them as an alternative starting point to the one you find, or just stimulate your own phantasy with the ideas to apply hdragc on the inverted instead of the as-is clip, or leave automatic control and switch to constant contrast correction.

In my experience, automatic gain control looks good in still motion preview because you focus on the scenes that need correction. But when you watch the whole thing, you'll almost certainly find scenes that are bungled afterwards.

The intention of your post was to suggest a modification to hdragc, so maybe my response is off topic and not welcome. Only in case you don't stick to hdragc, I also suggest that you try a non automatic correction, maybe limited to a frame range with the help of ApplyRange().
I once made SGradation because the Super8 movies looked like silhouettes after capture with my digicam. It compresses the histogram towards the center from both sides. If you don't want the lights to be softened, just replace "1.0/g" in the "lt=..." line by "1.0" to remove the effect from this line.

[DoctorM]

Working on something else and I thought Hdragc MIGHT be useful.
In this case the dark scenes are too bright, but the lighter scenes are fine.

I'm basically looking to make the work as a mask(?) or something to darken the darkest scenes more, and do minimal change to the lighter scenes.
Is this possible or am I just thinking about this wrong?

[Reel.Deel]

Since paviko's site is dead here's the archived link just in case someone is looking for it.

HDR AGC v1.8.7 info and download:
https://web.archive.org/web/20131018094707/http://strony.aster.pl/paviko/hdragc.htm

I also updated the link in the AviSynth wiki, would be great if a moderator can update the link in the first post.

[Guest]

would be great if a moderator can update the link in the first post. Done. Thank you for the link.

[Reel.Deel]

Thanks neuron2.

Unfortunately the archived link in the first post was copied incorrectly.

Here's the full link:
https://web.archive.org/web/20131018094707/http://strony.aster.pl/paviko/hdragc.htm (https://web.archive.org/web/20131018094707/http://strony.aster.pl/paviko/hdragc.htm)

[Guest]

Fixed.

[Argaricolm]

Does anyone have HDRAGC source code?

[StainlessS]

Best I can do (HDR AGC version 0.1.2 alpha, latest dll I have is v1.8.7):-
http://www.mediafire.com/file/cgvipn95ssiiojt/hdragc_25_dll_20050521.zip/file

EDIT: Seems to be the only posted source, from post #24, No longer available from that link.

[Argaricolm]

I will try to rewrite it (want to make 64 bit version).
Your source will help a lot. Looks not very hard.
Thanks.

[poisondeathray]

I will try to rewrite it (want to make 64 bit version).
Your source will help a lot. Looks not very hard.
Thanks.

Any progress on the 64bit version ?
(aka shameless bump :D)

Thanks

[color]

I just write to follow this thread. I also want to know about the 64bit version. =)

[StainlessS]

I just write to follow this thread. I also want to know about the 64bit version. =)

+1 on that.

[ABDO]

I just write to follow this thread. I also want to know about the 64bit version. =)
me too, +1 on that, or any improvment on HDRAGC, it is to disappointing that no profissional one can make an modern hdragc alternative, or make improvment
speed to it.

[Argaricolm]

Well my goal so far is to just rewrite it in C++ so we have source and x64.
I want to use StaxRip with it. But StaxRip is x64 now.
Already started to do it.
So far I can tell that there is an error in documentation.
Version 1.8.7 has mode = 1 by default.
As stated in docs for 1.8.6:
starting from 1.8.5 version:
- new mode (mode = 2), which is using float precision for some calculations (best quality, now mode = 2 as default)
But in code it is 1:
.text:10011944 mov eax, 1

[SteveT]

I recently discovered HDRagc and have been using it on various videos from 16mm film. It's been great, but today I encountered a clip that yields a light colored halo around dark objects positioned on a bright background as shown in the attachment.

16644

I have HDRagc setup with:

HDRAGC(coef_gain=5.0, max_gain=9.0, min_gain=1.0, coef_sat=1.0, max_sat=9.0, min_sat=0.0, corrector=0.8, black_clip=0.000, avg_window=15, protect=2, shift_u=0, shift_v=0, reducer=0.0,avg_lum=128)

I typically use the corrector at 1.0. I set it to 0.8 to enhance the halo effect so it shows up more clearly in my attached picture.

I have tried various settings to get rid of the halo. I set corrector above 1.0 which reduces halo but oversaturates the white background. Turning protect on and off had no effect. Any idea why the halo appears and what to do about it?

Thanks,
Steve

[metaspirit]

Hey it is possible the aura is caused by 2 sharpening filters if you add a blur this could solve the problem have a try.

example

#
Lanczos4Resize(1280,720) # Lanczos4 (Sharp)
#
Blur(0.40)
#
asharp(1.25,6,-1,false)
#

[Selur]

@Argaricolm: any update regarding a rewrite and a 64bit version?

[frencher]

@Argaricolm: any update regarding a rewrite and a 64bit version?

Hello,

An update would be really great.

Do you have a dominant redness problem on your videos ?

:goodpost:

[Mounir]

it's better when the snow is white
https://www.hostpic.org/images/2005271449230088.jpg

[StainlessS]

Mournir, much better, but looks a little bit cyan-ish to me, little bit too much red removed [but my eyes are lousy].
Anyway post you mod for OP.

[Mounir]

i used gimp's levels filters with manual selection for the white/gray/black

[Selur]

Sadly the plugin gives an Access Violation when using Avisynth 3.6.
Any hope for an update of this plugin?

[kedautinh12]

Sadly the plugin gives an Access Violation when using Avisynth 3.6.
Any hope for an update of this plugin?

Can you use with 3.6.1 test 4??

[StainlessS]

I thought I'de try in GamMac, see what happens.

SHOW=False
RedMul1=1.00
RedMul2=1.06
LockChan1=1
LockChan2=LockChan1
Scale1=2
Scale2=Scale1

O = Imagesource(".\Halo effect with HDRagc.JPG")#.Crop(3,5,-6,-7)
M = Imagesource(".\2005271449230088.jpg")#.Crop(3,5,-6,-7)
G1= O.Gammac(Th=1.0/256,LockChan=LockChan1,Scale=Scale1,dc=O.Blur(0.2),redmul=REDMUL1,show=SHOW)
G2= O.Gammac(Th=1.0/256,LockChan=LockChan2,Scale=Scale2,dc=O.Blur(0.2),redmul=REDMUL2,show=SHOW)

O = O.subtitle("Original")
M = M.subtitle("Mournir")
G1= G1.subtitle("Gammac_1")
G2= G2.subtitle("Gammac_2")

T=stackHorizontal(O,M)
B=stackHorizontal(G1,G2)
StackVertical(T,B)


There is a white border thing around edge, but gamMac default is 20 pixels ignored around all borderrs, so we dont need to crop.

click to enlarge
https://i.postimg.cc/ykp8dVKV/Color-00.jpg (https://postimg.cc/ykp8dVKV)

As still a bit cyan-ish, applied a red multiplier, not as bright as Mournir, but a bit more balanced prior to maybe tweak by hand.
There seems to be some kind of halo or aura around the little girl (extending far from her - see it best in original pic).

EDIT: You could eg add args omin=5 omax=250 to gammac args to leave some tweaking lee-way [default is 0, and 255]
EDIT: Maybe back-off on the redmul a bit, maybe Gammac2 looks too red again.

[manolito]

Can you use with 3.6.1 test 4??

On my Core i5 Thinkpad with Win7-64 it crashes under AVS+ 3.61 test version 4, but it runs without problems under test version 2.

[manolito]

Test version 5 also does not like HDRAGC, need to revert to test version 2.

//EDIT//
The brand new 3.6.1 test version 6 handles HDRAGC with flying colors, and I also did not find any older CPP 2.5 plugins which would cause crashes.

[metaspirit]

I have Hdragc working with MP_pipeline it gives a very nice fps boost this is in mode2 i don't think there would be much if any improvement if it was running a pure Hdragc x64.
i am running x64 avisynth+ with megui x64 i too still get the halo problem i am not sure what the cause is
it could be that luma is getting too much gain i wish there was a way to have a limiter built in for over 128 tv levels there is too much gain at the top but the enhanced shadows do look good
i hope this fps boost will help others.

[gispos]

Well, with avisynth_64 you can only use HDRAGC with MP_Pipeline. So I've always had the fps boost.:)

[minusthebear]

Im surprised no one has created a 64-bit version of this plugin. It is incredible in what it can do and nothing I've seen in terms of AI tools, or otherwords comes close.

[Selur]

from what I see: developer gone, no source code, so creating a 64bit version would require a complete rewrite,... (even if there were source code, the whole assembler code would need a rewrite)

[qyot27]

from what I see: developer gone, no source code, so creating a 64bit version would require a complete rewrite,... (even if there were source code, the whole assembler code would need a rewrite)
The source for 0.1.2 alpha is available, which is what the avisynth.nl wiki and StainlessS pointed to further upthread.

The changelog details that there definitely were deeper things that got altered in between 0.1.2 (last version with source, or at least the last one with source recovered from the depths of the Internet Archive) and 1.8.7 (the final version, if you don't count the GIMP plugin that got posted).

Luckily (or not? if later versions are what people actually want) 0.1.2 alpha does have a license; it's GPLv2.

This is all it took to get it building natively on Linux:
https://github.com/qyot27/hdragc/commit/e2f5c1fe668cca36aae6cfcab69cdb0fa8cdf40b

It very much looks like:
A) The asm is only used by the antialiaser for what I assume is an info text overlay
B) The plaincode implementation of what the asm is doing appears to be directly above it, commented out
C) That asm probably isn't even necessary these days, so disabling it and letting the compiler do that work with the non-asm version is likely fine
D) Most/all of the Windows-specific parts have to do with that text stuff.
E) There were parts that seemed to rely on/overload stuff in the AviSynth source itself, which got removed, because there's no point. One function had to be renamed to avoid a conflict with C++11 std headers.
F) It seems to multithread well, and appears to tolerate aggressive compiler optimization (-O3 -march=native).

https://i.imgur.com/sKztutR.png

$ file libhdragc.so
libhdragc.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=693537f0e317497afbac07fd5151ef2ad65eea83, not stripped

$ objdump -a libhdragc.so | grep format
libhdragc.so: file format elf64-x86-64

[qyot27]

Here's the thing, though: I'm pretty sure that whatever newer versions of HDRAGC were doing, you can probably get similar or better results by using newer tonemapping plugins or faking HDR using frame properties and letting mpv tonemap when playing back the script. One of the last posts the dev made about the research papers used as reference for the plugin even mentions Reinhard as the best option in said literature (then mentions that HDRAGC uses something different). And while Reinhard did/does have a lot of people now that still prefer it, there are other, newer algorithms.

[minusthebear]

Here's the thing, though: I'm pretty sure that whatever newer versions of HDRAGC were doing, you can probably get similar or better results by using newer tonemapping plugins or faking HDR using frame properties and letting mpv tonemap when playing back the script. One of the last posts the dev made about the research papers used as reference for the plugin even mentions Reinhard as the best option in said literature (then mentions that HDRAGC uses something different). And while Reinhard did/does have a lot of people now that still prefer it, there are other, newer algorithms.

Any personal recommendations for an alternative to this plugin? In AviSynth or even in a GUI app etc.

[qyot27]

Plugins: avslibplacebo, avsresize, maybe DGTonemap.

If you don't care about the playback being hardware accelerated, like I said in the quote you can change the frame properties in the script by using propSet() and then open the script in mpv, which can handle the tonemapping of HDR->SDR¹, or (presumably) properly engage the monitor's/OS' HDR mode. I don't have an HDR monitor to get into the weeds on that part.

¹libplacebo is essentially mpv's video renderer in library form, so avslibplacebo should definitely be able to do this in-script.

[Columbo]

Also HW-accelerated DGHDRtoSDR() if nVidia graphics is available.