Joel Hruska said:
I’m experimenting with renoise options at the moment, to see how they impact things. Also, yes, trying to calibrate the proper amount of processing and denoising to do in the front-end before letting an AI program have a go at it. Some AI models include denoising that works effectively but I’d rather not have to use them in the first place.My opinion: Better choice. Because it will kill details rather than create “new ones”, if you let the AI denoise. Just my experience, there may be other scenarios. Renoising - to say it again - is best if you use the original noise. This is not common practice, by the way. Mostly they use some more or less random algorithms, as you surely know.
It’s not the FX scenes that are automatically in 29.97. In fact, in the first season, at least some episodes are basically 100% film. I don’t know when this stops. In others, like Sacrifice of Angels, most of the battle scenes are 23.976 fps, though there’s one post-credits scene that has preserved incidents of 3:2 pulldown in a 29.97 fps stream. That one threw me for awhile, trying to figure out how that could happen. Baked-in source error is awesome.
So there ARE pulldowned 23.976 and native 29.97 scenes, right? Just this fact makes it A LOT harder to deal with the NTSC sources instead of PAL, if you finally want
-progressive (to use with AI)
-stutter-free
results.
In addition the PAL sources have less aliasing. So two very strong reasons to use PAL as sources.
And are there also scenes where they overlayed both? Am I right with this speculation? We had this in a series I worked at a few years ago, also SciFi, made about the same time as DS9, a bit earlier. The overlayed scenes are definitely not stutter-free, and there is no way to IVTC it 100% correctly.
We handled, by the way, the native 29.97 scenes different from the well IVTCed 23.976-scenes and had to convert it with Alchemist optical flow, which was the best option at that time (today also AI is somehow better in these cases…).Sorry, but in screenshot 2 there is more aliasing than in 1. Look at the shoulder.
I’m not seeing it. I see one pattern that might be what you are talking about, but doesn’t come across as aliased when the actor is in motion:
The most left part with the light background. A big difference concerning “staircases”.
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.
https://i.imgur.com/JBV6gtu.png
That’s a close-in zoom on the station and the runabout passing it. Here’s a few frames in sequence. I’m going to give you each frame so you can see what I’m working with:
https://i.imgur.com/t0QiE1a.png
https://i.imgur.com/qGbQlBX.png
https://i.imgur.com/r9PcDef.png
https://i.imgur.com/uILnJdN.png
https://i.imgur.com/cHK9fCC.png
https://i.imgur.com/BeHLD4Z.png
https://i.imgur.com/gmUSqFp.png
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.
Deinterlacing is enabled in these images. That’s not what the output looks like without deinterlacing. That’s what the output looks like with deinterlacing, although it is being assembled from the 29.97 fps D2V file. If you watch a MakeMKV file it’s not so terrible looking, though I was never able to find a way to start this process with a MakeMKV-derived file and wind up with smooth motion at the end of it. I’m not saying it isn’t possible – but I searched for a way to create smooth motion out of a VFR MakeMKV base-file for about six of the nine months I worked on this project, and found a way to create first a perfectly smooth 60 fps version and then a 23.976 fps version (with help from Cyril, who is also working on the PAL version of the show). Regardless, the credits are the absolute worst-looking part of the show on NTSC.
I don’t see why. I have access to the whole PAL show if I want it, but I also have episodes on-hand from S1 and S6. The PAL quality, as near as I can tell, is virtually identical to NTSC quality with the following differences:
Reasons are above. Of course, your decision.
1). Motion is intrinsically smoother and easier to deal with. NTSC can be brought back to PAL quality in this regard, but it’s taken me more work to do it.
I will have to check this once myself. I only read that IVTC seems complicated at doom9.
2). There’s a very slight color shift, at least in S6. Colors that are slightly more blue in NTSC are slightly more purple in PAL.
3). PAL is stretched slightly and just slightly blurrier by default. Compared this frame-by-frame in NTSC vs. PAL editions of S6.
4). PAL, of course, has the 4% audio shift.These are of course no significant reasons to take the PAL sources, I agree.
Because I want to create a project for people to do at home with legal source, asking people to buy PAL is pretty tricky.
Come on… I do love this code of honour that people obey here, but the difference between PAL and NTSC sources of the same show is purely technical.
I want to write an article about the best way to deal with PAL
What do you mean by “deal with PAL”? To convert it (back) to NTSC? For me it’s no question, I am in PAL-country, for me the question always is “how to deal with NTSC”…
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.
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.
However – it turns out that the following actually works pretty damn well:
TFM()
TDecimate()
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. The same Repair command I mention above will get rid of the frame blends and interpolations created by using TDeinterlace in double-output method and raising the frame rate to 60 fps. I may have even found a method of doing it all in a single script without a quality loss (right now, you have to use two different files to create a third using my 60 fps conversion method, IF you want the final quality to match the 23.976 fps method and to show no blended frames). I may have found a way to do it in a single ingestion with no loss of quality.
My Rio Grande encode uses 23.976 but is not perfect. It handles the majority of video content correctly but not all of it. Right now, my solution to that problem is to keep looking for ways to improve it while offering Orinoco at 60 fps as an alternative if someone runs into a problem episode. If I have to ask people to accept a few seconds of jerky motion every few episodes as a cost of getting this kind of quality improvement (or, alternately, to build that episode in 60 fps), that was a fair-sounding tradeoff to me.
One of the major goals of my project is an automated process. I want people to need to make as few script changes as possible and while I’m willing to do a custom script to fix an episode if I must, I’m trying to avoid that being necessary. The hand-combing and tuning that works for IVTC if you do it manually will unwind DS9 in perfection, but I didn’t want to do the scene-by-scene combing that it apparently requires. Still searching for a way to automate it perfectly (the commands above are automatic, but not perfect).
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. 😃