High Dynamic Range Texture Compression

Transcription

1 High Dynamic Range Texture Compression Kimmo Roimela Tomi Aarnio Joonas Ita ranta 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 storing the light incident on a point, and light maps that store the radiance of a surface. 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 fidelity, 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. Recent consumer graphics hardware has support for HDR via floating-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. CR Categories: I.3.1 [Computer Graphics]: Hardware Architecture Graphics processors I.3.6 [Computer Graphics]: Methodology and Techniques Graphics data structures and data types I.3.7 [Computer Graphics]: Three-Dimensional Graphics and Realism Color, 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 1 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 final 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, {kimmo.roimela tomi.aarnio joonas.itaranta}@nokia.com c ACM, This is the author s version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in ACM Transactions on Graphics, Volume 25, Number 3, July 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. 2 Background and related work 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. 2.1 High dynamic range image formats 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 sufficient (but not excessive) dynamic range for luminance, and just

2 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 significantly 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 floating 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 16- bit half float 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. 2.2 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 fixed-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 field 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 ipackman 1 [Ström and Akenine-Möller 2005] provide better image quality at the same bit rate (4 bpp, for 6:1 compression over 24-bit RGB) and equivalent hardware complexity. Note that these are all fixed-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 2 exp 128, 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 filtering of the nonlinear 1 also known as Ericsson Texture Compression, ETC exponent [Persson 2005], but is nevertheless a useful approach in many cases. 3 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 floating point values in storing arbitrary data in textures, but the precision requirements for such data vary by application. This makes application-specific 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 floating 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 difficult 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 64- bit 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 fixed-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 4 4 pixels seemed like the best balance between these requirements. To fit 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 efficient. 3.1 Coding floating point luminance The half float numbers used in OpenEXR and graphics hardware are similar to IEEE floating point numbers, only with 16 rather than 32 bits: the most significant bit is the sign bit, which is followed by five 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 floating 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

3 the following, we use the notation bits( f ) to denote the integer bit pattern of a floating 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 float format, we first compute per-pixel luminance values r Q + g Q + b Q = 1, (3) which allows us to discard one of the components without losing any information. For efficient decoding, we normalize with the color sum from Equation 1. This gives the coordinates L p = (R p + 2G p + B p )/4, (1) where p is the index of a pixel within the block and (R p,g p,b p ) its half float RGB color; the factor of two on green approximates perceptual weighting and makes for efficient arithmetic. We then find the per-pixel luminance with the smallest-valued bit pattern. From that, we construct a bias value L bias by zeroing the ten least significant bits, leaving five bits to store in the compressed block. The bit pattern of L bias is subtracted from the luminance bit pattern of each pixel p to arrive at differential luminances L p: bits(l p) = bits(l p ) bits(l bias ). (2) 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 n zeros in Table 1. Each bit pattern bits(l p) is then truncated by discarding the n zeros +1 most significant bits, the +1 accounting for the sign bit. With the leading zeros removed, each truncated bit pattern is rounded to its four most significant bits. Rounding is required to maintain the overall luminance, but can cause an overflow into the previously discarded leading zeros, so we clamp the rounded bit pattern to a maximum of The clamped result is then stored into the respective lum p field in the compressed block. The encoded luminance data is 72 bits in total, leaving 56 bits for coding the color information. byte bits L bias n zeros 1 lum 0 lum 1 2 lum 2 lum lum 14 lum 15 Table 1: Bit allocation for luminance data in the compressed block. 3.2 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 4 4 pixel block is split into four 2 2 quads of constant color. This gives us fourteen bits per color value. For each quad Q, we must determine some representative RGB color (R Q,G Q,B Q ); 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 (r Q,g Q,b Q ) normalized so that R Q r Q = R Q + 2G Q + B Q (4) B Q b Q =. R Q + 2G Q + B Q (5) With all the input values positive, r Q and b Q 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 4 4 block. byte bits r 0 b 0 10 b 0 r 1 11 r 1 b 1 12 b 1 r 2 13 r 2 b 2 14 b 2 r 3 15 r 3 b 3 Table 2: Bit allocation for chrominance data in the compressed block. We initially tried an alternative bit allocation with five 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. 3.3 Decoding To decode the luminance L p, we use integer operations only. The differential luminance L p is reconstructed first: the four luminance bits lum p from the compressed block are substituted for bits immediately following the n zeros + 1 most significant bits, and all other bits are set to zero. An example of this procedure is shown in Table 3. n zeros + 1 decoded zero zero bits bits LSB bits Table 3: Example of reconstructing the differential luminance bit patterns L p when n zeros = 3. The bias bit pattern L bias is then added to get absolute luminance values L p : bits(l p ) = bits(l p) + bits(l bias ). (6) To decode the color, we first use Equation 3 to get g Q = 1 (r Q + b Q ). Rearranging Equation 1, we find that the RGB sum used to

4 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 final RGB values R p G p = L p r Q (r Q + b Q ). (7) B p b Q Most of the equation is fixed point arithmetic, and the power of two scaling factors are easily implemented. The only floating point term is L p, which can have up to five bits of exponent and six bits of mantissa. Multiplying this with the color terms implies three 11- bit floating point multiplications per pixel after converting the color terms from fixed to floating 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 fixed-to-float conversion. It is difficult 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 fixed point colors, we can have some confidence that it would not be overly complex. 3.4 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 first determine the colors for the 2 2 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 2 13 valid values. Spreading them across the positive XYZ color space, which roughly envelopes all visible colors, we still have over 2 12 colors for the visible gamut, of which roughly 2 11 fall within the RGB gamut. This should still give much better color fidelity than our alternative bit allocation discussed above, which already was sufficient for all but the most extreme images. However, we have not made conclusive tests to verify this. 4 Results We compressed a set of images using our method, JPEG2000 2, 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 available at 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 first converted into the RGBE format. The RGB data was then extracted, compressed and decompressed with the codec 3 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 sufficient for many images. In our test set, the 4-bit exponent would be sufficient for five 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 factor with HDR images, as illustrated in Figure 1. Whether this deficiency is made up for by its better encoding of luminance remains to be seen. 4.1 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 Debevec 4 (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 in Microsoft s DirectX 9.0 SDK 4

5 Figure 3: The Probability of Detection Maps generated by HDR- VDP 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. 4.2 Quality metrics 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/m 2. 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: RMSE = 1 n n [(r i r c ) 2 + (g i g c ) 2 + (b i b c ) 2 ] (8) i,c=1 where n is the number of pixels in the image, and (r i,g i,b i ) and (r c,g c,b c ) are the colors of corresponding pixels in the original and compressed image, respectively. Note that we are comparing the half float 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 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 JPEG Analysis 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. 5 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.

6 JPEG2000 JPEG2000 JPEG2000 JPEG2000 DXTC Our method (8 bpp) (4 bpp) (2 bpp) (1 bpp) (12 bpp) (8 bpp) Backyard Desk GoldenGate Memorial Needle Ocean PiggyLamp StillLife StreetLight Tree Window Yucca VDP Geomean RMSE Geomean 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 floating point format, we are able to keep the decoding complexity very low. Only a few floating 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 today s 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 find 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 fidelity 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 identified through human inspection. We are confident 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 final word on this topic has not been said yet. Acknowledgements We would like to thank the anonymous reviewers for their valuable input that helped to shape this work into a more refined 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. References BEERS, A. C., AGRAWALA, M., AND CHADDHA, N 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, BLINN, J. F Floating-point tricks. IEEE Computer Graphics and Applications 17, 4, FENNEY, S Texture compression using low-frequency signal modulation. In HWWS 03: Proceedings of the ACM SIG- GRAPH/EUROGRAPHICS conference on Graphics hardware, Eurographics Association, Aire-la-Ville, Switzerland, Switzerland, IOURCHA, K., NAYAK, K., AND HONG, Z., System and method for fixed-rate block-based image compression with inferred pixel values. US Patent 5,956,431. KNITTEL, G., SCHILLING, A. G., KUGLER, A., AND STRASSER, W Hardware for superior texture performance. Computers & Graphics 20, 4 (July), MANTIUK, R., KRAWCZYK, G., MYSZKOWSKI, K., AND SEIDEL, H.-P Perception-motivated high dynamic range video encoding. ACM Trans. Graph. 23, 3, MANTIUK, R., DALY, S., MYSZKOWSKI, K., AND SEIDEL, H.-P Predicting visible differences in high dynamic range images - model and its calibration. In Human Vision and Electronic Imaging X, IST/SPIE s 17th Annual Symposium on Electronic Imaging (2005), vol. 5666, PERSSON, E HDR texturing. Radeon SDK, October 2005, ATI Technologies, Inc. REINHARD, E., WARD, G., PATTANAIK, S., AND DEBEVEC, P High Dynamic Range Imaging. Morgan Kaufmann Publishers. STRÖM, J., AND AKENINE-MÖLLER, T 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, WARD LARSON, G The LogLuv encoding for full gamut, high dynamic range images. Journal of Graphics Tools 3, 1, WARD, G Real pixels. In Graphics Gems II, J. Arvo, Ed. WARD, G., High dynamic range image encodings. anyhere.com/gward/hdrenc/hdr encodings.html. (Dec. 2005). WARD, G JPEG-HDR: A backwards-compatible, high dynamic range extension to JPEG. In Proceedings of the Thirteenth Color Imaging Conference. XU, R., PATTANAIK, S. N., AND HUGHES, C. E High-dynamicrange still-image encoding in JPEG IEEE Computer Graphics and Applications 25, 6,