POV-Ray : Newsgroups : povray.pov4.discussion.general : Gamma correction of input colours/image files : Re: Gamma correction of input colours/image files Server Time
18 May 2024 02:41:56 EDT (-0400)
  Re: Gamma correction of input colours/image files  
From: Ive
Date: 10 Oct 2008 15:10:45
Message: <48efa8b5@news.povray.org>
Warp wrote:

>   Take, for example, the GIF and JPEG image formats: No gamma correction
> values anywhere, never any problems with gamma correction. They are two
> of the most popular image formats ever, yet I don't remember reading
> anybody complaining about gamma correction issues with them. Why? Because
> they don't have any gamma correction info.
> 
the W3C, HP and Microsoft have agreed (since 1996 IIRC) that the www is 
in sRGB color space. So GIF and JPEG have - so to say - a build in gamma 
tag that reads 2.2 - close to the sRGB gamma curve.
But in the early 90ies, when I worked with a SGI graphics workstation 
things where horrible because JPEG & GIF images always looked completely 
different when viewed on a Mac, PC or a SGI IRIS.
Photoshop used to include ICC profiles into JPEG images and store the 
image data in an internal working color space. As most viewers and all 
web browsers do ignore color profiles in jpeg images the result was 
sometimes quite strange. Photoshop CS3 doesn't do this anymore. (well 
Adobe never cared much about being compatible to the rest of the world, 
seems to be part of their business model, and sadly enough this is even 
working)
POV assumes JPEG and GIF files to be in linear color space (and they 
usually are not). This results in the well known washed out colors and 
was the whole point of this thread.
Poser assumes that JPEG images used for bump, transparency or specular 
maps are in linear color space but textures are gamma 2.2. So when 
converting Poser figures to POV either the textures or the bump etc. 
maps are wrong. With assumed_gamma 2.2 the textures are correct but the 
other maps are not, with assumed_gamma 1.0 the textures are washed out 
but the other maps are right - so to render poser stuff in POV, 
assumed_gamma 1.0 and texture files converted to PNG are needed.
DAZ Studio uses some different assumptions about texture, bump and so on 
maps. So professional vendors do meanwhile provide two different sets of
maps for Poser and DAZ Studio. (And I bet when it comes to Lightwave, 
Maja, Cinema4D and what not we have similar problems!)

I can continue this list but this should be enough. Now tell me again 
that there was never any problem with gamma correction  and JPEG/GIF images.


>   Now take PNG: As a more modern image file format they decided to add
> gamma correction information to it, as well as some recommendations and
> specifications about how sofware should interpret it (as well as interpret
> what happens if the info is missing). The result? The PNG format is
> burdened with endless problems related to gamma correction issues. No two
> programs seem to agree on how a PNG should be shown, regardless of whether
> it has gamma correction info embedded or not.
>

This is the point I really do not understand. The use of the png gamma 
chunk is well documented in the png specs, the reference library libpng 
(used by almost everybody) already includes all the code needed and the 
usage is even as example code available. A programmer can just copy and 
paste it. Still, the programmers of a lot of browser and other image 
applications managed it to do it wrong (wrong as in programming a 
calculator that says 1 + 1 = 3). And as a result the PNG format is 
blamed for that.
The POV programmer (whoever this was) did it right, at least.


>   If PNG had never included the gamma correction information in its format,
> this problem would not happen, and it would be exactly as usable as GIF and
> JPEG. But no. Gamma correction = problems.
> 
>   It's no wonder why POV-Ray is also riddled with all kinds of problems
> related to gamma correction. Whenever you are dealing with gamma correction
> you are going to encounter big problems.
> 
>   I suppose that gamma correction is a bit like text character encodings:
> Nice ideas in theory, but the world is completely riddled with endless
> problems related to them, and every software has its own ideas about how
> it should implement them.
> 

Well, ok, do not get me wrong, I really do see your point but my 
conclusion is different. I would never say gamma correction = problem. 
Gamma correction is a necessary (and in fact quite simple) concept that 
has to been known in digital image processing. People who do not know or 
understand it should not work there as a programmer. But they did and 
this is the source for most irritation about the gamma subject.

-Ive


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.