for the Nokia 5510 and Nokia Music Player HDR-1

NOKIA AUDIO MANAGER

Copyright Nokia Mobile Phones 2002. All rights reserved | Issue 4

SUPPORT GUIDE FOR

Contents
1. 2. 3. 4. 5. 6. 7. 8. 9. INTRODUCTION.... 1 SYSTEM REQUIREMENTS... 1 AAC AND MP3.... 2 DIGITAL AUDIO TERMS.... 3 LSE DIGITAL RIGHTS MANAGEMENT (DRM).... 3 INSTALLING THE NOKIA AUDIO MANAGER... 3 NOKIA AUDIO MANAGER.... 4 TRANSFERRING SONGS TO NOKIA 5510 OR NOKIA MUSIC PLAYER HDR-1.. 6 COMMON PROBLEMS TRANSFERRING... 7

10. OTHER ISSUES.... 8

Legal Notice Copyright Nokia Mobile Phones 2002. All rights reserved. Reproduction, transfer, distribution or storage of part or all of the contents in this document in any form without the prior written permission of Nokia is prohibited. Nokia and Nokia Connecting People are registered trademarks of the Nokia Corporation. Other product and company names mentioned herein may be trademarks or tradenames of their respective owners. Nokia operates a policy of continuous development. Nokia reserves the right to make changes and improvements to any of the products described in this document without prior notice. Under no circumstances shall Nokia be responsible for any loss of data or income or any special, incidental, consequential or indirect damages howsoever caused. The contents of this document are provided "as is". Except as required by applicable law, no warranties of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose, are made in relation to the accuracy, reliability or contents of this document. Nokia reserves the right to revise this document or withdraw it at any time without prior notice.

INTRODUCTION

This guide briefly describes how to begin using Nokia Audio Manager. For more detailed information on the use of the Nokia Audio Manager, please refer to Online Help in the Nokia Audio Manager application. The Nokia Audio Manager consists of the following features: add audio files to the Nokia Audio Manager database by recording from a compatible audio CD (in AAC format, from 64 kbit/s to 192 kbit/s compression rate supported) play tracks from a compatible CD downloaded audio files from the Internet (should be converted to.lse format before using with Nokia 5510 or Nokia Music Player HDR-1 create custom playlists of selected tracks play tracks and playlists from the Nokia Audio Manager database create libraries of music collections to help organize audio files transfer selected tracks to the Nokia 5510 or Nokia Music Player HDR-1 Delete selected tracks in your Nokia 5510 or Nokia Music Player HDR-1 Format you new memory card for use with Nokia Music Player HDR-1 personalize the Nokia Audio Manager settings equipped with Help Menu that answers your questions on the usage Caution: Nokia 5510 supports only FAT file format; so do not format your Nokia 5510 to any other format (I e NTFS).

SYSTEM REQUIREMENTS

To install and run the Nokia Audio Manager, you need: An Intel-compatible PC (at least 266 MHz MMX and 64 Mb of system memory) equipped with Windows 98/Me, Windows 2000 Furthermore the software is not supported on a homemade PC with Windows 98 installed and/or a computer which has had its system upgraded from Windows 95/3.1 to Windows 98
Display/Monitor: More than 800 x 600 pixels. More than 65,536 colors, High Color setting. Browser: Microsoft Internet Explorer or Netscape Navigator, versions 4.0 or higher. CD-ROM driver *: SCSI/ANSI X3T10-1048D standard. ATAPI/SFF-8020i standard. Recommended Soundcard **: Sound Blaster 16 (recommended)
At least 35 MB of free disk space (preferably more), additional free space is required for music files For connection between the Nokia 5510 or Nokia Music Player HDR-1 and a PC you need a compatible USB 1.0/1.1 or above version of USB port in computer Internet connection*** for the use of CDDB (Compact Disc DataBase located in the Internet that has the album names and track titles stored for almost all of the Audio CD's available) Notes: * CD-ROM speeds may affect quality of encoding ** The soundcard is not required but without it playback of music with the Nokia Audio Manager on the personal computer is not possible *** Nokia Audio Manager 1.0 can be used without Internet connection and the track names and the album name can be inputted by the user Note: In this guide, all references to personal computers (PC) are also applicable to laptop computers. The USB connection is only available for Windows ME/98/2000.

Nokia Audio Manager supports Nokia Music Player HDR-1 and Nokia 5510 phone. The Nokia Music Player HDR-1 supports the following Nokia phones
Nokia 3310, Nokia 3330, Nokia 8250 and Nokia 8890 Nokia 8210, Nokia 8850 and Nokia 8850 Gold Edition Voice call activation via headset No voice call activation

AAC

AAC AND MP3
Stands for "Advanced Audio Coding" Is a high-quality audio compression coding technology Provides high-quality audio reproduction at lower bit rates Near CD quality at 64 kbit/s Supported by the Nokia 5510, Nokia Music Player HDR-1 and Nokia Audio Manager Stands for MPEG-1 Audio Layer III Is a format for audio compression developed in the beginning of 1990's Near CD quality at 128 kbit/s
Supported by the Nokia 5510, Nokia Music Player HDR-1 and the Nokia Audio Manager

DIGITAL AUDIO TERMS

Ripping (encoding) converting CD Audio to a digital audio format Bit Rate (kbits/sec) amount of data/second in the audio stream. The higher the bit rate, the more data used to express the sound, resulting in higher quality sound Most common is 128 kbps (64 kbps for newer formats (WMA, AAC and MP3Pro) NAM encodes into 64 kbps AAC by default Wave file (.wav), uncompressed audio file, 11x the size of a typical MP3 file and about 22x the size of a typical AAC file DRM (Digital Rights Mgmt) Technology used to secure a user rights to a file and enforce use policies set by content owners
LSE DIGITAL RIGHTS MANAGEMENT (DRM)
Nokia 5510 and Nokia Music Player HDR-1 support LockStream Encoding. So, when you buy tracks from I e Internet please verify that they are in LSE secured format. Digital Rights Management (DRM) technologies aim to protect and manage rights and interests in digital information. Authors, publishers, enterprises, and other participants are empowered to specify and agree on the rules regarding the use of digital information. DRM technologies protect various forms of digital information, enable persistent application of the agreed rules throughout the life cycle of the information, and help to automate many e-commerce processes related to content use. The Nokia 5510 supports high-quality AAC (Advanced Audio Coding). This AAC format is wrapped in Digital Rights Management technology, which assists that music cannot be uploaded to illegal websites that infringe copyright laws or distributed illegally. AAC is the preferred digital file format of a growing number of audio content companies.

INSTALLING THE NOKIA AUDIO MANAGER
1. Start the Nokia Audio Manager installation from CD-ROM 2. Follow the instructions on the screen, and note the following: - on the 3rd installation screen you are asked for the "Destination Location" where to store the files created with the Nokia Audio Manager (Picture 1.) - on the 7th installation screen you are prompted to choose whether to use the Nokia Audio Manager as your default player or not. It is advised to choose no if you have a lot of mp3 and AAC files stored already on your computer. Furthermore please notice that all the files imported to Nokia Audio Manager
are copied to Destination Folder that you chose on the 3rd installation screen. So, after adding files to Nokia Audio Manager you will have a duplicate of them, one unsecured (the original, in the original location) and the secure (in the Destination Folder). Please see Picture 2.
Picture 1. Choosing the Destination Location for the music files that you create in the Nokia Audio Manager.
Picture 2. Choosing whether to use the Nokia Audio Manager as your default player for media files or not. Note: Some installations may require a reboot to complete the installation. This depends on what version of Microsofts Windows Media Components is already installed on the PC.
Nokia Audio Manager supports playing of various media file types (both audio and video). However only MP3, AAC and Audio CD tracks (in AAC format) can be transferred to Nokia 5510 or Nokia Music Player HDR-1. You can only export music with Nokia Audio Manager, so you can't get any music files from your device back to your computer.
CD RIPPING - GETTING MUSIC INTO THE APPLICATION
Insert Audio CD Respond to prompt to retrieve track titles from the Internet (only Nokia Audio Manager 1.0) If connected to Internet, click YES, otherwise, click NO
If NO, edit track titles manually Click Read CD Encrypted songs are placed in default folder, added to database, playlist with Album Name is created Q. Where are the ripped music files? A. Default location = c:\My Music\Audio Manager Music\
WORKING WITH TRACKS AND PLAYLISTS - MAKE A PLAYLIST FEATURES
Adding non-CD Audio files to NAM Drag and Drop from Windows Explorer into NAM playlist window File>Add Tracks; browse for tracks, select single or multiple File>Search Hard Disk for Tracks Note: A duplicate secure copy of each MP3 and AAC file that is added to NAM is automatically created into Default Location Folder (by default C:\My Music\Audio Manager Music\). Note: NAM will not make any file conversions. So, you can not convert I e.wma or.wav files into MP3 or AAC format using NAM.

7.2.1 Add tracks using Drag & Drop
Open either a folder or a Windows Explorer and browse for media files. Select and drag the media files that you wish to add to NAM to Make a Playlist window. Playlist is created using the source folder name.
7.2.2 Add tracks using File Add Tracks
Go to File menu and select Add Tracks. Add tracks file dialogue box will open. Browse the folders to search for media files and select the files that you wish to add to NAM.
7.2.3 Add tracks using Search HD for Tracks
Go to File menu and select Search HD for Tracks. NAM will search your HD for media files and add all the files that it supports. All the added MP3 and AAC files are automatically secured.
Note: After adding files to Make a Playlist Window you need to click on "Save tracks as Playlist" to create a playlist. Only files that are in the playlist can be transferred to Nokia 5510 or Nokia Music Player HDR-1.
7.2.4 Make a Playlist functions
Select Track from Database Use to create custom lists of individual tracks in the database. Sort the track database by: Type, Title, Artist, Time (Length), Genre, Rating Search select sort field and type in name; list jumps to matching entries Edit track info Delete tracks Deleting Multiple tracks, must right-click and select delete tagged tracks
TRANSFERRING SONGS TO NOKIA 5510 OR NOKIA MUSIC PLAYER HDR1
Initiate transfer from: Make A Playlist window right-click and select send tracks to portable device Select tracks and click Copy to Portable Copy to Devices window
Color Coded Device Memory Status indicates space used (green), amount needed by selected music (yellow), and total available on player (gray), amount over capacity (red) NAM will warn user if selected files will not fit on the device If DRM license prohibits transfer or the selected files media type is not MP3 or AAC following screen will appear (Picture 3.)
Picture 3. Cannot Add Tracks window. Just click on "Proceed without these selections".
COMMON PROBLEMS TRANSFERRING
Unable to communicate with portable device Dead/low battery Try new battery Check power setting Unplug USB cable, power off device, power on device, plug-in USB and click Refresh With device connected, Check Device Manager for Unknown device or Unknown USB device. Remove that from Device Manager and disconnect device until after NAM is installed Powered off Device not detected in Nokia Audio Manager when trying to transfer songs Device connected to PC prior to install of the NAM software (and device drivers)

10. OTHER ISSUES

Q. Music that is either ripped or added to NAM does not play on other PCs or on the same PC with another music application (like Real Jukebox, WinAmp, etc).

A. NAM creates locally encrypted files that are only meant to be played back on the PC using NAM or
transferred to Nokia 5510 or HDR-1. If the.LSE file is moved to another PC, error message appears when attempting to play it through NAM. Even if the MainDB is copied along with the.LSE files to the new PC, error message will appear and you cannot play the tracks.

High Dynamic Range Texture Compression
Kimmo Roimela Tomi Aarnio Joonas It ranta a Nokia Research Center
Figure 1: Encoding extreme colors. Left to right: original (48 bpp), our method (8 bpp), DXTC-encoded RGBE (12 bpp), and our method with less bits for color (see 3.2). The intensity of the red illumination brings out the artifacts resulting from low color resolution.

Abstract

We present a novel compression scheme for high dynamic range textures, targeted for hardware implementation. Our method encodes images at a constant 8 bits per pixel, for a compression ratio of 6:1. We demonstrate that our method achieves good visual delity, surpassing DXTC texture compression of RGBE data which is the most practical method on existing graphics hardware. The decoding logic for our method is simple enough to be implemented as part of the texture fetch unit in graphics hardware. CR Categories: I.3.1 [Computer Graphics]: Hardware ArchitectureGraphics processors I.3.6 [Computer Graphics]: Methodology and TechniquesGraphics data structures and data types I.3.7 [Computer Graphics]: Three-Dimensional Graphics and RealismColor, shading, shadowing, and texture I.4.2 [Image Processing and Computer Vision]: Compression (Coding) Approximate methods Keywords: HDR, high dynamic range, texture, image, compression, graphics hardware
storing the light incident on a point, and light maps that store the radiance of a surface. Recent consumer graphics hardware has support for HDR via oating-point processing throughout the graphics pipeline, including textures for light probes and light maps. However, HDR images consume huge amounts of storage space and memory bandwidth. While texture compression is commonly used to reduce the memory requirements of LDR textures, there is no adequate scheme for compressing HDR textures as of yet. Given that real-time rendering is usually memory bandwidth limited, it is clear that LDR texturing today can achieve much better performance than HDR texturing. In this paper, we present a new HDR texture compression method suitable for hardware acceleration. We demonstrate that HDR texture compression can achieve equivalent compression ratio and image quality as LDR texture compression, with only a moderate increase in decoding complexity.
Background and related work

Introduction

High dynamic range (HDR) imaging and rendering have become popular topics in computer graphics in the recent years. Whereas a traditional low dynamic range (LDR) image can store only a fraction of the range of luminances encountered in the real world at any reasonable precision, a HDR image can accurately capture the entire range of luminances in most natural scenes. For photographs, this allows the nal exposure to be determined after capturing the image, as well as making local exposure adjustments to achieve various kinds of tone mapping. In computer graphics, it allows us to use natural light for lighting the virtual world via light probes,

e-mail:

Formats for representing high dynamic range images have been actively researched for quite some time now, and several good alternatives for storing and manipulating HDR images exist [Reinhard et al. 2006]. Texture compression is also routinely used to extract good performance out of graphics hardware. However, traditional texture compression methods are not a perfect match for HDR images, and there has been little research on combining the two.

High dynamic range image formats
{kimmo.roimela|tomi.aarnio|joonas.itaranta}@nokia.com
Radiance RGBE [Ward 1992] is probably the most widely used HDR image format. It uses 8 bits each for the red, green, and blue color channels and another 8 bits for a shared exponent, for a total of 32 bits per pixel (bpp). The bit allocation is not optimal, as the representable dynamic range of luminance is unnecessarily wide, whereas precision and color gamut could be improved [Ward 2005a]. The LogLuv encoding [Ward Larson 1998] improves upon RGBE by trading dynamic range for more accurate chromaticity. There are two variants of LogLuv, one using 24 bits per pixel and the other using 32. LogLuv32 is nearly optimal in the sense of providing sufcient (but not excessive) dynamic range for luminance, and just
c ACM, 2006. This is the authors version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The denitive version was published in ACM Transactions on Graphics, Volume 25, Number 3, July 2006. http://doi.acm.org/10.1145/1141911.1141945
enough bits for accurate color representation. The 24-bit encoding causes visible artifacts due to the limited range of luminances that it can represent. [Ward 2005a] A 27-bit-per-pixel encoding similar to LogLuv was introduced in [Mantiuk et al. 2004] in the context of HDR video encoding. It provides better color resolution than LogLuv24, and signicantly expands the dynamic range with a luminance quantization scheme that is adapted to the properties of the human visual system. The OpenEXR format was published in 2002 by Industrial Light & Magic. In its basic form, OpenEXR encodes pixels as RGB triplets of 16-bit oating point values, for a total of 48 bits per pixel. This gives higher precision and a wider color gamut than any of the other formats, albeit with a lower dynamic range [Ward 2005a]. The 16bit half oat datatype is widely supported in contemporary graphics hardware. A software library for manipulating images is also freely available from ILM, making OpenEXR a convenient choice for application developers. The JPEG2000-based codec from [Xu et al. 2005], called simply JPEG2000 in this paper, represents the state of the art in HDR still image compression. It provides very high image quality at only 2 bpp in most cases. A similar HDR extension to traditional JPEG was proposed by Ward in [2005b]. It is slightly less effective than JPEG2000, but has the important virtue of being backwards compatible with JPEG.

exponent [Persson 2005], but is nevertheless a useful approach in many cases.

Our approach

We set out to design a method that would be useful for the majority of real-time rendering use cases. This includes light probes and light maps, both of which are representations of natural light. We explicitly ruled out support for alpha channels and negative values. Various rendering algorithms make use of oating point values in storing arbitrary data in textures, but the precision requirements for such data vary by application. This makes application-specic compression methods more practical. The complexity of the decompression algorithm determines the complexity of the hardware, which directly translates into cost and power consumption. We aimed at decoding complexity comparable with existing LDR texture compression methods. This meant minimizing the number of oating point operations required in the decoder, and choosing luminance and chrominance mappings that have extremely straightforward transformations back to the RGB color space. Any perceptual color spaces, such as CIE L u v , would have been prohibitively complex to implement, and we wanted something even simpler than common encodings such as YUV and YCbCr. We initially experimented with DXTC texture compression augmented with an HDR exponent (power-of-two scaling value) per block, with the LDR part non-linearly mapped from linear light to 8-bit integers. Regardless of the mapping function used, it proved difcult to avoid visible quantization and blocking artifacts in problem areas with either smooth luminance variation or high-contrast edges. An explicit mapping function also made the decoder more complex than we wanted it to be, and adding auxiliary data to a 64bit block made for an impractical block size. We therefore chose to design a new coding scheme directly for HDR data. Like most texture compression methods, we chose block-based compression to achieve xed-rate coding. The block size must align well with hardware architectures, which favors powers of two in both bytes and pixels. The size must be large enough to exploit any block-global features, and small enough to keep blocking artifacts to a minimum. We also wanted to keep the blocks square to avoid any dependency on image orientation. A block size of pixels seemed like the best balance between these requirements. To t in the HDR data, we set the target block size at 16 bytes, or 8 bits per pixel. This is twice the size of DXTC and ETC blocks, giving the same compression ratio. Each block is encoded independently of all other blocks and without any image-global data such as a palette. This way, no dependent memory reads are required to fetch a texel, and the blocks can be cached in compressed form if this makes the texture fetch unit more efcient.

Texture compression

Texture compression is used in graphics hardware to reduce the consumption of texture memory, memory bandwidth, and ideally, texture cache. A successful texture compression method must strike a balance between bit rate and image quality while satisfying the constraints of hardware implementation. Each of the multiple texture fetch units must be able to decode texels from random locations in the image at a very high speed and in parallel to the other units. For best performance, each unit would have its own texture decoder. In practice, only xed-rate methods can provide simple enough decoding logic and random access to individual pixels. The concept of rendering directly from compressed textures was introduced in [Beers et al. 1996] and [Knittel et al. 1996]. The de facto standard in the eld is S3TC/DXTC [Iourcha et al. 1999], although it no longer represents the state of the art. More recent methods such as PVR-TC [Fenney 2003] and particularly iPACKMAN1 [Str m and Akenine-M ller 2005] provide better image quality at o o the same bit rate (4 bpp, for 6:1 compression over 24-bit RGB) and equivalent hardware complexity. Note that these are all xed-rate methods. None of the existing HDR image encodings are viable candidates for a compressed texture format. RGBE, LogLuv and particularly OpenEXR use more bits per pixel than desirable, whereas the JPEG based formats do not support random access to individual pixels. One way to compress HDR textures for real-time rendering is to store them in the RGBE format, so that the exponents are either stored into the alpha channel or separated into an 8-bit luminance texture. The RGB channels can then be compressed with any LDR texture compression scheme, typically DXTC. The high dynamic range colors are reconstructed in the pixel shader by multiplying the RGB values by 2exp128 , where exp is the separately stored exponent, and 128 is the exponent bias used by RGBE. This does cause certain artifacts due to linear texture ltering of the nonlinear

1 also

Coding oating point luminance
known as Ericsson Texture Compression, ETC
The half oat numbers used in OpenEXR and graphics hardware are similar to IEEE oating point numbers, only with 16 rather than 32 bits: the most signicant bit is the sign bit, which is followed by ve bits of exponent and ten bits of mantissa. A useful property of both formats, as pointed out in [Blinn 1997], is that the integer bit pattern of a positive oating point number is a piecewise linear approximation of the logarithm of that number. We take advantage of this to encode high-contrast blocks logarithmically, and low-contrast blocks linearly, both with very few bits per pixel. In
the following, we use the notation bits( f ) to denote the integer bit pattern of a oating point number f. The sign bit is assumed to be zero for all input values. Table 1 shows our bit allocation for luminance data in a single block of 16 pixels. From the pixels in half oat format, we rst compute per-pixel luminance values L p = (R p + 2G p + B p )/4, (1)

rQ + gQ + bQ = 1,

which allows us to discard one of the components without losing any information. For efcient decoding, we normalize with the color sum from Equation 1. This gives the coordinates
where p is the index of a pixel within the block and (R p , G p , B p ) its half oat RGB color; the factor of two on green approximates perceptual weighting and makes for efcient arithmetic. We then nd the per-pixel luminance with the smallest-valued bit pattern. From that, we construct a bias value Lbias by zeroing the ten least signicant bits, leaving ve bits to store in the compressed block. The bit pattern of Lbias is subtracted from the luminance bit pattern of each pixel p to arrive at differential luminances L p :
RQ RQ + 2GQ + BQ BQ bQ =. RQ + 2GQ + BQ rQ =

(4) (5)

With all the input values positive, rQ and bQ fall in [0.1], which we quantize into seven bits each as shown in Table 2. Together with Table 1, this constitutes the 128 bits allocated for a block.
byte 5 b0 r1 b1 r2 b2 r3 b3 r3 b2 r2 b1 bits 4 rrb0
bits(L p ) = bits(L p ) bits(Lbias ).
The differential luminances will share some number of leading zero bits that we need not encode. We identify the largest L p and count the leading zeros in its bit pattern, disregarding the sign bit. The count is clamped to a maximum of seven and stored in the three bits denoted nzeros in Table 1. Each bit pattern bits(L p ) is then truncated by discarding the nzeros + 1 most signicant bits, the +1 accounting for the sign bit. With the leading zeros removed, each truncated bit pattern is rounded to its four most signicant bits. Rounding is required to maintain the overall luminance, but can cause an overow into the previously discarded leading zeros, so we clamp the rounded bit pattern to a maximum of 11112. The clamped result is then stored into the respective lum p eld in the compressed block. The encoded luminance data is 72 bits in total, leaving 56 bits for coding the color information.
byte Lbias lum0 lum2. lum14 bits nzeros lum1 lum3. lum15
Table 2: Bit allocation for chrominance data in the compressed block. We initially tried an alternative bit allocation with ve bits of intensity per pixel and ten bits per color entry. While this gave very good results in general, notable color banding was present with highly saturated colors as seen in the rightmost image in Figure 1. The current allocation seemed to provide a better overall balance between color and luminance artifacts.

Decoding

Table 1: Bit allocation for luminance data in the compressed block.
To decode the luminance L p , we use integer operations only. The differential luminance L p is reconstructed rst: the four luminance bits lum p from the compressed block are substituted for bits immediately following the nzeros + 1 most signicant bits, and all other bits are set to zero. An example of this procedure is shown in Table 3.

nzeros + 1 zero bits 0000 0000. 0000 decoded bits 0110 1011. 0011 zero LSB bits 00000000 00000000. 00000000

Coding color

With 56 bits and sixteen pixels, per-pixel colors could not be stored very accurately. Like many existing image compression methods, we therefore exploit the fact that the human eye is more sensitive to variations in luminance than in chromaticity: we halve the resolution of color information in both dimensions, so that the pixel block is split into four quads of constant color. This gives us fourteen bits per color value. For each quad Q, we must determine some representative RGB color (RQ , GQ , BQ ); in practice, we have found that weighting the color contribution of each pixel by its perceived luminance (the Y component from CIE XYZ) produces good results. To separate chromaticity from luminance, we then derive chromaticity coordinates (rQ , gQ , bQ ) normalized so that
Table 3: Example of reconstructing the differential luminance bit patterns L p when nzeros = 3. The bias bit pattern Lbias is then added to get absolute luminance values L p : bits(L p ) = bits(L p ) + bits(Lbias ). (6)
To decode the color, we rst use Equation 3 to get gQ = 1 (rQ + bQ ). Rearranging Equation 1, we nd that the RGB sum used to
normalize the original color components (the denominator in Equations 4 and 5) is L p 4. Factoring in the weighting of green, we can now combine the color and luminance information to obtain nal RGB values Rp 4 G p = L p 0 Bp 0 rQ (rQ + bQ ). 4 bQ
Most of the equation is xed point arithmetic, and the power of two scaling factors are easily implemented. The only oating point term is L p , which can have up to ve bits of exponent and six bits of mantissa. Multiplying this with the color terms implies three 11bit oating point multiplications per pixel after converting the color terms from xed to oating point. We have made alternative software implementations of the decoder, one using a bit look-up table and one using arithmetic operations to achieve the xed-to-oat conversion. It is difcult to accurately estimate the complexity of a hardware decoder based on this, but given the low number of bits and the limited range of the xed point colors, we can have some condence that it would not be overly complex.
Figure 2: Luminance quantization artifacts. Clockwise from top left: original, our method, our method without the luminance correction described in 3.4, and DXTC. For DXTC compression, the test images were rst converted into the RGBE format. The RGB data was then extracted, compressed and decompressed with the codec3 in DXT1 mode, and recombined with the original E channel. The resulting RGBE images were converted back to OpenEXR for measurements. Note that the exponents could also be clamped to 4 bits and stored in the alpha channel using the DXT3 mode. This would reduce the available dynamic range, but should still be sufcient for many images. In our test set, the 4-bit exponent would be sufcient for ve images, and for the rest an average of only 0.38% of pixels would have to be clipped. A per-texture exponent bias would naturally be required, but is trivial to apply in a pixel shader. We also considered using iPACKMAN, which promises better quality than either DXTC or PVR-TC for most low dynamic range images. However, there was no freely available codec for it at the time, so we are limited to speculating based on the original paper. The authors concede that iPACKMAN is not as good in coding colors as DXTC [Str m and Akenine-M ller 2005], and this may be a o o factor with HDR images, as illustrated in Figure 1. Whether this deciency is made up for by its better encoding of luminance remains to be seen.

Further color space considerations
Our chosen color space transformation is very simple in order to minimize decoder complexity. While the luminance term roughly approximates the sensitivity of human vision, the chrominance part is not even close to isoluminous: when we average the chrominance over four pixels of different color, the perceived luminance of some pixels will change. Comparing the right-hand images in Figure 2 reveals the blocking artifacts this can cause in areas of sharp color changes. To correct the error, we take some additional steps in the encoder: Prior to encoding the per-pixel luminances, we rst determine the colors for the pixel blocks. The ratio of perceived luminance between the averaged color and the original color is then used to scale each per-pixel luminance so that the perceived luminance remains equal. Otherwise, encoding proceeds as previously described. Since we can only encode positive values, our color space is restricted to the RGB gamut. However, it is still possible for an application to interpret the RGB data as CIE XYZ instead: The 14 color bits are limited by Equation 3, yielding slightly more than 213 valid values. Spreading them across the positive XYZ color space, which roughly envelopes all visible colors, we still have over 212 colors for the visible gamut, of which roughly 211 fall within the RGB gamut. This should still give much better color delity than our alternative bit allocation discussed above, which already was sufcient for all but the most extreme images. However, we have not made conclusive tests to verify this.

Test material

Our test material consisted of twelve HDR photographs. Five were from the OpenEXR sample image package (Desk, GoldenGate, Ocean, StillLife, and Tree), one courtesy of Paul Debevec4 (Memorial), and the rest generated by the authors using ordinary digital cameras and the HDRShop software. Some of the OpenEXR images were cropped by 1-3 pixel rows and/or columns to make the width and height factors of four as required by DXTC and our method. Furthermore, some of the OpenEXR originals contained negative RGB color components, representing colors that are outside of the usual RGB gamut. Despite such colors being completely valid input, we had to clamp them to zero as none of the tested compression methods were able to handle negative values. The percentage of out-of-gamut pixels in any of the images was very low, however.

3 available

Results
We compressed a set of images using our method, JPEG20002 , and DXTC combined with separate, losslessly encoded 8-bit exponents. JPEG2000 serves as a reference on the quality we can hope to achieve with a given bitrate, whereas DXTC represents the de facto standard for current graphics hardware.

2 codec

in Microsofts DirectX 9.0 SDK
available at http://graphics.cs.ucf.edu/hdri/index.php
4 http://www.debevec.org/Research/HDR/
Figure 3: The Probability of Detection Maps generated by HDRVDP for two of the images shown in Figure 1: our method on the left, DXTC on the right. The brighter the color in the probability map, the more likely that an error would be seen at that pixel.
Figure 4: A close-up of a generic piece of sky encoded by the different methods. Left to right: original, our method, and DXTC.
our method, whereas the latter type (blurring) is typically exhibited by JPEG2000.

Quality metrics

Analysis
We used two different methods to measure the distortion introduced by compression. Our primary measurement tool was HDR-VDP (Visible Difference Predictor) [Mantiuk et al. 2005], which simulates the human visual system to detect differences between two input images. We compared our test images compressed with each method to the original, uncompressed images. The luminance of each image was scaled up using the --multiply-lum parameter so that the global adaptation luminance computed by VDP was roughly in the range of 1 to 30 cd/m2. Without this, artifacts in dark regions often went unnoticed. As the output, VDP produces a Probability of Detection Map (PDM) that contains, for each pixel, the probability of perceiving a difference there; see Figure 3 for examples. To distill a single number out of a PDM, we computed the arithmetic mean over all probability values in it, similarly to [Xu et al. 2005]. To measure the quality across the entire test set, we computed the geometric mean of the individual image scores. Both the per-image and overall scores are shown in Table 4. In addition to HDR-VDP, we used the traditional root-mean-square (RMS) error as a generic measure of signal distortion: 1 n [(ri rc )2 + (gi gc )2 + (bi bc )2 ] n i,c=1

Based on visual inspection as well as the VDP and RMSE scores in Table 4, we may conclude that JPEG2000 at 8 bpp is the undisputed winner in most cases. This is to be expected, as JPEG2000 employs complex variable-rate compression techniques, including discrete wavelet transforms and arithmetic coding.5 It is much more surprising to discover that at 4 bpp it no longer performs any better than our method. Comparing our method against DXTC, there is a clear difference to our advantage in terms of both subjective and measured image quality. Figure 1 highlights the artifacts caused by our method and DXTC in an image with very intense colors. The original image does not have a very great dynamic range, but the intensity of the red light proves problematic for compression. Our method shows some color banding on the lamp shade, but much more is present in the DXTC image. Although our method has fewer color bits than DXTC, it is able to better reproduce the smooth gradient. This is because the color bits in our method are used for chrominance only, whereas in DXTC chrominance and luminance are intertwined. Figure 4 shows another effect of the low color resolution: in areas where color and luminance vary smoothly, DXTC tends to produce blocks with distorted color. A different kind of artifact is due to DXTC being able to encode only two distinct colors per block: within a high-contrast block, the chrominance of the low-luminance part may leak into the bright pixels. This could potentially be countered with a DXTC encoder that optimizes based on the true HDR luminance; in our approach, the encoder is unaware of the HDR exponents. The close-ups in Figure 2 demonstrate luminance artifacts. The inside of the lamp has a different color than the sky outside, and the luminance gradient is very steep. This clearly shows the effect of the perceptual luminance correction (Section 3.4) with our method, yielding an end result notably better than with DXTC.

RMSE =

where n is the number of pixels in the image, and (ri , gi , bi ) and (rc , gc , bc ) are the colors of corresponding pixels in the original and compressed image, respectively. Note that we are comparing the half oat values, not tone mapped colors. For RMSE, Table 4 only shows the geometric mean result. Of the two quality metrics, HDR-VDP appeared to better correlate with the observed image quality; we found that it could spot most of the artifacts that we were able to see ourselves. However, as it does not take chrominance into account, it may have underestimated the visual impact of the color distortion and color bleeding artifacts exhibited by DXTC. The RMSE metric seemed to give unfounded advantage to JPEG2000, as it failed to notice the gross blurring artifacts on some of the images, particularly StillLife and Tree. We speculate that there are two reasons to this: First, the encoder is likely to be using RMSE as its rate-distortion optimization criterion [Xu et al. 2005]. Second, the RMSE formula gives more weight to large distortions in individual pixels than small distortions over large areas, even if both were equally noticeable to a human observer. The former type of artifact (e.g., haloing) is more common in DXTC and

Conclusion

We have presented a novel texture compression scheme targeted at high dynamic range images and graphics hardware implementation. Our method is based on locally adapting between dynamic range and precision so that high-contrast areas are quantized more,
5 For a more balanced comparison, our method followed by gzip compression yields an average bitrate of 6.5 bpp on our test set, indicating that there is plenty of inter-block redundancy to be exploited.
Backyard Desk GoldenGate Memorial Needle Ocean PiggyLamp StillLife StreetLight Tree Window Yucca VDP Geomean RMSE Geomean
JPEG2000 (8 bpp) 0.00 0.03 0.02 0.01 0.03 0.43 0.00 25.58 0.01 2.04 0.00 0.00 0.04 0.07
JPEG2000 (4 bpp) 0.08 1.12 0.50 0.69 0.58 3.91 0.08 79.36 0.26 11.44 0.18 0.07 0.84 0.15
JPEG2000 (2 bpp) 1.24 11.66 2.10 6.14 4.82 9.16 1.24 93.45 1.75 35.78 1.14 0.77 4.81 0.25
JPEG2000 (1 bpp) 8.41 34.63 3.32 22.71 18.28 18.85 8.41 95.09 8.25 64.47 5.81 3.43 14.36 0.39
DXTC (12 bpp) 0.41 1.21 1.13 1.11 1.33 1.26 0.47 1.20 0.38 1.16 0.75 0.80 0.86 0.33
Our method (8 bpp) 0.25 1.63 0.22 0.94 0.29 0.66 0.20 0.50 0.35 0.94 0.46 0.78 0.49 0.23
Table 4: VDP Probability of Detection Map average values (in percentages) for each image and compression method, their geometric mean, and the geometric mean of the RMSE score for each method. Smaller numbers are better.
whereas smooth areas receive greater precision. Exploiting lowlevel features of the oating point format, we are able to keep the decoding complexity very low. Only a few oating point operations are required per pixel, and even then at a very low number of bits. A comparison of our method with DXTC-compressed RGBE images a feasible approach for todays graphics hardware shows that we can achieve the same or better compression ratio with higher image quality and less disturbing visual artifacts. It should be pointed out that we have not attempted to nd an optimal solution for encoding HDR textures using LDR methods: Alternative encodings or HDR-aware encoders may deliver better results than we achieved with the straightforward use of DXTC. iPACKMAN may also be a viable alternative to DXTC in the future. However, these avenues present additional complexities that are best researched outside of this paper. Although we can demonstrate numeric results that agree with visual assessment, measuring the visual delity of HDR images is one topic that requires further research. HDR-VDP does a good job on our test set in general, but it is not a reliable metric by itself, as any chrominance errors must still be identied through human inspection. We are condent that with HDR imaging becoming more mature, this will be resolved in the near future. While our decoding logic is very straighforward, we have no concrete numbers on the complexity of implementing it in hardware. We would like to have the decoder more simple still, but this would likely require a slightly different approach. Hybrid methods utilizing LDR compression augmented with HDR data are one possibility, and completely different classes of encodings, for example based on the discrete cosine transformation (DCT), may also prove well suited to the task. All in all, we are certain that the nal word on this topic has not been said yet.

References

B EERS , A. C., AGRAWALA , M., AND C HADDHA , N. 1996. Rendering from compressed textures. In SIGGRAPH 96: Proceedings of the 23rd annual conference on Computer graphics and interactive techniques, ACM Press, New York, NY, USA, 373378. B LINN , J. F. 1997. Floating-point tricks. IEEE Computer Graphics and Applications 17, 4, 8084. F ENNEY, S. 2003. Texture compression using low-frequency signal modulation. In HWWS 03: Proceedings of the ACM SIGGRAPH/EUROGRAPHICS conference on Graphics hardware, Eurographics Association, Aire-la-Ville, Switzerland, Switzerland, 8491. I OURCHA , K., NAYAK , K., AND H ONG , Z., 1999. System and method for xed-rate block-based image compression with inferred pixel values. US Patent 5,956,431. K NITTEL , G., S CHILLING , A. G., K UGLER , A., AND S TRASSER , W. 1996. Hardware for superior texture performance. Computers & Graphics 20, 4 (July), 475481. M ANTIUK , R., K RAWCZYK , G., M YSZKOWSKI , K., AND S EIDEL , H.-P. 2004. Perception-motivated high dynamic range video encoding. ACM Trans. Graph. 23, 3, 733741. M ANTIUK , R., DALY, S., M YSZKOWSKI , K., AND S EIDEL , H.-P. 2005. Predicting visible differences in high dynamic range images - model and its calibration. In Human Vision and Electronic Imaging X, IST/SPIEs 17th Annual Symposium on Electronic Imaging (2005), vol. 5666, 204 214. P ERSSON , E. 2005. HDR texturing. Radeon SDK, October 2005, ATI Technologies, Inc. R EINHARD , E., WARD , G., PATTANAIK , S., AND D EBEVEC , P. 2006. High Dynamic Range Imaging. Morgan Kaufmann Publishers. S TR OM , J., AND A KENINE -M OLLER , T. 2005. iPACKMAN: high-quality, low-complexity texture compression for mobile phones. In HWWS 05: Proceedings of the ACM SIGGRAPH/EUROGRAPHICS conference on Graphics hardware, ACM Press, New York, NY, USA, 6370. WARD L ARSON , G. 1998. The LogLuv encoding for full gamut, high dynamic range images. Journal of Graphics Tools 3, 1, 1531.

Acknowledgements

We would like to thank the anonymous reviewers for their valuable input that helped to shape this work into a more rened form. Thanks also to Paul Debevec, Rafal Mantiuk, Greg Ward, and Florian Kainz for making available the tools and images used in our research and corresponding to our inquiries, and our colleagues at Nokia for providing constructive criticism.
WARD , G. 1992. Real pixels. In Graphics Gems II, J. Arvo, Ed. WARD , G., 2005. High dynamic range image encodings. http://www. anyhere.com/gward/hdrenc/hdr encodings.html. (Dec. 2005). WARD , G. 2005. JPEG-HDR: A backwards-compatible, high dynamic range extension to JPEG. In Proceedings of the Thirteenth Color Imaging Conference. X U , R., PATTANAIK , S. N., AND H UGHES , C. E. 2005. High-dynamicrange still-image encoding in JPEG 2000. IEEE Computer Graphics and Applications 25, 6, 5764.