I am posting this question to the CDB community as a whole concerning

raster data and gamma settings for the CDB.

The current 3.0 and 3.1 draft CDB spec both state a gamma of 1.0 for all raster data.

The current gamma display standard for Windows and OSX based systems is around 2.2

## http://en.wikipedia.org/wiki/Gamma_correction ##

With the specification for CDB raster being 1.0 and the majority display systems set at 2.2

there is a major difference between the spec and pc display systems.

Is the current standard of gamma 1.0 the right number?

Any feedback from the CDB community will be appreciated.

Patrick Davis

The current 3.0 and 3.1 draft CDB spec both state a gamma of 1.0 for all raster data.

The current gamma display standard for Windows and OSX based systems is around 2.2

## http://en.wikipedia.org/wiki/Gamma_correction ##

With the specification for CDB raster being 1.0 and the majority display systems set at 2.2

there is a major difference between the spec and pc display systems.

Is the current standard of gamma 1.0 the right number?

Most definitely not!

Even the CDB specification Appendix G Gamma Tutorial recognizes:

If we decide to use samples that are linearly proportional to intensity, and do the gamma correction in the frame buffer LUT, it turns out that we need to use at least 12-16 bits for each of red, green, and blue to have enough precision in intensity. With any less than that, we will sometimes see contour bands or Mach bands in the darker areas of the image, where two adjacent sample values are still far enough apart in intensity for the difference to be visible.<br>

However, through an interesting coincidence, the human eye's subjective perception of brightness is related to the physical stimulation of light intensity in a manner that is very much like the power function used for gamma correction. If we apply gamma correction to measured (or calculated) light intensity before quantizing to an integer for storage in a frame buffer, we can get away with using many fewer bits to store the image. In fact, 8 bits per color is almost always sufficient to avoid contouring artifacts. This is because, since gamma correction is so closely related to human perception, we are assigning our 256 available sample codes to intensity values in a manner that approximates how visible those intensity changes are to the eye. Compared to a linear-sample image, we allocate fewer sample values to brighter parts of the tonal range and more sample values to the darker portions of the tonal range.<br>

Thus, for the same apparent image quality, images using gamma-encoded sample values need only about two-thirds as many bits of storage as images using linear samples.

but it goes on to say:

The CDB specification does not rely on such gamma encoding in order to achieve smaller integer number representations. Instead, the CDB specification relies on standard compression algorithms to achieve an efficient representation of color imagery.5

5 The JPEG-2000 standard is based on the sRGB default color space per the IEC 61966-2-1 Standard which calls for a gamma 2.2 under the specified viewing conditions

This is a contradiction in itself. The CDB raster JPEG-2000 and SGI .rgb image data both decompress to 8-bits per color, so they both suffer from the artifacts described above if gamma encoding is not used. Furthermore, the sRGB specification defines a gamma encoding roughly equivalent to 2.2 without regard to the viewing conditions. Thus, to conform to sRGB, the gamma encoding can not be 1.0.

In many places appendix G confuses absolute gamma encoding values with residual or relative gamma values. It also implies that the IG operates in linear 1.0 gamma space (as is desired), but the pipeline depicted where the CDB RTP applies a 1.125/1.25 gamma encoding assures this is not the case (although it may be considered close enough by some). Furthermore, it also depicts exactly what the paragraph above discourages, ie. a conversion from linear 1.0 gamma in the 8-bit frame buffer to 1/2.2 gamma in the LUT.

The assertion that OS + Photoshop applies a 1/2.2 gamma in the LUT to display an image on an sRGB display device also appears false from my research. Photoshop normally assumes sRGB encoded imagery by default, and thus does no gamma encoding or correction when formatting for an sRGB display device in the LUT or otherwise.

For all these reasons, treating CDB raster data as 8-bit linear 1.0 gamma encoded is an extremely poor choice and will significantly handicap any CDB database and the adoption of the specification. Standardizing instead on sRGB gamma encoding, not just sRGB color primaries, removes these limitations and assures more straight forward interoperability with with typical imagery source formats, modeling tools, and workstation platforms.

The CDB offers information to be used and processed in a device-independent manner. Some processes, algorithms, and calculations affecting imagery before it is used by simulation and sensor processes, or ultimately displayed or projected on a display system require that the values represent the linearly varying reflective property the underlying material. This fact alone does not require that imagery and texture be stored with a linear encoding and the choice of standardizing on 1.0 could have been a poor one. The subject of gamma is quite complex and needs to be further studied. I plan to make a follow up post on this forum on the subject and will be glad to discuss the subject off-line.

Michel Lagacé

The CDB offers information to be used and processed in a device-independent manner. Some processes, algorithms, and calculations affecting imagery before it is used by simulation and sensor processes, or ultimately displayed or projected on a display system require that the values represent the linearly varying reflective property the underlying material. This fact alone does not require that imagery and texture be stored with a linear encoding and the choice of standardizing on 1.0 could have been a poor one. The subject of gamma is quite complex and needs to be further studied. I plan to make a follow up post on this forum on the subject and will be glad to discuss the subject off-line.

I think this is a reasonable high level summary of the issue, and I think you recognize the problem with the choice made by the current specification (1.0 gamma) since the specification even describes it. Since all the data in question represents visible spectrum reflectance, and since there is nearly uniform acceptance that gamma encoding is a reasonable perceptual approximation for storing linear reflectance as 8 bit data, I encourage the CDB secification to adopt either the sRGB standard for gamma encoding, or a simplified power law approximation of it, in the neighborhood of 2.0-2.2. 2.0 is suboptimal perceptually, but has the added benefit that conversion to linear space is simply a square (multiply by itself) operation, and conversion back to gamma encoding is a sqrt; both of which have reasonably low computation costs.

The CDB offers information to be used and processed in a device-independent manner. Some processes, algorithms, and calculations affecting imagery before it is used by simulation and sensor processes, or ultimately displayed or projected on a display system require that the values represent the linearly varying reflective property the underlying material. This fact alone does not require that imagery and texture be stored with a linear encoding and the choice of standardizing on 1.0 could have been a poor one. The subject of gamma is quite complex and needs to be further studied. I plan to make a follow up post on this forum on the subject and will be glad to discuss the subject off-line.

I think this is a reasonable high level summary of the issue, and I think you recognize the problem with the choice made by the current specification (1.0 gamma) since the specification even describes it. Since all the data in question represents visible spectrum reflectance, and since there is nearly uniform acceptance that gamma encoding is a reasonable perceptual approximation for storing linear reflectance as 8 bit data, I encourage the CDB secification to adopt either the sRGB standard for gamma encoding, or a simplified power law approximation of it, in the neighborhood of 2.0-2.2. 2.0 is suboptimal perceptually, but has the added benefit that conversion to linear space is simply a square (multiply by itself) operation, and conversion back to gamma encoding is a sqrt; both of which have reasonably low computation costs.

Ping

Recent information indicates that there are no current plans to change the gamma encoding for CDB raster imagery (reflectance data) from 1.0 to any better approximation of perceptual space given 8 bit data precision (sRGB, 2.2, 2.0, etc.). I would like to stress my points above again, and solicit a response that fully justifies the choice of linear encoding for these data sets.

Based on discussion that have happened since this last posting by Brian, it was discussed to add the ability to set a gamma value per image.

We will see what are the best options to do this - and we will work with Brian on this.