
Accurate(ish) CRT TV simulation theory
-
- Regular
- Posts: 347
- Joined: Tue Mar 07, 2006 10:32 am
- Location: The Netherlands
This is wrong, actually. Although it's true that either side accounts for about 15.7% of the total light, if you're looking at colour bleed you should use the centre pixel's intensity as a baseline. Since the middle pixel accounts for about 68.3% of the light in my example, the colour bleed into each scanline is about 15.7/0.683 = 23.0%. (a further 0.40% theoretically bleeds into scanlines outside these 3 scanlines)Verdauga Greeneyes wrote:Note this spread is probably a bit wide (it has about 15.7% bleed on either side of the central scanline); it's only an example.
-
- Trooper
- Posts: 376
- Joined: Tue Apr 19, 2005 11:08 pm
- Location: DFW area, TX USA
- Contact:
Hey Blargg, I see what you mean about the color bleed being closer, although my Trinitron displayed SNES S-Video a tad sharper horizontally, but that's very close.
Speaking of using bleed on scanline filters, I very much like the way FBA does its scanlines at 4xscale. Take a look at this cut section from a screen pic I did of Garou:

If you zoom in on the image with a paint program, you can see each scanline has a center "full-brightness" line that is then darkened down as it reaches the middle point in between. Easier on the eyes, yet still gives it a nice arcade quality look.
Speaking of using bleed on scanline filters, I very much like the way FBA does its scanlines at 4xscale. Take a look at this cut section from a screen pic I did of Garou:

If you zoom in on the image with a paint program, you can see each scanline has a center "full-brightness" line that is then darkened down as it reaches the middle point in between. Easier on the eyes, yet still gives it a nice arcade quality look.
wow guys
VERY impressive,
Blargg could you make another example with 15% bleed instead of 30%
30% was very rare in color tv's(normal in b/w though)
If we decide to like 30% better i think we should keep it. Also do you think that the bleed can be dynamically changed or would that add a huge overhead?
VERY impressive,
Blargg could you make another example with 15% bleed instead of 30%
30% was very rare in color tv's(normal in b/w though)
If we decide to like 30% better i think we should keep it. Also do you think that the bleed can be dynamically changed or would that add a huge overhead?
I don't get your multiple rewrites of the first post. Most of us probably don't even bother re-reading it, and it messes up the temporal order of the thread. Maybe you should set up a Wiki page?
Here's the same image with the between-scanline brightness halved, but this makes the effect almost invisible, as totally blacking them out looks virtually the same:

I made the original by expanding the image horizontally using the SNES NTSC filter in RGB mode with resolution and sharpness at +1.0. In Photoshop I expanded this vertically by 2X and blacked out every other line. Then I duplicated that image twice into two layers above, and set them to Screen mode. I moved one of them up one pixel, the other down, then set their opacity to 30%. That resulted in each scanline having a 30% copy of it mixed in above and below.
Here's the same image with the between-scanline brightness halved, but this makes the effect almost invisible, as totally blacking them out looks virtually the same:

I made the original by expanding the image horizontally using the SNES NTSC filter in RGB mode with resolution and sharpness at +1.0. In Photoshop I expanded this vertically by 2X and blacked out every other line. Then I duplicated that image twice into two layers above, and set them to Screen mode. I moved one of them up one pixel, the other down, then set their opacity to 30%. That resulted in each scanline having a 30% copy of it mixed in above and below.
The wiki is probably a good idea, the final simulation should spread to all emulators.blargg wrote:I don't get your multiple rewrites of the first post. Most of us probably don't even bother re-reading it, and it messes up the temporal order of the thread. Maybe you should set up a Wiki page?
I used a similar method to make my blurry example.blargg wrote: I made the original by expanding the image horizontally using the SNES NTSC filter in RGB mode with resolution and sharpness at +1.0. In Photoshop I expanded this vertically by 2X and blacked out every other line. Then I duplicated that image twice into two layers above, and set them to Screen mode. I moved one of them up one pixel, the other down, then set their opacity to 30%. That resulted in each scanline having a 30% copy of it mixed in above and below.
I agree with yout that your first example looks much more like a real TV than the second image(or my blurry one)
With the limitations we face with monitors in general and the simulation of the TV i think the first working version of the filter should be based on the settings used to create your first image. It looks VERY convincing. We can look into adding settings in a later version.
I don't have any site or whatever to create the wiki on, so developement will have to go in in this thread for now, i wont edit the first page any more. Also we need to think of a licence that will work for most emulators.
blargg what did you use for the NTSC filter?
Speaking of your NTSC filter, as said in blargg's explenation on how he made the image, this simulation is an ADDITION to the NTSC filter, not a replacement
Code: Select all
Version 7 (thanks to blargg)
1.Check if height =<243, if so double the height by inserting black lines
2.Pad the height with black lines(equally above and below) to 486
3.Pad black pixels(equally left and right) for pixels generated beyond the input image
4.Stretch the image horizontally to 640 (This will result in the correct pixel aspect ratio)
5.Duplicate the image twice, you'll have 3 layers.
6.the first image stays in place, the second image moves up 1 pixel, the third image moves down 1 pixel.
7.Apply screen effect with opacity of 30% to the 2nd and 3rd image layers.
A later version wil re-add(not that its possible now)
-Pal simulation(lets focus on a working NTSC implementation first)
-Selectable kell factor in step 7 (by adjusting the opacity between 0% and 30% )
-Overscan simulation by cropping the image(only positive overscan will be simulated)
Summary of my understanding of the LGPL: programs using unmodified LGPL code/libraries must either provide the full source code for the entire program, or build the LGPL code as a DLL, so that an end-user can freely modify/fix/upgrade the LGPL portion of the program. Further, if any modifications are made to the LGPL source code, those must be provided, even if the LGPL code is built as a DLL. These purpose of all this is to prevent a developer from restricting a user; user freedom is put before developer freedom (only where they conflict). The GPL applies this to the entire program, while the LGPL does this for the LGPL code only.
If you want a library that does something like the above (clean image WITHOUT NTSC composite artifacts), a much simpler library could be made. In fact, it could be done entirely with the graphic card; first expand the image horizontally by some integral factor using nearest-neighbor interpolation (that is, none), then scale back down using linear interpolation. For example, in Photoshop I took your original image, expanded it by 10x horizontally (282x243->2820x243) using no interpolation, then reduced it back to 640x243 using linear interpolation, then expanded by 2x vertically (to 640x486) using no interpolation: snes_svideo2.png
If you want a library that does something like the above (clean image WITHOUT NTSC composite artifacts), a much simpler library could be made. In fact, it could be done entirely with the graphic card; first expand the image horizontally by some integral factor using nearest-neighbor interpolation (that is, none), then scale back down using linear interpolation. For example, in Photoshop I took your original image, expanded it by 10x horizontally (282x243->2820x243) using no interpolation, then reduced it back to 640x243 using linear interpolation, then expanded by 2x vertically (to 640x486) using no interpolation: snes_svideo2.png
Offtopic:
It would be really nice if someone would write a license like the LGPL, but without the "you can convert this to GPL" clause, and allow static compilation of unmodified sources to not require you to release object files or link it as a DLL. It'd obviously not be GPL-compatible, but it'd be a damn fine license otherwise. At that point, it'd just be a "release your changes" license. Maybe call it the Lesser LGPL.
It would be really nice if someone would write a license like the LGPL, but without the "you can convert this to GPL" clause, and allow static compilation of unmodified sources to not require you to release object files or link it as a DLL. It'd obviously not be GPL-compatible, but it'd be a damn fine license otherwise. At that point, it'd just be a "release your changes" license. Maybe call it the Lesser LGPL.
Put the information on a blog
At least its all in a single place now
http://security-emulation.blogspot.com/ ... ation.html
At least its all in a single place now
http://security-emulation.blogspot.com/ ... ation.html