This is my first attempt at rescaling using Waifu2x. I combined it with Eedi3/Nnedi3 to remove aliasing. Comparision source vs encode - https://slow.pics/c/I8W2VAug I started planning this rip a couple of years ago, since the old rip from VCB-Studio, stored on my PC, did not satisfy me with its quality. When I started thinking about filtering a few months ago, I saw their new version of rip, which also wasn't very good (I mainly mean the video compression quality, but there are also remnants of aliasing and banding). Here's a comparison with this rip - https://slow.pics/c/odCz5BFE When I had already made a rip of the 1st season, I came across a rip from [Vodes]. I have no particular complaints about filtering, but the quality of video compression also leaves much to be desired. AA filtration is better in some places, worse in others. Here's a comparison with this rip - https://slow.pics/c/1g9gwnyx So, you can find some shortcomings in filtering, but it is difficult to find fault with the quality of video compression. Subtitles: styled english softsubs by Asakura It is recommended to use an MPV player to play subtitles correctly. You can add the scripts "*fuzzydir.lua*" and "*sub-fonts-dir-auto.lua*" to the "*scripts*" directory, as well as the following lines to your *mpv.conf* file to automatically load subtitles from subdirectories and fonts from the "*fonts*" directory: *--sub-auto=fuzzy --sub-file-paths=***

https://slow.pics/c/KJIKLYJZ comparison of this encode against a Bicubic (0, 0.6), 1439.75 x 809.75 rescale with pure w2x and no aa or dehalo. I have no comment on whether Beatrice is better than source or not, since the AA situation is very complicated, but I just want to note that the alternate rescale has less haloing despite not running a dehaloer.

Thanks!

@motbob Yes, indeed, your version has less halo - https://slow.pics/c/ytbI38pf But what to do with the remaining aliasing when using only w2x? Scenefiltering AA?

The backgrounds in this anime are 100% 810.0, in scenes with characters 809.8 - 809.9 In addition, the studio performed post-sharpening and previously there were a lot of 810 works, so I would consider the fractional 809.x a detection error.

> But what to do with the remaining aliasing when using only w2x? Scenefiltering AA? The standard practice is to do AA in a separate step after the rescale (or after the doubling and before the downscale back to 1080p). The aliasing in this show is pretty bad. I think most encoders would use basedAA to deal with it. I myself would probably just apply eedi3 on the doubled w2x image and then downscale, or perhaps downscale to 1440p before eedi3 to make the effect of eedi3 a bit more powerful. EDIT: I should mention that applying eedi3 to the doubled image is quite a conservative AA option (much weaker and less damaging than what was used in these encodes, but still fixes some stuff). > The backgrounds in this anime are 100% 810.0, in scenes with characters 809.8 - 809.9 In addition, the studio performed post-sharpening and previously there were a lot of 810 works, so I would consider the fractional 809.x a detection error. I am not prepared to have a discussion about descaling with you. I would prefer to let the screenshots speak for themselves here.

There is nothing to argue about here. You're right that it's 0/0.6, not 0.33/0.33, but you're wrong that it's 809.75, it's quite simple. ┐(‘～` )┌

`python -m getfnative pan.vpy -f 0 -bh 1080 -min 800 -max 820 -sl 0.05 --mode h`  That low point is at 809.75. How are you so confident in yourself here? I bet you're running getfnative without setting `--mode h` or `w`.

Don't blindly trust charts; they make mistakes. You have to use your experience and your eyes and make a lot of comparisons. You can check the scenes with background images without characters and effects yourself and see a 100% match of 810.0, and 809.8 in scenes with characters. Such a mixture of resolutions is unlikely, as is the accuracy of the calculation of fractional rescales, which allows us to judge with a 90% probability the whole resolution of 810. Actually, VCB-Studio also used 810, so...

OK, let's look at https://slow.pics/c/OIllkijH this frame, which is a background with no characters.  Sure doesn't look like 810.0p to me, which is at odds with what you said twice now. Again, why are you so confident in yourself? You use insaneAA at the default 0.3 descale strength, right? So you have *never* actually encoded a show with a pure descale before. Why are you so confident that you're getting the descale correct when you're always covering it up with 70% spline downscale --> nnedi3 or whatever?

motbob spitting facts

>Again, why are you so confident in yourself? Because I've been using descaling since 2016 (using different cores since 2018), and my colleagues at beatrice-raws have been doing it even longer. insaneAA was written in 2012 for AviSynth and was later modified for VapourSynth. While most encoders at that time still used various aasw2() or MAA2() functions and the like, we used the best quality tool and definitions of the original resolution kernels and their meanings. Now that almost all encoders have come to this, many like to make sarcastic comments about our tools, saying they are outdated and poorly written. Well, they were written a long time ago, so such claims are not taken seriously. Regarding the use of descaling power: the pixel-by-pixel algorithm of blending the Eedi3/Nnedi3 result with a neutral blurred kernel provides excellent masking and attenuation of overly strong anti-aliasing and is quite satisfactory for all of us (team members). This algorithm, like the insaneAA filter itself, was invented and written by members of beatrice-raws and yousei-raws quite a long time ago. And finally, I'm not the one who comes into comments to other teams and says what they should code better and what tools they should use. 

It's difficult for me to test frames that are that blurry. I don't usually get reliable results when doing so. > And finally, I’m not the one who comes into comments to other teams and says what they should code better and what tools they should use. As far as this goes, if you (or anyone else) sees that there is a way to drastically reduce haloing in any of my encodes with a different tool, please feel free to make a comment with a comparison showing that. That goes for anyone else, too. If someone pointed out to me that I had used a catastrophically wrong kernel in one of my encodes, I would be grateful.

So.. is it a 809.75 or 810? I saw two curves and two numbers, which one is correct? Who is the liar?

>If someone pointed out to me that I had used a catastrophically wrong kernel in one of my encodes, I would be grateful. I once pointed out that you didn't fix the terrible CGI in Oregairu S3. To which you answered me “I don’t see the difference.” https://slow.pics/c/uPD7i03V >Who is the liar? We can only find out the exact algorithm and resolution from the 8-bit animation studio in the Japanese office, lol. And so, I think it’s 810, motbob what’s 809.75, and I don’t know what Urotsuki thinks, he alone coded this anime without anyone’s help, and apparently he is sleeping now. Well, or if someone suddenly finds a key frame scan, like this one.  Then we can calculate the resolution quite accurately. For example, the key frame above scans A4 paper at 1754x1240 (150 dpi), and the middle frame (active area) with a solid black line has a resolution of 1552x872, and does not contradict the resolution definition of the various tools in this anime (872). Then it will be possible to say more precisely: “I’m right, and this is...”.

Uh, well, regardless of what I might have said in 2020 or 2021 about a scenefiltering issue, I still would be grateful if someone told me how I could improve every single frame of my encode. It seems you would be mad instead of grateful, and so I will keep that in mind for the future.

No, I'm pretty calm. Idle time I don’t like statements in the style of “you’re wrong, because my graph shows something else.” I expressed my opinion and argued for it, you expressed yours. And as I already said, I agree with you that it’s most likely 0/0.6, but I disagree on the resolution. Let's wait, maybe someone will provide more accurate data or we will remain with our opinion. ┐('～` )┌

@LoliHunter Motbob showed a couple examples of where 809.75 had low error and the resolution actually has a theoretical basis with the [match centers](https://entropymine.com/imageworsener/matching/) model. This can be calculated exactly by (1080 * 809 / 1079) and you get 809.7497... Additionally, Jensen has only shown one scene with an 810p spike and the scene doesn't look very suitable for reliable descale testing as it's blurry and doesn't have any decent lines. Now, does a show only have to use one resolution or kernel? Absolutely not, it's indeed possible that there are some 809.75p frac scenes and some 810p integer scenes in the same episode. Furthermore, pixel peeping a bit of Bob's original comp and I don't see anything wrong visually in the scenes I checked. Feel free to draw your own conclusions, but Bob certainly has shown more evidence. In all honesty, it doesn't even really matter what Beatrice chooses to go with as they still use InsaneAA (some weighted merge of Spline36 downscale with the descaled clip and eedi3+nnedi3 back to 1080p) that's heavily frowned upon by encoders of recent times. I'm not sure why they haven't grown and progressed over the years, but I digress

Blending with a neutral kernel allows for light anti-aliasing, whereas eedi3's anti-aliasing is very strong. If you don't apply smoothing, but only descaling - you leave a lot of jaggers, because descaling does not work with 100% accuracy. In addition, in insaneaa all this happens using an internal line mask to minimize lineaArt distortion. If we exclude the correct definition of native-res and upscale kernel parameters from the equation (which is a separate conversation altogether), I have not seen a better tool than insaneaa until now. Most encoders work without any line mask or anti-aliasing at all and therefore they destroy textures or leave small jaggers.

What. Just adjust your eedi3 arguments and supersample before using it? Literally read `based_aa`'s code. Your "neutral kernel" rings, forcing you to dehalo and lose detail. insaneAA is pointless and has no justification of being used today.

But you're wrong, lol. No matter how you configure eedi3, it is very strong. Mixing using a line mask without taking into account chroma with a neutral kernel is 99% better. And everyone has to put up with dehalo and its destructive influence, since often the source material has a ringing even after descaling with the correct settings (it appears due to post-processing after upscaling). We, like most encoders teams, do not use dehalo just like that and we do not bring it into our encodes. Only if one of the encoders made a mistake in the settings, but this is normal. The one who does nothing makes no mistakes. And if you are so sure that insaneaa is a bad remedy, then you can always make your own rip and prove that it is of better quality, if that bothers you so much. So far, the debate “your tools are worse/better” is groundless and ridiculous.

> So far, the debate “your tools are worse/better” is groundless and ridiculous. Except it's not groundless. Motbob's descale looks better than InsaneAA.

>If we exclude the correct definition of native-res and upscale kernel parameters from the equation (which is a separate conversation altogether) I already wrote about this above. The conversation is not in the context of this coding. By the way, if I'm not confusing anything, Urotsuki didn't use insaneaa for this rip, because he needed Waifu2x, lol.

For me this is still the best release yet of jensen encode, the nyaa site feels kind of different world to me, unlike wayback 2010 people's here warm and thankful, I just remembering the better days without social media, probably I'm old enough to see how to world changing and becoming worse..

> For me this is still the best release yet of jensen encode, the nyaa site feels kind of different world to me, unlike wayback 2010 people’s here warm and thankful, I just remembering the better days without social media, probably I’m old enough to see how to world changing and becoming worse… We're all adults here talking about something very technical and having a disagreement over it. Butt out.

I think that's the nature of mankind. In 2010 there was slower internet, weaker hardware, lack of software or so, I remember that some my early encodes (I didn't release them here at the time) took 2 weeks to encode with relatively simple filtering. That was an era of 2-core PCs :)

> I have no particular complaints about filtering, but the quality of video compression also leaves much to be desired While I have no problems agreeing with the fact that my old encodes are subpar at best, it's kinda ironic to be claiming to have no compression issues with those settings. Below is a comp with the latest encode I have for my, sooner or later, upcoming v2. https://slow.pics/c/h1V57I1L (Also [what the hell](https://slow.pics/c/UK1fo6SN) are you guys doing to the chroma in pretty much every recent encode??)

I checked a couple more series out of curiosity, it’s not very similar to 809.75, but it’s quite similar to 810.   

I already mentioned this yesterday, but you gotta stop checking both height and width at once. Check one or the other.

You're checking width and height... that mode got removed for a reason. If it's indeed match centers model like we surmise and 809.75 then the width is a bit different and actually 1439.75 (1920 * 1439/1919) instead of 1439.55 (809.75 * 16/9). Please evaluate the graphs for the height and width separately.

Just throwing this out there mostly as some fun history, but for some time, we've consistently encountered ~719.8 as the resolution for 720p titles when checking the width and height. This result doesn't really have any theoretical backing, which made us rather confused as to why it showed up so much. However, upon incorporating the match centers model, as detailed by Zander and further explained [here](https://entropymine.com/imageworsener/matching/), our descaling outcomes aligned way closer to our expectations, despite the minor discrepancies in width/height. Match edges:  Match centres:  Relatively recently, we figured out one of the key reasons: checking both width and height simultaneously introduces inaccuracies. This is because it assumes the aspect ratio will always remain a constant, which simply will never happen with the match centers model. This is why we keep pushing to check only the width *or* height, not both at the same time. For a 810p show, the results would be the following: `{'width': 1439.7498697238145, 'height': 809.7497683039852, 'base_width': 1440, 'base_height': 810}` This phenomenon may, incidentally, also explain why so many shows appear to have a fractional native resolution, but there's no real way to verify this right now. If you want to automatically calculate the values, [lvsfunc.get_match_centers_scaling](https://github.com/Jaded-Encoding-Thaumaturgy/lvsfunc/blob/master/lvsfunc/util.py#L106-L196) does this for you. Just pull git latest.

OK. Scenes with characters - 809.79. Backgrounds 809.9 - 810. What I talked about earlier. https://i.slow.pics/LX2wDWPs.png https://i.slow.pics/vSyW8Upm.png https://i.slow.pics/VbKX5gE0.png

I neglected to mention, but using genga such as the LycoReco example only gives us half the story. We understand that in actual productions, the studio works with integer resolutions. We've already long settled on the primary factor for fractional "native resolutions" being the upscaling method (match edges vs. centers, etc.), or any processes done that may have led to pixels being missing/added (such as oversampling beyond 1080p and cropping to 1920x1080). So, the only thing we can really glean from production materials are the original resolutions. Now, this is an important step for nailing down how to descale a show, but it's only the starting point. For all we know, it could be `~1549.807 x ~871.807` because of the match centres model, or some other decimal value depending on many factors, many of which could be beyond our knowledge. It doesn't give us the entire picture.


*Jot jot* Can we get this in a remote learning course Senseis? Excellent lecture. [looks on in blissful ignorance]

@Vodes https://slow.pics/c/gTwvCoRN LMAO hist-scenecut error

I can't replicate this. --hist-scenecut doesn't wreck chroma for me. I tried a few binaries.

x265 3.5+131-c5c0aa6fd:[DJATOM's Mod][Windows][GCC 13.1.0][64 bit] 10bit Perhaps the error here is caused by the combination of hist-scenecut with some other parameter. Urotsuki made a comparison above and the differences are clearly visible there.

Yeah, you might be right, it might be a mix of parameters. But perhaps the test had a mistake. A comp with 1) source, 2) filtering, 3) encode(s) would solve the issue for sure.

In the screenshots, 265 without filtering (8 bit bd) was specifically transferred to the encoder directly.