1 2 3 4
Posted: 8/7/2018 7:33 PM
Quote
Aktan
Publisher
Joined: 4/23/2009
Posts: 1283
creaothceann wrote:
Which is ideal for framerates close to 60 fps, e.g. the SNES.
You should specify that, since my first thought was like DooM 35 FPS =p.
Posted: 8/18/2018 1:51 AM
Quote
TheCoreyBurton
He/Him
Joined: 10/14/2013
Posts: 335
Location: Australia
I was curious about Youtube's current handling of AR flags and so I dumped some NES footage today and did two tests. The first was encoded losslessly with x264rgb at native resolution, muxed to MKV with a display aspect ratio of 16:9 and uploaded. The resulting video was encoded and played back in 16:9. The second test was point-resized to 823x720 and encoded with Lagarith, then muxed into MKV with a display aspect ratio of 4:3. It's playback resolution was 960x720. This could also have an interesting impact on the integer resizing suggestion I made, as a single scale value could be used for all resizing operations. If we divide the target height (2160 for example) by the initial height (224 in this case) and round up, we get a scale value that would provide a resolution equal or higher than the target, which can then be applied to both width and height to keep the pixel sizes consistent, then the aspect ratio can be set in the container for the final output. The significance of this is that the publication process would be faster, particularly with longer runs. We'd get smaller files (or alternatively higher quality encodes at the same size), which would help significantly in cases where encodes exceed the upload limit and have to be re-encoded at lower settings (sometimes several times). Smaller files also upload faster, and the encode process would take less time with integer point resizing than non-integer. The problem with this idea is that it's very likely that Youtube's resizing is inferior to our own method. Whilst downscaling might be fine, in this case it would be used for upscaling the width to reach the destination, which will likely add unwanted horizontal blurring or distortion. Depending on the severity and the comparison between this and our current way of encoding, it could very well be better to keep doing things the way we're currently are. I didn't expect either of these tests to work correctly and so I hadn't prepared anything to properly follow up. I'd like to see a comparison in streams that have been encoded both ways and processed by Youtube before drawing any proper conclusions. More testing is required at this point, but I thought I'd post this and my thoughts for now.
I'm not as active as I once was, but I can be reached here if I should be needed.
Posted: 8/18/2018 9:28 AM
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
It was really hard, but I found my old test: http://tasvideos.org/forum/viewtopic.php?p=456368#456368
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 7/9/2019 4:34 PM
Quote
SuperLumberjack
He/Him
Joined: 7/9/2019
Posts: 27
Location: France
Hello :-) I'm French and new on these forums. I don't want to do TAS videos, but I love the videos of the "TASVideosChannel" on YouTube and often watch them. However, I like to do some simple videos of gameplay that I share with my friends on Facebook, particularly of Super Nes games, just for fun ;-) So I tried lots of things with AviSynth's scripts too, to get a perfect picture, but as you all know, it's almost impossible to have something authentic, as in our memories, on our modern screens :-/ Despite this, I continue to test some new thing, but without stress ! But it's only some days ago that I got the idea to read some interesting things on your forums. If I had known this before... ^_^ So, I fell on this topic, which is very captivating, because it talks about the question of the aspect ratio and propose lots of interesting AVS scripts. The only thing I can say is that for the Super Nes games, I personnally don't use the perfect 4:3 aspect ratio. I take the same aspect ratio than Higan or the Super NT that suggest to take a resolution of "1410 x 1080" for example in 1080p. Here is a picture with 4:3 AR and a resolution of 1170 x 896 : Here is a picture with the original AR of 8:7 and a resolution of 1024 x 896 : I read this too :
Now here comes the important part: People generally get wrong how to aspect correct the SNES. They think you take the 256×224 active area and stretch that to a 4:3 image. That's not how it works. Instead, a formula is devised based on the pixel clock rate. In the case of the NES, SNES, and Genesis's 256×224 mode, the formula is 256 * 8/7, which equals about 293×224 for proper aspect correction. When scaling, the most accurate approach is to scale first and then apply the formula. So 2x scale would be (256 * 2) * (8/7) = 585×448 and 3x scale would be (256 * 3) * (8/7) = 878×672 and so on. Of course it's better to use multiples of 2 when it comes to digital displays, so for 1x scale: 292×224, and 2x scale: 584×448.
(source : https://www.neogaf.com/threads/best-nes-snes-and-gba-emulators.1433788/page-6 ) And this :
At 5.37 MHz, exactly 280 pixels fit into 52.148 μs. The ColecoVision, Master System, NES, and Super NES fill 256 of these with picture and the rest with black or solid-color side borders that fit in the overscan part of the signal that a TV doesn't display. To stretch 280 pixels on 240 scanlines to a 4:3 frame requires stretching each pixel horizontally by a factor of 8/7, giving an 8:7 pixel aspect ratio. Vertically, the NES always produces 240 scanlines, and the Super NES is switchable between 224 and 239. But it's traditional to crop the image at 224 lines as a rough approximation of what a TV cuts off. Thus in 720p mode, the device scales the 256x224 pixels produced by the built-in emulator to about 256*8/7*3 = 878 pixels wide and by 224*3 = 672 pixels tall. Elsewhere, I've collected a list of dot clock rates for classic arcade, console, and home computer platforms' picture generators and their resulting pixel aspect ratios.
(source : https://gaming.stackexchange.com/questions/318935/what-is-the-difference-between-the-43-mode-and-the-pixel-perfect-mode ) What do you think about all of that ? :-) (excuse me if my English isn't perfect :-/ )
Posted: 7/9/2019 9:18 PM
Quote
SuperLumberjack
He/Him
Joined: 7/9/2019
Posts: 27
Location: France
Here are all the exact PAR for the different consoles ;-) : https://pineight.com/mw/?title=Dot_clock_rates Exemple for the Sega Genesis and PlayStation 320px mode which have a exact PAR of 32:35 : If I take "Sonic the Hedgehog" and its resolution of "320 x 224", we will get this : 320 x (32:35) = 292,57 So a resolution of : 292 x 224 or "584 x 448" or "1410 x 1080" or "2820 x 2160" if I keep even numbers only.
Posted: 7/10/2019 3:59 PM
Quote
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Here's what I know: NTSC is 525 lines per frame, 262.5 lines per field. The last line of the first field ends at the bottom center of the screen, and the first line of the second field starts at the top center. That odd line pushes the second field between the lines of the first field. The frame rate is 60Hz for black & white NTSC and 60/1.001Hz for color NTSC. The SNES and other consoles (usually) don't output the odd line, creating a slightly faster progressive display. The field rate becomes the frame rate. There are 8 lines of VBlank at the top, followed by the active display, followed by 7 lines of VBlank. The first line of the active display is forced to black because the sprite buffers are initialized during that line. For the TV, line 0 is just a regular line. Many (but not all) games don't account for that blanked line, often creating a line at the bottom that is essentially garbage, easily visible on emulators. The duration of a SNES scanline is 1364 master clock cycles (master clock frequency is 5 * 7 * 9 / 88 * 6 MHz) except for certain cases.
Posted: 7/10/2019 5:04 PM
Quote
SuperLumberjack
He/Him
Joined: 7/9/2019
Posts: 27
Location: France
Whaou ! Impressive knowledges ! :-P I must admit that I'm not really familiar with all of this, so I just copy what I read here and there ^_^ It's not always easy to understand, it's a big jungle ! But so, do you agree with the question of the aspect ratio, or it seems fanciful for you ? ;-) Is it better to choose a real 4:3 aspect ratio or to choose these particular AR for each console ?
Posted: 7/10/2019 6:08 PM
Quote
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
It depends on what you're interested in. For casual playing on a TV I might just use bilinear filtering to 4:3 - it's cheap to generate and not very close anyway. For playing on a PC monitor I might prefer a CRT shader that uses the correct aspect ratio. For comparing an emulator's output with the real hardware (I have an OSSC and a capture device) I'd disable all image processing.
Posted: 7/10/2019 7:09 PM
Quote
SuperLumberjack
He/Him
Joined: 7/9/2019
Posts: 27
Location: France
I always regret having sold my Super Nes :-( I think I would have used it with an OSSC too on a modern screen ;-) Today, I play on emulator of course, but I plug my PC on the TV. I use generally a "Simple X2" filter with bilinear filtering in 1080p (before I prefered to use a "XBRZ X2" filter, but I think it's to artificial). It's not perfect, but enough natural I find. The real problem is when we want to do some videos of gameplay. I think I am on the good topic ! ^_^ What is the best way to represent these games when we want to show them to other people ? It's so subjective ! Personnally, I think there is a big problem with the approach to representing what we call now "pixel art" ! I think there is a confusion between the "old 2D games" and the "modern pixel art". I thought about all of this, and I think that "pixel art" has become a deformation of what the old 2D games were. OK. In these days, we see "pixels" with these games on a modern screen. But I don't remember that I have seen any pixels when I was a child and played with my Super Nes on a CRT TV. There were only graphics, often great graphics, I saw what it was supposed to be represented, but not the pixels ! It was all the magic of the trick ! In addition, it's clear that CRTs softened the image and did like a sort of natural anti-aliasing. To see pixels, I had to put my nose close to the screen :-D It's why I'm also not a fan of the "CRT shaders", even if I find that some are really great and impressive ! :-) But for me, it's a part of the new deformation of what retro games should be. Because the "scanlines" and "the pixels"... I only noticed them when I was glued to the screen ^_^ So, all of that to say that all the modern, indies, "pixel art" games have tended to make us forget what were the old games on an old screen, the sensations, the feeling, the immersion, etc. It's like the "modern retro" for me. We create a new myth of what it was in the past. I will attempt to conclude ! :-P For me, the modern "pixel art" aren't a real evocation of what the 2D games were. It's something different, because the old 2D games were nice on an old screen and are now pixelated on a modern screen. It's just a consequence ! So, I think there are the "modern pixel art games", that tends to expose the pixels and render them aesthetic. It's a kind of new "aesthetic", clearly a modern approach ! And there are the old 2D games, that were only art because developers arrived to create amazing graphics with big technical limitations. For me it's not the same. It wasn't supposed to be "pixel art" ! Sorry if I'm long ! But through this, I want to ask one question : is it now better to represent these old games with big perfect pixels or is it better to soften a bit the image ? Aren't we too focused on the quality and the perfection of the image today, but at the cost of the soul, the emotions and the ambiance of what we want to represent ? ;-)
Posted: 7/10/2019 7:23 PM
Quote
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
SuperLumberjack wrote:
It's why I'm also not a fan of the "CRT shaders", even if I find that some are really great and impressive!
Very impressive...
Posted: 7/10/2019 7:55 PM
Quote
SuperLumberjack
He/Him
Joined: 7/9/2019
Posts: 27
Location: France
Yes, I know this picture ! ^_^ The difference is really amazing, that's true ! :-) All of that to say that I'm still in research to find the better way to represent these old games in these days ! But I saw that I'm not the only one, because there are lots of AVS script on the previous page ! :-P By the way, concerning these scripts and the conversion of the color space, personnally I don't convert the video to a YV12 color space. I work with RGB24, but I export the video with a lossless codec that convert the RGB24 to the YV12 color space. It's the codec "UtVideo YUV420 BT.709 VCM" : https://www.videohelp.com/software/Ut-Video-Codec-Suite If it can be useful ;-) I think it's less complicated and the result is very good. And we got a lossless file ready for the encoding with the good color space and the good color matrix. Here is a screenshot zoomed X4 to compare (left RGB 24 - right YUV 4:2:0 with the codec) : RGB 24 : YV12 with the UtVideo codec :
Posted: 7/11/2019 1:31 AM
Quote
Aktan
Publisher
Joined: 4/23/2009
Posts: 1283
Welcome to the forums SuperLumberjack! I'm happy to see more people in search of the best image quality. Regarding your last post, the reason why we use YV12 is because we rather control how we get to YV12 instead of letting YouTube do it. Basically, the conversion to YV12 is the last step and we would like to control how the color information is thrown out. I hope this makes sense. Now, as to the matter on how to display retro games on a modern display, as you already stated, that is highly subjective. Without going way too off subject, I'm a fan this type of up-scaling for older games: https://www.youtube.com/watch?v=axDY3OBjxzA Here is another example on NES: https://www.youtube.com/watch?v=KkP7EscUrl4 This uses the very processor intensive method of nnedi3 up-scaling. Going back to the technical aspect of the perfect AR correction, I must admit I'm not sure how good our method is. I've not had the chance to read through the links, but they do sound interesting.
Posted: 7/11/2019 9:30 AM
Quote
SuperLumberjack
He/Him
Joined: 7/9/2019
Posts: 27
Location: France
Hello :-D Thanks ! ;-) Yes, I understand the better control with the color space conversion. By the way, I tested to compare what is the best between the result of the conversion with the feos scripts and the UtVideo codec. That's true, feos' script win ! :-P But the only strange thing I noticed is that the colors changed. We see this in the reds and greens. I don't knwo if it was itentional or not. I will show you and the comparison with UtVideo too, so we can see clearly the differences :-) I will write the script each time too. RGB 24 (uncompressed) : 
Language: avisynth
PointResize(2048, 1792)
Resize8(2820, 2160, kernel="Spline36", kernel_c="Spline36")
I know, it's very blocky ! :-P I used the "Resize8" plugin because it uses a anti-ringing filter by default : http://avisynth.nl/index.php/Resize8 The ringing isn't always bad, because it adds sharpness, but I find that the result with the anti-ringing filter is quite good (but it can adds other defaults if the scaling factor is too big). I didn't use the true 4:3 aspect ratio, but : 256 * (8:7) = 2048/7 So : (2048:7)/224 = (64:7)/7 = 64:49 YV24 then YV12 with AVS script (like feos did) : 
Language: avisynth
PointResize(2048, 1792)
Resize8(2820, 2160, kernel="Spline36", kernel_c="Spline36")
luma = ConvertToYV24(matrix="Rec709", chromaresample="point").ConvertToYV12(matrix="Rec709", chromaresample="point")
chroma = ConvertToYV24(matrix="Rec709", chromaresample="point").ConvertToYV12(matrix="Rec709", chromaresample="point")
MergeChroma(luma, chroma)
We can notice different pinks, reds and greens ! But the result is good ! ;-) YV12 with the "UtVideo YUV420 BT.709 VCM" codec : The conversion of the color space is most blurry and less clean than the conversion with the AVS script. Maybe bicubic or something else is used to reduce the chroma resolution. But in theory, the reduction of the chroma needs interpolation too, like when we upscale a picture, so "PointResize" or something else, it's a question of taste I suppose ;-) However, the color matrix is good and the file is taggued with it :
MediaInfo wrote:
General Complete name : H:\UtVideo.avi Format : AVI Format/Info : Audio Video Interleave File size : 229 MiB Duration : 2 s 567 ms Overall bit rate : 750 Mb/s Writing library : VirtualDub2 build 41585/release Video ID : 0 Format : YUV Codec ID : ULH0 Codec ID/Info : Ut Video Lossless Codec Codec ID/Hint : Ut Video Duration : 2 s 567 ms Bit rate : 749 Mb/s Width : 2 820 pixels Height : 2 160 pixels Display aspect ratio : 4:3 Frame rate : 60.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Compression mode : Lossless Bits/(Pixel*Frame) : 2.048 Stream size : 229 MiB (100%) Audio ID : 1 Format : PCM Format settings, Endianness : Little Format settings, Sign : Signed Codec ID : 1 Duration : 2 s 567 ms Bit rate mode : Constant Bit rate : 1 024 kb/s Channel(s) : 2 channels Sampling rate : 32.0 kHz Bit depth : 16 bits Stream size : 321 KiB (0%) Alignment : Aligned on interleaves Interleave, duration : 21 ms (1.23 video frame) Interleave, preload duratio : 500 ms
I use this codec because I had a problem of wrong color matrix when I used the Lagarith codec (because there is no tag for the color matrix) and then encode the video with Handbrake. I'm not a professional for encoding, it's why I use Handbrake. I think the result is really good ! :-) But I got the right color matrix with the AVS script if I don't specify it. YV24 then YV12 with AVS script (good color matrix) : 
Language: avisynth
PointResize(2048, 1792)
Resize8(2820, 2160, kernel="Spline36", kernel_c="Spline36")
luma = ConvertToYV24(chromaresample="point").ConvertToYV12(chromaresample="point")
chroma = ConvertToYV24(chromaresample="point").ConvertToYV12(chromaresample="point")
MergeChroma(luma, chroma)
Oki doki ! :-) For the Nnedi3, yes, I already tested it ! ;-) It gives excellent results, but gives sometimes some artefacts too :-/ But I like it too. What did you use to upscale to the final resolution ? Lanczos3 ? I forgot to say that personnally, I prefer the "Spline36" algorithm rather than "Lanczos3" (I did lots of comparisons to be sure). The result is quite similar, but there is a bit less ringing ! ;-) Later, I will show you other scripts that I tested, often softer that what I showed here (maximum pixels, very blocky ! :-P ), not crazy things, but some things that I find pleasant... but never perfect of course ! ^_^ It's too subjective !
Posted: 7/11/2019 10:58 AM
Quote
SuperLumberjack
He/Him
Joined: 7/9/2019
Posts: 27
Location: France
This quality is not bad for me ! ^_^ Link to video I think it's not necessarily nice when it's to blocky ! I think there is bilinear filtering somewhere or something else. I don't know. What do you think ?
Posted: 7/11/2019 2:43 PM
Quote
SuperLumberjack
He/Him
Joined: 7/9/2019
Posts: 27
Location: France
Hello again ! :-) I just want to show you some things I did. It's not extraordinary, it's even very simple, but I just tried to come close to how the picture was on a CRT (very basically, it was just for help me, because some CRT shaders are really better of course). I compared with some photos that I found here : https://www.neogaf.com/threads/scanline-screenshot-thread-because-240p-is-all-the-ps-i-need.921436/page-2 But here, I will take this capture as a model : (source : https://youtu.be/iPohK0D8qvM ) I know the picture is bad :-P But what is interesting is that the guy used a VGA CRT monitor instead of a CRT TV with the real console and an OSSC. I think it's better to compare with this than with a CRT TV and its scanlines, because it's closer to the conditions we have on a modern screen which hasn't scanlines. But there is the version with a CRT TV too ^_^ : (source : https://youtu.be/OxBXiCPFM78 ) And so, here is a test with (very basic) scanlines and a little boost of gamma to compensate : 
Language: avisynth
PointResize(512, 448)
Scanlines(STRENGTH=75)
Levels(0, 1.25, 255, 0, 255)
PointResize(1024, 896)
BilinearResize(2820, 2160)			# Personnally, with some other games like "Super Metroid", "Mr. Nutz" or "Super Mario World", I keep the 8:7 AR, so I choose a resolution of 2468 x 2160
Personnally, I wouldn't use scanlines for YouTube. It's just to compare ! :-) The same without scanlines : 
Language: avisynth
PointResize(1024, 896)
BilinearResize(2820, 2160)			# Personnally, with some other games like "Super Metroid", "Mr. Nutz" or "Super Mario World", I keep the 8:7 AR, so I choose a resolution of 2468 x 2160
Another capture for model : I tested something softer (without scanlines) : 
Language: avisynth
PointResize(512, 448)
Scanlines(STRENGTH=75)
Levels(0, 1.25, 255, 0, 255)
BilinearResize(1170, 896)			# Personnally, with some other games like "Super Metroid", "Mr. Nutz" or "Super Mario World", I keep the 8:7 AR, so I choose a resolution of 2468 x 2160
Resize8(2820, 2160, kernel="Spline36", kernel_c="Spline36")			# Personnally, with some other games like "Super Metroid", "Mr. Nutz" or "Super Mario World", I keep the 8:7 AR, so I choose a resolution of 2468 x 2160
I choose to change the aspect ratio with the bilinear filter to begin, because I think it's more convincing, but you can choose to do that only with the Spline36 resizer. The same picture without scanlines : 
Language: avisynth
PointResize(512, 448)
BilinearResize(1170, 896)			# Personnally, with some other games like "Super Metroid", "Mr. Nutz" or "Super Mario World", I keep the 8:7 AR, so I choose a resolution of 2468 x 2160
Resize8(2820, 2160, kernel="Spline36", kernel_c="Spline36")			# Personnally, with some other games like "Super Metroid", "Mr. Nutz" or "Super Mario World", I keep the 8:7 AR, so I choose a resolution of 2468 x 2160
I tested so many other things (with Nnedi3 too ;-) ) that I can just say one thing : the simpliest is often the best. I know that lots of people hate the bilinear filter, but personnally, I think that the best result is this (from what I suggested of course) : 
Language: avisynth
PointResize(1024, 896)
BilinearResize(2820, 2160)			# Personnally, with some other games like "Super Metroid", "Mr. Nutz" or "Super Mario World", I keep the 8:7 AR, so I choose a resolution of 2468 x 2160
There is no miracle with an upscale ! :-( Some people may think that it's to simple to be good, that it's inaccurate, but was it accurate in those days ? :-) The other problem, as I said above, it's the influence of the modern "pixel art" indie games and their pixel perfect blocky representation... :-P I'm curious to know what you think ! ;-) But I tested enough things (like a lunatic ^_^ ) to know that it's never finished if we are looking for the perfection ! The rest is too subjective... ! Personnally, I keep the PointResize filter with the bilinear. This with 1080p : 
Language: avisynth
PointResize(512, 448)
BilinearResize(1410, 1080)
This with 1440p : 
Language: avisynth
PointResize(768, 672)
BilinearResize(1880, 1440)
And this with 2160p : 
Language: avisynth
PointResize(1024, 896)
BilinearResize(2820, 2160)
Voilà ! :-P Sorry, there is no big revelation ! :-/ Just some reflexions I think.
Posted: 7/11/2019 7:54 PM
Quote
Aktan
Publisher
Joined: 4/23/2009
Posts: 1283
Whoa, that's a lot of testing. Nice to see you're super curious in what's the best. Here are some select comments:
SuperLumberjack wrote:
That's true, feos' script win ! :-P But the only strange thing I noticed is that the colors changed. We see this in the reds and greens. I don't knwo if it was itentional or not.
I thought the current script would be point resize to the target resolution or bigger in multiples of 2, then downscale to the target resolution if needed. For example: 
Language: avisynth
AVISource("movie.avi")
PointResize(3408, 2928).LanczosResize(2880, 2160, taps=2)
ConvertToYV24(matrix="Rec709", chromaresample="point")
ConvertToYV12(matrix="Rec709", chromaresample="lanczos") # Notice the change in chromaresample
There is a slight color bleed which is intentional to make the pixel sizes consistent.
SuperLumberjack wrote:
I use this codec because I had a problem of wrong color matrix when I used the Lagarith codec (because there is no tag for the color matrix) and then encode the video with Handbrake. I'm not a professional for encoding, it's why I use Handbrake. I think the result is really good ! :-)
Yes, Lagarith YV12 is probably using Rec601 color matrix, but since you already know how to use Avisynth, why not capture in RGB and convert it yourself as a last step, then send to Handbrake?
SuperLumberjack wrote:
For the Nnedi3, yes, I already tested it ! ;-) It gives excellent results, but gives sometimes some artefacts too :-/ But I like it too. What did you use to upscale to the final resolution ? Lanczos3 ?
What he did was upscale it above the target resolution, then downscaled to the target resolution with AreaResize. AreaResize uses weighted averages to figure out the end result.
SuperLumberjack wrote:
I forgot to say that personnally, I prefer the "Spline36" algorithm rather than "Lanczos3" (I did lots of comparisons to be sure). The result is quite similar, but there is a bit less ringing ! ;-)
This is why I personally use Lanczos with 2 taps instead of 3. Less ringing but more blurry.
Posted: 7/11/2019 8:51 PM
Quote
SuperLumberjack
He/Him
Joined: 7/9/2019
Posts: 27
Location: France
Aktan wrote:
I thought the current script would be point resize to the target resolution or bigger in multiples of 2, then downscale to the target resolution if needed. For example: 
Language: avisynth
AVISource("movie.avi")
PointResize(3408, 2928).LanczosResize(2880, 2160, taps=2)
ConvertToYV24(matrix="Rec709", chromaresample="point")
ConvertToYV12(matrix="Rec709", chromaresample="lanczos") # Notice the change in chromaresample
There is a slight color bleed which is intentional to make the pixel sizes consistent.
Hello ! :-) Very interesting logic ! :-P I tried these kind of things too, with some blurs, etc. ;-)
Aktan wrote:
Yes, Lagarith YV12 is probably using Rec601 color matrix, but since you already know how to use Avisynth, why not capture in RGB and convert it yourself as a last step, then send to Handbrake?
It's what I do ! ;-) In fact, I only use Lagarith when I temporarily want to export my videos in RGB and/or reduce the size of the file :-) And so, why this change of color in the script ? :-P
Aktan wrote:
What he did was upscale it above the target resolution, then downscaled to the target resolution with AreaResize. AreaResize uses weighted averages to figure out the end result.
OK. It's funny, because I tested lots of things like this too some years ago ! ^_^
Aktan wrote:
This is why I personally use Lanczos with 2 taps instead of 3. Less ringing but more blurry.
Yes, I agree ! But too sharp may be worst sometimes ;-) To be honest, I think I tried almost all the resizers that it's possible to try ^_^ I did a lot of scripts, and now, I still wonder what could be the best :-/ Maximum pixels ? A picture a bit blurry ? A compromise ? :-P I don't know ! But I think that the big problem for these old 2D games compared to the modern pixel art games, that are thought for our modern screens, it's precisely the fact that they were designed for the old CRT TV. I think that the scanlines were really important for the trick to work. It created relief and gave the impression that the vertical resolution was doubled. But we haven't this yet or only with CRT shaders. For me, a 240p progressive image with scanlines, it's almost the same than a 480i interlaced image in term of definition. And generally, on a modern screen, the most basic way to deinterlace a image is to blend fields. With VirtualDub, it's equivalent to this with AviSynth : 
Language: AviSynth
Blur(0, 1.0)
So I tested this with a 240p image doubled to 480p. With a Super Nes game, I tested this : 
Language: AviSynth
PointResize(512, 448)
Blur(0, 1.0)
For me, it's only like this that I finally see a convincing relief in the image, like it was on a CRT. But as everybody can see it, the result is blurry and not really nice ! Like a deinterlaced video with blended fields in fact ^_^ But I think that all the problem of the games in 240p is exactly the same that it is with interlaced contents on our modern screen. It's a bit unnatural... :-/ It doesn't work without deinterlacing or something else and even with that, it's far from perfect. For me, it's the only problem ! It really doesn't work on a modern screen ! Only the modern pixel art games are done to perfectly work on a modern screen I think. With the old 2D games, we always have to use a trick to render them acceptable. In the ideal, we should have the double of the definition for the vertical resolution !
Posted: 7/11/2019 9:55 PM
Quote
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Do not deinterlace a 240p video to progressive, it already is progressive. (Only very few SNES games use interlaced mode. IIRC only RPM Racing and Chrono Trigger (during this scene) use it for more than static screens.)
Posted: 7/11/2019 11:11 PM
Quote
SuperLumberjack
He/Him
Joined: 7/9/2019
Posts: 27
Location: France
Yes, of course ! :-P It's just for the comparison, for the idea ! ;-) I should have said too that a progressive image with scanlines it's not the same that a progressive image made for a modern screen. And concerning the interlaced video, I think that they shouldn't exist on the modern screens anymore. I believe that the 240p and 480i are only vestiges of the CRT screens and really only work on this kind of devices. The interlaced videos work on CRT TVs without the need to deinterlace them, as the progressive contents work well with scanlines. If we think about 240p and 480i content, a 480i video non-deinterlaced on a modern screen should be equivalent to a 240p video doubled to a 480p resolution with fake 100% scanlines. Am I wrong ? :-/ I don't know if I'm clear and if you understand what I try to say. But if you follow my logic : what is the equivalent of deinterlacing for the 240p videos (which should work with scanlines) ? I don't talk about progressive content for the modern screens, because they don't have to work with scanlines and of course don't need to be deinterlaced. It's just a reflexion. I really make the distinction between 240p contents which must work with scanlines on a CRT and progressive contents made for the modern screen. I hope you will understand me... ^_^ But the Higan emulator uses a logic like that with blurring the image horizontally. It's the opposite of what I said with the vertical blur, but yes, in fact it's more logical with a progressive image, to keep the vertical definition intact. But I think there is an idea like what I suggested, a kind of reversed deinterlacing (no interlacing of course) for the old progressive content made to work with scanlines. In fact, I analysed what they did with the Super Nes games. With the biggest scaling (the resolution is 1170 x 960), they : - double the resolution to 512 x 480 (448 pxs + black borders) - move the picture from 1 pixel horizontally (it's like a ghost image, it doesn't work with a simple blur) - double the resolution and correct the aspect ratio with a bilinear filter to achieve the resolution of 1170 x 960 It's really smart and work quite well ! :-) But lots of people will find the picture too blurry. But the effect in motion is good and rather natural I think !
Posted: 7/12/2019 12:10 AM
Quote
SuperLumberjack
He/Him
Joined: 7/9/2019
Posts: 27
Location: France
Two interesting videos to compare the picture from the Super Nes with an OSSC and from an Analogue Super Nt ;-) Link to video Link to video Do you think it's possible to achieve this quality with an AVS script ?
Posted: 7/12/2019 9:40 AM
Quote
SuperLumberjack
He/Him
Joined: 7/9/2019
Posts: 27
Location: France
By the way, concerning the good aspect ratio in 4:3, it seems that the Super Nes Classic Mini uses a 64:49 AR (8:7 for the horizontal resolution) too instead of 4:3 :-) This is a capture of the Super Nes Classic Mini : I found it here and just cut the borders : http://www.nintendolife.com/news/2017/09/hardware_review_the_snes_classic_mini_is_the_perfect_link_to_the_past There are others here : https://www.eurogamer.net/articles/digitalfoundry-2017-nintendo-classic-mini-super-nes-system-review The resolution is "877 x 672". It's just a Simple X3 (or nearest neighbor) and a bilinear filter to correct the AR. And just to check : 672 x (64:49) = 877 So even the "official" Super Nes Classic Mini doesn't use an exact 4:3 aspect ratio ;-) => List of the aspect ratios
Posted: 7/12/2019 8:14 PM
Quote
Aktan
Publisher
Joined: 4/23/2009
Posts: 1283
Are you sure you're not mixing DAR with PAR? Your link here says that the NES/SNES has a PAR of 8:7, which should be a DAR of 4:3 on a standard CRT TV.
Posted: 7/12/2019 10:10 PM
Quote
SuperLumberjack
He/Him
Joined: 7/9/2019
Posts: 27
Location: France
I agree that it can create confusion, because the native aspect ratio of the Super Nes game is 8:7 too and you're right, it was displayed with a 4:3 aspect ratio on the CRT TVs. But this 8:7 aspect ratio is apparently only for the horizontal resolution. It's why I wrote some calculations, because it's a bit confusing :-P For a Super Nes game, we know that the original resolution is "256 x 224", with a 8:7 aspect ratio. But to know the exact resolution that must be displayed with a 4:3 aspect ratio (for the modern displays I suppose, because the old CRTs weren't digital), we need to take the horizontal resolution and multiply it by the AR showed in the list, so a 8:7 AR. Yes, it's confusing with the native AR which is 8:7 too ^_^ 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 resolution 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).
Posted: 7/13/2019 7:49 PM
(Edited: 8/12/2019 1:40 PM)
Quote
SuperLumberjack
He/Him
Joined: 7/9/2019
Posts: 27
Location: France
If you are interested, you can tell me what do you think about the quality of these videos :-) (sorry, I deleted the videos) But I just have an issue for 4 months :-/ My videos in 2160p are always badly reencoded by YouTube. I hadn't this problem before March. And in addition, it's the same on my two channels (I have a private channel too). But even with this issues, you can see if the quality of these videos are good or not ;-) Thanks !
Posted: 7/13/2019 7:59 PM
Quote
Aktan
Publisher
Joined: 4/23/2009
Posts: 1283
What are you sending to YouTube? Might be a codec or a parameter to that codec that it doesn't like. Edit: fsvgm777 pointed out to me that you included MediaInfo in the description. I'll take a look and edit this comment.
1 2 3 4