GamMac v1.10 - 15 June 2018

[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 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 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.p...21#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

[videoFred]

Originally Posted by 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.

Perhaps not ideal but I was looking for a solution for this problem:
https://forum.doom9.org/showthread.p...28#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

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]

Originally Posted by StainlessS

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

Fred.

[color]

Originally Posted by StainlessS

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...&postcount=190


EDIT: And the original version without color cast correction via GamMac (result a bit red as original DC clip):

[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)

[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