Deep Space Nine upscale project

[JoelHruska]

This caught my eye before I saw the videoh curt response (but with humor - you took it the wrong way)

None of Videoh's responses to me have been intended with humor, as far as I can tell. He began by assuming bad faith when I joined the thread on page 6 and has not appreciably mellowed on that stance thereafter that I can see. I've got no quarrel with him or anyone here.

I am absolutely willing to test any script suggestion that anyone has. When I said I didn't see the point of posting test clips, I was only referring to test clips based on my own ideas. I'm currently out of ideas. :P

Also, Vdub2 question. Does anyone actually use Vdub2 for outputting video after editing, or do you just edit the project and then save the AVS script? If Vdub2 is used to output video, what export settings should I use?

[Katie Boundary]

Digging though the old posts in this thread, I stumbled upon the "QIVTC" script by h_h. It had three obvious problems, all of which I've managed to fix: first, it assumed a field parity that would be wrong 99.999% of the time, so I added a modification that Stainless and I have been working on for my own scripts, which automatically detects and uses the correct field parity. Second, after going through all the trouble of using QTGMC's weird shitty pseudo-motion-interpolation to create something that might look like natively 60 fps content if you were stoned, it decimated down to 23.976 fps for no damn reason. I cut that line out. Third, it used QTGMC's "very slow" preset, which has an extra dependency that the other speed settings don't have and which QTGMC's own documentation admits is a waste of CPU cycles for almost no quality improvement. So I restored it to its default "slower" setting. The final QIVTC looks like this:

function QIVTC(clip Video)
{

underpants = GetParity(Video) ? 0 : 1

A = Video.Tfm(mode=0, PP=1, MI=20, Slow=2, CThresh=4, Micmatching=0).QTGMC().SelectEven()
B = Video.Tfm(field=underpants,mode=0, PP=1, MI=20, Slow=2, CThresh=4, Micmatching=0).QTGMC().SelectEven()
C = Video.Tfm(mode=0, MI=20, Slow=2, CThresh=4, Clip2=A, Micmatching=0)
D = Video.Tfm(field=underpants,mode=0, MI=20, Slow=2, CThresh=4, Clip2=B, Micmatching=0)
Interleave(C,D)
QTGMC(InputType=1, ShutterBlur=3, ShutterAngleSrc=180, ShutterAngleOut=180, SBlurLimit=8)
}

If the moderators would like to put that on the wiki and credit it to Katie Boundary, hello_hello, and StainlessS, the three of us would be honored (note: I'm also putting a package together of two other functions that I'd like credited to just me and Stainless when I'm ready to publish it, which should be very soon).

As for my opinion on the results of this corrected version, I have to say... it's a brave and probably clever attempt, but ultimately it fails to do what a deinterlacer is supposed to do: get rid of visible interlacing. This is why I set cthresh and mthresh so low. At this script's settings, lots of interlacing still slips through:



That might not seem like a big deal at standard definition, but it'll play hell with AI upscalers. It also shares the same flaws as QTGMC: (a) it's slow, (b) it has lots of dependencies, (c) it bobs everything indiscriminately rather than preserving the original progressive frames whenever possible, and (d) it generates worse interpolation than other temporally-aware bobbers, then tries to hide the bad data by replacing all the good data around it (original scanlines) with more bad data. Basically it's just QTGMC with less aliasing but worse detection and removal of interlacing.

Also, since I'm not a QTGMC guru, I don't know exactly how the script is supposed to work, so all support, maintenance, and further improvement concerns should be directed to h_h and Stainless.

Originally Posted by manono

And KB put it a little more colorfully:

These days I don't see these mixed film/video television series' as I work on old films with constant framerates.

Paradoxically, newer TV shows also have constant frame rates because the rise of HDTV has made it necessary for TV shows to look good at multiple resolutions, thus putting an end to natively interlaced editing and content. This mixed-framerate, edited-on-tape crap was a fad that lasted less than 20 years, from the mid-'80s to the early 2000s.

Originally Posted by scharfis_brain

If I might chime in here:

I'd personally would skip VFR / 120Hz, just for these reasons:

1) compatibility: a 59.94p video file (despite codec/container) will work on almost any given hardware out there.

2) smart TVs: newish TVs are capable to detect 3:2 pulldown, 2:2 pulldown and video almost instantaneously. Thus no 3:2 judder will occur. Additional frame interpolation might be done for the 3:2 parts by the TV on the fly, if the user has set it up.

3) retention of the original frame sequence/cadence: no messing around with frame timings. No false judder being introduced. Just sticking to field-matching and proper deinterlacing.

You forgot:

4) it looks the same on a 60 hz monitor anyway

Originally Posted by JoelHruska

I am absolutely willing to test any script suggestion that anyone has.

Mpeg2source("601.d2v")

A=Tfm(field=1,mode=0,slow=2,pp=2,mchroma=false,cthresh=-1,micmatching=0).converttorgb().generalconvolution(matrix = "0 -1 0 0 4 0 0 -1 0",divisor=2,auto=false).converttoyv12()
B=Tfm(field=0,mode=0,slow=2,pp=2,mchroma=false,cthresh=-1,micmatching=0).converttorgb().generalconvolution(matrix = "0 -1 0 0 4 0 0 -1 0",divisor=2,auto=false).converttoyv12()
C=Tfm(field=1,mode=0,slow=2,mchroma=false,cthresh=-1,clip2=A,d2v="601.d2v",flags=1,micmatching=0)
D=Tfm(field=0,mode=0,slow=2,mchroma=false,cthresh=-1,clip2=B,d2v="601.d2v",flags=1,micmatching=0)

interleave(C,D)

As usual, feel free to tweak the parameters if you think you can improve the interlacing-detection.

[hello_hello]

Originally Posted by JoelHruska

Also, Vdub2 question. Does anyone actually use Vdub2 for outputting video after editing, or do you just edit the project and then save the AVS script? If Vdub2 is used to output video, what export settings should I use?

I've never used VD2 for x264 encoding, but you can open Avisynth scripts with it.

MeGUI is pretty easy, It's script creator comes with a preview so you can modify a script and preview the changes, or create the script yourself via other means, load it into MeGUI's video section and add it to the job queue. The encoder preset used for each job is the preset selected at the time the job is added to the queue. You can create your own.
For x264, you'd generally just pick a quality (CRF value) the slowest speed preset you can stand (I generally use slow or slower) and maybe select a tuning (I generally use the film tuning).
MeGUI also supports Xvid, X265 and a huffyuv lossless output (via it's pre-rending option).

For VD2, using the File/Save menu the selecting x264 as the compression method, the configuration looks like this. Is that what you meant?



Or you can pick a lossless option supported by the program you're want to use to import the output. If you're opening and editing the source video rather than a script, but want to open the edited video in a script, you'd possibly do it that way.

[scharfis_brain]

Originally Posted by Katie Boundary

You forgot:

4) it looks the same on a 60 hz monitor anyway

Nope: I left it out on purpose. I don't look at 60Hz screens anymore.

[Groucho2004]

Originally Posted by JoelHruska

If you're telling me that this is untrue and that AviSynth+ and AviSynth can co-exist just fine, that's great to know.

Proof:

[Katie Boundary]

Originally Posted by Groucho2004

Proof:
(image)

So AVIsynth and AVIsynth+ can coexist but only if one is 32-bit and the other is 64-bit?

[Groucho2004]

Originally Posted by Katie Boundary

So AVIsynth and AVIsynth+ can coexist but only if one is 32-bit and the other is 64-bit?

Correct.

[manono]

Originally Posted by hello_hello

For VD2, using the File/Save menu the selecting x264 as the compression method, the configuration looks like this. Is that what you meant?

Yes, that's the impression I got - that he was asking how to encode using VDub2. Thanks for explaining it and with the pictures as well. First set Video for Fast Recompress, followed by Video->Compression where he chooses x264 8-bit. To save resizing he might choose SARs of 4:3 (if 4:3 and not 16:9).

After setting up the video encode the way he likes and if he wants an MKV out of it, go File->Save As->Matroska and let 'er rip.

[JoelHruska]

Correct.

Then the AviSynth+ installer gives incorrect information, because I definitely was using 32-bit AviSynth and it still told me it could not be left installed. Noted.

[Groucho2004]

Originally Posted by JoelHruska

Then the AviSynth+ installer gives incorrect information, because I definitely was using 32-bit AviSynth and it still told me it could not be left installed. Noted.

Just use the Universal Installer.

[JoelHruska]

Just use the Universal Installer.

Until this moment, I was not aware one existed.

[Groucho2004]

Originally Posted by JoelHruska

Until this moment, I was not aware one existed.

You'll find it here. If you decide to use it I'd recommend the one with AVS+ 3.5.1.

[JoelHruska]

Thank you very much. This looks like a nice way to increase flexibility in future.

[hello_hello]

Originally Posted by Katie Boundary

Digging though the old posts in this thread, I stumbled upon the "QIVTC" script by h_h. It had three obvious problems, all of which I've managed to fix: first, it assumed a field parity that would be wrong 99.999% of the time, so I added a modification that Stainless and I have been working on for my own scripts, which automatically detects and uses the correct field parity. Second, after going through all the trouble of using QTGMC's weird shitty pseudo-motion-interpolation to create something that might look like natively 60 fps content if you were stoned, it decimated down to 23.976 fps for no damn reason. I cut that line out. Third, it used QTGMC's "very slow" preset, which has an extra dependency that the other speed settings don't have and which QTGMC's own documentation admits is a waste of CPU cycles for almost no quality improvement. So I restored it to its default "slower" setting. The final QIVTC looks like this:

The field parity was correct for the source, unlike the scripts for this sample you've uploaded. Is this a sad attempt to distract everyone from that because you didn't notice?

Where did your "Converting boolean values to integers and other AVSI problems" thread go? Did you delete it?

You can do what you like with the function, but don't give me any credit.

The slower the QTGMC preset in progressive mode, the less likely it'll cause "wobbles" in straight lines and sharp edges. Whether "very slow" makes much difference I don't know. I used it because that's what JoelHruska had been using previously, and the idea was to stabilise the picture as much as possible. Obviously you're the QTGMC expert now, so you'd know though....

It decimated to 23.976 because the output desired at the time was 23.976, and it looked quite smooth at the frame rate.

Originally Posted by Katie Boundary

That might not seem like a big deal at standard definition, but it'll play hell with AI upscalers. It also shares the same flaws as QTGMC: (a) it's slow, (b) it has lots of dependencies, (c) it bobs everything indiscriminately rather than preserving the original progressive frames whenever possible, and (d) it generates worse interpolation than other temporally-aware bobbers, then tries to hide the bad data by replacing all the good data around it (original scanlines) with more bad data. Basically it's just QTGMC with less aliasing but worse detection and removal of interlacing.

Complete nonsense. TFM field matches the film sections as it always would and only replaces the combed pixels by taking them from the de-interlaced clip in exactly the same way every other example of your method does.

Funnily enough, if lower TFM threshold settings caused it to take more pixels from the QTGMC de-interlaced clip you regularly claim not to like, despite all the evidence posted previously showing it can be better (which you've continually ignored) you're saying that would be better?

The final instance of QTGMC isn't de-interlacing, just smoothing the output.

Originally Posted by Katie Boundary

Also, since I'm not a QTGMC guru, I don't know exactly how the script is supposed to work, so all support, maintenance, and further improvement concerns should be directed to h_h and Stainless.

After the long critique on what it's doing, you're now claiming not to know how it's supposed to work?

The idea was to use TFM to field match, but not de-interlace itself, then QTGMC de-interlaces those frames, the logic behind that being the frames being de-interlaced by QTGMC would always be the same frames TFM wants to use to replace the combed pixels later on. Whether it works better or not, I don't know. Other than that it's just another variation of your method, and so far still looks better than any script you've posted.

How about you upload a sample yourself instead of pontificating, so we can compare it to the sample encode I no doubt linked to when I posted the script?

Originally Posted by Katie Boundary

This is why I set cthresh and mthresh so low. At this script's settings, lots of interlacing still slips through:

Nonsense. If anything, in hindsight, the combing detection was too sensitive. That was probably the cause of any picture wobbling, but it was an attempt to get through the fades between shots smoothly at 23.976fps, and I think it did that. I've gone off the idea now though, and I'd do a VFR encode instead.

Here's a script showing the pixels TFM is taking to repair combing.

Video = last
A = Video.Tweak(bright=200)
B = Video.Tweak(bright=200)
C = Video.Tfm(field=0,mode=0, MI=20, Slow=2, CThresh=4, Clip2=A, Micmatching=0)
D = Video.Tfm(field=1,mode=0, MI=20, Slow=2, CThresh=4, Clip2=B, Micmatching=0)
Interleave(C,D)


Here's what the frame you posted looks like using the settings from my script (or roughly, I don't know the frame number).


Here's what it looks like using cthresh=2 and mthresh=2.

Video = last
A = Video.Tweak(bright=200)
B = Video.Tweak(bright=200)
C = Video.Tfm(field=0,mode=0, mthresh=2, Slow=2, CThresh=2, Clip2=A, Micmatching=0)
D = Video.Tfm(field=1,mode=0, mthresh=2, Slow=2, CThresh=2, Clip2=B, Micmatching=0)
Interleave(C,D)


The TFM settings from my script.


cthresh=2 and mthresh=2.


The TFM settings from my script.


cthresh=2 and mthresh=2.


Your most recent TFM settings aren't much different. They don't detect any combing in frame 4500 (the first screenshot I used as an example). Try it for yourself.

A = Tweak(bright=200)
B = Tweak(bright=200)
C=Tfm(field=0,mode=0,slow=2,mchroma=false,cthresh=1,MI=30,blockx=4,mthresh=2,clip2=A,micmatching=0)
D=Tfm(field=1,mode=0,slow=2,mchroma=false,cthresh=1,MI=30,blockx=4,mthresh=2,clip2=B,micmatching=0)
interleave(C,D)


How about a sample encode instead of posting nonsense?

[manono]

Can the two of you please stop? I've already asked hello_hello via PM to just leave you alone. I have no idea why he even persists. Now I ask you to leave him alone. Just ignore each other. Is it so hard? I thought he was on your ignore list. What happened? You just relished the thought of letting have it? Me, I'm easy, but you don't want Swede to make good on his threats.

By the way, both Swede and I can see what you wrote and then thought the better of it just above.

[Katie Boundary]

I DO leave him alone. Everything I've said in response to him has either been debunking his bullshit claims about me or an impersonal analysis of his claims about video editing. Not once in the history of this forum have I gone on the offensive against him.

[Stereodude]

Originally Posted by hello_hello

Complete nonsense. TFM field matches the film sections as it always would and only replaces the combed pixels by taking them from the de-interlaced clip in exactly the same way every other example of your method does.

Funnily enough, if lower TFM threshold settings caused it to take more pixels from the QTGMC de-interlaced clip you regularly claim not to like, despite all the evidence posted previously showing it can be better (which you've continually ignored) you're saying that would be better?

The final instance of QTGMC isn't de-interlacing, just smoothing the output.

Careful, that's really not how TFM works. TFM doesn't replace pixels. It replaces entire lines of pixels. The TFM help file is misleading IMHO. I thought it only replaced the small areas of the frame that have detected interlacing. Like it made a mask of the moving part and would leave the underlying image. I'm nearly certain that it replaces the entire line for any line that has has detected interlacing in it. So in content like this DS9 stuff it's basically replacing the entire frame even if you're using PP>=5.

It may even be replacing anything between the top most line and bottom most line that have detected interlacing in them.

[Katie Boundary]

Originally Posted by Stereodude

Careful, that's really not how TFM works. TFM doesn't replace pixels. It replaces entire lines of pixels. The TFM help file is misleading IMHO. I thought it only replaced the small areas of the frame that have detected interlacing. Like it made a mask of the moving part and would leave the underlying image. I'm nearly certain that it replaces the entire line for any line that has has detected interlacing in it.

That would explain a LOT.

EDIT: I'm going through more of the DS9 footage and I'm extremely impressed by how much of this is straight film. The space battles, for example, are rendered at pure film; you don't have ships moving at 24 fps while firing phasers at each other that are animated at 30 fps. This is a huge departure from earlier seasons of Berman-era Star Trek, where you'd see, for example, the Enterprise-D moving at 24 FPS while stars whizzed by at 30. When Weyoun points at a screen showing some animation or another, the animation moves at 24 fps in sync with his hand, like that was an actual functioning display that they had on-set during filming and not something that was green-screened in later (as was done in Andromeda). Even the fades to and from black around commercial breaks are done at film. As far as I can tell, the only orphaned fields in this whole episode are during the opening and possibly closing credits (I haven't checked the closing credits yet), the credit fade-ins and fade-outs right after the opening credits, and around scene changes. A few frames of true 60hz content (i.e. "not text, not fades") do exist during the wormhole opening and closing at the end of the opening credits.

This episode would benefit strongly from a deinterlacing approach that favors preserving the original progressive frames untouched, even if it means reduced quality in the orphaned fields. This doesn't mean that a decimation down to 24 is safe, however. Those scene changes keep screwing up the cadence.

[zapp7]

Originally Posted by Katie Boundary

This episode would benefit strongly from a deinterlacing approach that favors preserving the original progressive frames untouched, even if it means reduced quality in the orphaned fields. This doesn't mean that a decimation down to 24 is safe, however. Those scene changes keep screwing up the cadence.

What do you mean by screwing up the cadence?

[Katie Boundary]

Originally Posted by zapp7

What do you mean by screwing up the cadence?

Meaning it stops being a 3:2 pattern and any given group of five consecutive frames won't necessarily have exactly three frames that should be decimated and two that should be kept.