Simulating display characteristics of embedded applications for consistent graphics

In the world of embedded graphics, where small video screens are proliferating in automobiles, GPS systems, music/media players, cell phones, metal detectors, and many other products, there is a marked discontinuity between the quality of PC based desktop graphics and embedded device graphics. On the desktop, you have video cards that contain hundreds of megabytes of video memory, consume more power and generate more heat than most light bulbs, are connected to a host bus wide and fast enough to move data in the gigabytes per second range and are backed by a host processor clocked in the gigahertz range.

Now contrast that with an embedded graphics environment - sometimes running on AA batteries - that contains tens of megabytes of video memory, consumes power in the 2 watt to 5 watt range, is connected to a host bus that moves data in the hundreds of megabytes per second range, and is backed by a host processor that runs in the 100MHz to 333MHz range. Yet, it is in the desktop graphics environments where embedded graphics artwork is created. Consequently, given this disparity it is no surprise when a graphics designer's beautiful artwork for the embedded environment using a tool like Photoshop on their dual-core 2.67 GHz Pentium based PC with 4GB of RAM connected to a 21-inch monitor running at 1600x1200, ends up looking like the graphics from an original Game Boy when deployed in the embedded environment.

So the question is did something happen to the graphics on the way to the embedded environment? Or is the embedded environment not powerful enough to support the graphics designed by the artist? The answer, it turns out, is both.

Part of the problem outlined above lies in the "tool chain" that goes from the desktop to the embedded environment. The tool chain consists of the myriad tools that are used in sequence to go from design to implementation for embedded graphics. Typically, at the head of the chain is a tool like Adobe Photoshop or Adobe Illustrator. Eventually, the graphics created by the use of these tools are exported to some format (like BMP, JPG, PNG, TIFF, etc.) and then handed off to a programmer who has to convert from this artist-chosen format to something that the embedded graphics environment actually understands. It is in this "conversion" process that beautiful graphics can start losing their beauty and in many cases start looking quite compromised -- or worse.

So what causes this graphical degeneration malady? Here is a list of some of the primary issues that I have experienced that can cause good graphics to start going bad during the tool chain process:

• Color space conversion
• Color depth conversion
• Embedded graphics system or end of tool chain tools incapable of utilizing or preserving "alpha" values
• Image scaling
• Screen color depth limitations

So, let's take a closer look at each one of these issues.

Color space conversion
Color space conversion is the process of changing the way color values are represented in graphics elements from one color space format to another. The most commonly known color space is RGB where there is a separate and individual number that represents a red, green and blue value for each pixel. Another commonly used color space is YCrCb where Y is a value that represents the brightness of a pixel (also known as luminance) and CrCb are values that represent the red and blue color components (chrominance) of a pixel. By way of example JPEG uses YCrCb as its color space. To bring a JPEG image into an RGB graphics environment, the color space must be converted from YCrCb to RGB. It is during this process where color errors can be introduced. Subtle shifts in color can take place throughout the conversion and in some cases dramatically change the appearance of the graphics.

In embedded graphics systems, RGB is far and away the most commonly used color space, but there are many other color spaces in use today by graphics design tools. These include: RGB, YCrCb, YUV, Lab, CMYK, HSV and others. It is important that the embedded graphics system engineers communicate color space requirements to the graphics designers to avoid color space conversion artifacts.

Color depth conversion
If I had to choose the single most frustrating problem in the generation of embedded graphics, color depth conversion would be it. Color depth conversion is the process of changing the number of colors in an image (usually reducing the number of colors in an image), as shown in Table 1:


Table 1: Color depth conversion

So, what happens when you take an image that was produced using 24-bit color and you convert it to 8-bit color? The images in Figure 1 provide the answer:

Figure 1: Color conversion

Next: Embedded graphical environments