Moire Effect & TFM(pp=0) Solution

[Danette]

I have DVD-sourced videos that, even in their source format, exhibit moire effect on tight patterns, such as checked coats.

Using TFM(pp=0), this effect is nearly eliminated.

My question, after searching extensively, is: what is the downside in using the pp=0 setting? The default setting is pp=6. I almost wonder why pp=0 isn't the default.

[poisondeathray]

If they had moire "even in their source format" on those patterns , but not with TFM(pp=0), it means whatever you're using to view the DVD is also applying a deinterlace on that section (instead of only field matching, decimation)

pp=6 is the default to treat residual combing. Combing is common for some sources, especially hard telecined older ones (orphaned fields from edits on in interlace timeline, interlaced fades). TFM pp=6 applies a simple cubic deinterlace (essentially resizing a field) when combing is detected. A single field resize causes that moire pattern - you only have 1/2 the spatial information. You can change what deinterlace is used with clip2 (but any deinterlace will be worse than if the "partner" field pair is available) , or the detection thresholds (unlikely to get a setting that will ignore this problem automatically), or set manual overrides

lines, moire patterns are often detected false positives, because they "look" like combing to an algorithm . The downside of pp=0 is residual detected combed frames are not processed. Maybe one day there will be some smart "AI" program that is able to accurately distinguish between them... but not today.

[Danette]

Thanks.

If they had moire "even in their source format" on those patterns , but not with TFM(pp=0), it means whatever you're using to view the DVD is also applying a deinterlace on that section (instead of only field matching, decimation).

I’ve watched this video in VDub2, AvsPMod and MPC-HC and all three show the moire effect prior to any processing, but not after applying pp=0. Are you saying that it could be the various monitors that have an interlace function built in? My TV also shows this difference.

The downside of pp=0 is residual detected combed frames are not processed.

Are you aware of any script that can analyze a file to identify any residual combed frames? This would be after processing the file with pp=0.

[poisondeathray]

I’ve watched this video in VDub2, AvsPMod and MPC-HC and all three show the moire effect prior to any processing, but not after applying pp=0. Are you saying that it could be the various monitors that have an interlace function built in? My TV also shows this difference.


A display can have processing built in, but usually not a computer monitor.

But how did you open it ? Vdub2/AvspMod/MPCHC with what source filter ? What input driver ? There might be additional processing that you are not aware of

Or, if you're using MPEG2Source (DGIndex) only , with honor pulldown flags, there is no processing at all. If there is moire before TFM(pp=0) , but not after using TFM(pp=0) where it becomes completely clean - it suggests the fields were not matched or out of phase (top field and it's "partner" bottom field are not aligned on the same frame) .



Are you aware of any script that can analyze a file to identify any residual combed frames? This would be after processing the file with pp=0.

There are various comb detection scripts, some are motion adaptive , some are masks to be used with other functions. None of them are "perfect" . eg. tcombmask, combmask, dcomb (iscombed) ,...a few others

For very fine residual combing, there are also non selective "brute force" approaches which do not degrade the image that much, such as vinverse, vinverse2

[Danette]

But how did you open it ? Vdub2/AvspMod/MPCHC with what source filter ? What input driver ? There might be additional processing that you are not aware of

Or, if you're using MPEG2Source (DGIndex) only , with honor pulldown flags, there is no processing at all. If there is moire before TFM(pp=0) , but not after using TFM(pp=0) where it becomes completely clean - it suggests the fields were not matched or out of phase (top field and it's "partner" bottom field are not aligned on the same frame) .

Well, just focusing on AvsPMod, I used the d2v file and DGI is set to honor pulldown flags. If there is a way to test to see if the fields are out of phase, let me know. They are TFF and so is the script.

For very fine residual combing, there are also non selective "brute force" approaches which do not degrade the image that much, such as vinverse, vinverse2

Perhaps adding one of these, when using pp=0, is the best clean-up approach. However, I have watched a few of the shows with the pp=0 and I donÂ’t notice any deficiencies in them, other than the moire effect being gone.

[johnmeyer]

Since when does interlacing have anything to do with moiré? Moiréis an interference pattern, and can be caused by many different things. The only thing you get when interlaced material is shown on a progressive display is "teeth" and those only show up when there is a lot of motion. By contrast, moiré happens even with nothing is moving.

A clip would make it a lot easier to know what it really going on.

[poisondeathray]

Since when does interlacing have anything to do with moiré? Moiréis an interference pattern, and can be caused by many different things. The only thing you get when interlaced material is shown on a progressive display is "teeth" and those only show up when there is a lot of motion. By contrast, moiré happens even with nothing is moving.

A clip would make it a lot easier to know what it really going on.

DEinterlacing , such as when TFM detects combing and applies deinterlacing - has a lot to do generating moire patterns

When you deinterlace (in this context meaning interpolation of a single field , such as resizing to a full frame) , a fine pattern like checker cloth, grids, it generates moire patterns. Simple interpolation like cubic resizing is prone to generating more severe patterns than other deinterlacers



Well, just focusing on AvsPMod, I used the d2v file and DGI is set to honor pulldown flags. If there is a way to test to see if the fields are out of phase, let me know. They are TFF and so is the script.


You separatefields() and look for field pairs that belong to the same progressive frame . TFM(pp=0) should align them if they are out of phase . TFM() default settings will also align them but also apply pp=6 deinterlacing if combing is detected as discussed above. So a false positive like checkered clothing is the prototypical example, or horizontal blinds, some type so fabrics, clothing etc.... and it will flare up with bad moire patterns. You can change clip2 to QTGMC, but it's still less ideal if it's not really interlaced (false positive fabric pattern)


Perhaps adding one of these, when using pp=0, is the best clean-up approach. However, I have watched a few of the shows with the pp=0 and I donÂ’t notice any deficiencies in them, other than the moire effect being gone.

The DVD's where you will often have problems are older DVD's many types of anime, ones that have been edited on an interlaced timeline (instead of removing pulldown or on a progressive timeline) , or some TV shows that have been edited.

[johnmeyer]

OK, I can see how deinterlacing would create moiré patterns. I guess I thought the OP was talking about interlaced video from a DVD.

[Danette]

DEinterlacing , such as when TFM detects combing and applies deinterlacing - has a lot to do generating moire patterns

A clip would make it a lot easier to know what it really going on.

If you are interested, here is a sample from the source file:

https://www.mediafire.com/file/48ryrqvdwwnskdj/Moire_Test.m2v/file

Pay attention to the jacket worn by the older man.

[poisondeathray]

It's not completely clean to leave pp=0 on that clip

at ~11.5-12.5 seconds there are about 6-7 frames few frames TFM gets wrong. The guy in the background is combed, it's easy to see because he's in motion. There is actually no problem in the fields (it's all perfect 3:2), it's just a result of a bad TFM match. Some of them get fixed slow=2, but not all. There might be other settings you can tweak to get it right , I didn't spend much time playing with them

This is an example where default adaptive TIVTC shoots you in the foot, probably because of the foreground patterns. A manual, set cycle, gets this perfect. But you'd have to check other segments, in case the cadence was broken


MPEG2Source()

manualIVTC(last,2)

function manualIVTC(clip v, int p)
{
v=loop(v, p, 0,0)
v=v.SeparateFields().SelectEvery(10, 0,1, 2,3, 5,6, 7,8).Weave()
v=trim(v,int(p*3/5),0)

return v.assumeFPS(24000,1001)
}

[johnmeyer]

If you are interested, here is a sample from the source file:

https://www.mediafire.com/file/48ryrqvdwwnskdj/Moire_Test.m2v/file

Pay attention to the jacket worn by the older man.As I expected, the moiréis in the video and has nothing to do with interlacing or deinterlacing. Here is one field (not frame) showing the moiré on Ray Walston's jacket:

https://i.imgur.com/iXhjdVe.png

Since it is a single field, the moiré is not caused by any interaction between fields.

"My Favorite Martian" was shot on 35mm film and then telecined when shown on TV. It did NOT originate on video and therefore interlacing doesn't enter into the equation.

The DVD you took this from either has that telecine "baked in" or when you extracted it from the DVD, the software didn't ignore the pulldown flag. If you want to do anything further you should remove the pulldown using TFM/TDecimate.

Either way, I'm pretty sure that TFM and its various pp modes have nothing to do with solving the problem and there is nothing you can do about this other than to find a better source. This probably happened during the scan of the film because moiré happens when you get beats between fine repetitive patters and the spacing of the scan lines or the "distance" between adjacent pixels.

"My Favorite Martian" is available for streaming via Amazon Prime or IMDB, with commercials. A quick search reveals that you may be able to get it via other streaming options. I think Hulu has it for free.

[poisondeathray]

TFM deinterlacing has everything to do with worsening moire patterns. The OP said when PP=0, the effect is nearly eliminated

When you deinterlace , instead of field matching, when a match is available = bad (!)

If you examine the clip with TFM(display=true) , vs TFM(pp=0, display=true) , it should be clear what is being discussed in this thread

TFM(display=true)
https://i.postimg.cc/KzT1gbQt/tfm-display-true.png (https://postimages.org/)

TFM(pp=0, display=true)
https://i.postimg.cc/2yF32xs6/tfm-pp-0-display-true.png (https://postimages.org/)

[Danette]

This is the script that I've been using:

AssumeTFF()
TFM(pp=0,slow=2)
TDecimate()
QTGMC(InputType=1,Preset="Medium",EZDenoise=0)
LimitedSharpenFaster(strength=200)
Lanczos4Resize(640,480)

In fact, it is what I use on nearly all backups, with minor variations, e.g.; sometimes decimation is not needed, sharpening and denoising varies.

As poisondeathray mentioned, pp=0 dramatically reduces the moire effect.

It's not completely clean to leave pp=0 on that clip

In this case, as you mentioned, would adding vinverse or vinverse2 clean it up?

[johnmeyer]

OK, I IVTC'd it and used pp=0 for TFM. That makes most of the frames look good.

I don't want to get tied up in semantics (what is interlacing vs. what is telecine).

The PP value being used is a red herring. The post processing is not what is eliminating the artifact. Instead, the trick is getting the matching to work every time. For instance, this produces a slightly better result than TFM(pp=0)/TDecimate:

TFM(pp=6,mode=2,cthresh=50,mChroma = false,MI=150,blocky=8,blockx=8)
TDecimate()

The pp value makes no difference. Mode and the threshold settings determine the goodness of the output. I was not able, in a limited time, to tune the script, and I expect that you'll have to feed it manual overrides.

[edit]Why are you using QTGMC? For noise reduction? The clip is progressive after it goes through TDecimate, so deinterlacing is not needed.

[poisondeathray]

In this case, as you mentioned, would adding vinverse or vinverse2 clean it up?

I would not. The problem in this case is the field matching - it's matching the wrong fields , so there is combing. Vinverse/2 or QTGMC or anything is always going to worsen the moire patterns and soften other parts of the image. TFM trying to be too smart, but this clip is perfect 3:2 cadence. See post #10, that's a perfect IVTC (the last frame isn't because of the way the sample is cut)

Usually the best solution (for anything) is to fix the actual underlying problem

There might be some TFM settings to fix everything, I didn't have time to play with it)

[poisondeathray]

The PP value being used is a red herring. The post processing is not what is eliminating the artifact. Instead, the trick is getting the matching to work every time. For instance, this produces a slightly better result than TFM(pp=0)/TDecimate:

TFM(pp=6,mode=2,cthresh=50,mChroma = false,MI=150,blocky=8,blockx=8)
TDecimate()

The pp value makes no difference. Mode and the threshold settings determine the goodness of the output. I was not able, in a limited time, to tune the script, and I expect that you'll have to feed it manual overrides.


The reason this is a slight improvement is a cthresh of 50 essentially means pp=0 . The threshold is so high, that it never deinterlaces. Remember, the default cthresh is 9

The end result is that same bunch of combed frames (around ~10-13 see) mentioned above get passed through , and the moire is worsened on those frames because of the wrong matches

This clip is solvable without those problems, see post #10. But non adaptive IVTC is potentially "dangerous" . The OP has to check that the cadence is not disrupted in other parts

[Danette]

OK, I IVTC'd it and used pp=0 for TFM. That makes most of the frames look good.

I don't want to get tied up in semantics (what is interlacing vs. what is telecine).

The PP value being used is a red herring. The post processing is not what is eliminating the artifact. Instead, the trick is getting the matching to work every time. For instance, this produces a slightly better result than TFM(pp=0)/TDecimate:

TFM(pp=6,mode=2,cthresh=50,mChroma = false,MI=150,blocky=8,blockx=8)
TDecimate()

The pp value makes no difference. Mode and the threshold settings determine the goodness of the output. I was not able, in a limited time, to tune the script, and I expect that you'll have to feed it manual overrides.

[edit]Why are you using QTGMC? For noise reduction? The clip is progressive after it goes through TDecimate, so deinterlacing is not needed.

Thanks, but I want to avoid fine-tuning to that level. I have ~100 episodes, so I need the one-size-fits-all aspect of the pp=0 (I can live with whatever the minor difference may be).

I use QTGMC, in this case, not for deinterlacing (thus the InputType=1). QTGMC does other beneficial things that helps me avoid more of that fine-tuning need.

[johnmeyer]

If mine works better, you should use it. Why wouldn't you use something that does a better job.

Your choice, of course.

[Danette]

If mine works better, you should use it. Why wouldn't you use something that does a better job.

When I compared the two, I could not see a difference.

[real.finder]

this method https://forum.doom9.org/showthread.php?t=176657 seems work

[Danette]

this method https://forum.doom9.org/showthread.php?t=176657 seems work

This did not do anything differently than the script I've been using. What is it that you think is different about it?

[poisondeathray]

This did not do anything differently than the script I've been using. What is it that you think is different about it?

No, it's different . It doesn't have the wrong matches like TFM, so it has less moire and combing and is much cleaner. Any post processing - even QTGMC in progressive mode - will worsen the moire patterns compared to pp=0, and much worse compared to a clean IVTC

That method produces perfect results like the function in post #10, it's 100% clean. But both those methods will fail if the cadence is interrupted, such as edits while still interlaced - there will sections where lots of frames are combed because it's out of phase

If you can't see the difference, interleave the results, or compare in avspmod tabs. Very different

[Frank62]

As I often said: I'd prefer the solution "by hand". You can use it adapted to the three possible patterns in this case. Usually one episode can be fixed with three or four pattern changes - if very much more, of course, not.
Or the best way: You buy the 100% Pulldown-free PAL-DVDs we released about two years ago. :)

[Danette]

No, it's different . It doesn't have the wrong matches like TFM, so it has less moire and combing and is much cleaner. Any post processing - even QTGMC in progressive mode - will worsen the moire patterns compared to pp=0, and much worse compared to a clean IVTC

That method produces perfect results like the function in post #10, it's 100% clean. But both those methods will fail if the cadence is interrupted, such as edits while still interlaced - there will sections where lots of frames are combed because it's out of phase

If you can't see the difference, interleave the results, or compare in avspmod tabs. Very different

Since I can’t see the difference (although I will scrutinize it more, later), and since there seems to be no downside to it, I will take your word that it is better than TFM. Can it be used interchangeably with TFM on all interlaced material, i.e.; is it superior to TFM or, at least, no worse?

[poisondeathray]

Since I can’t see the difference (although I will scrutinize it more, later), and since there seems to be no downside to it, I will take your word that it is better than TFM. Can it be used interchangeably with TFM on all interlaced material, i.e.; is it superior to TFM or, at least, no worse?

The bad frames just jump out at you. Some are as bad as the screenshot in the earlier post with deinterlacing. TFM bad matches are when the top field from one frame is matched with the bottom field of another frame. Instead of returning the original film frame (both fields from the same frame) . That wrong matching manifests/appears as combing, and if there is significant motion between the frames, such as when the suit guy is moving, they manifest as terrible moire patterns

Adding QTGMC in progressive mode makes almost every frame look worse with the suit pattern (degrading all the frames, even the previously clean ones TFM got right), everything is softer and no amount of added sharpening can return the lost details

I already mentioned the downsides - potentially it's very dangerous because those two approaches are not adaptive. The 2nd one is slightly adaptive (in that you don't have to choose the part of the cycle), but can still return the wrong matches for a changing or interrupted cycle. For someone that doesn't want to overlook things , possibly fix the phase for a certain segment, it's like playing with fire. But if all your DVD's are perfect 3:2, no breaks, then yes it will work and perfectly if it's the same phase everywhere. If it's any of the types of DVD's mentioned earlier, it's problematic

[VoodooFX]

What if for pp you run QTGMC to eliminate that residual combing, using conditional with something like qCombed (http://forum.doom9.net/showthread.php?p=1776501) or IsCombed to heal only combed frames.

[johnmeyer]

The bad frames just jump out at you. Some are as bad as the screenshot in the earlier post with deinterlacing. TFM bad matches are when the top field from one frame is matched with the bottom field of another frame. Instead of returning the original film frame (both fields from the same frame) . That wrong matching manifests/appears as combing, and if there is significant motion between the frames, such as when the suit guy is moving, they manifest as terrible moire patterns<snip>I'm now totally on the same page as you. Thanks for the education.

Once I understood that the artifact happend because of bad matching, I realized that you have to either tune TFM, or find another approach. It will be really interesting if Katie's work finally finds a use.

[real.finder]

and since it black and white film, it's better and faster to use Converttoy8/Converttoy

also I already made Katie method as function KGIVTC() in AnimeIVTC.avsi if someone care

[Danette]

I’ve scrutinized the differences and do agree that the clean Katie approach (removing my use of QTGMC) seems perfect on that small sample I provided and also seems to do the same on the full episode.

The 2nd one is slightly adaptive (in that you don't have to choose the part of the cycle), but can still return the wrong matches for a changing or interrupted cycle. For someone that doesn't want to overlook things , possibly fix the phase for a certain segment, it's like playing with fire. But if all your DVD's are perfect 3:2, no breaks, then yes it will work and perfectly if it's the same phase everywhere. If it's any of the types of DVD's mentioned earlier, it's problematic

This causes some confusion for me:
- Which is the “2nd one” to which you refer, the Katie or pp=0?
- Is there some way to determine where or how many breaks occur in a 3:2 or if the cadence is interrupted?

I don’t want to have to nurse these 100 or so TV episodes, frame-by-frame, so I would opt for the process that would quickly identify which script (among pp=6, pp=0 or Katie method) would be most likely to deliver the better results.

Are you aware of any analysis tools, such as DGIndex summaries, GSpot, MediaInfo or ReStream, that are able to give a good indication of the “perfect 3:2”, interrupted cycle or some other measure that could be used to decide between Katie, pp=0 or pp=6?

and since it black and white film, it's better and faster to use Converttoy8/Converttoy

How would this be applied? I tried adding it to the Katie method, but TDecimate seems to not accept the colorspace. Is Converttoy8/Converttoy, essentially, the same as Greyscale()?

[real.finder]

How would this be applied? I tried adding it to the Katie method, but TDecimate seems to not accept the colorspace. Is Converttoy8/Converttoy, essentially, the same as Greyscale()?

you need to update tivtc https://github.com/pinterf/TIVTC/releases

[poisondeathray]

I’ve scrutinized the differences and do agree that the clean Katie approach (removing my use of QTGMC) seems perfect on that small sample I provided and also seems to do the same on the full episode.

Lucky you! :)


This causes some confusion for me:
- Which is the “2nd one” to which you refer, the Katie or pp=0?


The function in post #10 is the 1st with the strict cycle and phase, Katie's approach is the 2nd . They both give the same results on that sample (the 1st keeps the last extra frame, and it's combed, but it's because the way the sample was cut) . But if you try them on typical hard telecine DVD's with issues (e.g. any 90's TV shows DVD's, older anime DVD's), you're in trouble.


- Is there some way to determine where or how many breaks occur in a 3:2 or if the cadence is interrupted?

I don’t want to have to nurse these 100 or so TV episodes, frame-by-frame, so I would opt for the process that would quickly identify which script (among pp=6, pp=0 or Katie method) would be most likely to deliver the better results.


Not automatically; you have to choose based on the pros/cons .

If these specific DVD's are from the same series, same set, same studio, same transfer process - there is a higher probability that you could just set and forget if you've checked this one and it was ok (but then again, you said you couldn't see differences the first time, and yet there were major differences....)

If there are edits/ out of phase / not perfect cycle - you're in trouble and you will see combing artifacts (and if all your DVD's have guys with suits featuring fine patterns, moire too)

One way might be to run it, and run a combed detection script (either for fallback, or treatment) . But you run into the exact same fundamental problem - there is no way an algorithm can 100% accurately determine between "combing" and say horizontal patterns like window blinds, patterns on a suit in the year 2020. This is why TFM is getting the wrong matches in the first place (It's generally good overall, but that's why it has manual overrides). You need human eyes. (Maybe some advanced neural net or "AI" in the future)


Are you aware of any analysis tools, such as DGIndex summaries, GSpot, MediaInfo or ReStream, that are able to give a good indication of the “perfect 3:2”, interrupted cycle or some other measure that could be used to decide between Katie, pp=0 or pp=6?


Only when it's soft telecine. It will indicate 100% film and you can "force film". Not when it's hard telecine . There has to be some way to analyze the actual content accurately. ie. your eyes.

[hello_hello]

TFM works fine on the sample, as long as you don't let it de-interlace, disable MicMatching, and restrict it to only using the top 140 lines of the frame for it's field matching decisions. :)

TFM(y0=140, y1=480, pp=0, micmatching=0)
TDecimate()

Why are you using QTGMC? For noise reduction? The clip is progressive after it goes through TDecimate, so deinterlacing is not needed.

He's running QTGMC in progressive mode. It can work very well as a denoiser, and can also be useful for stabilising the picture. It's not too often I encode a DVD without running QTGMC in progressive mode on it (assuming it's not interlaced). Unfortunately QTGMC isn't the right choice for denoising Uncle Martin's jacket though. Most denoisers probably aren't going to do well with it. TemporalDegrain tends to blur a bit where there's motion, but it doesn't do too badly with the jacket. Maybe someone else will have a better idea.

TFM(y0=140, y1=480, pp=1, micmatching=0)
TDecimate()
TemporalDeGrain()
GreyScale()
CropResize(0,0, 10,2,-10,-2, InDAR=15.0/11.0, ResizeWO=true)
Gradfun3()

https://i.ibb.co/xFsKWMK/Martian.png (https://ibb.co/jJ59mL9)

[StainlessS]

HH, have you tried SpotLess at all [just curious whether it would do any good].
(After un-moire, I have not looked at clip)

[hello_hello]

HH, have you tried SpotLess at all [just curious whether it would do any good].
(After un-moire, I have not looked at clip)

No I haven't. I'll check it out.

(I added a screenshot to my previous post)

[hello_hello]

This is the script that I've been using:

AssumeTFF()
TFM(pp=0,slow=2)
TDecimate()
QTGMC(InputType=1,Preset="Medium",EZDenoise=0)
LimitedSharpenFaster(strength=200)
Lanczos4Resize(640,480)

Nearly all 4:3 DVDs have an ITU or mpeg4 pixel aspect ratio.
(ITU and mpeg4 pixel aspect ratios are virtually the same, but the mpeg4 PAR's are easier to work with)

Pixel aspect ratios:
https://forum.doom9.org/showthread.php?p=1058927#post1058927

The mpeg4 display aspect ratio equivalents of 16:9 and 4:3, are 20:11 and 15:11, but if you crop 16 pixels from the width, what you're left with is exactly 16:9 or 4:3, so...

Crop(8,0,-8,0)
Lanczos4Resize(640,480)

The sample needs a couple more pixels cropped each side to make it clean, and because I'm OCD about the display aspect ratio being a minimum of 4:3, I cropped a couple of pixels top and bottom too for my previous screenshot. It'd be the equivalent of:

Crop(10,2,-10,-2)
Lanczos4Resize(636,476)

That's just me though.

Shameless plug:
CropResize (https://forum.doom9.org/showthread.php?t=176667)

CropResize(0,0, 10,2,-10,-2, InDAR=15.0/11.0, ResizeWO=true, Info=true)

https://i.ibb.co/DfbGd4g/Moire-Test-avs-snapshot.png (https://ibb.co/DfbGd4g)

[johnmeyer]

TFM works fine on the sample, as long as you don't let it de-interlace, disable MicMatching, and restrict it to only using the top 140 lines of the frame for it's field matching decisions. :)

TFM(y0=140, y1=480, pp=0, micmatching=0)
TDecimate()
Why didn't I play around with micmatching? I should have known better, but I guess it's been fifteen years since I did all the work with TFM and had to manipulate all the matching parameters in a spreadsheet.

As much as I like it that Katie's work finally found a home, I still think the OP is better off following hello^2' advice because, as we all know, the cadence is likely to change at some edit point, and then you need a tool which can adapt.

[poisondeathray]

Why didn't I play around with micmatching? I should have known better, but I guess it's been fifteen years since I did all the work with TFM and had to manipulate all the matching parameters in a spreadsheet.

As much as I like it that Katie's work finally found a home, I still think the OP is better off following hello^2' advice because, as we all know, the cadence is likely to change at some edit point, and then you need a tool which can adapt.

Disabling the micmatching is not doing the "heavy lifting" .

The reason that works is the lower ~3/4 of the image is not used for the 1st part of the metrics calculation because of the y0/y1 exclusion band. The reason why you have to disable micmatching in addition to the exclusion band - is the exclusion band does not actually bypass all checks.
See this for more info
https://forum.doom9.org/showthread.php?p=1913224#post1913224

If the suit guy moved to the top of the frame, camera tilted, etc.. , TFM would make the same types of mistakes. You'd have to animate the exclusion band somewhere else wherever the suit guy wasn't. Moreover, it's also potentially dangerous to field match based on the top 1/4 of the image only

[johnmeyer]

Disabling the micmatching is not doing the "heavy lifting" .

The reason that works is the lower ~3/4 of the image is not used for the 1st part of the metrics calculation because of the y0/y1 exclusion band. The reason why you have to disable micmatching in addition to the exclusion band - is the exclusion band does not actually bypass all checks.
See this for more info
https://forum.doom9.org/showthread.php?p=1913224#post1913224Interesting information about the exclusion band not bypassing all checks. I did not know that.

I did consider setting up an exclusion area, but didn't want to spend five minutes fiddling with the syntax, e.g., is the origin in the upper left or lower right; am I excluding things inside the box or outside the box, etc. I would eventually figure it out, but it was more time than I wanted to put into it.

[Danette]

After much back-and-forth experimenting with the above suggestions, it looks, to me, that the “TFM(y0=140, y1=480, pp=1, micmatching=0)” approach is superior in this case. I will probably be using it as the default for other DVD’s as well, unless I notice a problem. It seems that every approach is fraught with potential peril, leaving me with no highest-probability for avoiding problems.

I could not get the “Katie” method to work. It handled the moire effect well (not quite as good as aforementioned approach), but leaves what appears to be heavy interlace artifacts in many sections. If anyone wishes to address this, I’d be pleased to re-evaluate it. Examples are below.

Unfortunately, my normal use of QTGMC, in progressive mode, worsened the moire effect in all experiments. So, I’ll have to leave that out.

The script that seems most pleasing, to me, is:

TFM(y0=140,y1=480,pp=0,micmatching=0,slow=2)
TDecimate()
VagueDenoiser(chromaT=0)
KNLMeansCL(d=1,a=1,s=4,h=4)
LimitedSharpenFaster(strength=400)
Greyscale()
Lanczos4Resize(640,480)

Gradfun3()
Was this added because you found it useful in my particular case, or do you generally add it as a just-in-case tool?

Katie vs. TFM(y0=140,y1=480,pp=0,micmatching=0,slow=2) problem examples:

https://i.postimg.cc/QC3hJ2yB/Katie.jpg
https://i.postimg.cc/c4ddgN32/TFM.jpg

[johnmeyer]

The whole reason some of us weren't keen on Katie's approach is that it fails as soon as the pulldown cadence changes, which it often does at scene changes or cuts, if the video has been manipulated at some prior time. TFM/TDecimate is almost always the best way to go, although as this thread shows, getting it "tuned" can sometimes be a chore. Having said that, most of the time the defaults work fine.

[hello_hello]

The script that seems most pleasing, to me, is:

TFM(y0=140,y1=480,pp=0,micmatching=0,slow=2)
TDecimate()
VagueDenoiser(chromaT=0)
KNLMeansCL(d=1,a=1,s=4,h=4)
LimitedSharpenFaster(strength=400)
Greyscale()
Lanczos4Resize(640,480)

I still think the aspect ratio will be a little off if you don't crop.

Crop(8,0,-8,0)
Lanczos4Resize(640,480)

And if the only thing TFM has a problem with is that particular jacket, it'd consider splitting the episodes where he's wearing it and using TFM normally for the the scenes where he isn't. It's more work, but it's safer. Just make sure the Trim ranges are always multiples of five.
This sort of thing.

Trim(0,874).TFM(slow=2).TDecimate() ++ \
Trim(875,1289).TFM(y0=140,y1=480,pp=0,micmatching=0,slow=2).TDecimate() ++ \
Trim(1290,1574).TFM(slow=2).TDecimate() ++ \
Trim(1575,1834).TFM(y0=140,y1=480,pp=0,micmatching=0,slow=2).TDecimate() ++ \
Trim(1835,0).TFM(slow=2).TDecimate()

VagueDenoiser(chromaT=0)
KNLMeansCL(d=1,a=1,s=4,h=4)
LimitedSharpenFaster(strength=400)
Greyscale()
Crop(8,0,-8,0)
Lanczos4Resize(640,480)

Or you could IVTC first, and splice in the second TFM/IVTC where you see problems. Because the trims are post IVTC the frame numbers will be different, but I didn't bother changing them as I was just making up numbers anyway. It shouldn't be necessary to Trim in multiples of 5. Just switch between the two clips as required. Or add a third clip with different TFM settings or different IVTC if need be.

A = TFM(slow=2).TDecimate()
B = TFM(y0=140,y1=480,pp=0,micmatching=0,slow=2).TDecimate()

A.Trim(0,874) ++ \
B.Trim(875,1289) ++ \
A.Trim(1290,1574) ++ \
B.Trim(1575,1834) ++ \
A.Trim(1835,0)

VagueDenoiser(chromaT=0)
KNLMeansCL(d=1,a=1,s=4,h=4)
LimitedSharpenFaster(strength=400)
Greyscale()
Crop(8,0,-8,0)
Lanczos4Resize(640,480)

return A

# use return A to check the standard IVTC and find any problem frame ranges
# remove it to encode when you're done


Gradfun3()
Was this added because you found it useful in my particular case, or do you generally add it as a just-in-case tool?

I add it to the end of every script. It helps to prevent banding (https://en.wikipedia.org/wiki/Colour_banding) for 8 bit encoding by dithering. Noise naturally prevents banding, so noise removal can increase the likelihood of banding, and for B/W it can be even more likely as there's only luminance values. If there's enough noise left behind to prevent banding, and/or you're encoding at a very high quality, or using 10 bit h265 encoding, you probably won't need gradfun3.

Gradfun3 is part of the DitherTools package (http://avisynth.nl/index.php/Dither_tools).

[Frank62]

-Kathie's approach does work sometimes. As long as the frames (fields) to decimate are detected 100% correctly (which seems nearly impossible for a whole episode).
If not, there will be "interlacing" plus jerkyness. Late edits won't break Kathie's approach working well, the decimates MIGHT work before and after an edit well, maybe one frame keeps interlaced. But there will be scenes where decimation won't work 100%, as always, no matter how you set thresholds. You will have to change those and splice a lot of times.

-The TFM approach will work better, as always, because the probability is higher that fields are matched correctly first, and later decimation will also work better, than decimating fields before 100% correctly. But the jacket problem shows that also field matching can fail a lot. Ok, you can splice again, with different parameters, in this case not thresholds but exclusion areas like jackets. In the end there will still - as always - be some "interlaced" frames plus some dups left. About 3-10 per episode typically, with, without micmatching a. s. o.

-The by-hand solution is by far the best. You also will possibly have some splices to do by hand, but the result will be 100% clean, no mismatched fields, no dups, no jerkyness. We typically work about 5 minutes on an episode to find the right patterns (there are only three possible), that change 0-5 times typically per episode. Automatisms are good, when you HAVE to use them, if patterns change too often plus too many episodes.
So, where is the problem to use this approach?

[Danette]

-The TFM approach will work better, as always

Vs the Katie approach, this is what seems correct, to me, also.

The by-hand solution is by far the best. We typically work about 5 minutes on an episode

So, where is the problem to use this approach?

I think you hit on the answer to your question about "where is the problem" to using the by-hand solution. I acknowledge that it would be best, but 5 minutes per episode is 3 hours for a typical season and it is just too much time for too little benefit. I miss several frames every time I blink, so maybe the little combing that occurs will appear when my eyes are closed. Occasional combing is nothing as compared to the persistence and distraction of the moire effect.

[Frank62]

Of course your decision. I just wanted to point out that, IF you had to splice parts with different parameters of the two other solutions, THEN the by-hand solution would be the best by far.

[Danette]

Of course your decision. I just wanted to point out that, IF you had to splice parts with different parameters of the two other solutions, THEN the by-hand solution would be the best by far.

Yes, thank you for the better suggestion. It’s the time issue only, although the time issue may not be too big a problem because I believe this clip is not interlaced, but is telecined only, and there are few segments where the by-hand approach would be needed. For example, when I run this script on the entire episode:

CombTest=BlankClip(Last,Color=color_red)
TFM(Clip2=CombTest)
TDecimate()

I see red frames only in the moire segments when pp=6. When pp=0, there are no red frames and, as I understand it, pp=0 turns the deinterlacing function off and this should result in many combed frames if the video is truly interlaced.

I still think the aspect ratio will be a little off if you don't crop.

Crop(8,0,-8,0)
Lanczos4Resize(640,480)

Like you, I am very sensitive to the AR in my videos. However, I have found that cropping borders, simply because they are there, doesn’t always work. With each TV series, I do spend some time trying to verify the AR. I do this by trying to find a known circle or square object in the video that is not angled, depth wise, and ensure that the diameter is consistent. I suspect that, in many cases, that the studios crop the original edges because they are bad and then add the border to ensure the correct AR. It becomes a real pain when they seem to do this episode-by-episode, but this is less common. In the case of this series, the borders do seem to provide the correct AR.

[hello_hello]

Like you, I am very sensitive to the AR in my videos. However, I have found that cropping borders, simply because they are there, doesn’t always work.

That's the very reason I crop borders.... because they're there..... :)
It drives me nuts when the picture edges aren't clean, which is why I'd crop a bit more than 8 pixels from each side of your sample.

In the case of this series, the borders do seem to provide the correct AR.

It's very hard to tell just from your sample, but looking the globe in the background, I'm still inclined to lean more towards 15:11 than 4:3. Not that the difference is huge, but I'm not sure I've ever met a 4:3 DVD that didn't have an ITU or mpeg4 aspect ratio (15:11). It's a different story for 16:9 DVDs though.

CropResize(640,480, InDAR=4.0/3.0)

https://i.ibb.co/25W1b9L/4-3.png

CropResize(640,480, 8,0,-8,0, InDAR=15.0/11.0)

https://i.ibb.co/vHtXstj/15-11.png

[Frank62]

It's very common that left and right are blacked areas due to often worse picture quality near borders, so they're cropped. Has nothing to do with AR, that of course is 4:3. The master sources we had for PAL were HD, so I think the ones they used for the NTSC-DVDs will be pretty much the same.

[Danette]

What both of you DON'T have is the entire episode. In the opening credits there is a circle that I used determine if cropping gave better dimensions than uncropped. To me, it appeared that, by cropping, the circle was out of proportion (I mark the diameter on a piece of paper and then compare it when turned perpendicularly).

He's running QTGMC in progressive mode. It can work very well as a denoiser, and can also be useful for stabilising the picture. It's not too often I encode a DVD without running QTGMC in progressive mode.

I, too, like to run QTGMC in progressive mode on all videos for this reason. Is there some setting that can be turned off in QTGMC (placed after TFM/TDecimate) so that QTGMC can do all it's nice work, but without re-introducing the moire effect?

[hello_hello]

I've seen quite a few DVDs where the aspect ratio for the opening credits was wrong. Like these. I found them on the internet and don't know where they came from, but I've seen the poor MGM lion being tortured on DVDs in the past. These are both 1080p so it's likely they weren't resized.

https://www.logolynx.com/images/logolynx/fe/fe75bd653ac72fa98dd103e310d06826.jpeg
https://www.logolynx.com/images/logolynx/d1/d18edcad22bbd71a473fe4a190eab9d4.jpeg

Anyway... I can only go by the sample and guess what looks right to me. It's your encode though, so whatever looks right to you.

[hello_hello]

I, too, like to run QTGMC in progressive mode on all videos for this reason. Is there some setting that can be turned off in QTGMC (placed after TFM/TDecimate) so that QTGMC can do all it's nice work, but without re-introducing the moire effect?

Not that I know of. To the best of my knowledge InputType=1 doesn't de-interlace, but QTGMC still does everything else it'd do in order to repair a de-interlaced picture. That's why it can be great at stabilising, but I guess this is one example of when that has a negative effect.

[Danette]

I've seen quite a few DVDs where the aspect ratio for the opening credits was wrong. Like these. I found them on the internet and don't know where they came from, but I've seen the poor MGM lion being tortured on DVDs in the past. These are both 1080p so it's likely they weren't resized.

Yes, Leo looks pretty bad in that one link. I uploaded a segment from the credits having the circle - in case you’re curious. Note, too, that the credits are sandwiched between an intro to the story and the main story. I can’t detect any adjustment vs. the main video.

circle segment: https://www.mediafire.com/file/w0p0dqdd8d3qtfz/Circle_Example.m2v/file

Not that I know of. To the best of my knowledge InputType=1 doesn't de-interlace, but QTGMC still does everything else it'd do in order to repair a de-interlaced picture. That's why it can be great at stabilising, but I guess this is one example of when that has a negative effect.

I used to think this, as well. However, I’ve now tested a few episodes of the next two TV series I intend to backup, and they have similar moire problems, while demonstrating no interlacing (IVTC only) according to the test I’m now using (mentioned in post #45). After processing with your suggestion of “TFM(y0=140,y1=480,pp=0,micmatching=0,slow=2)” they are good with no moire (many thanks for that). Unfortunately, in each case, when I add QTGMC(InputType=1) after TFM, the moire is reintroduced. It appears that QTGMC falls down where moire effects are involved and I suspect that moire problems will exist in all TV series at some point or another. It leaves me wondering if I have to abandon QTGMC, unless I want to analyze every single future show I intend backing up ...ugh!!

Maybe I'll post the issue on the QTGMC thread.

[Katie Boundary]

Wow. I never expected one of my crazy experiments to find a practical use. It probably wouldn't have even occurred to me to try using Ghetto IVTC on this content. I'm happy to be of help, I guess :)

and since it black and white film, it's better and faster to use Converttoy8/Converttoy

also I already made Katie method as function KIVTC() in AnimeIVTC.avsi if someone care

While I'm honored that you would include one of my experiments in your filter package, I must object to the name. KIVTC, which I assume stands for Katie's IVTC, implies that this is my preferred method of IVTC, which is definitely NOT the case, and I don't want anyone to get the impression that that's the case. A more appropriate name would be GIVTC (Ghetto IVTC).

[StainlessS]

implies that this is my preferred method of IVTC
No, just implies that it was your idea, no more, no less. [dont lump extra work onto Real.Finder]

[hello_hello]

Yes, Leo looks pretty bad in that one link. I uploaded a segment from the credits having the circle - in case you’re curious. Note, too, that the credits are sandwiched between an intro to the story and the main story. I can’t detect any adjustment vs. the main video.

circle segment: https://www.mediafire.com/file/w0p0dqdd8d3qtfz/Circle_Example.m2v/file

Edited to delete this part of my reply. See the next post for an updated version.

It appears that QTGMC falls down where moire effects are involved and I suspect that moire problems will exist in all TV series at some point or another. It leaves me wondering if I have to abandon QTGMC, unless I want to analyze every single future show I intend backing up ...ugh!!

Maybe I'll post the issue on the QTGMC thread.

That sort of thing is pretty rare. QTGMC tries to repair each scan-line (normally after de-interlacing) and I guess it's causing a problem because the lines on his jacket are so fine.

Even though progressive mode is intended for repairing bad de-interlacing, on progressive content it can sometimes affect straight lines in a way that looks like bad de-interlacing, if straight lines happen to be on just the right angle.

Here's an example of what I mean. It's not severe (unless you have a huge monitor you might need to run it fullscreen to see it), but I remember it from an encode a few days ago. It's a 1080p source resized to 720p. Watch the edge of the books on the far side of the desk. The problem already exists in the source to some extent, but you probably wouldn't notice unless you knew to look for it. QTGMC just made it worse. The slower speed preset tends to cause less of that sort of thing, although it doesn't happen all that often anyway. There's a re-encode without QTGMC included.
A similar thing can happen when straight edges are almost perfectly horizontal and there's a lot of noise dancing around the edges.

QTGMC.zip (https://www.udrop.com/1DE4/QTGMC.zip) (4.7MB)

If there's halos around objects in a source, especially if it's also noisy, QTGMC tends to enhance them a bit more than I'd like.

On rare occasions it can cause motion interpolation type artefacts when an object moves across an almost flat background. For example, a person walking on grass and all you can see past that person is more grass. As he moves, sometimes QTGMC can cause the grass immediately behind him to blur. That's quite rare though.

Despite those negatives, I still use QTGMC for denoising more than any other denoising method, especially for standard definition requiring some "stabilisation".

[hello_hello]

Well.... at the risk of it causing a brain haemorrhage, I might have to consider the possibility I was wrong. I'd prefer to live in denial and go with the credits being a different aspect ratio to the episodes themselves, but I tried drawing squares around circles as Irfanview displays the aspect ratio in the title bar. Based on that, it does seem to be 4:3. At least for the opening credits.... :)

4:3
https://i.postimg.cc/x8RfP05s/4-3-B.png

15:11
https://i.postimg.cc/Vv1sMSqr/15-11-B.png

For this one, I'll confess it's hard enough to guess where the edges are to be certain if 15:11 is the correct one because it's correct, or if it's the correct one because I want it to be.

4:3
https://i.postimg.cc/NGrh18bW/4-3-C.png

15:11
https://i.postimg.cc/JzpdwtPN/15-11-C.png

[Danette]

That sort of thing is pretty rare. QTGMC tries to repair each scan-line (normally after de-interlacing) and I guess it's causing a problem because the lines on his jacket are so fine.

Even though progressive mode is intended for repairing bad de-interlacing, on progressive content it can sometimes affect straight lines in a way that looks like bad de-interlacing, if straight lines happen to be on just the right angle.

Despite those negatives, I still use QTGMC for denoising more than any other denoising method, especially for standard definition requiring some "stabilisation".

I think that the rarity of the problem is a function of the type of videos we prefer to watch. I am nearly 100% shows from the 50’s through early 80’s, so my DVD’s are nearly all NTSC and 4:3 AR. IVTC is mainly all that is needed (rarely interlaced). I have tested 5 different shows now and found the moire in 4 of them. I think that B&W sees a jump in frequency of moire effects, although one was in color.

In the past, I have seen a noticeable difference when QTGMC(InputType=1) is employed on many of my backups. Although the difference in using QTGMC for it’s beneficial cleaning/stabilizing can be subtle, the moire effect is not, so I am going to have to start using QTGMC only when I am sure that there is little chance of it inducing a moire effect …and that’s unfortunate.

Well.... at the risk of it causing a brain haemorrhage, I might have to consider the possibility I was wrong.

For this one, I'll confess it's hard enough to guess where the edges are to be certain if 15:11 is the correct one because it's correct, or if it's the correct one because I want it to be.

Alas, I must advise you that you were right. I never thought to use my old image editor until I saw what you did with IrfanView. With my editor, I can create circles, squares, etc. and, as you can see below, the cropped version is the correct version. However, I'm going to take a little credit by saying that the left border should cropped by 6 and not 8. It may be hard to see, but the dashed blue lines are the drawn circle.

https://i.postimg.cc/dZMDyL2V/AR-Test-1.jpg (https://postimg.cc/dZMDyL2V)
https://i.postimg.cc/zHnvS87S/AR-Test-2.jpg (https://postimg.cc/zHnvS87S)

[hello_hello]

Now I'm confused. Is that the same episode as the sample you uploaded? Because I was happy to concede the intro is 4:3.

However, I'm going to take a little credit by saying that the left border should cropped by 6 and not 8. It may be hard to see, but the dashed blue lines are the drawn circle.

You'd probably hate the way I'd encode the episodes with the vertical lines on the left side. If I was to encode those lines I wouldn't be able to sleep at night. There's a plugin called EdgeFixer you might want to try. It should be able to make them less noticeable, usually at the expense of blurring the edge a little. Me.... I'd just remove them entirely, so instead of this:

Crop(6,0,-8,0)
Lanczos4Resize(640,480)

https://i.ibb.co/tLJVkQC/1e.png

I'd be doing something like:
CropResize(640,480, 18,0,-12,0, InDAR=15.0/11.0)
(the script will crop the appropriate amount from the top and bottom to prevent aspect error)

https://i.ibb.co/JBCFKm2/1f.png

Or maybe even this to keep the height resizing to a minimum:
CropResize(624,468, 18,0,-12,0, InDAR=15.0/11.0)

https://i.ibb.co/tbQg1CL/1g.png


Anyway...
I found a copy of the first episode and had a play. I think for me, the result was the same as before. It was already cropped, but the aspect ratio of the opening credits seems wider (the square is 1.027:1). On the other hand, I'm pretty sure the shot of the radar screen about 4 minutes in is correct, assuming it's supposed to be round.

https://i.ibb.co/51FnLrT/1b.png

https://i.ibb.co/C6c7kSx/1a.png

I couldn't find any other shots of circles that were even close to straight-on, but I let my brain have a go at the angled shot of the car wheels a little after 19 minutes, and it seems happier with 15:11.
I only added the borders to simulate no-crop resizing by reducing the width in MPC-HC, as a single resizing step is very close to the difference between a generic and mpeg4 aspect ratio. It's not exact, but it is very close, and good enough for a comparison.

https://i.ibb.co/Dzv02m5/1d.png

https://i.ibb.co/fXJQcjh/1c.png

If you can be bothered, try the first episode yourself to see if the result is the same, but for the first episode at least, the aspect ratio of the opening credits and the episode itself do seem a little different.

[Danette]

Now I'm confused. Is that the same episode as the sample you uploaded? Because I was happy to concede the intro is 4:3.

Yes, it was from the same episode and I did look at that first episode. Drawing a circle around many objects, in both episodes, leaves me believing that the cropping results in the correct AR after all. I didn’t use the radar screen because those were convex and the resultant shadow would throw it off. However, in that same scene the reel in the top right is one I used. There is also a globe in the episode that first appeared in this thread.

How would you compare the resize quality of CropResize to Lanczos4Resize?

You'd probably hate the way I'd encode the episodes with the vertical lines on the left side. If I was to encode those lines I wouldn't be able to sleep at night. There's a plugin called EdgeFixer you might want to try.

I would lose sleep if I cut the content at all, so I’m usually ok with minor lines such as that. However, I do like that EdgeFixer you suggested and have applied that.


Incidentally, I’ve found that modifying the TFM(y0=140,y1=480,pp=0,micmatching=0,slow=2) line to:
TFM(y0=160,y1=480,pp=5,micmatching=0,slow=2) gives better results and allows the use of QTGMC(InputType=1) without re-introducing moire effects.

Perhaps you can explain why that is, for educational purposes, and if you see any downside to it.

[poisondeathray]

Incidentally, I’ve found that modifying the TFM(y0=140,y1=480,pp=0,micmatching=0,slow=2) line to:
TFM(y0=160,y1=480,pp=5,micmatching=0,slow=2) gives better results and allows the use of QTGMC(InputType=1) without re-introducing moire effects.

Perhaps you can explain why that is, for educational purposes, and if you see any downside to it.

On that sample, you're blend deinterlacing almost every frame with those settings. It's blurry, that' s the downside. You can add display=true to TFM to see which frames are affected

It's ok to selectively low pass some signal if there are problems on certain parts of frames, but you're basically applying a blur() to every frame globally

[Danette]

On that sample, you're blend deinterlacing almost every frame with those settings. It's blurry, that' s the downside. You can add display=true to TFM to see which frames are affected

It's ok to selectively low pass some signal if there are problems on certain parts of frames, but you're basically applying a blur() to every frame globally

Yes, thanks, I can see that now on high zoom. It’s very subtle …almost a denoising effect. It doesn’t seem to be a bad thing. I can tone down denoising a little and, on my screens (TV and monitor), can’t detect it at a distance. Am I right that this slight blur is tricking QTGMC into not seeing what it thinks is combing?

I’ve been using ShowCombedTIVTC() to see where the nominal combing exists after processing and
A=BlankClip(Last,Color=color_red)
TFM(Clip2=A)
TDecimate()
ShowChannels()
to determine if I’m likely to need this moire suppression approach in the first place.

[poisondeathray]

Yes, thanks, I can see that now on high zoom. It’s very subtle …almost a denoising effect. It doesn’t seem to be a bad thing. I can tone down denoising a little and, on my screens (TV and monitor), can’t detect it at a distance. Am I right that this slight blur is tricking QTGMC into not seeing what it thinks is combing?


Yes, it's essentially a vertical blur. ie. blur(0,1) - and that makes it no longer detected as combing by QTGMC .

Pros/cons - can help with patterns prone to aliasing, but you soften everything else

If you use QTGMC in progressive mode, it smooths everything over, cleans it up, but at the expense of detail loss and possible motion artifacts .

Like everything, it's about personal taste.

[hello_hello]

How would you compare the resize quality of CropResize to Lanczos4Resize?

The default resizing method is Spline36Resize, but you can use any resizer with arguments for cropping. It doesn't have to be an Avisynth resizer.
CropResize(640,480, 8,0,-8,0, InDAR=15.0/11.0, Resizer="Lanczos4Resize")

There's a wrapper functions script included that lets you use another resizer as an alternative default. You have to modify the very last line in the CropResize script to specify the new default. That line looks like this:
function CR_Resizer() { return "Resize8" }
So you'd change it to:
function CR_Resizer() { return "Lanczos4Resize" }

Then you can use the alternative default resizer (Lanczos4Resize) by appending an X to the function name.
CropResizeX(640,480) or
CRX(640,480)

The default alternative is the Resize8 (http://avisynth.nl/index.php/Resize8) function. Resize8 corrects the very slight chroma shift (https://forum.doom9.org/showthread.php?p=1506374#post1506374) caused by the Avisynth resizers (not that it's anything to worry about unless you're resizing by a huge amount). The defaults for Resize8 are Lanczos4 for luma upscaling, Lanczos for chroma upscaling, and Spline36 for luma/chroma downscaling, however there's "Wrapper Functions" and "Resizer Functions" scripts supplied with CropResize that can be used to force a resizer for Resize8, but it's probably easier to use the AVSResize plugin (http://avisynth.nl/index.php/Avsresize). I don't think it's resizers have the chroma positioning bug.
CropResize(640,480, Resizer="z_Lanczos4")
Or just use AVSResize on it's own.

Are you glad you asked? :)

By the way, CropResize will always crop if necessary to prevent aspect error when resizing, so if you do this
CropResize(640,480, 6,0,-8,0, InDAR=15.0/11.0)
it'll crop an extra couple of pixels from the width to resize to 4:3 without aspect error. If you're really determined the video only needs 14 pixels cropped from the width for 4:3, you have to change the input display aspect ratio, or specify the appropriate sample/pixel aspect ratio instead.

640 / (720 - 14) = 0.90651558 - sample/pixel aspect ratio
720 * 0.90651558 = 652.691218
652.691218 / 480 = 1.35977 - display aspect ratio

CropResize(640,480, 6,0,-8,0, InDAR=1.35977) or
CropResize(640,480, 6,0,-8,0, InSAR=0.90651558)
Or if you want the cropping even, for an NTSC DVD this would crop 7 pixels each side. Six using Crop() and one with the resizer.
CropResize(640,480, InDAR=1.35977, Resizer="Lanczos4Resize")
It'd be the same as
Crop(6,0,-6,0)
Lanczos4Resize(640,480, 1,0,-1,0)

Or this would crop four from the left and ten from the right.
CropResize(640,480, 0,0,-3,0, InDAR=1.35977)
Once you've set the new InDAR or InSAR though, you can crop however you like and CropResize will still make sure there's no aspect error by cropping extra picture if necessary.

I would lose sleep if I cut the content at all, so I’m usually ok with minor lines such as that. However, I do like that EdgeFixer you suggested and have applied that.

DVDs are created to account for over-scanning (https://en.wikipedia.org/wiki/Overscan). That's why when you watch a DVD on a CRT, or even on a modern display set to 4:3 mode (which also over-scans) you don't see any of the crud. Even if it's all picture, you still don't see 5% to 10% of it (https://en.wikipedia.org/wiki/Safe_area_%28television%29#Action_safe_area), which is why cropping some of the the over-scan area doesn't bother me if it gives me clean edges. Even modern TVs probably mostly over-scan by default, although often you can disable it (except for analogue composite inputs and anything received over the airwaves).

[Danette]

Are you glad you asked? :)

YES!

By the way, CropResize will always crop if necessary to prevent aspect error when resizing

On this video, at least, when I set CropResize to (640,480,0,0,-0,0, InDAR=15.0/11.0) it performs an auto-cropping type function. Apparently, it agrees with us that the correct AR is delivered by cropping the borders, although it chewed into the content very slightly.

It may be that the best thing to do is to use it in this way and accept whatever borders may remain and/or whatever content may be cut.

Comments?

[hello_hello]

On this video, at least, when I set CropResize to (640,480,0,0,-0,0, InDAR=15.0/11.0) it performs an auto-cropping type function. Apparently, it agrees with us that the correct AR is delivered by cropping the borders, although it chewed into the content very slightly.

It may be that the best thing to do is to use it in this way and accept whatever borders may remain and/or whatever content may be cut.

Comments?

Edit: Sorry about the essay, but hopefully this will help makes things clearer. :)

The script simply uses the supplied InDAR to base the calculations on. If no InDAR/InSAR is specified, it assumes the source is non anamorphic (square pixels). If you were to do the following, it wouldn't crop at all as the InDAR and output DAR (resolution) are the same. Info=true will show you what it's doing.
CropResize(640,480, 0,0,0,0, InDAR=4.0/3.0, Info=true)
For the following it barely crops as the output dimensions almost match the InDAR.
CropResize(652,480, 0,0,0,0, InDAR=15.0/11.0, Info=true)
For the next example, the shape of objects in the picture will be exactly the same after resizing as for the previous one, but because the output width is narrower this time, it has to crop the sides.
CropResize(640,480, 0,0,0,0, InDAR=15.0/11.0, Info=true)
So it's not agreeing about the AR, or auto-cropping in the traditional sense, it's just preventing an aspect error based on the InDAR and output dimensions. It just happens that InDAR=15.0/11.0 requires 16 pixels to be cropped from the width if you want a 4:3 output. If you want to use that InDAR (which I think we decided is correct), but don't want to crop, you can increase the output width a bit.

Think of any specified cropping as the minimum cropping, but the script will increase it as required to prevent aspect error. To see what's being cropped, enable a cropping preview. The yellow lines are the specified cropping and any blue lines are the additional script cropping. The video isn't resized while the cropping preview is enabled.
CropResize(640,480, 10,4,-6,-4, InDAR=15.0/11.0, CPreview=1, Info=true)

For a 16:9 DVD the equivalent InDARs are (and specifying 16:9 output dimensions for resizing).
CropResize(768,432, 0,0,0,0, InDAR=16.0/9.0) - generic DAR
CropResize(768,432, 0,0,0,0, InDAR=20.0/11.0) - mpeg4 DAR

The main idea of CropResize is to crop and resize without having to calculate aspect error and adjust the cropping or resizing manually to prevent it. An example might be cropping a 1080p source and resizing to 720p. If you don't specify a height (use zero instead), the script will apply your cropping and then pick the appropriate height for you. Because it's free to pick the height, any additional cropping to prevent aspect error will be fairly minimal. You can do exactly the same thing with a DVD source as long as you use the correct InDAR
(cropping a 1080p source like this would mean you have a video with a 2.40:1 aspect ratio after cropping the black).
CropResize(1280,0, 4,140,-2,-142)
If you were to specify the same cropping as above with 4:3 output dimensions (still a 1080p source), it'd apply the specified cropping, then crop a huge amount from each side to give you a 4:3 output without distorting the picture.
CropResize(720,540, 4,140,-2,-142)

I find it very handy when working with video where the amount of black varies quite a bit (usually old DVDs), but I'm OCD about cropping it all. So I can do something like the following, specifying enough cropping to remove the black, without having to worry about distorting the picture, because CropResize won't let me.

Trim(0,1596).CropResize(640,480, 8,0,-8,0, InDAR=15.0/11.0) ++ \
Trim(1597,1884).CropResize(640,480, 16,2,-8,-4, InDAR=15.0/11.0) ++ \
Trim(1885,2597).CropResize(640,480, 24,4,-12,-2, InDAR=15.0/11.0) ++ \
Trim(2598,0).CropResize(640,480, 8,0,-8,0, InDAR=15.0/11.0)

But anyway... what I was trying to explain in my previous post, is if you were to decide the source is 4:3 after you only crop 14 pixels from the sides, you can do it by specifying the appropriate InDAR, and that's the DAR the script will base it's calculations on. Use Info=true and you'll see it's only cropping 7 pixels each side here instead of 8.
CropResize(640,480, InDAR=1.35977, Info=true)

CropResize does have a "traditional" auto-cropping option. It requires the AutoCrop plugin (autocrop.dll). When it's enabled, the source is auto-cropped with autocrop.dll, any specified cropping is applied to the auto-cropped video, if necessary the script applies additional cropping to prevent aspect error, then it resizes. Try the following. Assuming auto-crop crops some or all of the black from the sides, the script will then crop 8 more pixels each side, and to prevent aspect error it'll crop a few pixels top and bottom before resizing to 4:3 dimensions.
CropResize(640,480, 8,0,-8,0, AutoC=true, InDAR=15.0/11.0, Info=true)
If you don't specify a height, you probably won't end up with a 4:3 output, but at the same time the script probably won't have to crop much extra picture to prevent aspect error.
CropResize(640,0, 8,0,-8,0, AutoC=true, InDAR=15.0/11.0, Info=true)

[kuchikirukia]

I always suggest pp=0 because it's better to have combing which can be seen in spot checks and redone than artifacts which may be buried in one destroyed scene.

[real.finder]

so as proof of concept

bob(0,0.5).reduceflicker(2).Ablur(0,blurv=2).interlaced60or50(BFF=!(GetParity())).Blur(1.58,0)
tfm(pp=0, micmatching=0)


with this tfm seems dont matching the wrong fields, but we dont need the output to be blurry so https://github.com/pinterf/TIVTC/issues/27

[real.finder]

I think this fully fixed with
https://github.com/pinterf/TIVTC/issues/27#issuecomment-3532872619