exist any filter specially done for (deinterlace) flicker

[Mystery Keeper]

Oh my. It connects lines so neatly! I'm not very good at avisynth, so I don't really understand what's happening in the script. For me you guys are wizards ^_^

[WorBry]

My friend, you dont really need to understand whats happening in the script, its a complete function to be used as such and Magician Didee is the sole author.

[Mystery Keeper]

I know. I'm already successfully using it ^_^
By the way, I usually process MPEG2 musical videos and I'm used to low speed. right now I'm encoding one at 0,5 fps ^_^' So don't you guys complain. Quality certainly worth it.

As for anti-aliasing, my choice is still EEDI2().TurnRight().EEDI2().TurnLeft() after cropping and before resizing. As it almost destroys no details, the result is much smoother than the same method with nnedi.

[Mystery Keeper]

Had it screw up large detailed and static frame in anime, over which a strongly interlaced spot was applied. MCBob handled that frame gracefully. Can not give snapshots now, but shall later.

[WorBry]

As for anti-aliasing, my choice is still EEDI2().TurnRight().EEDI2().TurnLeft() after cropping and before resizing. As it almost destroys no details, the result is much smoother than the same method with nnedi.

Tried that, and the NNEDI version, but it doesnt deal very effectively with the type of aliasing (notably 'quilting' or 'moire effect') that I encounter with my pseudo-progressive material.

[Didée]

Beta 1. (http://home.arcor.de/dhanselmann/_stuff/TempGaussMC_beta1.rar)

(Fixing update: BinomialBlur() leaks memory, replaced it with some equivalent filtering.)

[WorBry]

Wow, and just when I thought I'd got my head around the scripting of TempGaussMC_alpha3.

Ran a few tests and needless to say the results are incredible.

Glad you put in EEDI2maxd as an adjustable parameter, as I find the occasional hole in my 'stripey shirt' tests at default maxd=8; adjusting to maxd=6 seems to resolve that.

I see the default sharpness been increased a little i.e from 0.25+(tr1+tr2)/8. to 0.25+(tr1+tr2)/6. which (at default Tr1=2, Tr2=1) represents an increase from 0.625 to 0.75. I know the sharpness can be adjusted to personal taste, but just wondered if there is an empirical reason for the change i.e. more blur that needs to be countered?

[2Bdecided]

It's sharper and faster, but I'm getting slight combing-like artefacts. There are parts that were blurred in the original (either out of focus, or moving) which alpha3 kept blurred. The Beta versions adds little lines or steps within the blur.

Would it help to upload something to show this?

Cheers,
David.

[Didée]

@2Bdecided:
Yes, please. It's probably the "SVthin" thingy (try to set that to 0.0), but checking is better than guessing.
The faster performance is because the blocksize/overlap defaults now are 16/8, before they were 8/4.


@ WorBry:
The default is sharpness=0.75 for the spatial SLmode=1|3, or sharpness=1.5 for the temporal SLmode=2|4.

In theory (i.e. on a "perfect" syntetic showcase), it would need sharpness=4.0 (for Smode=1) or sharpness=2.0 (for Smode=2), in order to completely restore the blur-down of the temporal gauss. So the sharpness defaults are still on the conservative side of things.

[2Bdecided]

SVthin=0.0 dramatically improves it. It's still a little worse than before, but subtle.

See the finger nails on the boy's left hand (i.e. the hand on the red bar)...
http://rapidshare.com/files/126300644/1440x1080i50tgmcb.m2v.html

Cheers,
David.

[Didée]

Seems like it's one of the dangerous downsides of using the mc-compensated neighbors for limiting. The "flattening" of the search-clip makes the reckognition of bad compensations less reliable ... however the flattening is ultimately needed. Without it, MVDegrain would do almost nothing-at-all to the bobbing parts ...

I'll have a look at it. For the moment, here's some justification for why things are like they are in beta-1 :

http://www.hochladen.info/images/upload12/XZuDK47Z5dogwLs/thumb.png (http://www.hochladen.info/image/XZuDK47Z5dogwLs/) ( top: progressive reference | YadifMod(NNEDI) - bottom: TGMC alpha-3 | TGMC beta-1 )

Beta-1 is not only "sharper" ... it really recovers more true detail (detail that is 'not present' in a given field but only in its neighbors can not be recovered by the alpha versions, due to the spatial limiting), and it even is more stable than the previous alphas.


Edit:
With your sample, I can not (or hardly) confirm a problem with the new beta version as such. The artefacts e.g. on the fingernails are just a coincidence: they're worse with EEDI2 (beta's default, faster), and less prominent with NNEDI (alpha's default, slower). Also they're a bit worse with 16/8 (beta's default, faster), and less so with 8/4 (alpha's default, slower).
It seems in this case it's mostly a matter of the changed default settings.

Hmmh ... perhaps I should make make ALL parameters MANDATORY with NO DEFAULT settings, so everyone HAS TO choose his own poison ... :D

[2Bdecided]

That's a great comparison. It's very useful having the progressive source for testing - not something I have the luxury of with HDV (otherwise I wouldn't need TGMC!).

Thanks for taking a look at it Didée. I do like the extra sharpness of beta-1, though my HDV footage rarely has anything pixel sharp in it to start with (other than noise and encoding artefacts!).

Cheers,
David.

[Terranigma]

perhaps I should make make ALL parameters MANDATORY with NO DEFAULT settings, so everyone HAS TO choose his own poison ... :D
Or change the defaults to the most optimal settings and let users be able to alter them for speed over quality.

[Didée]

There is no such thing as "most optimal settings".

Par ex.: "EdiMode".
Yadif is blazingly fast, sometimes it looks okay, sometimes it looks terrible. NNEDI is very slow, often looks good, but I could show you cases where even NNEDI's neural network *fails*, yet the cheapo-quicko Yadif looks brilliant(!) in comparison. EEDI2 is king & pope when it comes to connecting diagonals and thin lines, but it also mis-guesses quite often, and is prone to give the dreadful "oilpaint look" (same as Yadif, but even more so). Ditching e.d.i. completely and just using plain bicubic interpolation will - in many places - look as good as any other setting, but in some places it'll cause aliasing (depending on vertical motion, when neighbor fields happen to not contain the necessary information.)

And now you tell me, which is the "most optimal" setting for EdiMode?

Yeah, exactly. Same goes for all other parameters.

Current defaults should be in reasonable mid-range. And altering the settings for trading speed vs. quality is exactly what the user is supposed to do, anyway. :)

[murrsturr]

Thanks for this great filter Didee. I am presently using it, and it only, on sd digital TV captures with great results.

With all settings default, save for edimode, on a Q9300 with 4 gigs of ram with multi-threading enabled (I am using SetMTMode(2) prior to calling your function) I am getting the following FPS averages:

EED12=4.7+
NNEDI=5.8+
Yadif=8.7+

With the lighter settings WorBry suggested (thanks WorBry) a few posts back I am getting 12.5+ fps with Yadif. So on my setup "mid-range" default EED12 is actually slowest but I am more than happy with the results that Yadif is giving me thus far. I am looking forward messing around with this much more.

Thanks again!

[WorBry]

With my home DV sources, I’m also noticing some ‘edge serration’ and, I’d dare say, a little distortion/erosion in places where objects are moving over objects/ high contrast edges.

Here are two examples from the test clip that put-up in Post #30

http://rapidshare.com/files/126551745/TGMC_NNEDI_222_beta_vs_alpha3.avi.html

Compared were (left to right):

TGMC-beta (Tr0=2, Tr1=2, Tr2=2, edimode=NNEDI)
TGMC-beta (Tr0=2, Tr1=2, Tr2=2, edimode=NNEDI, blocksize=8)
TGMC-beta (Tr0=2, Tr1=2, Tr2=2, edimode=NNEDI, SVThin=0)
TGMC-beta (Tr0=2, Tr1=2, Tr2=2, edimode=NNEDI, blocksize=8, SVThin=0)
TGMC-a3 (Tr0=2, Tr1=2, Tr2=2, edimode=NNEDI)

Note the finger as it passes over the railings (frames 8 – 24) and thumb and forefinger in frames 42 – 49.

With TGMC-beta, reducing the block-size from default 16 to 8 definitely helps a little. Not too sure if setting SVThin=0 makes much of a difference, if any, in this case. But of course, without a progressive reference source it is difficult to gauge what represents true detail (or lack of it) from the ‘original’ and so there’s no telling what the slightly more blurred result with TGMC-alpha3 actually masks.

So, I guess it boils down to what one considers the more subjectively appealing….at normal playback speed that is. Generally, from my tests so far I do prefer the overall crisper look of the beta.

[Mystery Keeper]

I suggest this thread renamed "TempGaussMC deinterlacer".

[Didée]

I rather suggest spanking Didée, until he gets off his duff and makes a dedicated thread for it ... :)

(Which is what I'll probably make ... when I've a little more free air again.)

[WorBry]

With my home DV sources, I’m also noticing some ‘edge serration’ and, I’d dare say, a little distortion/erosion in places where objects are moving over objects/ high contrast edges.

Here’s another example (from the test clip I put-up in Post #30).

This time I ran a parallel series with edimode=EEDI2.

http://rapidshare.com/files/126935573/TGMC_EEDI2_222_beta_vs_alpha3_test2.avi.html

The series shows quite marked ‘combing’ on the boy’s hand with TGMC_beta and to a much lesser degree with TGMC-alpha3. Reducing Blocksize= 8 and SVThin=0 together brought a little improvement but not complete resolution. Although not shown in this series, reducing the EEDI2maxd value had no effect.

With edimode=NNEDI, the effect was rather more subtle, but distinct combing is still visible in parts (see Frame 5)

http://rapidshare.com/files/126936026/TGMC_NNEDI_222_beta_vs_alpha3_test2.avi.html

I think anyone looking at the ‘EEDI2’ series in particular would, at face value, assume this to represent residual interlace combing and if it is definitely not, then what is it – interpolation error that slips through the net, aliasing?

More to the point, what other tweaks available in the beta might be applied to avoid it ?

Thanks.

Edit: Seems to be arising somewhere in Stage 1a, as the Stage 1 output looks OK.

[Didée]

The basic problem is that motion compensation can't be successful in such spots. Those twiddling finglers of the little man are too different from one frame to the next, so MC can't do much useful there. At best, MC should do *nothing* in such areas ... but that's one example of where it is highly difficult to separate "the good" from "the bad" ...

1st, lowering blocksize/overlap does help, like you already found. Smaller blocksize can adapt better to such chaotic motion.

2nd, the "rep" reparations play a big role. Those deal for accepting only bob-typical vertical differences from the temporal filters (a bob-typical difference is "thin" in vertical direction). However in the areas you showed, the artefacts from motion compensation do form differences with quite similar characteristics as bob-typical differences do have, that's a problem.
You can try using lower repX values to reduce those artefacts. repX=1 is most aggressive in avoiding artefacts, repX=5 is most relaxed. But OTOH, too aggressive repX values may introduce bob flicker in the output again. It's a trade-off that's also content related. Some average footage may get away with more aggressive repX values; extremely detailed footage like the "Stockholm" panning scene is a nightmare that requires very relaxed reparation.

3rd, SLmode is also related. The old mode (SLmode=1 or 3, spatial) is more safe to avoid motion-related artefacts, but in some places it can inhibit full detail recovery, or even can result in slight flicker re-introduced into the output.
The new mode (SLmode=2 or4, temporal) theoretically are the true thing, since they allow for full detail recovery and maximum stableness in static or low-motion areas. But, in areas where motion compensation wasn't successful, the temporal mode allows that the sharpening expands into wrong pixel values. It's a trade-off.


In the end, there's no holy grail in sight, and trade-offs have to be made. For general denoising and/or motion compensating, the consens is to accept only differences that are "small enough", since using big differences usually introduces artefacts.
However, in the case of "denoising" bob flicker, it is a MUST to accept big local differences, and it's this very fact why TempGaussMC looks as good as it (mostly) does.
In light of the fact that TempGaussMC does exactly that what most other filters are too anxious to do, I'd say that the potential artefacts are rather little.

Besides, I'm not sure if I would note the artefacts of your example when viewing in realtime. Flicker in almost-static areas is so much more obvious than a few stray pixels that are located in funky-motion areas.


For orientation, here's a table with Beta1 defaults, alpha3 defaults, and the corresponding values to make beta1 behave (mostly) like alpha3:


|Default |beta1=> |Default |
Parameter |beta-1 | alpha3 |alpha3 |
----------+--------+--------+--------|
tr0 | 2 | 2 | 2 |
tr1 | 2 | 2 | 2 |
tr2 | 1 | 1 | 1 |
EdiMode | EEDI2 | NNEDI | NNEDI |
rep0 | 4 | 1 | true |
rep1 | 0 | 0 | [true] | <- alpha's "rep1"
rep2 | 4 | 1 | [---] | <- is beta's "rep2"
blocksize | 16 | 8 | 8 |
overlap | 8 | 4 | 4 |
Smode | 2 | 1 | (1) |
SLmode | 2 | 1 | (1) |
SLrad | 1 | 2 | (2) |
SVthin | 1.0 | 0.0 | --- |
Sbb | 1 | 0 | --- |
thSAD1 | 600 | 800 | (800) |
thSAD2 | 300 | 400 | (400) | (MVTools' standard default)
SCth1 | 180 | 400 | (400) | (dto.)
SCth2 | 98 | 130 | (130) | (dto.)

[WorBry]

Thanks for the explanations and the tweak table. In addition to reducing blocksize to 8, disabling (=0) both sbb and SVThin seems to bring about the most noticable improvement.

[Yoshiyuki Blade]

Hmmm, x264 in MeGUI blows up using the beta, unless I do a lossless pass using Vdub first (via lagarith) and encode that. Is that normal?

It might be a huge amount of ram usage or something. I'm testing on a 1080 clip bobbed to 60p. On my 2GB lappy, I can't even complete a lossless pass. Vista complains about low memory and ultimately crashes Vdub.

The results are awesome though :D.

[Didée]

I've never used MeGUI (yes, indeed), so I can't tell. But every now & then, there are reports that seem to indicate that MeGUI sometimes might become instable with complex or ressource hungry scripts.

For me, if something works in VirtualDub, then it works. If it doesn't work in MeGUI, then it's not a problem with the script ... :whistle:

Processing 1080ish HD, otoh, is ultimately beyond what my hardware allows (2.6 GHz singlecore /w microscopic L1/2 Cache, 512MB RAM), so I don't test for that at all ...

[Mystery Keeper]

Being written using .NET MeGUI sucks by definition. It crashes when I'm just trying to add new job with complex script. I only use it for some preparations lately.

[Yoshiyuki Blade]

I've never used MeGUI (yes, indeed), so I can't tell. But every now & then, there are reports that seem to indicate that MeGUI sometimes might become instable with complex or ressource hungry scripts.

For me, if something works in VirtualDub, then it works. If it doesn't work in MeGUI, then it's not a problem with the script ... :whistle:

Processing 1080ish HD, otoh, is ultimately beyond what my hardware allows (2.6 GHz singlecore /w microscopic L1/2 Cache, 512MB RAM), so I don't test for that at all ...

Ah I see. Yeah it might be problematic when working with HD material if you don't have enough RAM. I think the lossless process uses up to 1.6GB, and transcoding the lossless clip to x264 right now is using 1.5 GB :eek:

Being written using .NET MeGUI sucks by definition. It crashes when I'm just trying to add new job with complex script. I only use it for some preparations lately.

Ouch, that kinda sucks for me. I wonder how using a standard command line interface will turn out.

[Mystery Keeper]

Good thing is that it stopped crashing with the last update. Can use it as automate again. But editor of choice is still AvsP.

[Didée]

Hmh. Did some specifc testing, and it seems that Binomialblur() from Variableblur.dll is leaking some memory when variances >1.0 are specified. That's not good.

[Mystery Keeper]

And MeGUI still does crash =/

[Didée]

I've uploaded a new version of TempGaussMC beta-1. Functionality is exactly the same, but the script no more uses VariableBlur.dll, because of BinomialBlur's memory leakage.

(A test with a simple script that uses three instances of BinomialBlur (like TempGaussMC does, on average) did leak 250MB over the curse of 60'000 frames ... the fixed beta-1 is stable, memory usage stays constant.)

Beta 1, updated (http://home.arcor.de/dhanselmann/_stuff/TempGaussMC_beta1.rar).

[Wilbert]

I've uploaded a new version of TempGaussMC beta-1. Functionality is exactly the same, but the script no more uses VariableBlur.dll, because of BinomialBlur's memory leakage.
Did someone contact the author of VariableBlur about this?

[Yoshiyuki Blade]

Hmm, this version causes x264 to use only one core. It hasn't crashed yet tho :p

EDIT: Fixed a dumb typo and... Actually, it crashed just now lol. Gonna play around with it and see if it was something I did. It may be an experimental build of x264 I'm using.

EDIT2: Running a lossless pass with Vdub on the 2GB lappy. Vista notified me of low memory once, but the process still seems to be going. Hopefully it can complete the process. That's definitely an improvement over before. I supposed the MeGUI+x264 crash is just due to the complexity of the avs script. Update: The lappy successfully completed the process without crashing.

[murrsturr]

I had originally attributed what I thought to be a memory leak to Megui. Its core had been updated the same time this beta came out and it was only apparent after I used larger files in Megui. Whoever was the culprit, I'm glad to report beta 1 now working fine in Megui\XPsp3.

thanks Didee.

[Yoshiyuki Blade]

Here's a sample that I did:

http://www.mediafire.com/?m4yn0fomm4j

1080i from the camcorder bobbed to 1080p 60fps, and lanczos resized to 720. Used edi mode nnedi. I havent compared it to other bobbers but Yadif. Yadif failed horribly on the long cable that goes across the water, while tempgaussmc renders it almost perfectly. The overall sequence is also much steadier in general.

I'd upload the 1080p version if it wasn't over 100MB (close to 200 MB actually). That one looks even better, though it requires a lot of CPU power to decode at full speed.

[WorBry]

Didee,

I see that the beta incorporates a measure to offset a slight chroma shift caused by MVDegrain when Pel >1 (as it is by default, Pel=2). In that case, would your recommendation be to apply this corrective measure to MVDegrain in any context? Taking, for example, standard 'standalone' MVDegrain2, would this be correct:

backward_vec2 = clp.MVAnalyse(isb = true, delta = 2, truemotion=true, pel = 2, overlap=4, sharp=1, blksize=8, idx = 1)
backward_vec1 = clp.MVAnalyse(isb = true, delta = 1, truemotion=true, pel = 2, overlap=4, sharp=1, blksize=8, idx = 1)
forward_vec1 = clp.MVAnalyse(isb = false, delta = 1, truemotion=true, pel = 2, overlap=4, sharp=1, blksize=8, idx = 1)
forward_vec2 = clp.MVAnalyse(isb = false, delta = 2, truemotion=true, pel = 2, overlap=4, sharp=1, blksize=8, idx = 1)
mvdg2=clp.MVDegrain2(backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400,idx=1)
chrcor = mvdg2.mt_lutxy(clp,"x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * - ?",Y=2,U=3,V=3)
Return(chrcor)

If so, perhaps other functions that utilize MVDegrain, like Temporal Degrain, should be modified accordingly? Maybe it should be reported as an MVTools bug, if it has not already.

[sidewinder711]

I've uploaded a new version of TempGaussMC beta-1. Functionality is exactly the same, but the script no more uses VariableBlur.dll, because of BinomialBlur's memory leakage.

Only FYI:

During the last week I used TempGaussMC_beta several times and everything worked without any problems.
Yesterday I made an update to
- TempGaussMC_beta1,
- VirtualDub 1.81 latest build and
- Avisynth 2.58 RC2.

Now, after loading an avs file into VirtualDub (more or less only using TempGaussMC_beta1 with default values), the screen stays black. If I push the start button, VD/Avisynth crashes due to an "CAVIStreamSynth" error.

After searching the forum, I have learned that this a quite general error message. The error can be based on scripts, codecs, hardware parts...

I went back to TempGaussMC_beta ... and don't have any problems until now. Because the error message can be based on so many items, I will investigate the aforementioned problem a little bit deeper and keep you informed if I'm able to figure out any other reason than the new script.

[Didée]

@ sidewinder:
Strange. The only change was to replace BinomialBlur() with GaussResize() or RemoveGrain(11).GaussResize(). Can you check if the following simple script also fails:
source
w = source.width()
h = source.height()

source.gaussresize(w,h,0,0,w+0.0001,h+0.0001,p=3)

Another vague possibility: If you have more than 2GB of RAM, squid_80 reported a problem (http://forum.doom9.org/showthread.php?p=1158423#post1158423).


@ Worbry
Not sure if it's a bug per se in MVTools, it could be just some rounding issue going unlucky. The color shift is very slight when pel>1 & overlap=0, and very slightly more when pel>1 & overlap>0. The actual shift seems to be in range +/-2, so it could be that +/-1 comes from rounding in the subpel interpolation, and +/-1 comes from the block summation code.
However I'm in no way sure about this, it's just guessing.

As a general measure against the problem it's a bit too harsh, since it shifts every pixel back towards its original value. Now, what if you have some *slight* chroma noise in your source that you expect to be removed ... it's very likely that this measure will just restore the chroma noise that MVDegrain had successfully removed.

People deal with this for a long time now, and there were not much complaints about it (Terranigma once asked me in a PM).
I just included it here because with some of the samples I used, the shift was quite noticeable (e.g. on the water in the "Stockholm" sample), and I didn't want to have reports like "Hey, TempGaussMC messes up my colors!". ;)

[sidewinder711]

@Didée
I checked your code above on 2 machines with nearly the same VD/Avisynth configuration... no problems. BTW: I do have 4 gb RAM, but in all my scripts is "SetMemoryMax=1024". I made some quick tests:

- I tested TGMC_beta1 on my old machine... no problems loading a source file.
- Then I did the same on my new machine, which I usually use for encodings. Loading the TGMC_beta1 avs file for the first time, no problem. But re-loading the same script caused the problem that no film was loaded, the screen stayed black, but no crash.

All of the above mentioned crash problem occured as I had created a joblist in VD and VD was working through the jobs during the night. In the morning half of the jobs were done, the other half was errored out. Re-loading the "error scripts" caused these crashes I mentioned above.

Atm, it seems to me that the problem is memory related. Usually I don't have memory or other hardware problem with my machines (no crashes, bluescreens etc). In one forum message I read about an xvid codec problem, if it is running on a "normal priority" level (which I do), but I need to do further tests to narrow the real source behind the problem.

I'll keep you informed if anything new occurs.

[Didée]

All of the above mentioned crash problem occured as I had created a joblist in VD and VD was working through the jobs during the night. In the morning half of the jobs were one, the other half was errored out.
Ah, that reminds me of some issues I had (long) time ago when using VD's joblist with "complex" AVS scripts. My solution was to have a small dummy file (huffyuv, ten frames or so) to be converted to something else. This "dummy task" I placed between all the "real" tasks, and surprise, those VD errors disappeared.
Must be related to VD not correctly releasing memory when a job is completed, or something.

[sidewinder711]

Thanks, Didée, for your help. Now I have another idea to test.:)

[IanB]

Most of the methods so far in this thread involve some sort of averaging of adjacent data. And generally none of them totally remove the flicker. This is probably due to the issue I encountered when adding the interlace option to the SubTitle() filter.

This issue is Gamma!

You need to undo the Gamma compensation, apply your favourite averaging method, then reapply the Gamma compensation.

[Gavino]

The gamma thing seems to have been widely overlooked in digital image processing. See this paper (http://www.4p8.com/eric.brasseur/gamma.html) and this thread.

However, although there is a real issue here, I wonder if it's slightly overblown. Consider that in many cases we are averaging as a form of interpolation. The fact that we have a non-linearity in the representation just means we need a better interpolator than simple bilinear. After all, the real-world (continuous) intensity doesn't usually vary in a linear manner, so all we are doing is interpolating a different function (I(x,y)^gamma instead of I(x,y)).

Or am I missing something?

[IanB]

Well actually I(x^(1/gamma),y^(1/gamma))^gamma instead of I(x,y)

For gamma=2.2 and I(x,y)=(x+y)/2

x y I(x,y) I(x^(1/gamma),y^(1/gamma))^gamma
0.5 0.5 0.5 0.5
0.25 0.75 0.5 0.463
0.1 0.9 0.5 0.390
0.0 1.0 0.5 0.218

[Terka]

Does this mean the TempGaussMC has to be updated regarding the gamma?

[Didée]

Nope. :)

Firstly, there's hardly any need for that. The aim of TGMC is not to produce any averaged values (though it produces them intermediately), but rather to end up with pixel values that exist discretely in the current, previous or next frame/field.

Of all the problems that TempGaussMC or any other bobber are struggling with, I'd say that gamma compensation is the least important of all ...


Then, while gamma compensation basically is a good idea, it's pretty much inpractical to do at the script level. At the script level we're yet bound to 8-bit precision, and that's highly insufficient for such a gamma compensation.
See:

a) TemporalSoften(2,32,32,32,2):
http://img337.imageshack.us/img337/2544/normalux9.th.png (http://img337.imageshack.us/my.php?image=normalux9.png)

b) The same with gamma compensation: (with 8bit/plane precision, through levels() )
http://img186.imageshack.us/img186/2784/gammacompensated8bitey8.th.png (http://img186.imageshack.us/my.php?image=gammacompensated8bitey8.png)

Another example: (left=normal resizing, right=gamma-corrected resizing)

http://img406.imageshack.us/img406/7600/normalnb6.th.png (http://img406.imageshack.us/my.php?image=normalnb6.png) -- http://img167.imageshack.us/img167/9200/gamma8bitbb7.th.png (http://img167.imageshack.us/my.php?image=gamma8bitbb7.png)

In both cases that's not an improvement. It's a severe degradation, caused by way too little precision available in 8 bits. One can play tricks like using gamma compensation only for values bigger than 64, or so, sure. But that defeats the purpose.


If you want to have gamma compensation, either urge all authors of all plugins that do any sort of spatial and/or temporal averaging to make their plugins perform that compensation internally. Or you wait for Avisynth (and the needed filters) to provide 16bit/plane precision. (Yes, 16 bit ... 10bit chimaera are still not sufficient for this.)

Apart from that, gamma really is an RGB concept. In YUV colorspace, "gamma" adjustment is a whacky approximation that doesn't truly reflect what gamma is supposed to be.

[Terka]

ok :)

[Gavino]

Apart from that, gamma really is an RGB concept. In YUV colorspace, "gamma" adjustment is a whacky approximation that doesn't truly reflect what gamma is supposed to be.
But aren't YUV filters affected by the gamma issue just as much as in RGB?

Perhaps even more so, precisely because of the whacky approximation used in RGB<->YUV conversion (which is done using gamma-encoded RGB values rather than gamma-encoding the converted linear values).

[WorBry]

Specifically, in DV camcorders, gamma correction is normally applied to the linear digital RGB signal after the Rec 601 transfer function and before conversion to Y'CbCr color space.

http://en.wikipedia.org/wiki/DV

[Didée]

This way, that way, or another. Still I don't see how TGMC could benefit, since it's basically flicker-free. If it flickers in places, then it's because of mocomp-mismatches, or because of misinterpreting a good compensation as being bad, and thelike ... but not because of missing gamma compensation.

My bigger fear is HOWDOIPROCESSYUY2SOURCESWITHIT ... sooner or later, it will come up ...

[WorBry]

My bigger fear is HOWDOIPROCESSYUY2SOURCESWITHIT ... sooner or later, it will come up ...

ConvertToYV12(interlaced=true) ?

[AVIL]

My bigger fear is HOWDOIPROCESSYUY2SOURCESWITHIT ... sooner or later, it will come up ...

A little help (sorry for inserting an attachment but the script exceeds 16000 chars limit)