Digital Art Zone

Hello, I’ve been wondering for some time about the ‘gamma correction’ option in Bryce. Do you use it in your works, and if you do, then what advantages do you have out of it? I’m curious about your opinions about this option.

Well, since we’ve talked about this elsewhere, you already know my former view, which has always been that gamma correction being checked makes the renders a bit washed out looking so I’ve tended not to use it except in situations where the render has been overly saturated I’ve felt I could take a reduction in contrast then at that point, I’ve used it for that reason.  However, given what you have already revealed with respect to the role of gamma, I’m prepared to open minded about how it could be used in the future.  I just thought I would throw this comment into the ring to get the ball rolling.

David knows I mostly do use gamma correction, because I like to do soft, watercolour type landscapes.

This one I have rendered two ways. One with and one without. (also other corrections in the second)

“But Muuuuuum, you did say it was a moon gate”

Same here as David, we’ve exchanged some emails on this topic and I tend more to not using gamma correction in most cases, but I’m not starting a crusade. Chohol’s left picture is how she wanted it and the artist decides. I like the right one with more contrast more, but this is my personal preference. Of course, mom will not fall on her nose in the right one and the soft shadows are an improvement.

David questioned me about using it with the pull toy I created and I did a render with it off.  In that instance it had the reverse affect of washing out the colors, so I left it in.  It will be something I’ll give more consideration to in my next works.

Going by Chohole’s examples, as Horo said it’s what the artist decides.  However, to me the left scene look better because everything doesn’t have that Hollywood spot lighting affect.  Perhaps the color intensities are a bit to high, but that scene leans more toward the real look of things.  Or how I perceive things should look.

@David Brinnen & Horo
Thank you for inviting more people to this discussion. It’s indeed interesting to know other opinions in this subject.

@David Brinnen
That gamma thing is indeed very deep subject. It’s the feature that would be useful for more advanced users wanting more control on the lighting and integration with other mediums. I think there’s a place for this function in the future versions of Bryce (with more control over it via additional options). I can see the big number of material libraries created by you with no gamma in mind. I think I wouldn’t convert them to be used with gamma and wouldn’t make the new libraries for the gamma correction on as currently that would cause the confusion and the future versions of Bryce may bring automatic conversion for colour swatches and colour textures. Yeah, that would be nice feature request. I can think of a GUI mockup that might have these options.

@chohole
I’ve noticed that gamma correction turned on is extremely useful option when you use IBL, TA and reflections in your scene, otherwise it doesn’t have such strong impact. Also gamma correction doesn’t have to make your image washed out, you simply can ‘inverse correct your colours’ while still using gamma. Speaking the easy way it’s done by making all colour swatches and bitmaps in the scene darker and more saturated, and speaking the more difficult way use the formula: ((colour/255)^1.585)^255 on each of the colour component (including lights and sky elements) and using gamma filter with value of 0.631 on your colour bitmaps.
About your images…
I like more on the first one:
- the vegetation (colours, light response)
- the mom’s clothes (colour and light)
- the mom’s left hand (fist) and angled right hand’s finger (on the second picture she looks more like she was laughing out from the kid)
- light under the gate’s arch and less intense shading of the bump.
- shadows of the left hand - because of making the shadows lighter on the second image they’re almost non existing under the palm
and on the second one:
- mom’s face colour and ground colours (they look more like the creator of textures intended them to)
- fog on the background (it’s not going to almost fully white)
- softened shadows

@Horo
Thank you again for the test that confirmed that Bryce applies gamma of 1.585 over the rendered image. The observed slowing down was also interesting point to not use gamma and render instead to *.hdr and apply it in the post.
I think it’s not handy to use it often at the current form, considering all colours would have to be corrected, so I understand why you don’t like it. Anyway I’m still sticking to using it and I’m going to try out new ways of generating HDR’s out of the scene in a single run by using the sphere mapper, and Bryce ability to save images of greater depth than displayed.

@GussNemo
You’ve got an eye for the things. Without gamma you get more contrast in light and shadow (it’s really evident when lighting interior scenes when using TA). Using Brycean gamma with colours corrected to be darker is more realistic, although still not fully realistic from mathematical point of view. To be more mathematically correct you’d have to apply the inverse gamma of 2.2 to all of your colours and bitmaps but current colour sliders (having 0 to 255 range) can’t really handle it. Gamma of 1.585 is a good compromise.

Here’s my example with using gamma without washing out the texture colours. She scene consists of:
- infinite plane
- 3 terrains forming the cave (slightly modified stalactite pro material)
- glass sphere (refraction only)
- sky turned into hdr for finer control with opacity of 75% blended with flat sky colour, atmosphere is turned off
- sunlight (very pale peach-orange, 100% intensity of shadows)
- mid cold blue ambient making the stone material glow with 20% strength (only for scenes 1, 2 and 3)
- orange point light with inverse square response

It’s rendered wit relativity low TA samples (9) and number of bounces (3)

1. A scene with gamma correction off, ambient appears slightly like a fog giving some light to dark areas. Ambient in TA mode does not appear that flat - it rather looks for me like some kind of inverse ambient occlusion. Notice burned out directly lit areas as well as hdr background.

2. The same scene as 1, gamma correction option is on, I used the formula that I’ve written above for fixing colours to appear the same with gamma used. All colours swatches were fixed - including the ones for lights, ambient, and those inside the procedural texture, no light intensities were changed. You can see softer distribution of lights (no burning out to white at the parts of the cave exposed to direct light).

3. The example pushed further than the Bryce allows in default workflow. The colours were corrected from 1st example - now by inverse of 2.2 gamma, and so was the final render. Now you can see that ambient materials are really glowing, and that ambient light is bouncing around and polluting the whole scene.
Side note: I rendered the image with gamma correction option turned on + some more, remaining gamma was added in the raster image editor (I could also render with gamma correction off, save as *.hdr and apply gamma in the editor that opens *.hdr images). The process of degammaing your inputs and applying 2.2 gamma on your final image is called sometimes linear workflow. Options to make it easier to follow and more automatic are often incorporated in modern graphic applications.

4. The scene from the 1st example. I removed ambient colour from the sky settings and from the materials and made the sunlight stronger (135 from 100), HDRI effect from 20 to 25, and intensity of orange light inside lowered from 50 to 25 (as it appeared too strong for me for such lighting conditions outside). Despite the TA turned on, and such strong light outside you can’t see almost anything in dark areas of cave.

5. The scene from 4th example with tweaks as described in 2nd example. This is looking quite realistic already, I really like that setup.

6. The scene from 4th example with tweaks as described in 3nd example. Not that strong difference from 5th example, a bit more light in the shadows and it’s more physically correct.

7. I decided to push 6 further. With some colour corrections and slight noise removal I made the version that I really like. It’s more comparable with its dynamic range with 5th example but the light areas of the stone became silky-smooth and the shadows are more saturated now.

8. Bonus scene - the 5th scene with the sphere with basic volumetric material around the whole cave. It was too pale so I restored the shadows strength and saturation to the levels I wanted.

Bryce’s Gamma Correction was a rough attempt at creating some image output uniformity between PC and Mac screens of the mid-late 1990s.

No-one uses CRT screens for image creation any more. Not only are people using flatscreens, but flatscreen technology itself has changed twice since this component (unchanged since the 90s) was added.

The curious thing is: even though Mac and PC computer screens are largely interchangeable now, both brands persist in maintaining gamut differences unique to their platform through software. It sounds expensive, and it is, but rather than use Bryce’s Gamma Correction option, make an effort to ensure your screen is calibrated for your work environment. If you’re a PC user and you have to ship a file to a Mac, ship it as-is and let the Mac guy correct it, and vice-versa.

Oroboros - 13 October 2012 08:18 PM

Bryce’s Gamma Correction was a rough attempt at creating some image output uniformity between PC and Mac screens of the mid-late 1990s.

It’s very likely that purpose of this option was that simple in the past as you say, but currently I’m proposing a new way to use it and new direction to expand it. Anyway the gamma of 1.585 neither conforms to difference between 2.2 and 1.8 ( 2.2 / 1.8 = 1.(2) ) neither 2.5 and 1.8 ( 2.5 / 1.8 = 1.3(8) ). So that still puzzles me why such value was chosen.
One explanation is… and now I can’t post links to different forum of application that uses gamma 1.6 by default here on public, so if you’re interested please google for: ‘1.6 gamma render’ (group of links very likely on the first page) and read opinions about ‘why the 1.6 gamma was chosen by default’ there.

Oroboros - 13 October 2012 08:18 PM

No-one uses CRT screens for image creation any more. Not only are people using flatscreens, but flatscreen technology itself has changed twice since this component (unchanged since the 90s) was added.

Cough, cough… I’m still terrified by how my TFT messes colours and saturations (even after calibration by hand) compared to my old CRT, but even then it conforms to gamma 2.2. Even worse… I’ve seen once the TFT that didn’t use gamma of 2.5 or 2.2 and couldn’t be forced to such setting. Imagine the movies from DVD’s (that were very likely compressed with sRGB in mind) displayed distinct shapes of compression blocks in the dark colour range - yuck! That person who had that screen surely wasn’t aware of colour management at all.

Oroboros - 13 October 2012 08:18 PM

The curious thing is: even though Mac and PC computer screens are largely interchangeable now, both brands persist in maintaining gamut differences unique to their platform through software.

Not anymore:
- http://www.geek.com/articles/chips/snow-leopard-and-windows-finally-share-22-gamma-setting-2009097/
- http://support.apple.com/kb/ht3712
Since 10.6 Macs are now defaulting to sRGB that’s ~ 2.2. Users were simply not aware of the gamma until they noticed that images on web that are wrongly gamma marked are not correctly displayed on their systems. I can’t speak for myself because I don’t own Mac, so I can show you only discussions and others opinions, but I’ve read that people who were working for print and web designers were already switching earlier to 2.2 not to generate unnecessary hassle when interchanging their files. http://blogs.adobe.com/jnack/2009/09/why_your_web_content_will_look_darker_on_s.html

Oroboros - 13 October 2012 08:18 PM

It sounds expensive, and it is, but rather than use Bryce’s Gamma Correction option, make an effort to ensure your screen is calibrated for your work environment. If you’re a PC user and you have to ship a file to a Mac, ship it as-is and let the Mac guy correct it, and vice-versa.

I think that would be the other way round you wrote. Cause when your images are 2.2 then they appear too light on 1.8 gamma display, and too dark on 2.5 gamma display. So that would be more like:
- old Mac’s user created an image without gamma correction on that would appear too dark for PC’s user, then PC user turns on gamma correction and rerenders.
- PC user creates an image with gamma correction on, then passes the file to the old Mac’s user that turns gamma correction off and rerenders.
I can think of such two chains. But when sliders aren’t gamma corrected, and the gamma difference does not conform to either of the transition then still the colour shifts occur.

Also in that situation nobody thinks that the colour pickers are also affected by the users system gamma setting. Linear workflow works this way:
- User corrects (or the application corrects for the user) according to users system gamma settings colour sliders to be in linear space
- User creates his scene (in ideal situation without even feeling that application assumed some defaults and fixes things behind his back)
- User renders and saves to *.hdr and *.bmp (while *.hdr is displayed on the screen according to his gamma settings and saved with gamma 1.0, and *.bmp has the gamma baked in - another transparent process)
- User passes *.hdr and scene to user of different gamma
- The second user opens the scene and the *.hdr in his system with different gamma setting and everything is displayed according his system settings, and if both systems were calibrated then everything looks exactly the same
- The second user works further on the scene and passes it to the first user seamlessly

Now I believe you think more about the first approach, which possibly the developers of old Bryce had in mind. But now I’m thinking more about the second approach and how to use the currently available tools to create images more in the second way, and how this option could possibly be developed in the following versions (to help more advanced and aware users).

I finally found the time to read through The Science for CG v2 PDF (from the CG Society) I got from David, who got it from somebody else. Very interesting reading and a lot of food how to improve Bryce. At the end of the 47 page treatise I found this sentence:

Linear lighting workflows are the single most important thing you can do to get a physically plausible result.

Horo - 17 October 2012 01:29 PM

I finally found the time to read through The Science for CG v2 PDF (from the CG Society) I got from David, who got it from somebody else. Very interesting reading and a lot of food how to improve Bryce. At the end of the 47 page treatise I found this sentence:

Linear lighting workflows are the single most important thing you can do to get a physically plausible result.

Look up… I got it from Dwsel, above.  I think I said, I should have said.

David Brinnen - 17 October 2012 01:33 PM

Look up… I got it from Dwsel, above.  I think I said, I should have said.

You did, but I wasn’t sure anymore and too lazy to browse through the emails. I apologise to Dwsel. The document is really very interesting.

I must say: I understand everything everybody writes in all posts here LOL

I added a new 8 page PDF explaining light intensities and falloff on my website (see sig). Go to Bryce Documents > Mine > Light > Brightness and Falloff or click directly on this link http://www.horo.ch/docs/mine/pdf/Brightness.pdf if you’re interested.

Horo - 20 October 2012 12:47 PM

I added a new 8 page PDF explaining light intensities and falloff on my website (see sig). Go to Bryce Documents > Mine > Light > Brightness and Falloff or click directly on this link http://www.horo.ch/docs/mine/pdf/Brightness.pdf if you’re interested.

Good to know.  But I think I might have to ponder this a few times before I come to a full understanding of some of the findings.  For a start,

>>

Multiplying the pixel values of the HDRI does not increase the dynamic range.

<<

Was contrary to my expectations.  But thinking about it, if the lowest value is 1 and not 0 then this has to be the case?

Also, the opperation of the HDRI effect falloff was not as I expected, but to be fair this is not a control I’ve experimented much with, so I didn’t have much of an expectation.

In turn my thoughts have turned to colour.  There is, I believe, a related problem.  For example, a colour red 1,0,0 has 255 discreet stages of intensity that it can go through before it hits the limit 255,0,0.  This colour 127,1,0 only has two discreet stages of intensity, the first one and 254,2,0 there are no other intensities which represent this precise colour.  A doubling of lighting intensity will result in red being capped 255,4,0 - this distribution of RGB does not relate to the original colour and with more light thrown in, the situation only gets worse.

First example shows the progression with sunlight intensities, 100,200,400,800

127,1,0
254,2,0
255,4,0
255,8,0

In this case though, after the initial doubling of light, the colour seems to settle down… so it does not seem all that drastic…

Now consider the situation with 127,25,0…

127,25,0
254,50,0
255,150,0
255,200,0

Then the scaling of green begins to rapidly catch up with red, so that what appears to be red under low light rapidly morphs into yellow under more intense lighting conditions.

With only two more doublings, what was ostensibly red will become definitely yellow.

It is all very well being able to provide a good range of light, but the colour response needs to have a corresponding range to cope with this flood of light.

What can be done to overcome this problem?

In addition… it would seem that 0 values in RGB should be avoided altogether.  Since these can never scale.

Instead HLS would be better, where the value was not resolved to RGB (as seems to happen now) and L could afford enough headroom to cope with the theoretical maximum any Bryce light could generate.  The result would not be displayable on rendered, but only captured in a HDRI which could then be processed accordingly.

In my understanding, Bryce works internally in the RGB colour space. The input in HSV or HSL is translated to RGB - I’m guessing here, the output is RGB, though. There is a reason why I did the measurements monochrome with R=G=B.

Also, it uses floating point values from 0 to 1 internally (or 0.996). It is not quite clear how many decimal places can be represented. I have some theories about this, but we would need a man like Vasily to shed some true light on this.