• 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

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 As you can see, when you reduce the number of colors in an image you start degrading the visual representation of the image. The question that might come to mind however is "Do you HAVE to reduce the number of colors in the image?" If the graphics designer starts with the correct number of colors in mind for the graphic element to be used in the embedded application, they can generally design the images utilizing the required color depth. But what is the purpose of limited color depth? Why not just use 24-bit color all the time? The answer lies in memory consumption. Smaller bit depth images consume less memory than larger bit depth images. Consider Table 2, based on an image that is 800 pixels wide by 600 pixels tall.:


Table 2: Based on 800 pixels wide by 600 pixels tall

In an embedded environment, memory is a precious thing so it is rare that you will find 24-bit color depth in use. In most embedded systems that I have worked with 16-bit color is the "order of the day"with 8-bit color used whenever possible. This results in pressure to perform color depth reduction on a routine basis. Tools like Photoshop don't make it easy to work in 16-bit color (in reality you really can't work in 16-bit color at all without switching your display to 16-bit color and just "eyeballing" it). Photoshop in RGB mode (and most other tools like Photoshop) lives in 24-bit color space. So until the designer "saves out" their work into a 16-bit color format and "looks at it" using some tool that approximates the 16-bit color environment, it is hard for the designer to know what the graphics are going to look like in the embedded environment. (We will discuss solutions for this deficiency below.) But clearly, converting graphics from 24-bit color to 16-bit or even 8-bit color can result in an astounding loss of visual information, so the designer must have a keen awareness of these limitations when designing the graphics, regardless of the design tool used. Four-bit and 1-bit color is often used in embedded graphical environments.

Embedded graphics system tools at the chain's end can't use or preserve alpha values
Let's start with the term 'alpha'. What is alpha? Simply putalpha is a transparency value. It is a value typically between 0 and 255 that represents how transparent a pixel should be. A value of 0 means that the pixel is 100 percent transparentessentially "gone." A value of 255 means that the pixel has no transparency and looks likes a "normal" pixel. A value of 128 implies that the pixel is 50 percent transparent. Alpha is what tools like Photoshop use to make the edges of objects blend together with their surroundings to eliminate the "jaggies" that you get due to screens having a finite resolution horizontally and vertically. When using alpha, each pixel in the image has a corresponding alpha (transparency) value that goes along with it. Take a look at the following images in Figure 2:

Figure 2: With and without Alpha

As you can plainly see, the images with alpha are much more desirable to look at than the images without alpha. It's easy to see why designers get upset when the images on the right are what they see in their design tool and the images on the left is what they see on the embedded graphics systembut this is VERY often the case. The reason for this is that either the conversion tools that converted the images have no capability to preserve the alpha values for the image, or the embedded graphics system has no ability to display images with alpha...either way you get what you see on the left.

The utilization of alpha is critical in creating high quality graphics and text, especially with screen resolutions that are low enough where individual pixels can be rather easily discerned by the user. Resolutions of 320x240, 640x480, and 800x480 are common in embedded graphics environments. At these resolutions if you cannot use alpha values to blend graphic elements together, the result is almost always undesirable looking text and jagged edges on the graphic elements. If the graphics designer is aware of the fact that alpha will not be preserved in the graphic elements, then they can sometimes create graphics and pick fonts that will minimize this effect in the final system. The ideal solution, however, is to have an embedded graphics environment that supports alpha and a tool chain that preserves alpha throughout the process from studio to screen.

Next: Image scaling

Image scaling
Many times, there is a difference between the size of the graphics elements being produced by the studio and the actual elemental size of the display being used.

This results in the programmer being required to "scale" the graphics up or down to make the element fit on the display in its correct location. Take a look at the following images in Figure 3:

Figure 3: Scaling the graphics

Effects of scaling
As you can see, scaling can have undesirable side effects on image quality. This gauge was designed to exist at a precise size (in this case 200x200) and when the image is scaled much beyond thatthe fonts start becoming unreadable, the effects of aliasing (jaggies) start becoming quite apparent, and the image in general starts to "fall apart". Converselyif we scaled the image down to 100x100 (which is, in effect, a 4x reduction in image quality since we are reducing the image in both the x and y directions) the fonts become unreadable and some of the compass "ticks" disappear. So, in short, this gauge was designed to be viewed at 200x200 on a specific size screen.

The ultimate destination screen size is also a very important issue that must be taken into account. When a graphics designer designs an element on a 21" monitor at 1600x1200 it's going to look very different on a 8" display at 800x480. Even assuming that you create a "800x480" frame with your design tool on your 21" monitor at 1600x1200, the actual physical representation of what is seen by the designer will be significantly different than what will be seen by the user. The ideal in this case is to create a "template" for the design tool (called a "preset" in Photoshop) that would physically mirror the size of the target display on the screen. There are, of course, many problems with that scenario, notably aspect ratio issues, resolution issues (pixels/inch), and pixel ratios (square versus non-square). It is, however, possible to get "close" and that is important. The planned viewing distance from the display should also be taken into account if possible. If these issues are not taken into account, the result is a display that doesn't work for the user and graphics that must be constantly "tweaked" to make them usable in the final product.

Pythagorean theorem
Let's look at an example of setting up your design tool that is driving a PC's monitor to mirror the actual targeted embedded graphics display. First, we need to either know or calculate the "pixels per inch" value for your PC's monitor. This can be done a couple of ways. If you know the diagonal size of your display and your display's "aspect ratio" you can calculate the horizontal and vertical size of your display in inches. The aspect ratio for standard monitors is 4:3, meaning if the width of your display was 4 inches, your height would be 3 inches. 640x480, 800x600, 1024x768 are all 4:3 aspect ratios (which works out to 1.33 when you divide 4/3). My desktop monitor is natively 1280x1024. This works out to an aspect ratio of 5:4 (1.25). The diagonal on my monitor is 19 inches. Now, some math. Since we know the diagonal of our PC monitor in inches and we know the aspect ratio of our monitor we can calculate the horizontal and vertical dimensions in inches precisely by using simple Euclidean Geometry and the Pythagorean Theorem of a²+b²=c² (governing the lengths of sides of a right triangle). See Figure 4 below.


Figure 4: Pythagorean Theorem
First, we have to solve for c so we can calculate for a 19-inch diagonal. If our aspect ratio is 5:4 then a=5, b=4 and c² would be the square root of a²+b² which would be the square root of 41 (25+16) which would be approximately 6.4. So our ratios between the sides are 5:4:6.4. Since we know our screen diagonal is 19 inch we simply multiply by our ratios:

19 X 5/6.4 = 14.84 horizontally

19 X 4/6.4 = 11.875 vertically

Another way to get the horizontal and vertical dimensions of your monitor is to use a tape measure.

Once you have the dimensions in inches, calculate the pixels per inch for your monitor. This is easy - just divide the number of pixels by the number of inches.

1280 horizontal pixels / 14.84 inches = 86 pixels/inch

1024 vertical pixels / 11.875 inches = 86 pixels/inch

As you can see since the math works out to 86 pixels/inch in both directions this means my pixels are square...which is good since most tools only allow you to set pixels/inch as a single value. Now, use those values we calculated. Designers will need to do the calculation (or measure) for the embedded display to get the right horizontal and vertical dimensions in inches. The embedded graphics display I'm using for this example is an 8-inch LCD display at 800x480. This yields an aspect ratio of 8:5 (1.6) and when you "run the numbers" you get 8:5:9.434 and with an 8 inch diagonal this yields: 6.78 inch horizontal and 4.24 inch vertical.

Now for Photoshop you would click on File->New and set the width of the new image to 6.78 inches and the height to 4.24 inches and the resolution to 86 pixels/inch and what you see on your screen will be an exact physical representation of the target embedded graphics display. Remember though, that the pixel counts will be off horizontally and vertically so this should only be used as for visual reference and not for actual design. This visual representation, however, will be extremely helpful to the designer in determining how the size of the graphic elements (including fonts) will work relative to one another and relative to the user.

Next: Screen color depth limitations Screen color depth limitations
Many times, there is a difference between the color depth that is supported by the graphics controller and the embedded graphics system display itself. For example, let's say that your graphics controller outputs 24-bit color (8 bits of RGB). Now let's say that the display being connected to the graphics controller supports 18-bit color (6 bits of RGB). This means that the number of unique colors that can be represented by the display is reduced to 262,144 colors out of the 16 million colors the graphics controller can generate. This is a unique color value reduction of 6,400 percent.

As we discussed before it is rare that 24-bit color depth is used in embedded graphics, but I have encountered several cases where a 24-bit color layer might be used as a "background" layer, perhaps a blue gradient that fills the screen that the other graphic elements will be placed on as in Figure 5:

Figure 5: 18-bit and 24-bit color

You can clearly see the "banding" caused by a reduced color depth in the 18-bit color example but there is no such banding with 24-bit color, for obvious reasons. This is another example where the graphics designer might say "It looks great on my system" but ends up appearing "not as planned" on the target embedded graphics system.

This problem is not so easy to isolate in the studio especially since you can't just "pop" graphics design tools into an 18-bit color mode to see how the graphics will look. This case might require some back and forth between the graphics designer and the system engineers to resolve.

Designing high quality graphics for embedded graphical environments is not a trivial task. But staying aware of these five key issues can help insure that the graphics generated in the studio will look the same on the embedded system's screen. Often, graphics designers don't always understand the limitations imposed on them by the target hardware. When this is the case, the graphics being generated don't work well on the target system and a lot of additional time and money must be spent to get everyone on the "same page." Having an understanding of these five issues and planning for them by the entire team will result in far fewer surprises once the graphic elements are deployed on actual embedded hardware.

Fujitsu Microelectronics America, Inc., a leader in the embedded graphics controller market, has utilities, plug-ins for leading graphics design tools and hardware to help graphics designers visualize their designs quickly and accurately for embedded target graphics hardware. This collection of software and hardware, referred to collectively as the "Coral Graphics Design Suite" can significantly reduce unexpected results from the process of studio to screen saving our customers time and money when working with embedded graphics.

About the author
Rick Tewell oversees software development strategy for Fujitsu Microelectronics' family of Graphic Processing Units. Previously, he founded Sequoia Advanced Technologies, Inc. which developed one of the first digital video implementations for the Windows and PC platforms using IEEE-1394 so users can connect digital camcorders to PCs for capturing and editing. In 2000, when Ligos Corporation acquired Sequoia, his team engineered a technology solution for converting video from digital camcorders directly to the MPEG-2 (DVD) format. He can be reached at attewell@fma.fujitsu.com.