Note that there is no difference between the "None" and the "Clean" filters when the picture size is 1X or 2X. It begins with 3X.
It's strange, because I had to search on Google to find a capture of the game in its native resolution without any blur :
So, this little blur with the "None" filter is always active.
Here is the game scaled 3X :
And in fullscreen in 1080p :
It's interesting to notice that the native resolution doesn't correspond exactly with a 16:9 aspect ratio, because :
424/240 = 1,7666666666666666666666666666667
But :
16/9 = 1,7777777777777777777777777777778
So the game has to be slightly stretched in fullscreen mode. I don't know if it's a bilinear filter that is used, something else or nothing. It's hard to compare with this blur.
But at least, we can compare how the blur works ! ;-)
I upscaled the original picture 3X with a Point resizer to achieve the 720p resolution (image left) and then compared it with the picture in-game (image right). The picture is zoomed at 400% :
As you can see, if we observe a big pixel (which has 12 pixels here, because of the 3X scaling and the zoom at 400%), the part which is blurry is all around the pixel (to the left, the right, the bottom and the top) and correspond to 1/3 of the pixel (4 pixels on 12 pixels).
If I show you this, it's because I think that this method of representation of the pixel art isn't bad and rather transparent. Maybe we can took our inspiration from this ;-)
Who suspected there is a little blur in this game when there is no filter ? :-P
The only problem is that I don't know what kind of blur it is... :-/
Here is the same picture with an aspect ratio corrected with a bilinear filter, like Higan does :Language: AviSynthA=Avisource("G:\name_of_the_file.avi").convertToRGB24.PointResize(512, 448).AddBorders(0, 16, 0, 16) # the picture resolution is doubled and black borders are added to achieve the 480p resolution x = -1.0 # this shift the picture to the left y = 0.0 OP= 0.5 # the blend ratio B=PointResize(A,A.Width,A.Height,-x,-y,A.Width,A.Height) A.Overlay(B,Opacity=OP) # the shifted image and the original image are blended together BilinearResize(1024, 960) # the picture resolution is doubled with a bilinear filter
In addition, we can upscale the image in a 2160p resolution, for example with a "Spline36" resizer (the one I prefer, because it's equivalent to "Lanczos3", but with less ringing and artefacts) or a "Lanczos3" resizer :Language: AviSynthA=Avisource("G:\name_of_the_file.avi").convertToRGB24.PointResize(512, 448).AddBorders(0, 16, 0, 16) # the picture resolution is doubled and black borders are added to achieve the 480p resolution x = -1.0 # this shift the picture to the left y = 0.0 OP= 0.5 # the blend ratio B=PointResize(A,A.Width,A.Height,-x,-y,A.Width,A.Height) A.Overlay(B,Opacity=OP) # the shifted image and the original image are blended together BilinearResize(1170, 960) # the picture resolution is doubled and the aspect ratio corrected with a bilinear filter
I use the "Resize8" plugin because it uses an anti-ringing filter : http://avisynth.nl/index.php/Resize8
(But be careful ! Other defaults can appear with the anti-ringing, if the scaling factor is too high)
Or we can remove the black borders too :Language: AviSynthResize8(2632, 2160, kernel="Spline36", kernel_c="Spline36")
I know that some of you will find this blurry, but it's like Higan does. I will finish with the question of the aspect ratio, or rather remind what I found, to stay within the theme of the topic ;-) Higan use the same aspect ratio for the Super Nes games that the one which is in this list here : https://pineight.com/mw/?title=Dot_clock_rates I will quote some things that I said (sorry for the narcissism ^_^ ) to help you to understand :Language: AviSynthA=Avisource("G:\name_of_the_file.avi").convertToRGB24.PointResize(512, 448) # the picture resolution is doubled x = -1.0 # this shift the picture to the left y = 0.0 OP= 0.5 # the blend ratio B=PointResize(A,A.Width,A.Height,-x,-y,A.Width,A.Height) A.Overlay(B,Opacity=OP) # the shifted image and the original image are blended together BilinearResize(1170, 896) # the picture resolution is doubled and the aspect ratio corrected with a bilinear filter Resize8(2820, 2160, kernel="Spline36", kernel_c="Spline36")
And so, we calculate the new resolution like this : 256 x (8:7) = 292, 57 In fact, the original ratio of 8:7 correspond to : 256 x (1:1) = 256 Otherwise, you can simply do this : (64:49) x 224 = 292,57 With the standard 4:3, we get this : (4:3) x 224 = 298,66 And with the original 8:7 aspect ratio this : (8:7) x 224 = 256 Finally, with a 4:3 AR on a modern screen, we need to choose the resolution : 292 x 224 or 293 x 224 Higan proposes these resolutions in 4:3 : - Small : 585 x 448 (585 x 480) - Medium : 877 x 672 (877 x 720) - Large : 1170 x 896 (1170 x 960) And the Super Nes Classic Mini proposes a resolution of "877 x 672" too (1280 x 720 with borders).
A screenshot in-game that I took in windowed mode with window size 3X and the "None" filter (edit : it shouldn't be blurry) :
And the "None" filter that I reproduce with an AviSynth script :
Screenshot in-game windowed mode 3X with the "Clean" filter :Language: AviSynthA=Imagesource("H:\source image.png",end=0).convertToRGB24 A=A.PointResize(1272, 720) ## None Filter x = 1.0 y = 0.0 OP= 0.25 B=PointResize(A,A.Width,A.Height,-x,-y,A.Width,A.Height) A.Overlay(B,Opacity=OP) A=Last # Make A as above x = 0.0 y = 1.0 OP= 0.25 B=PointResize(A,A.Width,A.Height,-x,-y,A.Width,A.Height) A.Overlay(B,Opacity=OP)
The "Clean" filter reproduced with an AviSynth script :
But what's really interesting is this game is the "Fullscreen mode". I would even say that it is amazing, because I totally failed to try to recreate it ! Indeed, it looks like if there wasn't any interpolation to display the picture !Language: AviSynthA=Imagesource("H:\source image.png",end=0).convertToRGB24 A=A.PointResize(1272, 720) ## Clean Filter x = 1.0 y = 0.0 OP= 1.0/3.0 B=PointResize(A,A.Width,A.Height,-x,-y,A.Width,A.Height) A.Overlay(B,Opacity=OP) A=Last # Make A as above x = 0.0 y = 1.0 OP= 1.0/3.0 B=PointResize(A,A.Width,A.Height,-x,-y,A.Width,A.Height) A.Overlay(B,Opacity=OP)
I tried with a PointResize filter, but it didn't match :
Here is the image in-game zoomed :
And my reproduction with the PointResize filter :
But as you can see, it's less accurate...
You can even try with a LanczosResize filter, it will look blurry and inaccurate.
But the most interesting thing about the game, to return to the subject of the thread, is that the picture has in addition to be stretched a bit, because the aspect ratio of the game isn't a perfect 16:9 AR.
So, could somebody explain to me how the developers did to create this miracle ? :-P
I'm really interested, because it looks like a perfect solution ! :-)
It's good to scale the image by a non integrer number and to display the image with another aspect ratio apparently.
Bonus :
Super Metroid with a Simple 3X filter only :
Super Metroid 3X with the "None" filter of Sonic Mania (it's wrong, because it already wasn't correct in Sonic Mania on my desktop PC) :
Note :
You just need to put this at the beginning of the script :
The rest is always the same. Super Metroid 3X with the "Clean" filter of Sonic Mania :Language: AviSynthA=A.PointResize(768, 672)
I find this really interesting ! :-)
Personnally, it's the "Clean" filter that I prefer !
Edit : You were right Aktan, the picture shouldn't be blurry with the filter on "None", even with the windowed mode. Because on my laptop, I didn't notice any blur in Sonic Mania with no filter. So there is a strange problem with Sonic Mania on my desktop PC with the filter on "None" in the windowed mode.I was too focused on the perfection of the reproduction and the technic with the blended images ^_^ So in fullscreen it's another technic, the picture needs to be upscaled 4X with a PointResize filter and then, it's simply a bilinear filter to achieve the 1080p resolution ! And for the "Clean" filter, it's simply that :Language: AviSynthImagesource("H:\source image.png") ## 1080p None Filter PointResize(1696, 960) # Simple 4X BilinearResize(1920, 1080)
So, there is no magic ! :-P However, the scripts that I posted above are still correct for the windowed mode of the game. To conclude, I will just say as I said before, that really I think that the Bilinear filter is the best to smooth the image and correct the aspect ratio of these old games. It's the most natural I find ! I tried with Bicubic, Lanczos, Spline36, etc., but the ringing... ugh ! And with the anti-ringing filter, it's strange ! In fact, I would only use one these filters to upscale a high resolution image to a higher resolution (Spline36 + anti-ringing personally). But for the low resolution image, I think the bilinear filter is better. So, I still prefer the "Clean" filter in "Sonic Mania", with the resolution doubled with a Point resize filter and then the picture upscaled to the 1080p resolution with the bilinear filter. Oki ! End of the story ! :-D Edit : I changed my mind and finally have adopted the "None" filter, because with some phases of gameplay, it's easier when you see better ! ^_^ And it's more clean in fact (than the "Clean" filter...). But is just for playing ! Because even in 2160p, I would prefer the association of a "Simple X4" filter with a bilinear filter, than simply a "Simple X8" or "X9" filters, too blocky I find and therefore unsightly. In fact, I tried with lots of low resolution images (224p, 240p, 480p...) and for me the ideal would be to have the half of the output resolution with the PointResize filter and then achieve the output resolution with the Bilinear filter. In a perfect world, it would be the perfect compromise I think (particularly with 480p contents). If I take for example a Super Nes game with a resolution of "256 x 224", in the ideal I would like to get this :Language: AviSynthImagesource("H:\source image.png") ## 1080p Clean Filter PointResize(848, 480) # Simple 2X BilinearResize(1920, 1080)
Or this still for example :Language: AviSynthImagesource("H:\source image.png") PointResize(1024, 896) BilinearResize(2048, 1792)
But it's not the ideal for our current standards. So in 2160p, this is better, with the correction of the aspect ratio in addition :Language: AviSynthImagesource("H:\source image.png") PointResize(2048, 1792) BilinearResize(4096, 3584)
Si it's still equivalent to the Clean filter of Sonic Mania. But the only problem is that it seems a bit too blurry in 1080p. But with a 2160p resolution, I'm sure it's perfect ! ;-) I know it's a question of tastes, but I think it's the ideal for the old games ! For the modern 2D games in pixel art, it's another story... With recent games like "Celeste" or "Axiom Verge", I would never have the idea to use a Bilinear filter, and a pixel perfect mode is of course better ! But as I said before, these new games were thought to be displayed on modern screens, whereas the old weren't ! And I think that lots of people know how the blurriness of some cables and screens were important to have some proper effects in lots of these games with the dithering for example, etc. The interesting posts concerning the subject of the thread (the aspect ratio correction) : http://tasvideos.org/forum/viewtopic.php?p=486114#486114 (the end of the post) http://tasvideos.org/forum/viewtopic.php?p=486163#486163Language: AviSynthImagesource("H:\source image.png") PointResize(1024, 896) BilinearResize(2820, 2160)
Forgot to post links to the videos. Setting DAR: https://www.youtube.com/watch?v=VHCIp5kPn4s Pixel Stretching: https://www.youtube.com/watch?v=WD2uE6lA2RI
Interesting, but how did you do the pixel stretching method? Please post your script. The reason why we don't use the flag is control. If we stretch it ourselves before sending to YT, we have control on how the stretch would take place. It's because we did the stretch already that causes the filesize to increase. This is a given. Depending on how YT does the stretch, it could end up with a smaller file size than how we do it, since the method we stretch is suppose to be an higher quality stretch.
I posted the ffmpeg commands used in the test, I simply did a nearest neighbor scale to the intended resolution. I think testing a stretch directy to 5974x4480 should be tried as well, as this scales the height by an integer.
Test 1: Do we need to convert from RGB to YV24 to YV12 to preserve quality, versus converting directly from RGB to YV12?
The script has had this "double" conversion for some time now, and Aktan recalls that it was likely originally done because there was a bug in AviSynth that caused direct conversions to YV12 (4:2:0) to either ignore parameters, or suffer some other type of quality loss. There is mention of an issue that sounds quite similar in official Avisynth documentation on this page: http://avisynth.nl/index.php/Sampling#RGB_-.3E_YUY2_conversion. Relevate quote:
(In v2.58, the [0 1 1] kernel was used to interpolate chroma. This is technically wrong and results in a 0.5 pixel right shift of the chroma, but it was originally done for performance reasons.)
RGB -> YV12,PointLanguage: AviSynthwide = AviSource("E:\xtreme\2Xtreme.avi") wide1 = wide.ConvertToYV12(chromaresample="point") wide2 = wide.ConvertToYV24(chromaresample="point").ConvertToYV12(chromaresample="point") # Extract chroma planes for comparison since luma should remain unaffected and will make comparison more difficult. wide1.ExtractU() wide2.ExtractU()
RGB -> YV24,Point -> YV12,Point
XORing these planes together in Paint.net yields a uniformly black (0,0,0) image, meaning that the planes are identical, and the trip through YV24 did not make a difference.
Let's test the internal order of operations of the convert functions to ensure that the transfer function is performed first, then resizing.
RGB -> YV24,Point -> YV12,LanczosLanguage: AviSynthwide = AviSource("E:\xtreme\2Xtreme.avi") wide3 = wide.ConvertToYV24(chromaresample="point").ConvertToYV12(chromaresample="lanczos") wide4 = wide.ConvertToYV12(chromaresample="lanczos") wide3.ExtractU() wide4.ExtractU()
RGB -> YV12,Lanczos
XORing these planes together in Paint.net yields a uniformly black (0,0,0) image, meaning that the planes are identical, and that converting directly to YV12 preserves the desirable order of operations.
Test 2: Increasing bit depth prior to color space conversion, dithering, and other assorted goodies courtesy of Aktan.
Aktan provided a technique for colorspace conversion that might improve accuracy:
Code as posted produces:Language: AviSynthAviSource("E:\xtreme\2Xtreme.avi") # Assume RGB32 source ConvertToRGB64() # ConvertToYUV444(matrix="Rec709", chromaresample="point") # Might be needed? Needs testing ConvertToYUV420(matrix="Rec709", chromaresample="lanczos") # Conversion from 16-bit RGB to YUV 4:2:0 16-bit ConvertBits(bits=8, dither=0) # Reduce back to 8-bit color with dithering, bits=10 for our encodes in 10-bit color ExtractU()
Code with optional conversion to YUV444 enabled:
XORing these planes together shows that they are identical, so the trip to 444 (as with the previous test) appears unnecessary.
Here is the full image using Aktan's method:
Here is the full image, converted directly to YV12 with Lanczos:
Here is the XOR of these two images:
Very unsurprisingly they are different (there is dithering going on). No conclusion, subjective difference would have to be examined. Take the two images into paint.net, put them on separate layers, and switch between them if you want to try to determine which is subjectively better.
Sorry I didn't mention it right away. The reason I suggested testing this on 512px mode of PSX and/or A2600 is to see how it compares after ARC. Because ARC is what makes them inherently not pixel-perfect. And heavy ARC is what may kill things really hard (slight fractional ARC too tho). But since we don't target 1x anymore, it also has to go 2x with pixel first, and then shrink or stretch width without changing height, because height isn't meant to be stretched by fractional factor. Finally, this test image has a lot of almost-white on a lot of almost-black, which means color changes are almost pure luma too. Good comparison would be going from chroma to no chroma (or vice versa), because detail loss is the most apparent there. As long as there's a lot of chroma, even changes from one chroma color to another won't make the loss apparent. EDIT: I'm switching between the 2 resulting images above at 1000% zoom I can't tell which one is better.
ControlLanguage: AviSynthAviSource("kain.avi") # 560x240 (512,240 framebuffer) PointResize(1120, 480).LanczosResize(640, 480) one = ConvertToYV12(chromaresample="point", matrix="rec601") two = ConvertToYV12(chromaresample="lanczos", matrix="rec601") #Aktan's method ConvertToRGB64() three = ConvertToYUV420(matrix="rec601", chromaresample="point").ConvertBits(bits=8, dither=0) four = ConvertToYUV420(matrix="rec601", chromaresample="lanczos").ConvertBits(bits=8, dither=0) ExtractV()
YV12, Point
YV12, Lanczos
Aktan's Method, Point
Aktan's Method, Lanczos
After doing this, I realize that this game as probably a bad pick for this because it's dark and kind of dull. For this type of content (full 3D), the differences between point and lanczos sampling is nearly indistinguishable to me. Aktan's method vs straight to YV12 has differences that are a little more different though - if you zoom in a LOT, you can see that there seems like a very slight increase in contrast for the strictly YV12 route, vs smoother gradients in Aktan's (expected because of dithering). The difference is very small though and you've gotta squint.
I think that this sampling may have a bigger effect for pixel-y games. Anyone want to recommend a 2D, 512px mode PS1 game? Someone should test A2600.
