Joel Hruska said:
FrankB,Pleasure to meet you. Before we discuss relative processing technique I should probably provide you some samples. For example:
Nice to meet you, too. You are right: Theoretical discussions are always a bit too - theoretical. Your results are astonishing, especially the captions! I am still sceptical against the whole AI-upsizing (why I wrote here in another thread, if you are interested in pure theory I can search for it), but it seems that maybe I am too old meanwhile - maybe a mix of that fact and some true facts…
But it looks great!
Critics and proposal: For my taste a bit too LESS noise. Maybe you should consider to
-denoise in avisynth (as you did), because the AI-denoising may be worse in quality, thus having full control of the denoising
-scale up denoised, which is necessary for the AI in order not to produce too much “new details from noise”
New:
-mix back some of the original noise(!) - which makes it more natural. F. e. just resize the original in avisynth with nnedi3 or so and mix it back with overlay(…, opacity=0.2) or similar. We do this very often, and it’s common practice in studios to re-noise.
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.
The net effect of TR2=4 or TR2=5 is a substantial improvement in the final output.
You are right concerning aliasing. But you have to pay with less detail before AI (I suppose).
I don’t like the QTGMC “input type” > 0, also because in some scenes it works pretty well, and sometimes suddenly there is quite no effect.I have spent 20-40 hours per week for the past nine months running thousands of encodes of Deep Space Nine. DS9, however, is also my first project.
I wish I had the time for my private projects, too. Hats off to all your efforts, great that there are still people who really pull off something.
Because I was able to work at this project as part of my job, I was able to treat it equivalently to part of my job. This is not to say I haven’t invested huge amounts of time, because I had everything else to do with my job while working on this as well. None of my work responsibilities got shifted. But I also wanted to try and build a new coverage area for ExtremeTech in this space, so… mutual priority alignment.
QTGMC2 = QTGMC(Preset=“Very Slow”, SourceMatch=3, TR2=5, InputType=2, Lossless=2, MatchEnhance=0.75, Sharpness=0.5, MatchPreset=“Very Slow”, MatchPreset2=“Very Slow”)
QTGMC3 = QTGMC(preset=“Very Slow”, SourceMatch=3, Lossless=2, Sharpness=0.5, MatchEnhance=0.75, InputType=3, TR2=5)After a lot of experiments some years ago I decided not to use “placebo” and “very slow” any more, because you lose too many details. In this special case (to feed the AI upscaler) it may be good - but as I said before: You should consider to put SOME of the noise back in the end…
Repair(QTGMC2, QTGMC3, 9)
That seems interesting, I never had this idea!
If you want 23.976 fps output, just throw TFM() and Tdecimate() ahead of the QTGMC calls.
But this would ruin the original 29.97i (cgi) sequences? Or aren’t there any? I am sure there must be, I never checked this myself up to now, just picked it up from doom9 postings.
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.
Baseline DVD. From PastPrologue.
Identical screenshot after processing. Zero upscale: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:
Here’s a pair of enlarged shoulder shots from the same base pair of images.
https://i.imgur.com/OnEo5w3.png (DVD)
https://i.imgur.com/rOgxQEE.png (upscale)
Are you referring to the very faint line above Bashir’s right (left from our perspective) shoulder?
But maybe this is all obsolete with the PAL sources? I am ashamed not to find time for even look at it (apart from watching some epissodes in the late evening, when my brain doesn’t want to think any more…)
If you know a better way to clean up the former into the latter – possibly by preserving more detail on Bashir’s forehead, where my method is losing some of it – I’d love to incorporate it.
We should postpone everything else until you tried the PAL sources, shouldn’t we?
But again: Astonishing!
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:
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.
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.
Because I want to create a project for people to do at home with legal source, asking people to buy PAL is pretty tricky. I want to write an article about the best way to deal with PAL, possibly in partnership with the folks like yourselves and my friend Cyril who have worked on it, if people were amenable to that. Either way, though, I want to be able to give solutions for both.