Tuesday, August 11, 2015

Getting optimal Apple ][ screenshots w/NTSC emulation

A while ago over at MobyGames, AppleWin NTSC was recommended (okay, by me) for obtaining Apple ][ shots.  However, it's a bit of a pain to use, since the built-in screenshot function doesn't work.  Also the NTSC output is still not *quite* ideal (there's some ghosting/ringing going on, and black/white areas are somewhat 'noisy').

Thankfully Michaelangel007 has provided a newer build which addresses both of these issues.  The full discussion is on github, but here's a quick-start guide to make your lives easier and your screenshots better:
  • Grab Applewin.exe here (feel free to *rename* it and drop it into your AppleWin dir).
  • Run it.  You'll want to be in TV mode (cycle through with F9), with "50% scanlines" disabled.
  • Hit PrintScreen to capture a .BMP shot in the same path as the disk image.
There's still some post-processing to do however.  For some reason, the rendering in this build is rather blurry - luckily this is not hard to fix, since only every *other* scanline is interpolated (so no image data is lost).  Plus we still get a border, which we typically don't want.

To do it all the easy way, and convert to .PNG while we're at it, I use this simple batch file with ImageMagick:

FOR %%a in (*.bmp) DO convert -crop 560x384+23+17 -interpolate integer -filter point -resize 100%%x50%% -scale 100%%x200%% -format png %%a %%~na.png & del %%a

Save as .bat in a folder with all your BMPs, run it and you're done. Note that the original BMPs will be deleted, and of course you'll need the PATH in your environment to point to your ImageMagick directory (or just stick the path before 'convert' above).

Here are a few results (click to enlarge):


These improve on the previously-available AppleWin NTSC, which itself is already much more faithful than other emulators out there.  Hopefully a version of this (without the blurry, cross-scanline interpolation) can be merged into mainline AppleWin, and adopted by others -- maybe then we'll stop seeing plain wrong shots like these all over the internet.

3 comments:

Christian Kent said...

Don't you *want* the cross-scanline interpolation? It gets you the additional HGR colours.

Take a look at the top image: http://video-kungfu.blogspot.com.au/2016/07/and-now-for-some-sdtv-fun.html

In your screenshot, look at the moon in Choplifter. It should be gray in the middle, not orange+blue interleaving.

In your screenshot they end up looking like "Hanover bars" https://en.wikipedia.org/wiki/Hanover_bars in pre-1990s PAL televisions without a delay line, when the hue drift was severe.

VileR said...

Thanks for the interesting link!

AFAIK, the one thing that would make the Choplifter moon grey on an NTSC TV is a comb filter - the actual purpose of which is to sharpen *luma* detail on typical broadcast signal, but with the side-effect of averaging the *chroma* component over consecutive scanlines. When these consecutive scanlines have the same luminance level (as they do in the bottom row of your screenshot, but not in the middle one) you would indeed get a solid, continuous color. As you mention, the Apple outputs a progressive-scan signal so there's no interlacing at work.

(More info on comb filters: http://www.cockam.com/vidcomb.htm)

This didn't appear to be emulated by the improved NTSC build of AppleWin that I was testing (that could've changed since then... gotta check!). On the other hand, comb filters weren't common at all in 1980s TV sets, to the best of my knowledge. It's an open question whether Apple's own composite monitors had them or not, but I guess there's a reason that contemporary literature always mentioned six colors for HGR, not ten.

The cross-scanline interpolation that I remove is due to a rather different filter (bilinear?); it doesn't simulate a comb filter to any stretch, but rather inserts RGB-averaged pixel rows *in between* the source lines. The result is blurring in the vertical domain, something that isn't associated with comb filtering, or indeed with any kind of analog CRT. Blurring in the *horizontal* domain is fine, since the composite signal is analog so it varies smoothly as the beam scans from left to right, but in the vertical domain scanlines are always discerete, so no blurring or interpolation should occur.

(To make matters worse, this interpolation is also gamma-unaware, which introduces yet more errors - see http://www.4p8.com/eric.brasseur/gamma.html ;-))

VileR said...

Addendum to my above comment: on the Apple color monitor itself, consecutive blue/orange scanlines are *not* comb-filtered to grey (see the first photo here - https://github.com/AppleWin/AppleWin/issues/254). Therefore the colored scanlines would be visible on Choplifter's moon as well, unless viewed on a (later generation!) TV with a comb filter.