Jump to content

  • Log In with Google      Sign In   
  • Create Account





Digital Test Cards For Games

Posted by OrangyTang, 09 July 2009 · 589 views

Don't you hate it when you're writing some new image loading or texture drawing code but don't have any suitable test images? I always waste lots of time looking for a "nice" image to test with, and often end up drawing something with distict pixel values so I can pinpoint where any given image loading bug is. With that in mind I've spent a few evenings working on a proper "test card".

TV test cards are a rare sight on broadcasts these days, with most digital channels choosing to just have a blank screen when a channel is off air, but pretty much everyone in the uk will have the famous Test Card F burnt into their retina at some point. Test card design is rather facinating, as all the various elements (blocks of colour, diagonal stripes, etc.) are designed to allow particular elements of a broadcast or tv configuration to be tested and tweeked.

Most of them aren't relevent to games though, since we don't have to worry about scan amplitudes and all that mumbo jumbo. Mostly we're concerned about getting binary data off disk and accurately displaying that on the screen (dealing with file formats, endianness, and display surface formats in the process). So while Test Card F is nice and iconic, it's not really suitable for our use.

Here's a couple of my old (crude) test images:





They're not bad, but by todays standards they're a little small, the nicer Tails one is an awkward 48x48 and neither of them are good when you're trying to debug file format, image pitch or similar issues since the borders and colours aren't terribly helpful.

With those issues in mind, here's my new test card:



This breaks down as:
1. Well defined an unique border pixels make it easy to see if you're displaying the whole image or if you've sliced off an edge accidentally.
2. The main circle shows is for judging aspect ratio, and making sure you've not accidentally streched or squashed it.
3. The checkered edge markings are every 8 pixels, so you can line things up easily.
4. Various pixel patterns in the corners for checking 1:1 pixel drawing.
5. Colour and greyscale bars and gradients for general colour/gamma correction and to highlight colour precision issues.
6. Ticks mark the center of each edge for alignment.
7. Tails is always cool. [grin] Replace with your own favorite character as you see fit. The image and the text make sure you're displaying it at the correct orientation and not flipping or mirroring it.
8. The empty box at the bottom is left blank for you own logo or text.

One nice "feature" is the very outer border, here's a close up of the top left corner:



The start of the scanline starts with easily identifiable red, green and blue pixels (which show up as nice round non-zero, non-FF, hex numbers in a debugger's memory window) which are similar to a text file's byte-order mark. Just after that the desaturated colours spell out (again, when viewed in a debugger's memory view) "RedGreenBlue TestCardA 256x256". Of course if you're actually loading from a BGR image format that'll just be a row of junk characters, so directly after that the message is repeated (this time "BlueGreenRed TestCardA 256x256). This allows you to easily identify if you've actually calculated the start position of the image header from your image file and that you're reading it in in the right format and endianness - if you can read "BlueGreenRed" when you were trying to load a RGB image, you know you've messed something up somewhere. :)

The top right has a similar terminating series of characters:



This time it's a slightly different hex pattern for the numbers so you can distinguish the start of one scanline from the next. Similarly the rest of the image has two distinct colours all the way down the edges. These are particularly useful when debugging misaligned image data or pitch issues. The bottom row contains the same encoded messages for those crazy image formats which are stored bottom up rather than top down.

So there you go. Use it, modify it, abuse it however you see fit. If I get chance I think I'm going to produce a few variants for lower resolutions (maybe 128x128 and 64x64) plus RGBA versions for testing alpha channels. And suggestions for improvements or tweeks are welcome.

Licensed under Creative Commons 2.0.




I've never really had problems with images who's dimensions are even powers of 2 or multiples of 4. However time and time again I've had issues with images that are funny widths especially. This is a really, really good idea, and I'm not sure how it applies to other people, but the one thing I would change is to make it, say, 257x256 or 259x256, or 257x257, or whatever. I realize that somewhat damages the whole 8-pixels-nice-alignment thing in the border, but it would be very useful in pointing out problems (like the pitch issues you mentioned).

Anyway cool stuff, thanks for sharing it with others :)
Nice idea, I like it!
That's really, really well thought out. I could also see it being a useful test texture for certain things.

Thanks for sharing, I'll definitely be borrowing it for my own use.
Hey, very cool! You seem to have most stuff covered, though it might be interesting to include some HDR tests. Is it under any particular license? Creative commons, etc?
Useful. [smile] Shows that IE does not draw images correctly. The one-pixel elements show up smudged when I view them.

Cool idea to spell out info text in the pixel data by the way.
Quote:
Original post by PolyVox
Hey, very cool! You seem to have most stuff covered, though it might be interesting to include some HDR tests. Is it under any particular license? Creative commons, etc?

Although HDR test images would be cool, I don't do HDR myself so I'm not sure I know what would need to be included and what constitutes useful test data.

I've updated the original post with license info (Creative Commons 2.0).
- "safe area" markers. The area which text or important icons will be safely readable on a CRT TV. Useful for console game development.

- Make sure the colour/gamma space of the file is made clear. sRGB?, Gamma 2.2?, linear?

- Colours & greyscale gradients in each of the above colour spaces (useful for determining where gamma and de-gamma bugs are in your engine/pipeline as well as demonstrating the difference between linear and perceptual luminance).

- Maybe take a leaf out of the MPEG test card book and make part of it useful for testing the quality of different DXT/BC compressors.

Recent Comments

PARTNERS