GamMac v1.10 - 15 June 2018

[Aktan]

By the way, there is a 64 bit version of GamMac (https://forum.doom9.org/showthread.php?t=173259). I didn't encounter any problems converting it to 64 bit.

:thanks: I'll try that one instead. Maybe it's me using VS Community 2017? I really have no idea...

[StainlessS]

Aktan, can you post a response after trying G2K4 x64 compile, thanx.

[pinterf]

Edit 3: I tracked it down to line 747 in GamMac.cpp. Really seems like AVS+ doesn't like AVSValue defined in the Create method (just like the Median filter). If I return the newly create object directly, it works fine. Maybe someone else with better C++ knowledge knows what's going on?
I suppose the avisynth header comes from the old 2.5 'baked code' times. No wonder it is incompatible with a 64 bit avs+ environment.
(In general I can see no reason for keeping this obsolate avisynth header file in any project. I'm using header file and stuff from the avs+ project (surprise :) ), which are compatible with classic avs 2.6 filters but one can still use it in avs+, use the new color spaces, check for modern processor features and get a painless 64 bit option)

[Groucho2004]

I suppose the avisynth header comes from the old 2.5 'baked code' times. No wonder it is incompatible with a 64 bit avs+ environment.That's probably it. I automatically update to AVS+ headers when I convert a plug to 64 bit so this potential issue didn't even enter my mind. :)

[StainlessS]

Yip, the original GamMac header was version 3, v2.58 compatible (RGB only), not surprising that it crashes.
I'll do a version with VS2008 project for v2.5, v2.6 x86, and x64, later two with latest avs+ headers.

[Aktan]

Aktan, can you post a response after trying G2K4 x64 compile, thanx.

G2K4 x64 compile is fine :thanks:

I suppose the avisynth header comes from the old 2.5 'baked code' times. No wonder it is incompatible with a 64 bit avs+ environment.
(In general I can see no reason for keeping this obsolate avisynth header file in any project. I'm using header file and stuff from the avs+ project (surprise :) ), which are compatible with classic avs 2.6 filters but one can still use it in avs+, use the new color spaces, check for modern processor features and get a painless 64 bit option)

What's stopping me from using the newer header is that I needed to change more of the source file, aka learn about the new methods and change them, and I was a bit too lazy to do that, lol. Unless I don't need to change it and I can just drop it in... then I had no idea!

[StainlessS]

Need Also in source directory:-

Avisynth+ v2.6 AVISYNTH_INTERFACE_VERSION=6 (latest available) Named as Avisynth.h

Also need additional Avisynth+ headers somewhere in an AVS directory,


AVS
alignment.h
avisynth.h
capi.h
config.h
cpuid.h
minmax.h
types.h
win.h

and point Menu/Tools/Options/Projects and Solutions/VC Directories/ :Include Files: Win32 and x64, to the parent directory containing the AVS directory. [EDITED: in bold]

Above for VS2008, probably not much different for other compilers.

[Aktan]

Need Also in source directory:-

Avisynth+ v2.6 AVISYNTH_INTERFACE_VERSION=6 (latest available) Named as Avisynth.h

Also need additional Avisynth+ headers somewhere in an AVS directory,


AVS
alignment.h
avisynth.h
capi.h
config.h
cpuid.h
minmax.h
types.h
win.h

and point Menu/Tools/Options/Projects and Solutions/VC Directories/ :Include Files: Win32 and x64, to containing AVS directory.

Above for VS2008, probably not much different for other compilers.

:thanks: I remember you said this too in the Median thread. You've motivated me to try it out, lol.

[StainlessS]

Sorry, think I got that wrong, need point to the directory that contains the AVS directory, not AVS itself.

Only got to do it once, then are good for all projects, just need to update avs+ headers when updated.

[Aktan]

Sorry, think I got that wrong, need point to the directory that contains the AVS directory, not AVS itself.

Only got to do it once, then are good for all projects, just need to update avs+ headers when updated.

Yea I figured it out. I got it to compile. I still needed to change "AvisynthPluginInit2" to "AvisynthPluginInit3" and change varies "pointer to char" to "pointer to const char". Now to test it! Seems later VS are a lot more strict.

Edit: On a side note, at first I got the headers from the master branch from pinterf's fork of AVS+ (a mistake, I know) and had to fix a bunch of void problems. To my surprise, the MT branch had these void errors already fixed. I was surprised since Groucho2004's avisynth header that I got from his compiled x64 also had the void problems.
Edit 2: The compiled DLL works! \o/

[StainlessS]

Here something from WaterMark2 plug, which I'm doing a bit on [Just ignore/remove the DPRINTF() lines.]


// The following function is the function that actually registers the filter in AviSynth
// It is called automatically, when the plugin is loaded to see which functions this filter contains.
#ifdef AVISYNTH_PLUGIN_25
extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env) {
DPRINTF("AvisynthPluginInit2::AddFunction(Watermark2::Create)")
#else
/* New 2.6 requirement!!! */
// Declare and initialise server pointers static storage.
const AVS_Linkage *AVS_linkage = 0;

/* New 2.6 requirement!!! */
// DLL entry point called from LoadPlugin() to setup a user plugin.
extern "C" __declspec(dllexport) const char* __stdcall
AvisynthPluginInit3(IScriptEnvironment* env, const AVS_Linkage* const vectors) {

DPRINTF("AvisynthPluginInit3::AddFunction(Watermark2::Create)")
/* New 2.6 requirment!!! */
// Save the server pointers.
AVS_linkage = vectors;
#endif
env->AddFunction("Watermark2", "c[watermark]c[displace]i[light]i[depth]i[softEdge]b[lightFrom]s",Watermark2::Create,0);
// The AddFunction has the following paramters:
// AddFunction(Filtername , Arguments, Function to call,0);

// Arguments is a string that defines the types and optional nicknames of the arguments for you filter.
// c - Video Clip
// i - Integer number
// f - Float number
// s - String
// b - boolean
// . - Any type (dot)
// Array Specifiers
// i* - Integer Array, zero or more
// i+ - Integer Array, one or more
// .* - Any type Array, zero or more
// .+ - Any type Array, one or more
// Etc
#ifdef AVISYNTH_PLUGIN_25
DPRINTF("AvisynthPluginInit2: Exiting to Avisynth")
#else
DPRINTF("AvisynthPluginInit3: Exiting to Avisynth")
#endif
return "`Watermark2 plugin' Watermark2 plugin";
// A freeform name of the plugin.
}


Need AVISYNTH_PLUGIN_25 defined for avs v2.58, otherwise avs/avs+ v2.6.

EDIT: Also, #includes either "Avisynth25.h" or "Avisynth.h" (avs+) based on AVISYNTH_PLUGIN_25.

[Aktan]

Here something from WaterMark2 plug, which I'm doing a bit on [Just ignore the DPRINTF() lines.]

<snip code>

Need AVISYNTH_PLUGIN_25 defined for avs v2.58, otherwise avs/avs+ v2.6.

:thanks:

[JoeSuper8]

I have read this thread but do not understand how best to use FredAverage with GamMac. I am familiar with Avisynth.

Could someone please post a working GamMac script incorporating FredAverage? Or a working FredAverage script if it has to be done separately? I was reading that a detect clip has to be made?

[StainlessS]

Well, I dont actually use FredAverage(), maybe Fred could provide some help.
Fred tends to use AvsPMod with sliders, I dont like AvsPMod, as it changes my scripts and I've gotta keep changing them back again.

I would suggest using Scale=1 or Scale=0, rather than the more aggressive (and perhaps overly correcting) Scale=2.
In addition, using noise processed DC detect clip [ or Eg blur(0.2)] will reduce any flickering and over correction due to 'Sparkles' in the source clip.

Here, a function collection for applying multiple FredAverage dampening settings to multiple ranges in a clip, although I've no real idea if of any use,
Fred seems to have fixed his original clip (using original script function attempt) and not had further need to use again.

Here:- https://forum.doom9.org/showthread.php?p=1831521#post1831521

EDIT: PostImage.org has killed a lot of my site images, they changed the filehost name from PostImage.org to PostImage.cc,
and many (maybe all) now are invisible, I've fixed some in several threads today.

EDIT: result of above mentioned FredAverage dampening scripts.
Showing at bottom of frame, [top downwards] FredAverage Dampening Bar[100% dampened], metrics, and the real frame Average.
EDIT: Where 100% dampening, the Dampening bar is a photo negative invert of the real frame average.
GamMac processes just the image and dampening bar [which dampens GamMac effect] the metrics and real average bar are added just for display purposes.
https://s20.postimg.cc/4knv8suul/Fred_DB_DBar.jpg (https://postimages.cc/)

[videoFred]

I was reading that a detect clip has to be made?

Yes, a detect clip with colored borders and the color of these borders is created by FredAverage().
It's just the average color on frame level, reversed (to make it difficult haha)
Serious, I got this idea from someone here on the Forum (was it Martin?) who has made a very simple but very effective auto white script.

So, in short: if you create a 'detect' clip with FredAverage() borders, it will soften the Gammac effect. Specifically on scenes with a lot of blue sky.
On those scenes, all auto white algorithms will fail. They all create ugly brown colors.

PS: The option to use a detect clip is included in Gammac()

PS2: like I showed here, but with borders instead of a square box.
https://forum.doom9.org/showthread.php?p=1803528#post1803528

And that was before FredAverage, but it's the same principle.
StainlessS was so kind to create FredAverage(), because Scriptclip was not working in Avisynth+ MT modus.


You will also see two tiny square boxes, one white, one black.
They are softening the auto levels effect from Gammac() on very problematic scenes.
Scenes with colored noise for example.


Fred.

[johnmeyer]

Thanks Fred! I never did quite get GamMac to work. Hopefully these hints will get me to the finish line.

[Yanak]

Hello StainlessS,

I tried to self compile GamMatch 0.4 in VS2017 and I'm not sure if it's important or not but i get some "C4244 (https://msdn.microsoft.com/en-us/library/2d7604yb.aspx)" warnings about possible loss of data :
https://i.imgur.com/beEMb0N.png

The x64 dll compiles fine despites those warnings and after a few quick tests it seems to work correctly ( and getting a nice speed boost according to avsmeter which was my primary goal when trying this ).

Probably not a big deal but i'd better ask in case in can lead to some errors.

Thanks a lot.

PS: GamMac and GamMatch do an amazing job on videos or even static images, i finally could put my hands on a old family video and a bunch of photographies that were taken the same day, not all is digitalized yet and the transfer of the video i get for now is not really in high quality, will need to find a better way or bring this to some professionals for the transfer but i don't like much the idea of giving private stuff like this so I'll see in the next months, when I'll have gathered more videos how i can achieve something better, i'm not in a hurry so it's not a problem at all.

Still experimenting with this when i have a few hours to kill and having good results on static pictures too, quite amazed by the results out of the box, a big thank you for those nice tools :)

[StainlessS]

GamMac v1.10 (beta removed), see first post.

Zip approx 1MB, incl 3 png files, avs v2.58 x86, avs+ x86 and x64 dll's + source + VS2008 project files.
Changed default Scale from 2 to 1 (default was a little too severe).

@Yanak, the warnings you mention, are pretty much all down to string lengths in DDigit source, and can safely be ignored as no Avisynth string
is likely to be more than 2GB in size. Fixed DDigit source so as not to give warnings. (about 4 Warnings, + another warning in GamMac args conversion from float to double to float)

EDIT: Fixed all of the PostImage file host images in thread (or I hope so), which got broken some weeks ago due to PostImage changes in filename URL's. [Only mine, I cant fix anybody elses].

[Yanak]

Thanks Stainless,

too late to try it tonight but i'll compile it tomorrow using the new DDigit from GamMac and run a few tests to compare speed. I had no idea if this could lead to problems, now i manage to compile stuff myself but coding is still a very long way to go :p

As for the postimage links broken, i fell you man... I also have to do it, already had to change all my pics links not long ago from hostingpics.net to postimage since hostingpics will cease activity after something like 8 years hosting my pics there... changed all my forum pics to postimage as it looked good but now I'll have to do this again :/ pain in the rear ...

Thanks a lot for the quick fix, the nice tools and work put on all this :)

[StainlessS]

You will also need update the other files, not just DDigit.cpp, had to make a few small changes in connection with convert for
x64 and also because of implementing resource file stuff.
Make sure that you have project preprocessor defines set in Preprocesor and also Resource,

'AVISYNTH_PLUGIN_25' if compiling for avs v2.58

And also for avs+ x64, add '_WIN64' (do not delete the 'WIN32' entry) to both C/CPP/Preprocessor/ & Resources/General/ Preprocessor Definitions.

[Yanak]

Hi,

I use my own solution template ( same one i used for watermark2 plugin ) where i just compile for avisynth+ x64, for GamMatch 0.0.4 i just replaced the DDigit files and updated the compiler file, also had already the resources and versions infos done in my template but updated it (https://i.imgur.com/V3RQnqD.png) and used the infos you provided in yours to credit you more properly than before :) .

Tested GamMatch quickly and it seems to do the job and gain a few FPS already, but will try to do like for WaterMark2 (https://forum.doom9.org/showthread.php?t=163870&page=4) and try to boost a bit more the performances by training it a bit using PGO, might take a few days since i'm a bit busy with other stuff but I'll post the results here, might serve some others.

Haven't touched GamMac itself for now, the version i use until now is the one released by Groucho2k4, but it's now on my to do list when i will be done with GamMatch ( not sure if you will also port some of the changed code done on GamMac to GamMatch or it the things you modified are not code shared between the 2 plugins that does not need to be modified btw )

Again thanks a lot for all this.

[JoeSuper8]

Thanks Fred and StainlessS!

I am going through the scripts linked by StainlessS https://forum.doom9.org/showthread.php?p=1831521#post1831521

I noticed two issues that I am having:
1. The text color of the FredFun metrics affects the dampening and resulting colors of the image in the comparison mode, as well as the rectangle colors at the bottom. I changed the color from the default to white and the colors of the image and topmost of three rectangles' color changed in windows 3 and 4 (the bottom half of the screen).

2. By setting FredFun show metrics to false, the dampening effect disappeared, the bottom rectangles disappeared, and the image matched window 2. Setting FINAL to True in FredDB.avs had the same effect where there is no more dampening effect, even if Show was set to True.

[StainlessS]

I'll take a peek when I get home.

EDIT: Sure sounds like something is terribly wrong.

EDIT: Might have to wait until tomorrow, I'm a bit dead on my feet.

[StainlessS]

@ Fred,

I've been thinkin bout it a bit, and seems to me that the FredAverge(Invert=true) with overlay thing will
not perform as ideally required.

Firstly, if (as mostly expected) we are using LockChan=1 ie lock to Green channel, then DC green channel
average will be 'tickled' towards 127.5, (where green channel would not normally be touched when LockChan=1
and FredAverage not used), so green channel is actually changed where it would not normally be.

Is it intentional that FredAverage thing modify green channel when using LockChan==1 ???
(I presume that intent is to only dampen R and B modification when Lockchan==1).

EDIT: @ JoeSuper8, sorry for delay, have some difficulty getting time to fix this prob, and also a bit stuck as to how to.
(FredAverage thing will probably have to go and be replaced with something else, arg to GamMac).

EDIT: -ve LockChan complicates things further, kind of wish that they had not been implemented in the first place.

EDIT: Also, does FredAverage dampen only work [EDIT: nearly] properley when LockChan==1, my head hurts :(
(Green channel pays greatest contribution to luma value, ~59%)

EDIT: Take your time Fred, not expecting any immediate answer here :)

[Yanak]

Took me way longer than expected to test a few things, thanks to Open Office who crashed and never was able to re-open the sheet i had with alll stats collected after many tests... all lost while almost finished...

Anyways, results for this script : https://pastebin.com/AQLQ7AJS

Original GamMatch x64 :
FPS (min | max | average): 16.41 | 22.65 | 22.47
Time (elapsed): 00:05:20.426

Recompiled GamMatch x64 :
FPS (min | max | average): 20.66 | 31.33 | 31.10
Time (elapsed): 00:03:51.531

GamMatch_x64 (Not GamMac!) Dll download + source and solution for VS2017:
https://www67.zippyshare.com/v/5hOp8j4P/file.html

PGO don't bring very much here, Intel compiler can bring a very little plus, from 0.08 to 0.12 FPS on average only for this synthetic test script, but it's not worth it... maybe while activating some specific instructions for recent CPU's it could gain a bit more but I have only a Ivy Bridge CPU so...

Anyways quit happy with the boost, will need to find time to do all those tests again with GamMac_x64 and compare with Groucho's released x64 dll, i doubt there is any gain to get there, Groucho2k4 releases are quite optimized for what i could test before, probably will wait until you make some changes to your code before putting my head again into this :p

[videoFred]

@ Fred,

I've been thinkin bout it a bit, and seems to me that the FredAverge(Invert=true) with overlay thing will
not perform as ideally required.

Perhaps not ideal but I was looking for a solution for this problem:
https://forum.doom9.org/showthread.php?p=1803528#post1803528


Is it intentional that FredAverage thing modify green channel when using LockChan==1 ???
(I presume that intent is to only dampen R and B modification when Lockchan==1).


No, not intentional, I was only looking for a solution for the R and B channels. I wanted less red and more blue.
Did not realize was a green channel modification too. Anyhow, it looks good by eye :D

Fred.

[StainlessS]

OK, F, I'll try get something working, dont hold your breath, (also try fix the original cause thing too).

[color]

I try to save the script to GaMac.avsi but then I can not open the Avspmod. It says it wrong with the file on line 9, then it crash. Or am I doing it wrong?

[StainlessS]

It says it wrong with the file

Well at a guess, maybe should use avs not avsi (avsi for autoload plugins dir), maybe avsi messes up AvsPMod.

Imagesource("GreenChurch.png",end=0)
#Imagesource("Puppy.png",end=0)
#Imagesource("lennaRed.png",end=0)

ConvertToRGB24.KillAudio
#Spline36Resize(512,384)
O=Last
DC=Last
# LINE 9 is empty
#DC=DC.Blur(1.0) # Detection Clip (uses source clip if dc not supplied, Denoised or whatever)
#DC=DC.BilinearResize(320,240) # Test DC not same size as source

...



Is the line 9 an AvsPMod line number ?

Does it play in eg MPC-HC or VDub2 ?

Is it script supplied with GamMac_x86_x64_v1.10_dll_20180615 ? [as the snippet in code block above]

What is the exact error message ?

[videoFred]

Well at a guess, maybe should use avs not avsi (avsi for autoload plugins dir), maybe avsi messes up AvsPMod.

AvsPmod works fine with .avsi, so it must be something else.

Still holding my breath :p

Fred.

[color]

Well at a guess, maybe should use avs not avsi (avsi for autoload plugins dir), maybe avsi messes up AvsPMod.

Imagesource("GreenChurch.png",end=0)
#Imagesource("Puppy.png",end=0)
#Imagesource("lennaRed.png",end=0)

ConvertToRGB24.KillAudio
#Spline36Resize(512,384)
O=Last
DC=Last
# LINE 9 is empty
#DC=DC.Blur(1.0) # Detection Clip (uses source clip if dc not supplied, Denoised or whatever)
#DC=DC.BilinearResize(320,240) # Test DC not same size as source

...



Is the line 9 an AvsPMod line number ?

Does it play in eg MPC-HC or VDub2 ?

Is it script supplied with GamMac_x86_x64_v1.10_dll_20180615 ? [as the snippet in code block above]

What is the exact error message ?

Oh, the dll....I must have missed to read the first post. I went to your plugin page and there it was. Okey It works. Thank youl. :)

[lollo2]

Newbie to video restoration, I have a question on GamMatch: why the plugin allows only to mask edges in reference video?

I need to match two video sequences, both having black borders (differing in size) on the edges and "vhs noise" (differing in size) on the bottom.

I thought that for GamMatch it would be better to work with the images exactly in the same position and then I shifted one of the 2, without
removing the noise at the bottom.

I used then the x/y/w/h options of GamMatch to remove borders and noise in reference video.

For a better behaviour of GamMatch, should I also remove noise and borders in the video to be matched, or the algorithm does not care? (in my
experiments I do not see a difference, but I may be wrong)

Thanks!

[StainlessS]

NOTE, From Post #66 (where GamMatch first appeared),
DC and DC_AVE derived from DC (Good color clip), all others from clip c (BAD color clip, Incl OUTAVE).

Having both clips spatially aligned is not absolutely necessary.
GamMatch only makes histograms similar, so cropping off borders (from both clips) stops those regions from producing messed up histograms.
A little noise reduction on detect clip [maybe eg Blur(0.2) would do], would also stop hi/lo 'sparkles' from taking part in DC histogram.

Best crop Source clip borders, to produce better histogram, but can use the x,y,w,h coords option (or crop, either would do), to eg avoid
some logo on DC clip that is not present in Source clip.

Have successfully used DC single frame (FreezeFrame) to match source clip to that single frame. (Where missing DC frames
compared to Source, but entailed lots of hand editing in script).

EDIT: Me also loves this little demo using both GamMac and GamMatch:- https://forum.doom9.org/showpost.php?p=1825391&postcount=190
https://s20.postimg.cc/u9y9n3pv1/Gam_Gam.png (https://postimages.cc/)

EDIT: And the original version without color cast correction via GamMac (result a bit red as original DC clip):
https://s20.postimg.cc/i4fxto9dp/Gammatch_v0_zps8h9khfyf.png (https://postimg.cc/image/mqc220uwp/)

[lollo2]

Thanks for your reply!

Having both clips spatially aligned is not absolutely necessary

Right, sorry. I aligned the two clips because I have to replace in a video a bad sequence with a good sequence; I align and then "gammatch"
the good to the bad; I learned now I can do first the "gammatch" without impact.

Best crop Source clip borders, to produce better histogram ...

Not sure I understand everyting here, I conclude that is better to crop (mask) also the video to be matched (Source)

... Where missing DC frames compared to Source, but entailed lots of hand editing in script).

Yes! The Source is a capture from a damaged tape (lots of missing/inserted frames); DC is a capture of the same program from another
tape (GamMatch needed because different "look").

Matching DC frame by frame to Source to make GamMatch efficient was a nightmare.

In addition, I had to replace damaged frames in DC (i.e. big portion of the frame is white or black) causing GamMatch to fail, with a duplicate
of a good frame; another nightmare.

But the final overall result is good: thanks for your GamMatch plugin!

I also compared GamMatch versus MatchHistogram versus HistogramAdjust versus a Manual Brightness and Contrast Tweak and, in my case,
GamMatch produces the best results (I was not able to include ColourLike in the bench because I always have a Stack Overflow error)

[StainlessS]

Best crop Source clip borders, to produce better histogram ...
Not sure I understand everyting here, I conclude that is better to crop (mask) also the video to be matched (Source)

I just meant that there are two histograms to consider, ie the DC dectection clip, and of the source clip, if source clip has lots
of eg black border, then the histogram is already screwed up, need to remove borders from source clip histogram, ie crop them off.
You can if necessary AddBorders() back again. [EDIT: with resulting borders being probably a better even black than original].

JFYI, Masking is not the same as cropping.

[lollo2]

Clear explaination. Thanks!

[lollo2]

The results I obtained, FYI

original is the original damaged video
in replace_sequence I replaced the image from a clean video
in replace_sequence_gammatch I used GamMatch on clean video and then replaced the image

clean video is vhs, while damaged video is s-vhs (little little bit more details)

https://s6.postimg.cc/lb867su3l/example1.jpg (https://postimg.cc/image/5czghnzvh/)

https://s6.postimg.cc/cg7bxad0x/example2.jpg (https://postimg.cc/image/3xxvsy6i5/)

[StainlessS]

Not sure what you are telling me.
You seem to swap and change description,
Which one is the source that will be modified, and which is the good color clip (DC) which will be used to adjust source.

Judging by provided upper images, I'm guessin' that what you describe as Original is actually the DC clip, and Replace_Sequence is actually the Source clip.
With above interpretation, Note, that white crud at top of upper samples LEFT image (DC clip), will be making the result a little too light. [unless cropping off or using coords on that frame, is it damaged all through video ?].

EDIT: OK, I think I understood correctly.
'Replace_Sequence' frame [MIDDLE frame] is modified to color match 'Original' [LEFT frame] {hopefully not using cruddy area of Original} and then replaces the original 'Original' damage frame. 'Replace_Sequence_Gamatch', [RIGHT frame] is the color matched frame [MIDDLE frame, matched to LEFT frame] used to repair the damaged frame in the source clip.

[lollo2]

I apologize: I was not clear, but you understood correctly.

The names and the videos I used are of the final files after replacement and eventually GamMatch operations.

original = damaged video = DC - this is the damaged file where I want to replace a sequence
replace_sequence = Source - this is at the same time the result of the replacement without using GamMatch
replace_sequence_gammatch = GamMatch output - this is at the same time the result of the replacement and the usage of GmaMatch

DC is unchanged in the comparison image, but it has been modified in the script to match frame by frame Source and to remove the
bad frames as the one you mentioned for proper GamMatch operations.

[StainlessS]

I thinks we gots it, thanx Commander Straker :)

[lollo2]

I thinks he thanks you because your plugin makes his face looking similar to my reference ;-)

https://s6.postimg.cc/f02yrpdj5/comp2.jpg (https://postimg.cc/image/b3pmvpsjh/)

[lollo2]

In addition to color match, there is another reason why I prefer GamMatch.

As told, I have bad frames that I have to replace with previous good frame (video_ref_seq_ria_sos)

HistogramAdjust and MatchHistogram match the color of the reference (in the left portion, the color of the face tend to be similar to the color of
the hair); it is ok, but it does not work in my case.

GamMatch, with its different approach, shows better results in my case.

I hope this could be of some utility for somebody else...

https://s6.postimg.cc/fbph1pam9/comp3.jpg (https://postimg.cc/image/e9faj5rst/)

[JoeSuper8]

Thanks StainlessS for looking into those color bar issues.

Fred in the meantime, are there any additional instructions on how to use a detect clip with gammac?

I could not successfully follow your post from last year on the detect clip: https://forum.doom9.org/showthread.php?p=1803528#post1803528

[videoFred]

I could not successfully follow your post from last year on the detect clip: https://forum.doom9.org/showthread.php?p=1803528#post1803528

??? What could you not follow?

Fred.

[Zetti]

This should hopefully be of use.
All it does is pass on args to respective plugins.
Some of the AutoLevels args are not passed where it makes no sense, eg the gamma related ones.


Function AutoLevelsGamMac(clip c,
\ Bool "DoAutoLevels", bool "DoGamMac",
\ int "filterRadius",int "sceneChgThresh",String "frameOverrides",
\ int "input_low",int "input_high",int "output_low",int "output_high",float "ignore",float "ignore_low",float "ignore_high",
\ int "border",int "border_l",int "border_r",int "border_t",int "border_b",bool "debug",
\ int "LockChan",Float "LockVal",Float "RedMul",Float "GrnMul", Float "BluMul",
\ Float "MinLim",Float "MaxLim",float "GamLo",Float "GamHi",Bool "Show",int "Verbosity") {
c
DoAutoLevels=Default(DoAutoLevels,True) DoGamMac=Default(DoGamMac,True)
(DoAutoLevels)
\ ? Autolevels(filterRadius=filterRadius,sceneChgThresh=sceneChgThresh,frameOverrides=frameOverrides,
\ input_low=input_low,input_high=input_high,output_low=output_low,output_high=output_high,
\ ignore=ignore,ignore_low=ignore_low,ignore_high=ignore_high,
\ border=border,border_l=border_l,border_r=border_r,border_t=border_t,border_b=border_b,
\ debug=debug)
\ : NOP
(DoGamMac)
\ ? GamMac(LockChan=LockChan,LockVal=LockVal,RedMul=RedMul,GrnMul=GrnMul,BluMul=BluMul,
\ MinLim=MinLim,MaxLim=MaxLim,GamLo=GamLo,GamHi=GamHi,
\ Show=Show,Verbosity=Verbosity)
\ : NOP
Return Last
}

#Imagesource("test_RGB_Doom.jpg",end=0) Crop(0,0,width/2,height/2) Crop(0,0,width/4*4,height/4*4)

Imagesource("G1.bmp",end=0) crop(0,0,0,-48) Spline36Resize(480,360) # Lollipop lady minus RHS and histograms
#Imagesource("G2.bmp",end=0) crop(0,0,0,-48) Spline36Resize(480,360) # Plant lady minus RHS and histograms
#Imagesource("G3.bmp",end=0) crop(0,0,0,-48) Spline36Resize(480,360) # Avenue minus RHS and histograms
#Imagesource("G4.bmp",end=0) crop(0,0,0,-48) Spline36Resize(480,360) # Walkers minus RHS and histograms
#Imagesource("G5.bmp",end=0) crop(0,0,0,-48) Spline36Resize(480,360) # Parot minus RHS and histograms
#Imagesource("G6.bmp",end=0) crop(0,0,0,-48) Spline36Resize(480,360) # Deer minus RHS and histograms
#Imagesource("G7.bmp",end=0) crop(0,0,0,-48) Spline36Resize(480,360) # Taj Mahal minus RHS and histograms
#Imagesource("G8.bmp",end=0) crop(0,0,0,-48) Spline36Resize(480,360) # Puppy minus RHS and histograms

#Avisource("1937 Lund Utah 16mm Film [Low, 360p].mp4.avi")
#Avisource("1941 Flint Michigan Parade [Low, 360p].mp4.AVI")
#Avisource("v.avi")
#A=Trim(0,99)
#B=A.BlankClip(length=1) # Test Black Frame @ 100
#C=A.BlankClip(length=1,Color=$FFFFFF) # Test White Frame @ 101
#D=Trim(100,0)
#A++B++C++D

ConvertToRGB24
ORG=Last
LockChan = 1 # Chan for lock to Ave, 0=R, 1=G, 2=B
# -1 = Use LockVal below.
# -2 = LockVal=(RedAve+GrnAve+BluAve)/3.0 for LockVal.
# -3 = LockVal=Median(RedAve,GrnAve,BluAve)
LockVal = 128 # Only valid if LockChan == -1
GamHi = 4.0 # Extreme values for guess gamma (starting guess range and limit)
GamLo = 0.25 # Extreme values for guess gamma (starting guess range and limit)
RedMul = 1.00 # Required Ave multiplier for Red Channel, applied when requesting GuessGamma(reqAve*RedMul), Even applied when LockChan=-1.
GrnMul = 1.00 # Same for Green channel. GrnMul even applies when LockChan is Green Channel, etc for chans.
BluMul = 1.0 # Same for Blue channel. Allows tinkering/fine tuning.
MinLim = 32.0 # If Original channel Ave lesser then DO NOT FIX.
MaxLim = 255.0-32.0 # If Original channel Ave greater then DO NOT FIX.
Show = true # Subtitles
Verbosity= 1 # 0=Only Upper metrics, 1(default)=Upper + important ones. 2=All metrics.

A= AutoLevelsGamMac(DoGamMac=False)
B= AutoLevelsGamMac(DoAutoLevels=false,LockChan=LockChan,LockVal=LockVal,RedMul=RedMul,GrnMul=GrnMul,BluMul=BluMul,Show=Show,Verbosity=Verbosity)
C= AutoLevelsGamMac(LockChan=LockChan,LockVal=LockVal,RedMul=RedMul,GrnMul=GrnMul,BluMul=BluMul,Show=Show,Verbosity=Verbosity)
TOP=StackHorizontal(ORG,A)
BOT=StackHorizontal(B,C)
StackVertical(TOP,BOT)
return Last



EDIT:


That IanB quote was from the AutoLevels thread, I assume that Frustum corrected it in later versions of AutoLevels
to match what IanB said.

Is this the only setting AutoLevelsGamMac() or is there more settings i can't see??

[StainlessS]

That was prior to Scale=2 setting, try GamMac(Scale=2).

EDIT: Was implemented in this post:- https://forum.doom9.org/showthread.php?p=1774775#post1774775

[Zetti]

Thanks for info.

I will try it.

[Zetti]

I like the result with GamMac(Scale=2)

But i hope i have understand it right, that i can limit the colors with RedMul, GrnMul and BluMul

Like this way GamMac(Scale=2, BluMul=0.9,Show=false)

[StainlessS]

You can reduce blue content as in your example, but maybe Scale=2 is not the right one for the job, try Scale=1.

Scale = 2 is a little ferocious, and modifies each channel separately (each chan min and max), whereas Scale = 1,
finds minimum_of_any_Channel(min) and maximum_of_any_Channel(max), and uses those.

Scale=1 is safest, but sometimes dont look as good.

EDIT: Scale=0, uses 0 and 255 for all input mins/maxs.

[Zetti]

Thanks now can i see the last details for now, that's good.

GamMac is a good new toy.