[sldev] Cache politics: performance vs obfuscation

[Dahlia Trimble]

I agree, the color rendering in sl is horrendous. I had the opportunity to
work with Michael Stokes on a closely related project while he was
developing the sRGB spec. If my memory is accurate, it was meant for the
display of images that were taken with digital cameras or scanned with
scanners and will be displayed on CRTs  or printed. The sRGB color space is
somewhat compromised as it is optimized for consumer devices and was not
designed for very high quality color reproduction applications. Given that
3D applications have internal lighting models and radically alter the
viewing conditions as the rendering perspective changes (viewing conditions
which sRGB is dependant on), I can see that introducing nonlinearities may
impose quantization errors and they would be exacerbated when multiplied by
scene rendering "lights", especially if the color calculations are limited
in precision to 8 bits. However I am *not* currently familiar with the light
mixing implementation in OpenGL or the viewer so I dont know how well these
comments apply. Off hand it would seem if there were a lot of precision
available for the calculations, the 'banding/posterization" would be
minimized, at least in the middle level ranges for RGB levels.

I wouldn't assume that all the textures in sl are in sRGB space though. I
was under the impression that the texture creator could use any color space
that the RGB format could support. Could someone familiar with the intricate
details of the uploading/conversion/rendering processes add some comments,
specifically, what is assumed about the image and do any color conversions
occur in the processes? Perhaps some guidelines exist for content
creators who create textures, but I haven't seen any.

On Sat, Jun 14, 2008 at 11:17 AM, John Hurliman <jhurliman at jhurliman.org>
wrote:

> Yes it really does matter. The problem is that sRGB (the color-space of
> every texture in SL) has a gamma of 2.2 (
> http://en.wikipedia.org/wiki/Image:SRGB_gamma.svg), a non-linear color
> space. An RGB value of 0.5,1.0,1.0 does *not* mean 50% intensity for red,
> you get something like 25% intensity. However your rendering engine (lets
> say a Phong shading model) is expecting linear values for the inputs. If it
> sees 0.5,1.0,1.0, it interprets that as "project 50% red photons in relation
> to blue and green". Linear math is also built directly into OpenGL such as
> mipmapping, where you'll get incorrect results describing an sRGB
> color-space as GL_RGB[A]8.
>
> John
>
> On Sat, Jun 14, 2008 at 10:55 AM, Jason Giglio <gigstaggart at gmail.com>
> wrote:
>
>>  John Hurliman wrote:
>> > If you really want to tackle banding/posterization, SL should be using
>> an
>> > sRGB color format for textures. It's already encoding textures in sRGB
>>
>> Does that really matter when the end user then feeds that into a monitor
>> running 9600K color temp at a brightness appropriate for direct sunlight?
>>
>> We aren't doing prepress here.
>>
>> -Jason
>>
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080614/56978c82/attachment.htm