logo Sign In

Post #1374796

Author
FrankB
Parent topic
Star Trek Deep Space Nine - NTSC DVD Restoration & 1080p HD Enhancement (Emissary Released)
Link to post in topic
https://originaltrilogy.com/post/id/1374796/action/topic#1374796
Date created
12-Sep-2020, 4:10 PM

Joel Hruska said:
Alright. Now I see it. If that’s what you call a major anti-aliasing problem, I strongly suggest you never watch the NTSC credits. I cannot upload them to YouTube in SD because the YT algorithm utterly destroys SD content, so I have to give you screenshots – but take a look.

Looks like shifted fields. Can you upload the credits, or a few seconds of it, without conversion somewhere?
I do not understand where the problem realy lies?

Look at the degree of aliasing in those images, and I think you’ll understand why I’m experimenting with TR2=4 or TR2=5. TR2=3 creates a ripple across the front of the station that TR2=4 (at least) helps fix.

Seems not the right way to handle this, but let me see it first - maybe I will have to admit it IS that horrible. But hard to believe.

The reason to write an article telling people how to deal with PAL is so that PAL people know how to best convert the show. I am not advocating for some kind of code of honor. I want to produce the best overall version of Deep Space Nine. But the goal is to provide a “Best-in-class” improvement method to everyone, which means I’m also interested in the best way to handle PAL.

Not much difference to NTSC. After you made NTSC sources progressive and the anti-aliased possible rest of aliasing which came from reordering fields it should be pretty much the same procedure plus a slowdown at the very end.

Doom9 is correct that IVTC is complicated. The only way to perform it perfectly, as far as I know, is to hand-comb every scene and manually tune the frame order method via a TFM OVR file.

It is even better not to write a file for TFM, but to IVTC completely by hand. Not very complicated, I do this all the time, if the pattern doesn’t change too often. With the amount of episodes it is quite a job, though, but writing files for TFM also… If you like, I can post a typical script for by-hand-IVTC.

However – it turns out that the following actually works pretty damn well:

TFM()
TDecimate()

Would be easy then, but if you do so with native 29.97(i or p) content there will be missing frames and skipping (is that the right word?) all the time.

I have also developed a secondary method of creating a 60 fps method of the show that matches the quality of what I’ve shown you.

No good idea, because it doesn’t remove stuttering from telecine-double-fields. That is the whole problem with content like this. Progressive 30, 60 will stutter with originally film=24fps. How could this be avoided? There have to be double frames, at least fields, or can you divide 60 through 24?

Still searching for a way to automate it perfectly (the commands above are automatic, but not perfect).

Don’t exactly know, what’s your goal. But simply the first necessary, to IVTC, is not perfectly automatically possible. That’s why we do it by hand if ever possible.

Initial evaluation of naive implementation of AniMaxx’s algorithm suggests it’s oversharpening in my case. I like the overall output otherwise. Going to adjust some variables, then toss in the rest and see what it looks like. 😃

I wouldn’t sharpen at all, only a bit unsharpmasking, but that’s another question… 😉