nesdev.com

It's something I've been obsessing about lately. I figured out a way to make a B&W "composite" image with the checkerboard chroma signal. I also can decode the image back to color, but it always comes out in an abysmal quality.

I think part of the problem is limited filter types. GIMP's convolution filter only allows filters that are 5x5 pixels. The other 2 types are Gaussian and boxcar. Another problem is GIMP tends to be very prone to quantizing error.

If GIMP didn't have the above limitations would it be much easier to make an NTSC-style image?

If you can't use blargg's snes_ntsc for whatever reason, here's my recipe for approximate NTSC simulation entirely inside GIMP:

1. Image > Mode > RGB
   You can't apply most filters in indexed mode.
2. Image > Scale Image, factor 200%, interpolation None (i.e. nearest neighbor)
   Horizontally because each pixel lasts 2/3 of a color subcarrier period, and vertically because each of two fields has its own phase.
3. Filters > Distorts > Video, 3x3, additive off, rotated on
   This encodes the image using pixel-sequential RGB, which has similar but not identical properties to the YUV/YIQ QAM that NTSC uses, with a phase offset from one row to the next similar to that of the NES PPU and Super NES S-PPU.
4. Filters > Generic > Convolution Matrix, center row [0 1 1 1 0], divisor 1, offset 0, normalize off
   This decodes pixel-sequential RGB.
5. Filters > Blur > Pixelize, width 1, height 2
   This blends the even and odd fields.
6. Image > Scale, width 114%, height 100%, interpolation Linear
   This corrects the pixel aspect ratio.

Gimp has plugin and scripting systems that can add all kinds of filters, so it's completely possible.

I don't know of a relevant plugin, offhand, though. I'm having trouble searching the GIMP plugin registry at the moment: http://registry.gimp.org/glossary/a

Farbfeld Utilities includes a NTSC decoder. Maybe there is a way to be able to write a plugin for GIMP to allow farbfeld filters to be used with it; if you can, it can help for anyone to use GIMP to also be able to use farbfeld filters.

_________________
.

It would probably be more accurate if you convert color spaces so that Red, Green and Blue represent wave heights at different phases.

Okay, got the conversion matrixes:

R' = .905R + .286G - .191B
G' = -.16R + 1.177G - .017B
B' = .152R + .298G + .55B

R = .991R' - .326G' + .333B'
G = .129R' + .801G' + .069B'
B = -.344R' - .344G' + 1.689B'

I notice that when you have a black line surrounded by red, it tends to bleed over it due to chroma filtering and RGB limits. Do any TVs have circuitry to remove out-of-gamut color bleed on black or white details?

I first noticed that sort of bleed in Mario Paint for Super NES. Then I saw it in regular cable TV with cyan corporate logos on a white background, which is the inverse of the red-on-black case.

I figured out how to fix the color bleed.

First, fix color overflow. Find the highest color channel value of a pixel. Subtract the luma value from it to find saturation level. Clamp the highest color channel value to 100%. Subtract the luma value to find the clamped saturation. Then divide the clamped saturation by the full saturation. Use the result to mask out the color.

Then fix the underflow, by doing the same thing, but inversed.

Here's my first attempt at a Python-Fu plug-in to perform the recipe I described above. On X11-based systems, extract the .py file into ~/.gimp-2.8/plug-ins and restart GIMP. I don't have Windows in front of me to test at the moment.

It'd be easier if I could actually convert things to YUV, but Channel Mixer doesn't support adding an offset the way Generic Convolution does.

I just realized something strange. Am I seeing this correctly or does blurring the chroma more actually make the dot crawl look worse. With just a little bit of filtering, it looks a little gritty on colored edges, but at least solid areas look clear. Using a heavier filtered chroma, on the other hand, looks extremely staticky.

Something just occurred to me. Does anybody know what color phase the SNES outputs? I think having "CMY" sub pixels would be less noisy than "RGB" sub pixels, because with "RGB" sub pixels, one primary is always missing, as opposed to having one boosted primary per pixel.

Would you try rephrasing your question?

I assume you're starting off asking something equivalent to "what is the exact matrix that the encoder IC uses to convert from RGB to YUV", but I don't understand the second half.

I know the matrix. I want to know if the NES and SNES always start the color burst and pixel clock on the same phase when you turn the system on.

Not sure about the S-PPU, but I know the NES PPU's color burst phase varies from one reset to another because my RGB121 demo's artifact pattern changes so drastically when I reset.

I realized there is an issue with using a 512x448 resolution in GIMP. You would have chroma aliasing, resulting in an extra blocky chroma signal.