8 ms·
Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)
- mPReDiToR 6y agocool-retro-term is fab for this. It takes me back to the Amstrad PCW8256 that I used as a kid. Those double sided CF2 disks were a better disk than either the 5.25" or the 3.5" IMHO.
- guenthert 6y ago> Those double sided CF2 disks were a better disk than either the 5.25" or the 3.5" IMHO. Not sure how they were better than 3.5" disks at that time (they might have been better than the poor quality once sold towards the end of the Floppy era), but for sure they were much more expensive. I don't miss them one bit.
- tinus_hn 6y agoXScreenSaver also has a demo that simulates an analog tv instead of a monitor like this.
- teddyh 6y agoIt’s called “XAnalogTV”: https://www.youtube.com/watch?v=VmM1KkFsry0&list=PLbe67PprBSpqM_-HU49fmIS8ncApw4i08&index=92 https://www.youtube.com/watch?v=VmM1KkFsry0&list=PLbe67PprBS...
- cmiller1 6y agoI've been using CRTs again for the first time in a few years and none of these really capture the way they look.
- kiwidrew 6y agoThe TTL RGBI 320x200 one looks pretty accurate to me when compared to a real 15.7khz 200-line CRT, and the render of Crystal Caves on a double-scanned VGA also looks about right as compared to an early 90's 14" VGA CRT. Can't comment on the others, though. In Part 2 (monochrome) the Apple II green monochrome is spot-on accurate and the Amber MDA 80x25 textmode is pretty good except that the background contrast is quite poor. A real amber MDA monitor has much deeper blacks.
- cmiller1 6y agoThe contrast issue is what I notice the most. CRTs had much more "glow" and "bleed" I guess
- kiwidrew 6y agoMany of the retro takes on CRTs seem to over-emphasize the scanlines and (perhaps in pursuit of capturing the CRT "glow") also end up over-doing the background. On a properly adjusted CRT you shouldn't be able to see any scanlines at all in areas that are displaying pure black, unless you're viewing the display in an extremely dark room.
- cmiller1 6y agoYeah I don't see the scanlines at all on the CRT I've been using
- viler 6y ago(Author of the script here): appreciate the observations. Pretty much all of these parameters (scanline intensity/sharpness, pixel blur, glow/halation, blackpoint for the background) can be adjusted to taste in the configuration files. :) I tried to show the range of possibilities in the screenshots/video samples, e.g. higher-res EGA/VGA with no visible scanlines, and some amber monitor shots with deeper blacks, etc. Admittedly, this script is geared more towards simulating lower-resolution CRTs - mostly because my approach entails a large oversampling of the input.
- kiwidrew 6y agoI'm impressed with the results from your lo-tech batch file approach. The output is really quite nice. It turns out that real CRTs also have a number of user-adjustable parameters, which of course makes it impossible to define any sort of "canonical" or most-accurate preset. :) (Like this weird paper-white monochrome CRT that uses P7 phosphor, designed for 350-line MDA but can also handle a greyscale 15.7khz 200-line CGA input... the scanlines are so sharp that it looks 100% fake!)
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- IronWolve 6y agoDigital Foundry did some good videos on CRT and Gaming, how lower resolutions looked so well, and could crank up the ray tracing at lower resolution. We really traded high pixel count for the CRT's blending of pixels with higher refresh. >DF Direct: CRT Displays - Was LCD A Big Mistake For Gaming? https://www.youtube.com/watch?v=tvRyVZWuvQ4 https://www.youtube.com/watch?v=tvRyVZWuvQ4 >DF Direct! Modern Games Look Amazing On CRT Monitors... Yes, Better than LCD! https://www.youtube.com/watch?v=V8BVTHxc4LM https://www.youtube.com/watch?v=V8BVTHxc4LM
- herf 6y agoShadow-mask CRTs were the best ever for low-res antialiased text. It looked great for the low resolutions of the time. (Even trinitron wasn't as good.) You were guaranteed a near-gaussian point in the output, and from a signal-processing POV, this makes filtering and display just really beautiful and easy to do right. For instance, you could do a totally convincing subpixel translation with no visible artifacts.
- pixelpoet 6y agoomg, it's the stereopsis guy! I learnt so much from your old gfxcoding articles, thanks very much for those.
- emmanueloga_ 6y agohaha so it is happening... CRTs are for gaming, in the same vein LPs are better for music, and valves are better for amps, etc, etc
- JohnBooty 6y agoIf you care about this stuff... (and there is absolutely no reason to care, but you are making a comment, so you seem to care a little) ...the tradeoffs are really fascinating. Don't think of it as one being better. It's just a different set of tradeoffs. CRTs are objectively better at some things, and are of course also objectively worse in a lot of obvious ways. I would say that LPs and tube amps are objectively worse than their modern counterparts in every way. But the tradeoffs involved and the subjective issues are cool and sometimes do make for a better subjective experience in some ways.
- a-dub 6y agoit's a dos batchfile on github that applies ffmpeg filters in clever ways to recreate the distortions and artifacts of displaying images on old cathode ray tube displays. cool!
- JohnBooty 6y agoI suspect (worry?) that a lot of folks miss out on the other thrill of physical CRTs... an experience that is as close to zero latency as is physically possible. This article breaks it down in wonderful detail: http://renderingpipeline.com/2013/09/measuring-input-latency/ http://renderingpipeline.com/2013/09/measuring-input-latency... The TL;DR is that on a "modern" stack (USB, display buffering, etc) with a 60hz display you're looking at over 100ms of input latency. You can roughly halve that with a 120hz display. But it won't ever touch the sub-16ms latency that's possible with a "retro" 8/16-bit console hooked up to a CRT display. A lot of those games were garbage, but damn... it felt like your brain was wired directly into the machine. A very very cool part of the experience that is being lost to time.
- Sunspark 6y agoYes, the same thing with telephone calls over copper. No latency. You could both talk at the same time, more immersive. I also remember vector displays first-hand.. those were pretty awesome. You're never going to get a vector graphics experience ever on an LCD because LCDs are rasterized pixels not a drawn line. No one will ever make a limited run of CRTs or vector monitors ever again, but I wish they would. People would buy them.
- JohnBooty 6y agoThat's a great example. Nobody will ever really experience that again! No one will ever make a limited run of CRTs or vector monitors ever again, but I wish they would. People would buy them. The prices people are paying for high-quality CRTs today are proof of that. I was lucky enough to get a sweet Sony PVM before the prices really went through the roof. But yeah, they'll never be manufactured again. It would be such an absolutely massive undertaking. I also remember vector displays first-hand.. those were pretty awesome. You're never going to get a vector graphics experience ever on an LCD because LCDs are rasterized pixels not a drawn line. Yeah and there's also the temporal aspect -- the "smearing" of ultrabright vector dots, like your bullets in Asteroids. I've seen folks be totally blown away when seeing something like an Asteroids cabinet in person for the first time.
- 6y ago
- skratlo 6y agoLoving it! Get into shaders asap if you want to push it further.
- viler 6y agoThanks. Yep, a pure GPU approach is probably the way to go for this stuff in general. One reason I used FFmpeg here was the goal of applying the effect to stand-alone videos/images, which you can't conveniently/easily do with shaders (AFAIK). The other reason is that my shader coding experience is pretty much zero, something I should fix at some point. ;) But if someone more knowledgeable gets inspired by this in the meantime and cooks something up, that'd be cool for sure.
- Lammy 6y agoSee also: http://avisynth.nl/index.php/QTGMC http://avisynth.nl/index.php/QTGMC
- viler 6y agoCheers for the comments. I'm still improving and tweaking this script - planning to test a fully 16-bit-per-component version of the filter chain, to eliminate any artifacts that might still exist. (Also, halation/diffuse glow for color CRTs isn't yet true to real-life visual results, but that will be improved.)
- tomxor 6y agoShameless plug.. I made a super slow motion 184 byte aperture grille (Trinitron) animation: https://www.dwitter.net/d/12335 https://www.dwitter.net/d/12335 And a more recent one with more interesting motion at faster speed: https://www.dwitter.net/d/21705 https://www.dwitter.net/d/21705 It is interesting how even as an animation it makes it look a lot smoother than the raw upscaled pixels of the same simple graphics.
- codetrotter 6y agoThe second one does not run for me on an iPhone X, but the first one does.
- tomxor 6y agoI can only speculate as to why because it's safari which i don't have. If the eval is throwing an exception it's probably something to do with the unicode encoding that packs 2 ASCII chars into each UTF16 surrogate pair - the second one ultilises slightly more of the 20bits available and some UTF16 implementations/interfaces are buggy. You could replace 'eval' with 'throw' and see if the output looks like sane JS
- bronson 6y agoOutput from iphone 11 seems to confirm your theory: https://dpaste.com/GU8A3X4H7#wrap https://dpaste.com/GU8A3X4H7#wrap
- tomxor 6y agoHah, actually that code is correct (Although I realise it probably looks like gobbledygook :D) so it disproves my theory. The code is mostly arithmetic, so the only thing I can see which could be implementation sensitive is the canvas fillStyle HSL string, which omits commas and spaces since the % postfixes are enough to delimit the saturation and luminance, but obviously this depends on the canvas interface implementation.