Use of Images in U-verse Enabled Applications

[#1]

This post was orginally written as a forum topic by John O Dowd.

In this post, I am going to step back from the U-verse Enabled SDK and talk about the design considerations for using images in an U-verse Enabled Application. I will go over the image formats supported by U-verse Enabled Applications and the considerations you will need to take so your application will be have the layout you desire on both high definition televisions and standard definition televisions, with different aspect ratios.

The features described in this post may be used only with content that you have permission to use, and should not be used with U-verse TV content or programming in the form of overlays, squeezebacks, or other means.

Supported Resolutions

The resolutions and aspect ratios that are supported by the U-verse television service. 

SD (standard definition)	640x480 pixels	4:3 aspect ratio
SDW (standard definition wide)	854x480 pixels	16:9 aspect ratio
HD 720p (high definition)	1280x720 pixels	16:9 aspect ratio
HD 1080i (high definition)	1920x1080 pixels, interlaced	16:9 aspect ratio

Applications do not support 1080i, but are expected to support the three other resolutions. At the moment the recommended method is to design for SD and SDW modes only. The U-verse Enabled receivers can scale SDW layouts to HD without additional coding. There are also texture memory limits, which I will discuss later in the post, that are easier to adhere to, if you only use standard definition resolutions. The major consideration with layout changes between SD and SDW would the left location of the on-screen elements and how to re-position your elements for a wider screen size. SD and SDW have the same pixels in the y direction, while SD has 640 pixels in the x direction and SDW has 854 pixels in the x direction. 

SD	640x480 pixels	4:3 aspect ratio
SDW	854x480 pixels	16:9 aspect ratio
HD 720p	1280x720 pixels	16:9 aspect ratio

In designing the application layout it is important to consider some televisions will overscan the video signal. Televisions will differ in the amount of overscan, but the general recommendations are for 90% of the viewing screen to be “action safe” , suitable for the display of graphics and 80% of the viewing screen to be “title safe”, suitable for the display of text on a SD television. On televisions with a 16:9 aspect ratio, the “action safe” and “title safe” are both recommended to be 90% of the television resolution. 

SD full resolution	100%	640x480 pixels
SD action safe	90%	576x432 pixels
SD title safe	80%	512x384 pixels
SDW full resolution	100%	1152x648 pixels
SDW safe area	90%	768x432 pixels
HD full resolution	100%	1280x720 pixels
HD safe area	90%	1152x648 pixels

Image Formats

The only image formats supported by receivers are JPEG and PNG. All images must be in the RGB colorspace.

• PNGs must be 32 bit per pixel (8 bits each of RGB and alpha).
• JPEGs must be 32 bit as well and cannot be progressive.

In the RGB colorspace all values should be less than 240 and the white in U-verse Enabled library is set at RGB(235, 235, 235). This is to avoid bloom that will make text and graphics less legible The largest size that images will be rendered for is 720p, but it is recommended that create jpegs at 1/4 the desired resolution and let the hardware scale up.

Texture Memory Management

All graphic elements except solid color fills are loaded into texture memory. The lowest powered receiver will have 6.5 MBs of texture memory. A good estimate for the system widgets(volume control, etc) is 500 kB. When a new page is being loaded into memory, the old page will remain in memory until the new page is loaded. Therefore a good estimate for the maximum texture size of a page is 3MB. You could go above this, but would need to test and try to design any transition to be from/to a lower page texture size and and the larger page texture size. 

Textures are created when the first packet of the image arrives at the receiver. The exception to this is uveLabel textures will be created on page load. If there is not enough texture memory available, the request will fail. The graphics subsystem requires that each image is stored in a continuous block of memory, which can lead to fragmentation of the texture memory, and large textures can fail to load because there is not a large enough block of continuous memory available even if there is enough memory available.

When a new page is loaded, all the textures for the new page will be created and loaded in to texture memory while the currently displayed page is still on screen. Once the new page is fully loaded in to texture memory, the new page will be displayed on screen and the textures used by the old page will then be released.

A couple of tips

Scale up large images. A 1280x720 background only leaves you 1.2MB for foreground textures. If you scale up a 854x480 image you’ll save 1MB of texture memory and, if you turn up the JPEG quality to get the same file size it will often look just as good on a TV set.

Keep your backgrounds simple and save the texture detail for the foreground.

Break up large images when the opportunity presents itself. Borders should be broken into 4 or 8 pieces. This is due to the fact if you supply the border as one image the empty space in the middle of the image will be counted towards the texture budget.

Try not to clip textures. The pixels that are not shown but part of the texture still count against your texture budget

Beware texture layering. The more textures you stack, the more memory you use to fill that real estate. Note that many controls create multiple texture layers. For instance a TVButton uses separate textures for background, text, focus text (due to different focus foreground color), focus background, glow, focus glow and onClick animation. Usually these are shared across many buttons, but if every button uses different textures it can be a problem. All textures on screen will count towards the texture memory limits. For example when drawing text over an image, both are stored as separate textures, and will both count towards the texture memory limit even though, they occupy the same area on the screen.

If you have any questions or comments about this post, please reply on the original forum topic.

[#2]

This post was orginally written as a forum topic by John O Dowd.

In this post, I am going to step back from the U-verse Enabled SDK and talk about the design considerations for using images in an U-verse Enabled Application. I will go over the image formats supported by U-verse Enabled Applications and the considerations you will need to take so your application will be have the layout you desire on both high definition televisions and standard definition televisions, with different aspect ratios.

The features described in this post may be used only with content that you have permission to use, and should not be used with U-verse TV content or programming in the form of overlays, squeezebacks, or other means.

Supported Resolutions

The resolutions and aspect ratios that are supported by the U-verse television service. 

SD (standard definition)	640x480 pixels	4:3 aspect ratio
SDW (standard definition wide)	854x480 pixels	16:9 aspect ratio
HD 720p (high definition)	1280x720 pixels	16:9 aspect ratio
HD 1080i (high definition)	1920x1080 pixels, interlaced	16:9 aspect ratio

Applications do not support 1080i, but are expected to support the three other resolutions. At the moment the recommended method is to design for SD and SDW modes only. The U-verse Enabled receivers can scale SDW layouts to HD without additional coding. There are also texture memory limits, which I will discuss later in the post, that are easier to adhere to, if you only use standard definition resolutions. The major consideration with layout changes between SD and SDW would the left location of the on-screen elements and how to re-position your elements for a wider screen size. SD and SDW have the same pixels in the y direction, while SD has 640 pixels in the x direction and SDW has 854 pixels in the x direction. 

SD	640x480 pixels	4:3 aspect ratio
SDW	854x480 pixels	16:9 aspect ratio
HD 720p	1280x720 pixels	16:9 aspect ratio

In designing the application layout it is important to consider some televisions will overscan the video signal. Televisions will differ in the amount of overscan, but the general recommendations are for 90% of the viewing screen to be “action safe” , suitable for the display of graphics and 80% of the viewing screen to be “title safe”, suitable for the display of text on a SD television. On televisions with a 16:9 aspect ratio, the “action safe” and “title safe” are both recommended to be 90% of the television resolution. 

SD full resolution	100%	640x480 pixels
SD action safe	90%	576x432 pixels
SD title safe	80%	512x384 pixels
SDW full resolution	100%	1152x648 pixels
SDW safe area	90%	768x432 pixels
HD full resolution	100%	1280x720 pixels
HD safe area	90%	1152x648 pixels

Image Formats

The only image formats supported by receivers are JPEG and PNG. All images must be in the RGB colorspace.

• PNGs must be 32 bit per pixel (8 bits each of RGB and alpha).
• JPEGs must be 32 bit as well and cannot be progressive.

In the RGB colorspace all values should be less than 240 and the white in U-verse Enabled library is set at RGB(235, 235, 235). This is to avoid bloom that will make text and graphics less legible The largest size that images will be rendered for is 720p, but it is recommended that create jpegs at 1/4 the desired resolution and let the hardware scale up.

Texture Memory Management

All graphic elements except solid color fills are loaded into texture memory. The lowest powered receiver will have 6.5 MBs of texture memory. A good estimate for the system widgets(volume control, etc) is 500 kB. When a new page is being loaded into memory, the old page will remain in memory until the new page is loaded. Therefore a good estimate for the maximum texture size of a page is 3MB. You could go above this, but would need to test and try to design any transition to be from/to a lower page texture size and and the larger page texture size. 

Textures are created when the first packet of the image arrives at the receiver. The exception to this is uveLabel textures will be created on page load. If there is not enough texture memory available, the request will fail. The graphics subsystem requires that each image is stored in a continuous block of memory, which can lead to fragmentation of the texture memory, and large textures can fail to load because there is not a large enough block of continuous memory available even if there is enough memory available.

When a new page is loaded, all the textures for the new page will be created and loaded in to texture memory while the currently displayed page is still on screen. Once the new page is fully loaded in to texture memory, the new page will be displayed on screen and the textures used by the old page will then be released.

A couple of tips

Scale up large images. A 1280x720 background only leaves you 1.2MB for foreground textures. If you scale up a 854x480 image you’ll save 1MB of texture memory and, if you turn up the JPEG quality to get the same file size it will often look just as good on a TV set.

Keep your backgrounds simple and save the texture detail for the foreground.

Break up large images when the opportunity presents itself. Borders should be broken into 4 or 8 pieces. This is due to the fact if you supply the border as one image the empty space in the middle of the image will be counted towards the texture budget.

Try not to clip textures. The pixels that are not shown but part of the texture still count against your texture budget

Beware texture layering. The more textures you stack, the more memory you use to fill that real estate. Note that many controls create multiple texture layers. For instance a TVButton uses separate textures for background, text, focus text (due to different focus foreground color), focus background, glow, focus glow and onClick animation. Usually these are shared across many buttons, but if every button uses different textures it can be a problem. All textures on screen will count towards the texture memory limits. For example when drawing text over an image, both are stored as separate textures, and will both count towards the texture memory limit even though, they occupy the same area on the screen.

If you have any questions or comments about this post, please reply on the original forum topic.