SVP-like frame interpolation?

[MysteryX]

Masking with blending indeed often doesn't look great. False positives look worse than MVTools2 alone; but when MVTools2 makes really ugly artifacts, it's important to take those out and it does a better job at that.

While you test, also look with output="mask" or "overlay" to see where the differences are, and whether the mask is being applied correctly.

If there are areas where you would manually fix differently, you can tell me exactly how you would do it.

[johnmeyer]

While you test, also look with output="mask" or "overlay" to see where the differences are, and whether the mask is being applied correctly.Thanks for the tip. I'll try that next.

[MysteryX]

Now I can do something with this.


StripeMask(blksize=8, gam=2, str=2)


https://s10.postimg.org/wcw4y6zid/Stripe_Mask_Lighthouse.png (https://postimg.org/image/wcw4y6zid/)

I tried on a video that fails drastically
https://s10.postimg.org/60mletkjp/Stripe_Mask_Fem.png (https://postimg.org/image/60mletkjp/)

Blksize 16, 32
https://s10.postimg.org/c2ytj1ydh/Stripe_Mask_Fem16.png (https://postimg.org/image/c2ytj1ydh/) https://s10.postimg.org/4bi3khu85/Stripe_Mask_Fem32.png (https://postimg.org/image/4bi3khu85/)

From there, I call mt_expand and got good data to work with.

While passing through a regular video, stuff does get detected, but it's generally areas that cause problems anyway, so it might just help remove areas that are borderline. It's kind of funny to look at a live video with those sticks though.

[MysteryX]

This is looking pretty good.

This frame...
https://s22.postimg.org/g6maqk01p/4088orig.png (https://postimg.org/image/g6maqk01p/)

Gives this...
https://s22.postimg.org/ny30p4471/4088flow.png (https://postimg.org/image/ny30p4471/)

With this raw mask...
https://s22.postimg.org/hmxt8p2yl/4088raw.png (https://postimg.org/image/hmxt8p2yl/)

StripeMask enhances the mask like this
https://s22.postimg.org/pgyeu3arh/4088raw2.png (https://postimg.org/image/pgyeu3arh/)

and turns the skip mask from this...
https://s22.postimg.org/scbi0yerh/4088skip.png (https://postimg.org/image/scbi0yerh/)

into this
https://s22.postimg.org/j5xsreywt/4088skip2.png (https://postimg.org/image/j5xsreywt/)

Now it's just a matter of testing and tweaking the settings.

[MysteryX]

Johnmeyer, for now, focus on testing with blksize=8, as with the next release of MVTools2 (https://github.com/pinterf/mvtools/blob/mvtools-pfmod/README.md), the mask is going to be normalized to blksize=8 (I believe). The version you have "hacks" for other block sizes by increasing the thresholds, but that hack won't be necessary anymore, and it won't produce the same output.

I don't know whether the original MVTools2 also had this issue of mask strength changing with blksize and with dct. Pinterf appears to be saying it was a regression, and perhaps earlier versions are fine.

Now I have a question.

I have StripeMask of the current frame. Is it possible to add StrikeMask of the next frame with 50% opacity without needing to calculate it twice? It would need to go into the cache, but I'm not sure how to go about that.

What happens if I write something like this? Does it calculate each frame once or twice?

EM = C.DeleteFrame(0).StripeMask(C.StripeMask(EM, str=2), str=1)

[johnmeyer]

Johnmeyer, for now, focus on testing with blksize=8, <snip>

Now I have a question.

I have StripeMask of the current frame. Is it possible to add StrikeMask of the next frame with 50% opacity without needing to calculate it twice? It would need to go into the cache, but I'm not sure how to go about that.

What happens if I write something like this? Does it calculate each frame once or twice?

EM = C.DeleteFrame(0).StripeMask(C.StripeMask(EM, str=2), str=1)
That looks like something Gavino needs to address. I know nothing about how AVISynth handles reentrant code.

[MysteryX]

btw you might want to wait until I get the new version out before testing as the behaviors will change with the new MVTools2 and with StripeMask. Everything needs to be re-adjusted.

Also for testing, set debug=true to view more metrics

And by the way, this doesn't work

EM = C.DeleteFrame(0).StripeMask(C.StripeMask(EM, str=2), str=1)

I'll use only the previous frame for the mask (which can serve for several interpolated frames) unless someone provides a solution here.

[MysteryX]

I spent a lot of time on StripeMask and can't get perfect results.

This simple algorithm works 80% of the times, but it tends to take too much geometric forms (especially of high contrasts) and skips low-contrast patterns.

[MysteryX]

Victory, sweet victory!!

I knew I could do this.

From the mask of contrast lines, I looked for repeating patterns OR 2 full blocks of continual contrasts lines.

I also process the next frame with 50% transparency.

Sweet lighthouse
https://s10.postimg.org/5knv9yx2t/Lighthouse.png (https://postimg.org/image/5knv9yx2t/)

Contrasts are high and small so lines form continuous zones
https://s10.postimg.org/6bglfqzg5/Lighthouse_Lines.png (https://postimg.org/image/6bglfqzg5/)

After detecting patterns and continuous zones
https://s10.postimg.org/y038n9mgl/Lighthouse_Patterns.png (https://postimg.org/image/y038n9mgl/)

This image was giving me trouble because contrasts are too low, requiring to set a low threshold (causing the lighthouse to go so white)
https://s10.postimg.org/7leeust85/4015.png (https://postimg.org/image/7leeust85/)

Lines get partially detected on that frame
https://s10.postimg.org/n85o86705/4015lines.png (https://postimg.org/image/n85o86705/)

That's enough to detect a lot of patterns
https://s10.postimg.org/n9fm1l8tx/4015patterns.png (https://postimg.org/image/n9fm1l8tx/)

This frame was giving me trouble because it shows just as much lines as previous frame
https://s10.postimg.org/9ywclt7n9/1405.png (https://postimg.org/image/9ywclt7n9/)

Lots of geometric forms being detected
https://s10.postimg.org/9ani2v8xh/1405lines.png (https://postimg.org/image/9ani2v8xh/)

But very few patterns
https://s10.postimg.org/koa1e2jg5/1405patterns.png (https://postimg.org/image/koa1e2jg5/)

That will do the job :D

[cork_OS]

It looks very promising, congratulations!

[johnmeyer]

So is your plan to replace your current masking approach with this mask, and then, within the mask, switch to something besides motion estimation?

[MysteryX]

So is your plan to replace your current masking approach with this mask, and then, within the mask, switch to something besides motion estimation?
No, this is mostly useful for the Skip threshold to know which frames to blend and which ones to skip. Otherwise, bad frames are passing through.

[MysteryX]

Now that mask levels are normalized, I played around with masks of different settings.

DCT=1 generally gives better quality but often adds artifacts, while removing others. Let's just say artifacts are different. However, if I take DCT=1 mask and substract DCT=0 mask, MT_Binarize, MT_Expand, Blur and then add DCT=0 image to the areas where DCT=1 has more artifacts, then it consistently gives better results. The areas that are only in the DCT=1 mask always look better on the DCT=0 image. That's consistent from my tests.

As for using masks of different block size, the problem is that the mask still tends to be slightly stronger with higher block sizes. Thus, it makes it very hard to compare. If the fallback is a larger block size, the logic explained above will almost never trigger, and if the fallback is a smaller block size, the fallback triggers way too often.

[raffriff42]

By the way, the name of the lighthouse (I have learned) is Pemaquid Point Light (https://en.wikipedia.org/wiki/Pemaquid_Point_Light), located in Maine. In case you want a nicer image, Wikipedia has got some:
https://upload.wikimedia.org/wikipedia/commons/thumb/d/da/Preston-pemaquid-lighthouse.jpg/180px-Preston-pemaquid-lighthouse.jpg (https://en.wikipedia.org/wiki/File:Preston-pemaquid-lighthouse.jpg) https://upload.wikimedia.org/wikipedia/commons/thumb/d/dd/Pemaquid-lighthouse.jpg/320px-Pemaquid-lighthouse.jpg (https://en.wikipedia.org/wiki/File:Pemaquid-lighthouse.jpg)

There are lots more online, but they are not open-source like Wikipedia's.

[cork_OS]

By the way, the name of the lighthouse (I have learned) is Pemaquid Point Light (https://en.wikipedia.org/wiki/Pemaquid_Point_Light), located in Maine. In case you want a nicer image, Wikipedia has got some
There are also a couple of videos on youtube: https://www.youtube.com/watch?v=KgssW9TJ5-I

[MysteryX]

and now you'll want me to test my script on THAT video!??

[burfadel]

Now that there are a whole lot more permissable block sizes, are any of these useful for this script? The 64x64 would be beneficial for >HD material, I can imagine 48x48, 32x32 etc being good for lower resolutions (such as HD as 32!).

The other point of interest are block sizes like 32x16. I was thinking that maybe these odd block sizes could be beneficial. Most video movement is horizontal in nature, with much less vertical movement. If the normal system is 16x16 then 8x8, woudn't 24x12, 16x8, and maybe another recalculate step (just recalculates detected bad vectors from the first two) with 12x6? Obviously if autosetting if you are encoding 3840x2160 you might want it to autoselect 64x32 for example?

[MysteryX]

Please play around with block sizes and see if there are cases where you get better results with non-square blocks.

Also test which block size works best for various video sizes.

This will help me tweak the script. Meanwhile, I got other things to test.

[kolak]

Now that there are a whole lot more permissable block sizes, are any of these useful for this script? The 64x64 would be beneficial for >HD material, I can imagine 48x48, 32x32 etc being good for lower resolutions (such as HD as 32!).

The other point of interest are block sizes like 32x16. I was thinking that maybe these odd block sizes could be beneficial. Most video movement is horizontal in nature, with much less vertical movement. If the normal system is 16x16 then 8x8, woudn't 24x12, 16x8, and maybe another recalculate step (just recalculates detected bad vectors from the first two) with 12x6? Obviously if autosetting if you are encoding 3840x2160 you might want it to autoselect 64x32 for example?

I asked for this and it was implemented by jackoneill in mvtools for vapoursynth (looks like there may be some issues with parameters scaling to block size).

[MysteryX]

If you want to test various block sizes, disable artifact masking and look at the raw interpolation only. Set Output="flow".

There is still a mask strength discrepancy between block sizes, and if we do non-square sizes, it will make it more complex to sort this one out.

Perhaps it would help to understand exactly the cause of this difference, and what kind of mathematical relationship there is.

[MysteryX]

Alpha Release: 2017-05-16 (https://github.com/mysteryx93/FrameRateConverter/releases/tag/v0.1-alpha)

I think I did a good job at normalizing the masks per block size.

StripeMask also is working. I've done a lot of changes, so here's a version you guys can play with. You'll need both the DLL and the AVSI. Pinterf's latest MvTools2 is highly recommended. If there are mask discrepancy problems, manually adjust MaskTrh and SkipTrh.

https://github.com/mysteryx93/FrameRateConverter/releases

I think everything should be good as it is. The one setting that will require testing is MaskTrh. A lower value will result in larger artifact masks, and a higher value will keep more interpolated images. I've put a default of 140 but haven't tested it much. Try with other values and report what value works best for your content.

To test, what I generally do is open various VirtualDub windows. I set the script to MaskTrh=120, open in VirtualDub, then MaskTrh=130, open in VirtualDub, then MaskTrh=140, open in VirtualDub, etc. to have 5 or 6 versions to compare. I place all instances at the same frame, then switch between them to see which one looks better on difficult areas.

If you set BlkSizeV to a different value than BlkSize, for now I'm only using BlkSize for normalization so you may have to adjust MaskTrh and SkipTrh manually for the difference. Larger block sizes result in a slightly stronger mask and require higher thresholds. By default, BlkSizeV>BlkSize will result in stronger artifact detection and BlkSize<BlkSizeV will result in weaker artifact detection, but the difference shouldn't be much.

This code can work in MT mode when debug=false.

StripeMask currently only supports 8-bit and isn't optimized, but it works.

[manolito]

Wanted to test this new Alpha, but I can't... :devil:

The framerateconverter.dll crashes, probably because it requires a CPU with SSE2 support, which I do not have.

Commenting out the ConditionalReaderMT calls and the call for stripemask fixes it, but where's the fun without the stripe mask? I tried to compile a stripemask.dll myself (using the DigitalMars compiler), but this was unsuccessful.

Whatever, unless you can compile the DLL without the need for SSE2 I will be outta here...


Cheers
manolito

[MysteryX]

StripeMask has no ASM code. Did ConditionalMT work for you before? It's the same, and can be replaced easily.

[Sharc]

I think I did a good job .....
You really did! Thanks for all your efforts and sharing your results :)

I will upload some test results for various MaskTrh later today ....

[Sharc]

Here some first results for various MaskTrh settings, for comparison. All other parameters = default.
(The original source has been provided by Selur)

http://www.mediafire.com/file/3d7x9y562jfbfru/FRC.mkv

[manolito]

StripeMask has no ASM code. Did ConditionalMT work for you before? It's the same, and can be replaced easily.

I redid the tests several times, but it is clearly the "FrameRateConverter.dll" which is not working on my system...

The ConditionalFilterMT never worked on my computer, and I never expected it to work since my CPU is single threaded. Thankfully the AVSI contains a workaround (comment out 2 lines, uncomment the following lines) which I have always used successfully.

Alright, here is the detailed report:

I used Groucho's STR test clip (the Japanese girl with the striped stockings). This is the AVS script:
video = DSS2("F:\Download\str.mpg", fps=25.000, preroll=15)
audio = DirectShowSource("F:\Download\str.mpg", video=false)
AudioDub(video, audio)
Crop(0,0,-Width % 8,-Height % 8)
ConvertToYV12()
framerateconverter(NewNum = 50, NewDen = 1)

With the untouched "FrameRateConverter.avsi" I get this error:
Avisynth open failure:
Evaluate: System exception - Illegal instruction
The error occurs at line #160 of the AVSI, this is the first call to "ConditionalFilterMT".

After commenting out "ConditionalFilterMT" I get this error message:
CAVIStreamSynth:
System exception - Illegal instruction at 0x4b860c4

Then I commented out lines 139 and 140 which disables the stripe mask, and after this the conversion went without problems.

(The funny thing is that this conversion gave good results, and it was quite a bit faster than the previous version which did not have the stripe mask yet).


This is my system setup:
Intel Coppermine CPU, single threaded, MMX and SSE, no SSE2 and above
Win XP SP3
AviSynth 2.60
MVTools 2.5.11.22 (latest Fizick release)
MaskTools 2.0a48
RemoveGrain 1.0b by Kassandro (non-SSE2 version)

All these plugin versions are the latest which work on my machine, and I use them for a couple of other plugins where they have always worked flawlessly.


So I am quite sure that your FrameRateConverter.dll is to blame. Probably the newer compilers always optimize for SSE2 unless you tell them not to do this...


Cheers
manolito

[MysteryX]

do you have Visual C++ Runtime 2017 installed?

It has no ASM code and is compiled with WinXP support.

[MysteryX]

I have added Preset="slower" and I think you'll be pleased with the results

https://github.com/mysteryx93/FrameRateConverter/blob/master/FrameRateConverter.avsi

Frame 644: normal / slow / slower, output="flow" (no artifact masking)
https://s16.postimg.org/q3iy81tmp/644-normal.png (https://postimg.org/image/q3iy81tmp/) https://s16.postimg.org/syw1ewxmp/644-slow.png (https://postimg.org/image/syw1ewxmp/) https://s16.postimg.org/5lxzwehj5/644-slower.png (https://postimg.org/image/5lxzwehj5/)

Normal: DCT=0
Slow: DCT=1
Slower: Both DCT=1 and DCT=0, and take from DCT=0 the areas where the mask is better

[MysteryX]

I updated the code again. Replaced preset="slower" with DiffBlkSize and DiffBlkSizeV
https://github.com/mysteryx93/FrameRateConverter/blob/master/FrameRateConverter.avsi

To achieve the same result as
blksize=8, preset="slower"
use this
blksize=8, preset="slow", diffblksize=8

Now you can try with all kinds of other block sizes, such as "blksize=8, diffblksize=12" or "blksize=16, diffblksize=24"

Now that mask strengths are normalized I'm able to compare various masks, but I'm not getting as consistent results with different block sizes as with comparing DCT=1 and DCT=0.

Yet, it gives a lot more options and possibilities to play with. You can try "blksize=8, dct=1" and "blksize=12" as fallback, or you can try "blksize=12, dct=1" and "blksize=8" as fallback.

Or maybe I'll go back to preset="slower" to simplify. Play with it and see what works for you.

Also added output="diff" to see the areas affected by the diff.

Now john you can spend a few hours testing the whole thing

[manolito]

do you have Visual C++ Runtime 2017 installed?

It has no ASM code and is compiled with WinXP support.

No, the latest VC++ Runtime I had installed was 2015. But after your post I did upgrade to the latest 2017 version, without success though. The error messages stayed exactly the same.

[MysteryX]

Manolito, I have no idea then. Perhaps someone else has an idea.

You can get the latest script here (https://github.com/mysteryx93/FrameRateConverter/blob/master/FrameRateConverter.avsi)

- Slightly increased MaskTrh from 140 to 150

- Re-added Preset="slower", results are truly impressive

- You can still perform a diff mask with other block sizes with DiffBlkSize and DiffBlkSizeV. With preset="slower", it default to same block size.

[noisyfart]

Manolito, I have no idea then. Perhaps someone else has an idea.A quick look at the documentation (https://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx) might help. If "-arch" is not specified, it defaults to SSE2.

[MysteryX]

A quick look at the documentation (https://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx) might help. If "-arch" is not specified, it defaults to SSE2.

ok, try this version (https://mega.nz/#!jdoGBB5D!n9_tWPd5YhfoyHrueszaPq89pcXyawSlnwhezaPBBjc)

[manolito]

Thanks so much, also to noisyfart... :thanks:

This version works perfectly, even with the VC++ Runtime 2015. Both ConditionalFilterMT and the stripe mask work now.


But I got another problem with my older MaskTools 2.0a48. The last line in the CalcDiff section:
EM = CalcDiff ? mt_merge(EM, EM2, EMdiff, luma=true, chroma="process") : EM

throws this error message:
[avisynth @ 0335ea20] mt_merge : "luma" is unsupported in 422 and 444

My source file is 420, but it looks like one of the mt_merge input masks have become 422 or 444. I got it working by removing the "luma=true" param, but the result might not be what you intended...


Cheers
manolito

[MysteryX]

It may not recognize the mask in Y8 format and expects a YV12 mask. Try to convert the mask to YV12. Do that for other MT_Merge(s) as well.

[Sharc]

- You can still perform a diff mask with other block sizes with DiffBlkSize and DiffBlkSizeV. With preset="slower", it default to same block size.
Does preset="slower" overrule any DiffBlkSize settings? Means when I want to specify DiffBlkSize and DiffBlkSizeV I must not use any of the presets?

[MysteryX]

Look at the script how parameters are handled. But basically, it calculates 2nd version if Preset=slower or DiffBlkSize is specified.

Then if we calculate 2nd version, if DiffBlkSize isn't specified, it defaults to BlkSize.

[Sharc]

Ah it's clear now. Thanks.

[nhope]

I did some testing of MysteryX's 18th May FrameRateConverter vs jm_fps.avsi in manolito's post (https://forum.doom9.org/showthread.php?p=1800439#post1800439), converting the 50p 1080p file linked to here (https://www.vegascreativesoftware.info/us/forum/50-to-60p-for-3d--106617/#ca660294) to 59.94p. So this sort of line:

FrameRateConverter(NewNum=60000, NewDen=1001, Preset="medium", MaskTrh=140)

With Preset="medium" and MaskTrh=120, 140 or 160, the render was very fast and the picture was identical to jm_fps.avsi except for some interpolation artefacts along the left hand edge.

With Preset="slower" and MaskTrh=150 it was extremely slow and hung after 98 frames. That may have been down to my SetMemoryMax and MT settings which I left at the same as I had optimised for previous MFlowFps scripts (SetMemoryMax(3072), Prefetch(12)).

With Preset="slow" and MaskTrh=150 it was still very slow and still getting artefacts down the left hand edge. It also made a few changes to other parts of the image (compared to Preset="normal" or jm_fps.avsi) but unfortunately mostly for the worse.

[MysteryX]

Make sure to preview with output="mask", or with output="over" debug=true to see where it's detecting artifacts and whether the masks are accurate.

Also, this version of StripeMask doesn't currently work in MT; there was a bug I couldn't figure out and the temporary work-around isn't MT-compatible.

12 threads with DCT=1? That can definitely bring a memory issue.

To be clear, under normal preset, it's designed to give the exact same output as jm_fps except in areas of bad artifacts where it falls back to frame blending, and on bad frames that it either skips or blends.

[manolito]

It may not recognize the mask in Y8 format and expects a YV12 mask. Try to convert the mask to YV12. Do that for other MT_Merge(s) as well.

Yes, that's the problem. I tried all the newer MaskTools versions by tp and pinterf, but none of them runs on my machine...

I modified the script like this:
EM = CalcDiff ? EM.ConvertToYV12() : EM
EM2 = CalcDiff ? EM2.ConvertToYV12() : EM2
Flow = CalcDiff ? mt_merge(Flow, Flow2, EMdiff, luma=true, chroma="process") : Flow
EM = CalcDiff ? mt_merge(EM, EM2, EMdiff, luma=true, chroma="process").ConvertToY8() : EM

Does this look correct to you?
Flow and Flow2 are already YV12 so I think I do not need to convert them. And for EMdiff I was not sure if it was YV12 or Y8. I left it alone and it seems to work.


Cheers
manolito

[MysteryX]

I believe you only need to call ConvertToY12() on the 3rd argument of MT_Merge -- unless your version doesn't recognize Y8 *at all*, in which case anything passed to it must be in YV12.

Or simply remove any mention to Y8 conversion, as the masks returned by default are in YV12 format -- except StripeMask which returns in Y8.

[manolito]

No, the third argument for mt_merge is EMdiff, and it does not matter if I convert EMdiff to YV12 or not. I do not really understand how EMdiff is created, but I suppose that it already is YV12. (Is there a way in AviSynth to inspect variable properties at a certain point in the script?)

//EDIT//
but I suppose that it already is YV12
No, it isn't...
Flow and Flow2 are YV12, EM, EM2 and EMdiff are all Y8.
The old mt_merge function seems to have no problem with EMdiff being Y8, but it sure wants the first 2 arguments to be YV12.
//END EDIT//


The culprit for the luma error are EM and EM2, they need to be YV12.


During my tests I found some other interesting things (I used johnmeyer's Parade clip):

1. Commenting out the ConditionalFilterMT lines and using the GScript based lines instead gave very different results. The moose scene had the interpolated frames with ConditionalFilterMT, using the GrunT alternative the moose scene was blended (which looks better).

2. For this clip using the stripe mask introduced some very juddery movement. Commenting out the two lines where the stripe mask is invoked gave a much much better result.

For my tests I used Preset = "slower", all other settings were at their defaults.


Cheers
manolito

[MysteryX]

The culprit for the luma error are EM and EM2, they need to be YV12.
Duh! "luma" makes no sense for a Y8 clip; the error is correct. Luma is to apply the Luma part of the mask to both luma and chroma planes. In this case it makes no sense. You can safely remove "luma".


1. Commenting out the ConditionalFilterMT lines and using the GScript based lines instead gave very different results. The moose scene had the interpolated frames with ConditionalFilterMT, using the GrunT alternative the moose scene was blended (which looks better).
Moose scene should be blended or skipped. When you put Debug=true, what is the Skip value of those frames?

2. For this clip using the stripe mask introduced some very juddery movement. Commenting out the two lines where the stripe mask is invoked gave a much much better result.
Where?

[raffriff42]

manolito, testing on my end with older plugins (but running AVS+), these changes allowed the script to work (Version 16-May-2017)
* source clip must be YV12;
* in script, replace all ConvertToY8 with ConvertToYV12;
* in script, replace both ConditionalFilterMT's with ConditionalFilter;
* in script, delete all "overlap=..." (accepting default overlap values)

[manolito]

Alright, some tests are here:
https://www.sendspace.com/file/9nmqry

I do not really know what to make of them...

Test setup:
Source is johnmeyer's Parade clip. Latest FrameRateConverter script. Used Preset = "slower" and block size 16 (IMO looks better for 720x480 sources than a block size of 8). Otherwise all default params.


I created three test conversions:

1. Using the stripe mask and the ConditionalFilterMT function. Sorry but for this conversion I forgot to turn on debugging. But for the moose scene it is quite obvious that there is no blending or skipping, the interpolated frames are used. Looks bad...

2. Using the stripe mask, but disabled ConditionalFilterMT and used the GRunT based alternative instead. The moose scene is now mainly blended (as it should), but there are ugly motion artifacts. This one looks really bad...

3. Disabled the stripe mask and the ConditionalFilterMT function (removed the FrameRateConverter.dll file from my AviSynth\plugins folder). IMO this conversion beats the other ones by a huge margin.


Cheers
manolito

[manolito]

@ raffriff42

Thanks for the tips, will test...

But I believe that most of my old plugins do not need this treatment (using plain vanilla AviSynth 2.60).

My version of MaskTools (mt_masktools-26.dll) supports the new AVS 2.60 color spaces quite well, Y8 is no problem.

The MysteryX script already contains an alternative method for ConditionalFilterMT (based on GRunT) which seems to work better.

And Fizick's latest version of MVTools2 has no problem using custom values for Overlap.


Cheers
manolito

[MysteryX]

The parade clip is the one I used for testing and tweaking. If it's not using blending on the moose scene, then your script isn't running right.

I also set it to 8 for 480 specifically because I'm getting better results on that specific clip with 8 than with 16. Generally, lower gives better results but also more artifacts. So for 1080p, we have the choice between 16, 24 and 32. 16 is generally the best choice -- except for anime.

[manolito]

The parade clip is the one I used for testing and tweaking. If it's not using blending on the moose scene, then your script isn't running right.

That's what I thought, but I could not find anything on my side... :scared:

Here is a new set of tests, this time using Preset = "normal". I can confirm that the CalcDiff routine has nothing to do with these issues.
https://www.sendspace.com/file/41ntzd

What I did:
Downloaded the latest version of the script from 18-May-2017.
Modified the script in 2 places. I removed "luma=true" from the last mt_merge line, and I changed the default block size for 720x480 from 8 to 16 (still like it better this way).

I had to use older versions of MVTools2 and MaskTools2, plus I needed to use the special Non-SSE2 version of FrameRateConverter.dll.


My observations:
1. When using ConditionalFilterMT (lines 207 and 208) as in conversions #1 and #4 then the moose scene gets weird. The debug output says "blend", but the frames sure do not look blended. The horns are flapping badly making the scene look horrible.
2. Conversion #2 puzzles me the most. That's the one using the stripe mask, but not ConditionalFilterMT. The moose scene looks alright, but the marching guys in the red uniforms have blending all over the place, and this blending occurs at all the wrong positions. Very weird...
3. Conversion #3 still looks best to my eyes. Only the moose scene is blended, the other scenes look good without blending. How could disabling the stripe mask (commenting out lines 186 and 187) change the result so massively?


What could be the reason for these issues? Is the Non-SSE2 version of the DLL not working correctly?


Cheers
manolito

[MysteryX]

The clip actually looks best with BlkSize=12, but you can't use that with the old MvTools2. If you use BlkSize=16, however, the artifact mask is much stronger and a lot of parade frames are being blended, so you'd have to set BlendOver to 60 instead of 50.

If the masks are showing up all at the wrong places, it's generally that the mask hasn't been converted to the destination frame rate -- and the 2nd half of the clip then has no mask at all.