The power of Avisynth: restoring old 8mm films.

[poisondeathray]

Maybe 2 instances of 6-8 threads would yield higher numbers overall

[Groucho2004]

Maybe 2 instances of 6-8 threads would yield higher numbers overallQuite possible. Maybe Avisynth becomes less and less efficient with an increasing number of threads, particularly with scripts that run various temporal filters.

[Meloware]

Maybe 2 instances of 6-8 threads would yield higher numbers overall
I ran 2 instances of AvsPmod, and pointed one instance to frame 1, and the other to frame 750. I then hit "play" on each and allowed the ImageWriter function to write out frames as set in my result option "C1". Each instance of the script was set to operate with 12 threads.
CPUID reported the CPU was 95%+ occupied, with 35% memory use. I then reviewed the time stamps over a complete 6 minute period of rendering. There were 1050 frames total rendered frames, which suggests a total system performance of about 2.9 frames per second. This doesn't appear to be an exciting option, compared to a single instance running at 20 threads.

Groucho2004 - I noticed AVSMeter will allow me to run the script and the Imagewriter() function will write frames. Is this an option for rendering out of the script? The images are low quality. Do you know if there is a setting option to improve jpg quality? Lastly, AVSMeter will only allow a single instance to be run, at a time. Was this intentional? Maybe the option to run multiple instances might be good.

Since getting this system, it has been rare to find any software that shows any interest in using 64 threads. Blender tries, hard, but it seems like many of the legacy libraries and compile options have no concept of what to do with 32 cores.

The help I have been offered, here, has pegged all 64 threads to the limit. This is the first time I have seen a single instance of an app even come close. Perhaps the future processing algorithms may become more efficient, for my AMD chip, but at least I am seeing the resources in my investment finally being used. Life has already improved, dramatically. I certainly hope further development will improve performance on multi-core AMD chips, but I already appreciate the current improvement!

[Groucho2004]

Groucho2004 - I noticed AVSMeter will allow me to run the script and the Imagewriter() function will write frames. Is this an option for rendering out of the script? The images are low quality. Do you know if there is a setting option to improve jpg quality? Lastly, AVSMeter will only allow a single instance to be run, at a time. Was this intentional? Maybe the option to run multiple instances might be good.
There is an option in the AVSMeter.ini file ("AllowOnlyOneInstance" ) which, if set to '0', allows multiple instances of the program. Check the included documentation. However, if you just want to write an image sequence from a script I recommend using avsr (https://forum.doom9.org/showthread.php?t=173259).

As for the quality of the images I can imagine that png or tif will produce better results than jpeg. Check the documentation (http://avisynth.nl/index.php/ImageWriter).

[bassquake]

I forgot to take Autolevels out once I added GamMac. Autolevels never worked for me and I never, ever used it.

Also, I second Fred's recommendation to use a lower resolution.


I'd rather keep the high resolution capture for future proofing!

Anyhoo, took out Autolevels and the Denoise stuff as I prefer to maintain the film grain. Results are now at around 7fps in ffmpeg which will do for now.

Edit: Cranking threads variable to 64 when changing the Prefetch(4) to Prefetch(threads) gives me up 12fps! Looks like it forces the cpu to render at a much higher percentage. Nice :)

[pinterf]

Quite possible. Maybe Avisynth becomes less and less efficient with an increasing number of threads, particularly with scripts that run various temporal filters.
I suppose that memory bandwidth is also a significant limiting factor if not the biggest one.

[minusthebear]

Hey guys

Over the past year I have modified and updated this script to all 64 bit versions and equivalents as well as versions that use the GPU over CPU.

I will be posting my script here in the next month for everyone. Im still having a bit of trouble getting Mtools2 to utilize the GPU version of SVP, but im hoping to fix it soon.

The last plugin I cannot find a good 64 bit equivalent for is the unsharpen mask. So if anyone knows a good version for that let me know please.

Works great with 4k, 8k etc content. Much faster with GPU utilization.

[felicialee]

Thanks for a wonderful script and the results are great for colour 8mm film. :):)
I've also got some black and white 8mm films as well.

[SnillorZ]

The last plugin I cannot find a good 64 bit equivalent for is the unsharpen mask. So if anyone knows a good version for that let me know please.


@Bear did you see the earlier posts?

AVS+ Script Unsharpmask function (https://forum.doom9.org/showthread.php?p=1875711)

Warpsharp x64 DLL (https://forum.doom9.org/showthread.php?p=1876526)

Interested to see what your numbers are like on GPU vs CPU processing (based on these scripts) :script:

[bassquake]

If anyones interested, I posted a video showing the different stages of post-processing. I used VirtualDub2 mostly as have better control, but use AviSynth+ for some mild dirt removal and sharpening using settings posted on this thread.

Youtube Video (https://www.youtube.com/watch?v=lWE4eOX740w)

Appreciate comments.

[johnmeyer]

If anyones interested, I posted a video showing the different stages of post-processing.Very nice!

What software did you use for dirt removal? If you used RemoveDirtMC, what settings did you use?

All your other steps look really, really good, but I think you might be able to get better dirt removal.

[edit]Here is one of my "before/after" comparisons, using the scripts I've posted. I have it queued up to a section where there is a lot of dirt removal. I'm not doing this to get into a "who's script is better" discussion, but merely to point out that I think you can get better dirt removal:

https://www.youtube.com/watch?v=tBAHzO7rJS0&t=1m6s

and here is that same clip queued up to the point where the amount of dirt removal hits "ludicrous speed:

https://www.youtube.com/watch?v=tBAHzO7rJS0&t=3m51s

[bassquake]

Thanks johnmeyer!

Cheers for a look at dirt removal comparisons.

Yes, was RemoveDirtMC for dirt removal and a smidge of sharpening for the final touch.

I prefer to keep film grain which is why I don't use DeNoise, and kept dirt removal to a setting of 20 for the variable dirt_strength. I guess I could go higher but I like a bit of "character" on the film :D

[johnmeyer]

Yes, was RemoveDirtMC for dirt removal and a smidge of sharpening for the final touch.

I prefer to keep film grain which is why I don't use DeNoise, and kept dirt removal to a setting of 20 for the variable dirt_strength. I guess I could go higher but I like a bit of "character" on the film :DHmm ... If you are using the same version of RemoveDirtMC that I use, 20 should have given you a little more dirt removal (it is almost exactly what I use). However, I think the numerical setting interacts with the resolution you use. I do most of my film work at the NTSC SD resolution of 720x480 (non-square pixels). If you are doing your work at 720p or higher resolution, you might need to use a larger value in order to get the same level of dirt removal.

The two big downsides to using larger values of RemoveDirt are the disappearance of objects you want to keep (a thrown ball will almost always disappear, for instance), and the introduction of "gooey" artifacts where objects begin to morph instead of move.

[bassquake]

However, I think the numerical setting interacts with the resolution you use.

Probably. I create 1440 x 1080 videos! Looks great on a 55" tv :D

I might play around with upping settings more, but I do like some of the charm of flawed film!

[johnmeyer]

... I do like some of the charm of flawed film!Then why restore it at all? Along these same lines, many people prefer leaving the gate weave (the residual bounce) because that is an inherent quality of movie film, but you've removed that. What's the difference between removing all the gate weave, but only some of the dirt?

I got my start in media restoration by restoring 78 rpm recordings. I heard many of the same arguments back then, that removing the residual hiss and pops took away much of the "life" and "authenticity" of the original medium.

OK, that's a fair criticism, but I do have this to say: listening to restored shellac or vinyl recordings, or watching completely restored film sure is a lot easier on the ears and eyes, and lets you concentrate on the content of the media.

[bassquake]

Some dirt removal is better than none but I don't want to go overboard due to the issues you listed.

[minusthebear]

@Bear did you see the earlier posts?

AVS+ Script Unsharpmask function (https://forum.doom9.org/showthread.php?p=1875711)

Warpsharp x64 DLL (https://forum.doom9.org/showthread.php?p=1876526)

Interested to see what your numbers are like on GPU vs CPU processing (based on these scripts) :script:

Thank you! will incorporate this.

[minusthebear]

Ok, so here is my mod.

This is a 64-bit GPU enabled version of Fred's filter.

This requires AviSynth+ btw, if you want to use the prefetch enhancements,

If you don't want the prefetch, just comment out that line and you can use AviSynth.

Obviously needs virtualdub64 or another 64 bit program to capture.

You will most likely have to put the FFT3dGPU.dll and fft3dfilter.dll plugins in your system32 folder. If you have 32 bit versions there you will have to rename them with .bak and replace. Can't have both as far as I can tell.

There are 2 versions I created;

1. Fred 64 with MDegrain - This uses a GPU enabled SVPflow motion flow. The rest is 64-bit but CPU.
2. Fred 64 with GPU MDegrain - This utilizes the SPVConvert function to utilize the CPU with the MDegrain denoising filter. However it has artifacting and doesnt work properly. Maybe someone can fix it.

I will be honest, the speed enhancements are marginal at best, unfortunately there are many functions that the GPU is waiting for while the CPU handles them. Especially the AutoAdjust plugin.

However this is 64-bit now, meaning you will not have any issues with Ram overflow etc. The skys the limit, 4k, 8k, whatever you want.

Enjoy.

https://drive.google.com/file/d/1O-ACG2V-ptp5_LTv3Vpo6AxNtMf37YC_/view?usp=sharing

[Groucho2004]

You will most likely have to put the FFT3dGPU.dll and fft3dfilter.dll plugins in your system32 folder. If you have 32 bit versions there you will have to rename them with .bak and replace. Can't have both as far as I can tell.Firstly, these DLLs are plugins and should therefore be in the appropriate plugin directories. Secondly, on 64 bit Windows there are dedicated system directories for DLLs that need to be within the reach of the standard Windows search hierarchy (System32 for 64 bit, SysWoW64 for 32 bit). No renaming necessary/recommended.

[Natty]

1. Fred 64 with MDegrain - This uses a GPU enabled SVPflow motion flow. The rest is 64-bit but CPU.

can u pls give a basic example? :thanks:

[videoh]

@minusthebear

You are distributing one of my DLLs without my permission (DGDecodeNV.dll). It is not in the public domain. I demand that you remove it from your distribution. If you do not, I will ask the mods to take appropriate action.

[minusthebear]

@minusthebear

You are distributing one of my DLLs without my permission (DGDecodeNV.dll). It is not in the public domain. I demand that you remove it from your distribution. If you do not, I will ask the mods to take appropriate action.

Oh shoot, I didnt realize.

Its gone.

[minusthebear]

can u pls give a basic example? :thanks:

I'm not sure what you mean?

Do you want like a before and after type clip?

The end result is almost identical to the 32-bit FRED version.

This is just using 64-bit and GPU

[videoh]

Oh shoot, I didnt realize.

Its gone. Thank you, Sir.

[SnillorZ]

I'm not sure what you mean?

Do you want like a before and after type clip?

The end result is almost identical to the 32-bit FRED version.

This is just using 64-bit and GPU

Looking to see what your performance numbers are?

e.g. from @Groucho2004's AVSMeter to compare the CPU based script & plugins vs GPU ones

:thanks:

[SnillorZ]

Here is one of my "before/after" comparisons, using the scripts I've posted. I have it queued up to a section where there is a lot of dirt removal. I'm not doing this to get into a "who's script is better" discussion, but merely to point out that I think you can get better dirt removal:

https://www.youtube.com/watch?v=tBAHzO7rJS0&t=1m6s


John in this example of yours, there are a lot of vertical lines along with the dirt spots that you've managed to remove in the "after" clip.

Interested to know, was this all achieved with RemoveDirt?

I have some footage with vertical lines (some static, some with frame weave) that I was thinking would need another method for removal, including possibly frame by frame by hand for the "static lines".

[johnmeyer]

John in this example of yours, there are a lot of vertical lines along with the dirt spots that you've managed to remove in the "after" clip.

Interested to know, was this all achieved with RemoveDirt?Amazingly, RemoveDirt can sometimes remove gigantic spots (you'll easily see that in the beach scene) and even a few scratches, but only if the scratches move around a lot. Unfortunately, normal vertical scratches really cannot be removed by any automatic methods because they persist from frame to frame and don't move around much. As a result, automated algorithms really can't tell the difference between a scratch and a normal thin vertical line (fence, wallpaper, etc.). RemoveDirt, and other similar plugins like Despot, rely on the artifact lasting for only a single frame.

About the only way I know of to truly remove film scratches is to do it during transfer using a "wet gate," which involves putting a lubricant on the film, prior to transfer, which fills in the scratch and causes them to almost perfectly disappear. Your transfer equipment has to be able to accommodate wet film, which mine does not, in order to be able to take advantage of this "trick." Also, it involves extra steps, thus making the transfer take longer.

The man who started this thread, "VideoFred," uses a wet gate and has posted about it several times, both in this thread and elsewhere. Do a forum search on "wet gate" and his user name to learn more.

[bassquake]

Maybe try the DeScratch (https://avisynth.org.ru/descratch/descratch.html) tool for AVISynth to remove vertical scratches. Haven't tried it myself yet.

[SnillorZ]

The man who started this thread, "VideoFred," uses a wet gate and has posted about it several times, both in this thread and elsewhere. Do a forum search on "wet gate" and his user name to learn more.

Thanks John, yes I had researched wetgate transfers for emulsion damage. I'll revisit the footage I have to see if the amount that would benefit justify the cost of a rescan with wetgate.

Maybe try the DeScratch (https://avisynth.org.ru/descratch/descratch.html) tool for AVISynth to remove vertical scratches. Haven't tried it myself yet.

Think I had previously stumbled across Fizicks DeScratch plugin, but bypassed it in the pursuit of x64 bit plugins for Fred's/John's scripts. Will take another look and do some (x32 script) testing. :sly:

[johnmeyer]

I was never able to get ANY positive results from Descratch, but you should try it, just to see if you have better luck.

[manono]

I was never able to get ANY positive results from Descratch...
Me neither.

[bassquake]

Attached 64bit version of Descratch in case want to try it in your 64bit workflow.

[videoFred]

I had researched wetgate transfers for emulsion damage.

Only layer scrathes can be made (temporal) invisible with wetgate.
Unfortunately emulsion damage can not be fixed with wetgate.
(See also my turorial on Youtube)

However, if the emulsion damage change for frame to frame, then Removedirt() might remove it.

Otherwise you will have to look for other solutions.

Fred.

[minusthebear]

Looking to see what your performance numbers are?

e.g. from @Groucho2004's AVSMeter to compare the CPU based script & plugins vs GPU ones

:thanks:

Ok ill try that, but really, the biggest issue is that with 4k video the 32-bit version literally crashes, it fills up the 2gb of ram VirtualDub can access and creates a memory access violation.

Which isnt an issue with 64-bit.

The GPU helps a bit with speed but not much, ill post a comparison though.

[rjansen1]

Hi everyone,

I've only recently stumbled upon all the wonderful stuff you guys have created here when trying to restore some digitized Fuji Single 8 family movies. Unfortunately my dad threw away the original movies after he'd had them restored so I had to make do with the MPG files I extracted from the DVD. After removing duplicate frames and trimming some of the uglier splices I managed to get some pretty decent results with Fred's scripts to start out with and later on with John's scripts.

But of course I wouldn't be posting here if I didn't have any question. From what I read in the threads here GamMac is preferably used with a detect clip as this creates a more subtle / less harsh color correction. Unfortunately I've found that a lot of the movies I'm fixing have whites that are tinged pink-ish. GamMac without a detect clip seems to fix these fine:

https://i9.photobucket.com/albums/a56/dmrazor/avisynth/beach-nodc_zps9gfazc0w.png

with the detect clip the pink tinge remains although not a strong as before:

https://i9.photobucket.com/albums/a56/dmrazor/avisynth/beach-dc_zpsy6ha9adh.png

Of course the easy answer is to just go without the dc, but on some of the other scenes I find the color better with dc. Is this expected behaviour, or am I doing something wrong here? Or should I adjust my workflow and fix the movies scene by scene (not something I'm looking forward to tbh)

Cheers and thanks for creating all these great scripts!

Remco

[videoFred]

Hi everyone,

Hi Remco, welcome here :)

What DC clip have you used?

Fred.

[rjansen1]

What DC clip have you used?

I used this one from John's version of your script:

Baseclip = PreBorderFrame.crop(borderV,borderH,-borderV,-borderH,align=true).bicubicresize(W,H)
blank_black = Blankclip(baseclip, width=autolev_bord1,height=autolev_bord1)
blank_white= Blankclip(baseclip, width=autolev_bord1,height=autolev_bord1, color=$FFFFFF)
Average= baseclip.FredAverage().invert()
over1 = overlay(baseclip,blank_black, x=40,y=300)
over2 = overlay (over1,blank_white, x=160, y=300) \
.bicubicresize(width(baseclip)-(al2)*2,height(baseclip)-(al2)*2)
Detect = (al2 >1) ? overlay (Average, over2,x=al2,y=al2) \
.converttoRGB24(matrix="rec709") : over2.converttoRGB24(matrix="rec709")

I initially left all the settings at their defaults: (Al2 = 20; autolev_bord1 = 50; borderV=10; borderH=10), but I've also experimented with a smaller border. This leaves less of the pink tinge, but it doesn't dissappear.

Cheers,
Remco

[videoFred]

I used this one from John's version of your script:

Hmmmm... yes, I must take a closer look at John's version.
Can you upload an example clip?

Fred.

[rjansen1]

Hmmmm... yes, I must take a closer look at John's version.
Can you upload an example clip?

Yeah, sure. But will be on Sunday as I'm away tonight and tomorrow. What type of clip do you need: couple of seconds of the source AVI?

Cheers,
Remco

[johnmeyer]

There are many versions of "FredAverage" which is used to create the detect clip. This is the version I am using:

AVISynth FredAverage_26_dll_v0.01_20170414.zip

The DLL is dated 4/14/2017.

[rjansen1]

Ok, found time to prepare two clips:

pink clip (https://drive.google.com/open?id=1Hr-_39Lsc3hME4O_3hOt7mvhN4rjAN9W)
purple clip (https://drive.google.com/open?id=1O6tK2NUfrJhtzFr6Cf-egEquQULn8Ugn)

Both clips clean up to good white balance without using a DC, and keep the pink/purple tinge with DC.

I'm using FredAverage_25&26_x86_x64_dll_v0.03_20190115

Ciao,
Remco

[StainlessS]

There are many versions of "FredAverage"

Not that many versions really,


FredAverage_26_dll_v0.01_20170414.zip
FredAverage_25&26_x86_x64_dll_v0.02_20190115.zip
FredAverage_25&26_x86_x64_dll_v0.03_20190115.zip

/*
v0.01, First release. 2.60 only.
v0.02, 15 Jan 2019. Moved to VS2008, Added Version Resource + v2.58 + x64.
Added bool arg TV_YUV;
v0.03, 15 Jan 2019. BugFix version, fixed TV_YUV rounding. # Same day fix
*/


EDIT: The only difference between first and current version (apart from being now v2.58 and x64 versions)

TV_YUV, Default false, If True(And YUV), then photo negative invert around TV levels mid Y(125.5), rather than 127.5.

Default TV_YUV false, same as original v0.01.

TV Levels Y Mid point = (16 + 235) / 2.0 = 125.5. [ Same as (235-16) / 2.0 + 16.0 = 125.5 ]

EDIT: So, for Avs YUV TV_Levels Invert() filter is really a bit wrong, as invert is around 127.5 [0->$FF, $FF->0, $7F->$80, $80->$7F].
Maybe Invert() Filter should have something like TV_YUV arg, default false. [ignored for RGB]

EDIT:

G1=BlankClip(Width=128,height=64,Pixel_Type="YV12",Color_YUV=$7F8080)
G2=G1.Invert
G3=G2.Invert
B=G1.BlankClip(height=8)
G1=G1.RT_Subtitle("$%02X",G1.RT_YPLaneMin(n=0))
G2=G2.RT_Subtitle("$%02X",G2.RT_YPLaneMin(n=0))
G3=G3.RT_Subtitle("$%02X",G3.RT_YPLaneMin(n=0))
StackVertical(G1,B,G2,B,G3)

https://i.postimg.cc/7Y5BGwZs/Test-00.jpg (https://postimages.org/)

Fred Average same as Invert

TV_YUV=False
G1=BlankClip(Width=128,height=64,Pixel_Type="YV12",Color_YUV=$7F8080)
G2=G1.FredAverage(Invert=true,TV_YUV=TV_YUV)
G3=G2.FredAverage(Invert=true,TV_YUV=TV_YUV)
B=G1.BlankClip(height=8)
G1=G1.RT_Subtitle("$%02X",G1.RT_YPLaneMin(n=0))
G2=G2.RT_Subtitle("$%02X",G2.RT_YPLaneMin(n=0))
G3=G3.RT_Subtitle("$%02X",G3.RT_YPLaneMin(n=0))
StackVertical(G1,B,G2,B,G3)

https://i.postimg.cc/7Y5BGwZs/Test-00.jpg (https://postimages.org/)

FredAverage Y=125($7D) TV_YUV=False (same as Invert) [For TV Levels is WRONG-ish]

TV_YUV=False
G1=BlankClip(Width=128,height=64,Pixel_Type="YV12",Color_YUV=$7D8080)
G2=G1.FredAverage(Invert=true,TV_YUV=TV_YUV)
G3=G2.FredAverage(Invert=true,TV_YUV=TV_YUV)
B=G1.BlankClip(height=8)
G1=G1.RT_Subtitle("$%02X",G1.RT_YPLaneMin(n=0))
G2=G2.RT_Subtitle("$%02X",G2.RT_YPLaneMin(n=0))
G3=G3.RT_Subtitle("$%02X",G3.RT_YPLaneMin(n=0))
StackVertical(G1,B,G2,B,G3)

https://i.postimg.cc/LX2S2vjp/Test-04.jpg (https://postimages.org/)

FredAverage Y=125($7D) TV_YUV=true (TV mid Y = 125.5, 125[$7D]->126[$7E], 126[$7E]->125[$7D] )

TV_YUV=True
G1=BlankClip(Width=128,height=64,Pixel_Type="YV12",Color_YUV=$7D8080)
G2=G1.FredAverage(Invert=true,TV_YUV=TV_YUV)
G3=G2.FredAverage(Invert=true,TV_YUV=TV_YUV)
B=G1.BlankClip(height=8)
G1=G1.RT_Subtitle("$%02X",G1.RT_YPLaneMin(n=0))
G2=G2.RT_Subtitle("$%02X",G2.RT_YPLaneMin(n=0))
G3=G3.RT_Subtitle("$%02X",G3.RT_YPLaneMin(n=0))
StackVertical(G1,B,G2,B,G3)

https://i.postimg.cc/6QSHhQ51/Test-05.jpg (https://postimages.org/)

EDIT: And just for good measure, (16=$10, 235 =$EB)
FredAverage Y=16($10) TV_YUV=true (TV mid Y = 125.5, 16[$10]->235[$EB], 235[$EB]->16[$10] )

TV_YUV=True
G1=BlankClip(Width=128,height=64,Pixel_Type="YV12",Color_YUV=$108080)
G2=G1.FredAverage(Invert=true,TV_YUV=TV_YUV)
G3=G2.FredAverage(Invert=true,TV_YUV=TV_YUV)
B=G1.BlankClip(height=8)
G1=G1.RT_Subtitle("$%02X",G1.RT_YPLaneMin(n=0))
G2=G2.RT_Subtitle("$%02X",G2.RT_YPLaneMin(n=0))
G3=G3.RT_Subtitle("$%02X",G3.RT_YPLaneMin(n=0))
StackVertical(G1,B,G2,B,G3)

https://i.postimg.cc/SxM9WmRD/Test-06.jpg (https://postimages.org/)

EDIT:

if(invert) { // invert ?
if(tvy) {
ave = int(-(ave_D - 125.5) + 125.5 + 0.5); // TV_YUV Y mid = 125.5, invert, and Round
} else {
ave = int(ave_D + 0.5) ^ 0xFF; // PC_YUV Y mid = 127.5, symmetrical about 127.5
}
} else {


For YUV,
Invert() filter + FredAverage(TV_YUV=false), both mid Y = 127.5, symmetrical about 127.5.
FredAverage(TV_YUV=True), mid Y = 125.5, symmetrical about 125.5.

[Bernardd]

Hi Rjansen1,

An other way based on Stainlesss plugins.

I tried quickly my script on your videos. https://forum.doom9.org/showthread.php?p=1881328#post1881328

The first seem in accordance with default args :

https://i.postimg.cc/J4NWdYTV/frame-65.png

The secund need spimd args tune and manual spow action, thus with r_spmid = 0.2 , g_spmid = 0.5, b_spmid = 0.8 and g_spow = 0.8 :

https://i.postimg.cc/d07HgLqk/frame-45.png

[videoFred]

Both clips clean up to good white balance without using a DC, and keep the pink/purple tinge with DC.

It is not mandatory (is this good English? :o) to use FredAverage() on the DC clip. The idea of using a DC clip is to use a prepared clip before the Gammac analysis. For example, denoising/cleaning/cropping. Only in some cases, for example on scenes with water and blue sky, FredAverage() can help to avoid wrong Gammac() results.

So, in your case, I advice to use a DC clip without FredAverage().

Fred.

[videoFred]

I tried quickly my script on your videos.

Good results Bernardd! Gammac() gives very similar results.

Fred.

[rjansen1]

Only in some cases, for example on scenes with water and blue sky, FredAverage() can help to avoid wrong Gammac() results.

So, in your case, I advice to use a DC clip without FredAverage().
Thanks, that's good to know. And I think I've seen this on some scenes with water that seem to render better with FredAverage().

@Bernardd: I'll also give your script a go!

Greetings,
Remco

[StainlessS]

It is not mandatory (is this good English? ) to use FredAverage() on the DC clip.

Just like a native speaker, perfectly good, Fred ol' chap :)

[rjansen1]

@Bernardd: tried replacing Gammac with your script and found that it gives good results on some scenes, but then again worse results on others. Also it doesn't seem to work multithreaded. Is that correct?

I guess there's no magic bullit and in the end it's a matter of selecting the method that works good for 80% of the movie and fix the other bits using different methods. From what I read that's what you guys do as well :)

Cheers,
Remco

[Bernardd]

@rjansen1, thanks for you feed back.
For multithread, i do not know.

[videoFred]

Just like a native speaker, perfectly good, Fred ol' chap :)

Haha I do my best with a little help from.... my friends no I mean Google. :D

Fred.