Deep Space Nine upscale project

[Stereodude]

The interlaced fade-ins and fade outs can be handled with the smartfade() routine right after the IVTC. I think I pulled it out of the AnimeIVTC script. Might as well get rid of those if you can.

#based on smartfade v0.2 by martino - Aimed at removing interlaced fades in anime. Uses luma difference between two fields as activation threshold.
#mod by thetoof : removed degrainmedian post-processing,
# changed how the fields are blended together (average of 2 nnedi interpolations + contra-sharpening to retain more detail) and
# added cache parameter to forward the setting of animeivtc to this function
# renamed global parameter to something less general than "threshold"

function smartfademod(clip c, float "sfthr", bool "sfshow", int "cache") {

global sfthr = default ( sfthr, 0.4 ) # Threshold for fade detection.
show = default ( sfshow, false ) # Displays luma difference between fields without processing anything.
cache = default ( cache, 10 ) # Cache the frames to help seeking and other functions requesting many frames

show ? scriptclip(c, "subtitle(string(abs( separatefields().selectodd().averageluma() \
- separatefields().selecteven().averageluma())))") : \
scriptclip(c, "sep = separatefields() \
avg = sep.selectodd().averageluma() - sep.selecteven().averageluma() \
abs(avg) > sfthr ? interleave(sep.selecteven(),sep.selectodd()).weave().mcdaa3() : last")

cache<0 ? last : last.RequestLinear(8, cache, 5, false, false)

return last

}
Unless I'm misunderstanding something I don't think works very well. In order to get it to work well on the fades it needs a sfthr value that is low enough it affects lots of non-fading frames.

[SaurusX]

Unless I'm misunderstanding something I don't think works very well. In order to get it to work well on the fades it needs a sfthr value that is low enough it affects lots of non-fading frames.

It works well enough as-is and makes a noticeable improvement.

[Stereodude]

It works well enough as-is and makes a noticeable improvement.
With the default of 0.4?

I'm going to have to disagree with your conclusion. In S06E01 of DS9 the first several fades in and out of black it wouldn't get a single frame. The first one where it would find any affected frames it only gets about 30% of the frames you'd want it to get. And, there are plenty of static scenes where it detects ~.25.

So you have static scenes with no interlaced fading going on with a higher detected value than actual interlaced fades. It doesn't work for this type of content.

[bladerunner1982]

How about this dirty tweak?


function smartfademod_ds9(clip c, float "sfthr", bool "sfshow", int "cache") {

global sfthr = default ( sfthr, 0.4 ) # Threshold for fade detection.
show = default ( sfshow, false ) # Displays luma difference between fields without processing anything.
cache = default ( cache, 10 ) # Cache the frames to help seeking and other functions requesting many frames

show ? scriptclip(c, "subtitle(string(LumaDifference(separatefields().selectodd().crop(150,180,-150,-16),separatefields().selecteven().crop(150,180,-150,-16))))") : \
scriptclip(c, "sep = separatefields() \
diff = LumaDifference(sep.selectodd().crop(150,180,-150,-16),sep.selecteven().crop(150,180,-150,-16)) \
abs(diff) > sfthr ? interleave(sep.selecteven(),sep.selectodd()).weave().mcdaa3() : last")

cache<0 ? last : last.RequestLinear(8, cache, 5, false, false)

return last

}


It looks only in the parts of the half-frame, in which the credits are and calculates the absolute Luma difference in it. Then use a sfthr of maybe 1.2...

[Stereodude]

How about this dirty tweak?


function smartfademod_ds9(clip c, float "sfthr", bool "sfshow", int "cache") {

global sfthr = default ( sfthr, 0.4 ) # Threshold for fade detection.
show = default ( sfshow, false ) # Displays luma difference between fields without processing anything.
cache = default ( cache, 10 ) # Cache the frames to help seeking and other functions requesting many frames

show ? scriptclip(c, "subtitle(string(LumaDifference(separatefields().selectodd().crop(150,180,-150,-16),separatefields().selecteven().crop(150,180,-150,-16))))") : \
scriptclip(c, "sep = separatefields() \
diff = LumaDifference(sep.selectodd().crop(150,180,-150,-16),sep.selecteven().crop(150,180,-150,-16)) \
abs(diff) > sfthr ? interleave(sep.selecteven(),sep.selectodd()).weave().mcdaa3() : last")

cache<0 ? last : last.RequestLinear(8, cache, 5, false, false)

return last

}


It looks only in the parts of the half-frame, in which the credits are and calculates the absolute Luma difference in it. Then use a sfthr of maybe 1.2...
I wasn't looking at text, just the video fading in and out of any black (like at commercial breaks). Unless the text is faded into black I would think that leaving it alone is the better option compared to deinterlacing the entire progressive frame degrading it for the sake of the text.

[Chir]

@Stereodude

A couple questions, if you don't mind. I'm still struggling how I'm supposed to identify the frames that I need to add to the OVR files, and I think I might have identified them. I just want to run it by you.

You gave me the following script -- one to test, and one for production.

#for testing
source.tfm(d2v="VTS_02_1.d2v", PP=1, MI=24, clip2=deint, display=true, flags=5)
#source.tfm(d2v="VTS_02_1.d2v", PP=7, MI=24, clip2=deint, display=false, flags=5, ovr="D:\DS9S6D1\E01\tfm_ovr.txt")


Everything looks prety good with the display on, and no override files -- so I flip over to the production one and things start to go south. I end up seeing, during transitions, weird effects -- like portions of the images are blacked out or leftover from the previous frames. It looks like this happens during really quick, brief scene changes. Are these the frames that should get added to the OVR file?



UPDATE:
I think I figured this out. Going over the docs for TFM, I stumbled across the cthresh parameter. It defaults to 9, and suggested values are from 8-12 -- I had to bump it up to 25.

[Stereodude]

@Stereodude

A couple questions, if you don't mind. I'm still struggling how I'm supposed to identify the frames that I need to add to the OVR files, and I think I might have identified them. I just want to run it by you.

You gave me the following script -- one to test, and one for production.


Everything looks prety good with the display on, and no override files -- so I flip over to the production one and things start to go south. I end up seeing, during transitions, weird effects -- like portions of the images are blacked out or leftover from the previous frames. It looks like this happens during really quick, brief scene changes. Are these the frames that should get added to the OVR file?
Can you give me a frame number where you see this? Is it repeatable?

Are you sure your deinterlaced video from QTGMC is working correctly? You can check this by putting deint at the bottom of your script so that it returns that instead of the output from tdecimate.

Also, for almost the entire episode if both tdecimate lines are commented out you should have one duplicated frame out of every 5. This is normal and expected. tdecimate will remove this duplicated frame and that's how you get 23.976fps content from it.

You shouldn't have to add much of anything to the ovr file for S06E01. I've subsequently looked at the intro more closely and the metrics and have a somewhat different idea on how to treat it that addresses all the fades and largely doesn't rely on the MI to kill off combed frames (since it missed some and flagged some that it shouldn't have).

I'd use this override:;intro higher MI override
13331,16497 i 45

;comet override
13331,13947 -

;14243 DS9 title first frame where visible - for alignment

;fade in intro
14717,14786 +----

;fade in intro
15097,15171 +----

;fade in intro
15472,15541 +----

;fade in intro
15821,15872 +-++-

;fade in intro
16145,16186 ----+

;wormhole open override
16382,164502 +

;override for title fade in
17069 -

;override for title fade in
18203 -

;override for title fade in
18478 -

;override for title fade in
18982 -

;override for title fade in
19843 -

;credits override
79880,81234 p
You can use a simple spreadsheet to adjust the frame numbers in the override for the intro for another episode by using the frame number where the DS9 title is first visible to calculate an offset.

I was also wondering why PP=1 was in the test line and PP=7 was in the production line. Was that just a mistype?
PP=1 calculates the MIC, but doesn't replace any part of the frame. PP=7 uses some parts of the deinterlaced video. It's not a typo. It's intentional so you can see if the source actual has interlacing that should be replaced or not. If you use 7 (or 6) in that line part of the frame will be replaced and you won't be able to see if it should have been or not.

edit: You should not have to change cthresh. Something else much be wrong and that's not the right fix.

[Chir]

You were spot on with my QTGMC not working. It was returning a mostly black screen. Once I fixed that, the issue went away.

I'm off to play around with your ovr file and see if I can pick up on your method!



I so appreciate all the help and patience!!!

[Stereodude]

Oh, you'll want to change the MI in your TFM call to: MI=33. Otherwise there are two frames, 898 and 900, that need to be added to the override file with a -.

[Stereodude]

I've been trying to apply the same processing method to S06E02 and S06E03. S06E02 is largely no issue. S06E03 is a bit more complicated. In it most of the space VFX shots will need to forced (as not combed) in order to avoid false positives and the MIC calculation of quite a few of the video segment after the intro throw high MIC values and will have to be forced (as not combed).

Also, I found a mistake or two in the "intro" portion of the override file I posted last night for S06E01 that I've fixed.

[bladerunner1982]

I found them too :)

;wormhole open override
16382,164502 +

better:
;wormhole open override
16382,16505 +

Right? Anything else?
Is this your way of testing if people are still there? :D

[bladerunner1982]

Another thing:

Maybe its better to reauthor the DVDs first to get vob files for every episode. Makes dubbing the audio later a little bit easier...

I used DVDshrink https://www.videohelp.com/software/DVD-Shrink

Steps:
1. Load Disc
2. Re-author
3. Drag titles from right to left
4. Set no compression for all titles !
5. Backup to a new folder

Now you have vob files for every episode split correctly.
Then making ovr files for every episode...
If you assign seasons to different members it would be much time saving ;)

[StainlessS]

I always use DvdShrink whether episodes or not.
Also, set up DvdShrink preferences, eg set output DVD9 [avoids need to switch to "No Compression" on each title], also select required Subtitles lang etc.
DVDShrink usage helps avoid some minor user mistakes and ReDo's.

EDIT: Some disks may have eg 27 differenct versions of a title, all different length with only a single one that plays properley.
To select correct one [in DS], see how long title is [duration] in a DVD player, and select the title in DS that corresponds to same length,
can be as simple as that [often is as simple as that] when using DS.

[Stereodude]

Another thing:

Maybe its better to reauthor the DVDs first to get vob files for every episode. Makes dubbing the audio later a little bit easier...

I used DVDshrink https://www.videohelp.com/software/DVD-Shrink

Steps:
1. Load Disc
2. Re-author
3. Drag titles from right to left
4. Backup to a new folder

Now you have vob files for every episode split correctly.
Then making ovr files for every episode...
If you assign seasons to diffrent users it would be much time saving ;)
I just use DVD Decrypter in IFO mode to rip each episode to a separate folder on my HDD. I use the stream processing to demux the video and audio streams, but I leave the subtitles in the .vob so I can use SubRip to convert the subtitles to a .srt (it wants a .vob).

[Stereodude]

Right? Anything else?
Is this your way of testing if people are still there? :D
It depends on the episode, but you also have to watch that the titles fading in and out after the intro don't mess up the pattern detection of the underlying video during the fade. It mainly happens when the scene is basically static, or has very low motion. If it does, you get to add more things to the TFM override file.

I didn't notice this until several episodes later. I went back and looked at S06E01 closer specifically for this and found 3 areas where this happens.

;override for title fade in
17069 -

;override for title fade in
17757 -

;override for title fade in
18203 -

;override for title fade in
18478 -

;pattern override for title fade in
18972,19055 pcccp

;override for title fade in
18977 -

;override for title fade in
18982 -

;pattern override for title fade in
19839,19922 pcccp

;pattern override for title fade in
19964,20047 pcccp

A possible alternative way handle the video and not have this issue occur (that I specifically haven't tested on DS9 yet, but have on other things) is to duplicate the video, mask out the area where the titles are fading in, stack the two vertically, and then use the y0 and y1 options for TFM to only look at the portion of the clip with the masking for pattern detection. That way the titles can't affect pattern or duplicate frame detection.

something like: (not currently working as expected)
#deint may be need to be stacked, like deint=StackVertical(deint, deint). Not sure yet because I hit a problem before getting to that point.
h = source.Height()

moverlay = ImageSource("overlay.png", end=1000).ShowRed ("YV12")
mmask = ImageSource("mask.png", end=1000).ShowRed ("YV12")

c1 = mt_merge(inputvid, moverlay, mmask, luma=true)

comp=StackVertical(c1, inputvid).TFM(d2v="VTS_02_1.d2v", y0=(h), y1=(h*2-1), PP=1, flags=5, MI=24, clip2=deint, display=true, ovr="D:\DS9S6D1\E01\tfm_ovr.txt")
#comp=StackVertical(c1, inputvid).TFM(d2v="VTS_02_1.d2v", y0=(h), y1=(h*2-1), PP=7, flags=5, MI=24, clip2=deint, display=false, ovr="D:\DS9S6D1\E01\tfm_ovr.txt")

full=comp.crop(0, h, -0, -0)
masked=comp.crop(0, 0, -0, -h)

#masked.tdecimate(hybrid = 1, dupThresh=1.5, vidThresh=2.3, display=true, ovr="D:\DS9S6D1\E01\td_ovr.txt", clip2=full)
#masked.tdecimate(hybrid = 1, dupThresh=1.5, vidThresh=2.3, display=false, ovr="D:\DS9S6D1\E01\td_ovr.txt", clip2=full)
Edit: It doesn't work here. When fed the stacked clip and excluding the bottom clip with y0 and y1 it does not work. It seems y0 and y1 do not work as expected. The bottom clip still is affecting the matches which confuses me because I've used this method before on videos and it has worked (AFAIK, though I didn't look at it this closely).

Edit2: I made a quasi bug report for this apparent issue with TFM here (https://forum.doom9.org/showthread.php?p=1907771#post1907771). Hopefully Pinterf can take a look.

[Chir]

I think I've learned enough to start going through the episodes and creating the TFM OVR files. I've gone all the way back to the beginning and started from season 1.
If anyone wants to contribute or use the files, I've started a project on Github.

https://github.com/Chireven/DeepSpaceNine

If there is a better place for these, please let me know and I'll share what I'll remove the project and move the work over there.

[Stereodude]

I don't think anyone has attempted to share their work in this way, so that's as good of a place as any.

FWIW, I don't think your handling of the credits in S1E01 is correct. They look to be progressive to me, so the override should be p, not -.

Are you also planning to include a tdecimate override file for each episode (usually needed for the credits)?

[Katie Boundary]

So the problem that we have is that some frames need to be reverse telecined and some need to be deinterlaced, but not both. Would that be a correct statement of the problem?

Not quite. See below...

You want to IVTC all the parts of the original DVD that are encoded as film with a soft pulldown. You still want to IVTC as much of the rest of the video portions as possible. You only want to deinterlace any frames that have residual combing or are interlaced video.

Inverse telecine involves converting the footage back to 24 fps, which is not only unnecessary, but also makes this project about 10x as complicated as it needs to be because suddenly you're in the world of mixed-framerate video which is incompatible with the entire VFW ecosystem.

You will, however, need to do a mix of field-matching and bob-deinterlacing. I provided the script for that earlier.

To deal with this, we'd need to create an OVR file (two actually),

Whoa whoa whoa, no. There is no need to drag OVR files into this. You're making it way more complicated than it needs to be.


I think I figured this out. Going over the docs for TFM, I stumbled across the cthresh parameter. It defaults to 9, and suggested values are from 8-12 -- I had to bump it up to 25.

Oh god no, that is the exact opposite of what you should be doing. Cthresh should be 1-2 if you want to kill all visible combing. Whatever problem you're trying to solve, you're creating an even worse one

You were spot on with my QTGMC not working. It was returning a mostly black screen. Once I fixed that, the issue went away.

QTGMC shouldn't even be used in this sort of situation to begin with.

It depends on the episode, but you also have to watch that the titles fading in and out after the intro don't mess up the pattern detection of the underlying video during the fade.

Or, you could use a method that doesn't require any pattern-detection at all.

mpeg2source("212.d2v")

Y=nnedi3(field=-2)

A=yadifmod2(mode=1,edeint=Y).selecteven()
B=yadifmod2(mode=1,edeint=Y).selectodd()
C=Tfm(field=1,mode=0,cthresh=2,mthresh=2,clip2=A,micmatching=0)
D=Tfm(field=0,mode=0,cthresh=2,mthresh=2,clip2=B,micmatching=0)
Interleave(C,D)

[Stereodude]

Stuff it Katie... Your method returns soft looking video that has nasty cadence judder for nearly all of it. The method Chir is using has no cadence judder retains the original sharpness of the source over as many frames as possible.

[wonkey_monkey]

You will, however, need to do a mix of field-matching and bob-deinterlacing.

[...]

QTGMC shouldn't even be used in this sort of situation to begin with.


Make your mind up.

[bladerunner1982]

Well, I did a full encode of S01E03 with my script from page 2 (Tdeint as deinterlacer) and Stereodude's script (with QTGMC as deinterlacer). Both with and without ovr Files from Chir.
IMHO I would strongly recommend NOT using QTGMC for deinterlacing, because it kills too much details that are later missing in the upscale process.
I sit here 7 feet away in front of my well tuned 50" plasma TV connected to well tuned htpc and I really can see a difference between the two versions.
With QTGMC as deinterlacer (not as a cleaner as I use it after IVTC !) the picture looks to me like an upscale only, but when using Tdeint instead I have a pseudo HD feeling.
And adding grain at the end of the script is necessary in my opinion, because it forces the x264 encoder (btw. crf 16 !) to encode those details in the upscaled 1080p image.
And it really does looking at the file sizes of both encodes (3.7GB vs. 2.9GB)

And I must say that not using ovr files and just standard settings

deint = tdeint()
tfm(d2v=myvideo,clip2=deint)
TDecimate(hybrid = 1)

isn`t that bad either.
I mean for those short sequences (comet,wormhole,exlosions,teleporter) I personally can live with not using ovr files.
I never had the feeling that without them makes some scenes unwatchable.
So my question is: Is it really worth the effort to crawl through every episode only to have the best IVTC version for those short moments, which are only 1-2% of the episode?

Don't take me wrong, I really appreciate the work and time Chir and Stereodude are putting into these files, but is it really worthwhile?

[Stereodude]

Well, I did a full encode of S01E03 with my script from page 2 (Tdeint as deinterlacer) and Stereodude's script (with QTGMC as deinterlacer). Both with and without ovr Files from Chir.
IMHO I would strongly recommend NOT using QTGMC for deinterlacing, because it kills too much details that are later missing in the upscale process.
I sit here 7 feet away in front of my well tuned 50" plasma TV connected to well tuned htpc and I really can see a difference between the two versions.
With QTGMC as deinterlacer (not as a cleaner as I use it after IVTC !) the picture looks to me like an upscale only, but when using Tdeint instead I have a pseudo HD feeling.
And adding grain at the end of the script is necessary in my opinion, because it forces the x264 encoder (btw. crf 16 !) to encode those details in the upscaled 1080p image.
And it really does looking at the file sizes of both encodes (3.7GB vs. 2.9GB)
I don't really understand your conclusion since virtually none of the episode is deinterlaced. Almost all of the episode is handled strictly by the IVTC. With no ovr files there are only 228 frames that will have any deinterlacing used in them out of 81758 frames. Additionally, QTGMC should have minimal noise reduction with the options I posted.

If you're seeing visible differences something else is going on.

I think the ovr file chir put on github doesn't handle the intro correct for S01E03. Frankly, the intro looks so bad, I'd find another version of it from another episode, perhaps in another season, and use that instead (if it's the same number of frames / same content).

And I must say that not using ovr files and just standard settings

deint = tdeint()
tfm(d2v=myvideo,clip2=deint)
TDecimate(hybrid = 1)

isn`t that bad either.
I mean for those short sequences (comet,wormhole,exlosions,teleporter) I personally can live with not using ovr files.
I never had the feeling that without them makes some scenes unwatchable.

So my question is: Is it really worth the effort to crawl through every episode only to have the best IVTC version for those short moments, which are only 1-2% of the episode?

Don't take me wrong, I really appreciate the work and time Chir and Stereodude are putting into these files, but is it really worthwhile?
If you're going to go through the effort to encode all the episodes don't you want to get the most out of it? Further, if chir is doing all the work for you with the .ovr why not use them?

[Boulder]

Additionally, QTGMC should have minimal noise reduction with the options I posted.

I think the tr2 parameter is what causes the denoising. I would try setting tr2=0, it will then bypass the MDegrain phase at the end.

[wonkey_monkey]

Has anyone had a look at the PAL DVDs? I think they used something called something like DEFT or DFET to convert the film sequences correctly and to do their best with the video sequences.

I think I've got seasons 1-3 somewhere. Might see if I can dig them out.

[Boulder]

Has anyone had a look at the PAL DVDs? I think they used something called something like DEFT or DFET to convert the film sequences correctly and to do their best with the video sequences.

I think I've got seasons 1-3 somewhere. Might see if I can dig them out.

That's what was done with Star Trek TNG so it's a possibility that the same approach was used with DS9 a well. SRestore works against that with good enough results.

[StainlessS]

Think DEFT, no idea what it is though. [Have looked for it before and never found any adequate explanation]

DFET variation of Field Effect Transistor, dont know what the D stands for. [EDIT: guessing that D may stand for Dual]
Other variations, JFET [Might be Junction, not sure], and MOSFET [Metal Oxide Semiconductor Field Effect Transistor].
CMOS that you've probably heard of, Complimentry Metal Oxide Semiconductor. [Low power alternative to TTL Transistor Transistor Logic]
DDL, very old pre TTL Diode Diode Logic.
FET, sort of like a transistor, but behaves more like a vacuum tube or valve [I think] very high impedance & sensitive to static electricity can blow them just by touching them.

[Boulder]

Think DEFT, no idea what it is though. [DFET variation of Field Effect Transistor, dont know what the D stands for].

It's a marketing name. Standards conversion by Snell & Wilcox, apparently a bit less worse than simple field blending things we've seen.

[StainlessS]

Arh, that explains why I never found it, probably saw that it was company specific and thought it not what I was looking for, thanks.

[scharfis_brain]

Deft stands for
Digital
Electronic
Film
Transfer

Essentially it is a speedup of 59.94i to 62.5i
then doing 3:2 pulldown to 25p
and if that fails fieldblend conversion from 62.5i to 50i

They however completely borked the vertical field alignment during the 3:2 pulldown scenes.

TNG PAL DVD were undergone this procedure.

Essentially DEFT is a more clever way to do NTSC to PAL converssions that have a lot of 23.976p scenes

[Chir]

I don't think anyone has attempted to share their work in this way, so that's as good of a place as any.

FWIW, I don't think your handling of the credits in S1E01 is correct. They look to be progressive to me, so the override should be p, not -.

Are you also planning to include a tdecimate override file for each episode (usually needed for the credits)?

Yeah; I was completely wrong with S01E01 (and 03). I've since changed it, but I haven't pushed the changes to the project yet. I'll do that in a few. The wife and I have been battling that nasty virus going around and I've not had much time lately -- sorry if anyone wasted time with those...

In regards to the OVR files for TDECIMATE, I'm not entirely sure where they should be used. I kind of have a handle on the TFM ovr files, but I know I don't have it perfect yet.

Is there a more logical way to know which frames to look at for either of the OVR files? I've been doing it by just watching the video and looking for flaws.

I also plan to move on to Voyager after this, so hopefully the foundation that gets built here translates well to that (which I expect it will). I really don't mind doing the work to create them as long as people don't mind asking a million questions and helping me figure it out!

[Stereodude]

The credits at the end are 30p, however they have low enough metrics that tdecimate will drop a frame (treating it as film with a duplicated frame) instead of blending them to 24p. So, the stars behind the text end up moving irregularly. The override forces it to blend them to 24p instead. I didn't find other areas of episodes in my limited testing that were 30p that were incorrectly handled requiring and override. The wormhole opening and closing in the intro might be, but it's pretty much a toss up.

I would expect Voyager is similar, but I haven't actually examined an episode to see.

[Chir]

Oh - I get it now.

I'll move the credits from the TFM overrides to the TDecimate and mark them as P...

[Stereodude]

Oh - I get it now.

I'll move the credits from the TFM overrides to the TDecimate and mark them as P...
You need the credits in both. You need them marked as p in the TFM override and marked as v in the td override.

[Katie Boundary]

Stuff it Katie... Your method returns soft looking video

Wrong. It returns the frames exactly as they appear on the DVD, with no blurring, whenever field matches can be found.

that has nasty cadence judder for nearly all of it. The method Chir is using has no cadence judder

I believe what you mean to say is that my method allows conversion to VFR to be done as a second step, rather than making everything 10x more complicated than it needs to be by trying to deinterlace while in a VFR workflow.

[Stereodude]

That's very rude. You should be nice to the ladies.
Katie might have XX chromosomes, but she's no lady. Katie reaps what she sows.

[wonkey_monkey]

I just tried Katie's script on the sample clip provided. No idea what the aim actually was, but I get a 60fps output with up to four repeating frames at some points, plus a lot of misordered frames.

[manono]

Please stop with the gratuitous insults, Stereodude. If you wish to rebut what she says, then maybe do something like wonkey_monkey and try one of her scripts.

[huhn]

so i looked at the sample and i couldn't find a single part that is interlaced.

it's just 3:2 telecine with PsF credits.

i mean ok the the credits are sometimes only in 1 field but that doesn't change that i couldn't find a single part where the credits fade with 60 FPS not 30.

so what do i miss here?

[Stereodude]

I guess that all depends on how you're defining "interlaced". You can't simply IVTC the thing to p24 and call it a day. There are i60 post telecine fades (in/out of black and into other scenes) on top of the telecined content and the text titles are faded in and out as i60 on top of the telecined underlying image.

[huhn]

not here to say this makes it trivial but this is stuff that's been dealt with all the time it's now similar to broadcast where sometime text with 30 FPS is shown.

[Katie Boundary]

Katie reaps what she sows.

Oh really?:rolleyes:

What I sow:

my method allows conversion to VFR to be done as a second step, rather than making everything 10x more complicated than it needs to be by trying to deinterlace while in a VFR workflow

What I reap:

Stuff it Katie
Katie might have XX chromosomes

Hmmm, those things don't seem very similar.

By the way, Chir, this is exactly the sort of hysterical poop-flinging that I told you about in that PM I sent you. Now you have proof :)

[ryrynz]

Oh really?

up to four repeating frames at some points, plus a lot of misordered frames.

TBH that result speaks for itself, just drop it.

[hello_hello]

You can fix the out of order frames when using the Katie method on the sample, by swapping the field arguments used by TFM, but her method is quite bizarre. I'd be keen to learn how she decimates it for a VFR encode.

Y=nnedi3(field=-2)
A=yadifmod2(mode=1,edeint=Y).selecteven()
B=yadifmod2(mode=1,edeint=Y).selectodd()
C=Tfm(field=0,mode=0,cthresh=2,mthresh=2,clip2=A,micmatching=0)
D=Tfm(field=1,mode=0,cthresh=2,mthresh=2,clip2=B,micmatching=0)
Interleave(C,D)

When I tried her method in an older thread it resulted in duplicate frames that probably didn't need to be duplicates, but whatever makes her happy. She's been told why it isn't as clever as she thinks it is in several threads.
I think Yadif is a new addition to the workflow though. I'm not sure I understand the benefit of telling TFM to replace the combed pixels using a clip de-interlaced by Yadif, which is replacing the combed pixels by taking them from a clip de-interlaced with nnedi3. Maybe I'm missing the obvious, but why wouldn't you use the "Y" clip for TFM's Clip2?

Y=nnedi3(field=-2)
A=Y.selecteven()
B=Y.selectodd()
C=Tfm(field=1,mode=0,cthresh=2,mthresh=2,clip2=A,micmatching=0)
D=Tfm(field=0,mode=0,cthresh=2,mthresh=2,clip2=B,micmatching=0)
Interleave(C,D)

[zapp7]

Hi all, thanks so much for developing this workflow. I've started working on producing override files and have finished S01E01-02 (The Pilot). The output definitely looks better than my old workflow, which was rip with MakeMKV and then detelecine and deinterlace with Handbrake.

One thing I'm not 100% sure about is when to use the p, c overrides versus the + for the TFM ovr file. I'm guessing the p and c ones should be used to correct combing only when the frame fits in with an obvious 3 progressive-2 interlaced pattern. Is that correct?

Another question I have is what is the best way to save this output at the highest quality for input into the Topaz Video Enhance AI software? Right now I'm using ffmpeg with the command:

ffmpeg -i input.avs -aspect 640:480 -c:v copy output.mkv

I tried to fix the aspect ratio because it looked off. From what I understand, this is a lossless file? The output for one episode is about 31GB, which is fine with me as I have a lot of hard drive space.

(Note to @Chir: I'm the one that contacted you on GitHub.)

[SaurusX]

ffmpeg -i input.avs -aspect 640:480 -c:v copy output.mkv

I tried to fix the aspect ratio because it looked off.

Decreasing the resolution before upscaling seems like a wrong move IMO. You want to use all the original details you can. You should use Topaz to expand everything so that your minimum dimensions are met and then downsize after that.

[zapp7]

Decreasing the resolution before upscaling seems like a wrong move IMO. You want to use all the original details you can. You should use Topaz to expand everything so that your minimum dimensions are met and then downsize after that.

Yeah, I think I misunderstood what I needed to do. I figured out that I need to encode with the original NTSC sample aspect ratio (SAR) of 8:9. I'm now using:

ffmpeg -i input.avs -c:v libx264 -preset ultrafast -crf 0 -vf scale=-2:480,setsar=8/9 output.mkv

The original res is 720x480, but I noticed there are black strips on the sides of the image so I trim a few pixels off of the left and right sides in avisynth. The -2 accounts for the slight variance in the x dimension from episode to episode (i.e. 710 vs 706, etc.) depending on how much I trim it.

[Chir]

Yeah, I think I misunderstood what I needed to do. I figured out that I need to encode with the original NTSC sample aspect ratio (SAR) of 8:9. I'm now using:

ffmpeg -i input.avs -c:v libx264 -preset ultrafast -crf 0 -vf scale=-2:480,setsar=8/9 output.mkv

The original res is 720x480, but I noticed there are black strips on the sides of the image so I trim a few pixels off of the left and right sides in avisynth. The -2 accounts for the slight variance in the x dimension from episode to episode (i.e. 710 vs 706, etc.) depending on how much I trim it.


I think this would produce a more lossless result:
ffmpeg -i <your avs file> -map 0:v -c:v copy <your output file>

If you are happy with your results, feel free share your results with the github project that I started. Anyone can contribute!

https://github.com/Chireven/DeepSpaceNine

[zapp7]

I think this would produce a more lossless result:
ffmpeg -i <your avs file> -map 0:v -c:v copy <your output file>


Do you correct for the SAR at any point later in the process? I ask because this command appears to produce a horizontally stretched image. It's not super obvious but it's evident if you compare your output it to the original DVD footage. I used the codec because it's my understanding that SAR can't be corrected using the "copy" command. I read that CF 0 H.264 is lossless so I was hoping that would be sufficient.

I have about 10 episodes "complete", and I put that in quotes because I feel as though I am still learning the whole process and making refinements. There are undoubtedly errors in what I have. Should I share anyway? What do you think?

[JoelHruska]

Hey all,

Just thought I'd post here and introduce myself. I'm Joel Hruska, from ExtremeTech, and I've been working to upscale Deep Space 9.

Some of the workflows I'm currently evaluating are below: When I refer to "my" QTGMC filter, it's nothing exotic -- just a simple repair script, lightly tweaked from the AviSynth Wiki. This isn't all of them -- I'm not in front of my PC at the moment -- so this is just what I can recall from memory.

Handbrake Source -- DaVinci Resolve Studio (framerate conversion to 119.88 fps using dummy frames) -- StaxRip (AviSynth to apply my own QTGMC filter ) -- Topaz VEAI upscale.

Handbrake Source -- DaVinci Resolve Studio (framerate conversion to 119.88 fps using interpolated frames) -- StaxRip (AviSynth to apply QTGMC and decimate the frame rate back to 23.976) -- Topaz VEAI upscale.
)
Handbrake Source -- StaxRip (AviSynth to apply a Doom 9 Deinterlacing filter suggested on the first page + my own QTGMC repair filter + daa3mod) -- Upscale 4x in TVEAI .

Handbrake Source -- StaxRip (AviSynth to apply my own QTGMC repair filter) -- Topaz VEAI 4x upscaling -- DaVinci Resolve Studio ingestion and 119.88 fps conversion -- 23.976 fps decimation in a second run through AviSynth.

Handbrake Source -- StaxRip (AviSynth to apply my own QTGMC repair filter) -- DaVinci Resolve Studio Ingestion and 119.88 fps conversion -- AviSynth decimation back to 23.976 fps -- Topaz VEAI upscaling.

Note that all of the above assume that I'm using a CFR MKV or M4V file created in Handbrake. VBR files have their own dependencies and must be processed in a different order. The five workflows above are more representative than static -- while I'm actively experimenting with all of them, I'm also trying some ideas that aren't listed above.

I do not currently have an option to use MakeMKV. StaxRip will not / cannot match A/V if handed a VFR file -- at least not that I can figure out. I would love to solve this problem by feeding the MakeMKV file directly into DaVinci Resolve Studio, but DRS will not ingest MPEG-2 files. (DRS won't ingest MKV files either, and StaxRip cannot mux M4V files properly. There's a merry hell of file dependencies depending on what kind of source you start with in all this).

In my last article I referred to an encode process I call Rubicon. Rubicon is created by ripping the DVD in Handbrake into H.264 Max Production, CFR (I'm evaluating this workflow in VFR right now, but Rubicon as demonstrated was created with CFR):

After ripping, I ran it through a QTGMC repair filter, set for Input Type 2 on the first pass and Input Type 3 on the second. I then run the QTGMC repair function (daa3mod is used for AA as well). This fixes the interlacing and 3:2 pulldown problems, but doesn't do a great job on the credits.

Once the StaxRip encode is finished, I upscaled the video in Topaz VEAI, dropped the upscaled footage into DaVinci Resolve Studio, interpolated 119.88 frames of information into the video stream (Optical Blend, Large Motion Vectors, Enhanced Better), then ran it back through AviSynth with a ChangeFPS(24000, 1001) command.

This produced the following video (Please set to 4K):

https://www.youtube.com/watch?v=8DwfHADU0QY&feature=youtu.be

For comparison, here's the exact same clip from an upscaled MKV of a DS9 episode that I ran through Topaz Video Enhance AI with no further processing:

https://www.youtube.com/watch?v=DzeENB9JKmE&feature=youtu.be

When I started this project I said I wanted to provide a free software workflow and I mean that. Katie Boundary's deinterlacing filter from Page 1 fixed most of the problems I had in Sacrifice of Angels, and the simple QTGMC repair script I'm using appears to fix the rest. It produces a rather nice 48fps version of the show. There's also the option to rip the VOB directly at 29.97 fps. When the same script is used on them, they become 60fps files, and I'm evaluating that option as well just to see how well it compares.

Finally, I'll be evaluating the impact of leaving the show at 119.88 fps without ever decimating the frame rate down at all. (This only applies to the versions of the show that use dummy frames -- the interpolated "supersmooth" variants are not being used.

Right now, I'm wondering what the best way is to get moire out of the early show credits and out of Episode 1-1, Emissary, where the Borg cube is absolutely riddled with it. Is there a way to remove the rainbow effect with a filter, or does it have to be done by hand?

One question I'd really like to know the answer to, if anybody does: Everyone talks about H.265 in terms of its ability to deliver high-quality results in a smaller file size. I don't really care about that aspect of it. What I'm curious about is this: Does H.265 ever produce better visual results than H.264? Are there times when one should use H.265 rather than H.264 because it results in a higher quality picture *in absolute terms, regardless of file size?*

Happy to discuss results and any of the above. Apologies that it's a bit of a muddle.

Link to my last story, if anyone wants to see the video samples. Set for 4K in all cases when available. I upscaled the same clips from a DVD rip, an MKV file, and my own Rubicon upscale method.

https://www.extremetech.com/extreme/310176-deep-space-nine-upscale-project-season-finale-what-we-brought-ahead

[SaurusX]

What are your QTGMC calls specifically? QTGMC is great and can be used on progressive material, but most of this series does not need it. There are a handful of 60i sequences throughout and that's it. There has already been much discussion in this thread as to the "best" workflow for resolving the interlaced sections of this series. Don't get married to Handbrake.