[sldev] Cache politics: performance vs obfuscation

[John Hurliman]

The source code line I referenced, llimagej2coj.cpp:282, points to where all
textures being uploaded to the grid are converted to sRGB color-space. This
is the default for JPEG2000, and although someone could technically use a
third party client to upload an image with an embedded color profile it
would be discarded. I found a website that explains the issue in better
depth (with a specific example of the mip-mapping problem):
http://www.sjbrown.co.uk/?article=gamma

Created a JIRA for the issue here:
http://jira.secondlife.com/browse/VWR-7778


John

On Sat, Jun 14, 2008 at 12:39 PM, Dahlia Trimble <dahliatrimble at gmail.com>
wrote:

> 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/370683b8/attachment.htm