Here is an example using Octane: the left image was rendered using proper linear workflow, the right image was rendered assuming any RGB colors can be fed directly into the renderer, and the rendered colors can be directly sent to the screen. Note how harsh the lighting looks on the right.
The key issue is that a display doesn't normally have a linear response. (100, 100, 100) is not twice as bright as (50, 50, 50), in fact it is usually more than four times as bright. And images and RGB colors are usually given as values to be sent to the display.
The good news is that most settings in Octane are by default correctly set up. The most problematic part is inputting RGB values. The tone mapper by default is set up with gamma = 1.0 but the selected film curve does some gamma correction.
To avoid errors you need to get two parts right:
Getting data into Octane:
This image shows you the difference between (1.0, 0.5, 0.0) in linear space, and (255, 128, 0) in most color pickers (Photoshop, MS Paint, or #ff8000 on a web page):
- RGB colors: If you have 8-bit colors given these are usually in sRGB, they need to be converted to linear space for Octane.
- Versions prior to 1.17: If you get a hex value (like ff0807) you can paste it into the hex input at the bottom. Otherwise you may have to convert it to [0-1] range and use the sliders just above the hex input. In preferences » Application make sure the color picker space is set to sRGB. The sliders in the node inspector are linear, only use those if you know the RGB values are in linear space.
- In version 1.17 and newer you can paste either the hex value (ff0807) or the decimal numbers (255 8 7) into the HEX field. These will then be converted to linear space, independent of the color picker space preference.
- If you use an integrated plugin it may let you pick a color in screen space, and then feed these RGB values directly into octane. This will give a wrong (lighter and less saturated) color in the renderer. You may be able to enable linear workflow in the application to correct this problem.
- Images are always encoded for a certain display gamma. You need to set the gamma slider of images to this value.
- For most low dynamic range images (PNG, JPG, etc.) this is 2.2.
- For most alpha images this is 1.0.
- HDR images typically have linear encoding → 1.0.
If you have a known gamma value less than 1.0, this is the encoder gamma, which is the inverse of the display gamma.
- RGB colors in exported MTL files may or may not be specified in linear space. Some apps export linear values, others don't. Octane currently assumes the values are linear, which may cause wrong colors to be imported into Octane. Future versions may introduce a setting in the import preferences to correct this.
Getting the rendered image:
- If you want a linear HDR image choose openEXR Untonemapped as format when saving.
- To save a LDR image set the gamma slider in the tone mapping to 2.2. This is the standard value used on the web.
- For viewing on your monitor you are currently limited to sRGB—Octane doesn't have display color management yet. The gamma slider in the tone mapping settings is the intended display gamma, which should match your screen, most commonly 2.2, although macs may use 1.8.
The film response curve doesn't have any effect if you save as untonemapped openEXR. For the other cases you may have to use different gamma values if you enable one, some film curves have gamma correction built-in.
So, what happened in our render above?
The most visible effect is that the falloff of the lighting is wrong. If you move away from a light source, the irradiance from this light source decreases with the square of the distance to the light source. If the distance from the light source doubles, the irradiance decreases by a factor 4.
Now our image is displayed on the screen, which usually applies a gamma curve with an exponent of 2.2. Suppose two points in the image have (80, 80, 80) and (20, 20, 20) as color values, a factor of four difference. Due to gamma correction this is displayed as 0.37% and 7.81% brightness. Our factor four difference according to the renderer turned into a difference of a factor 21 on the screen!
Another thing that you may note is that the green and red tints are approximately right. Here the error of feeding RGB values directly into the renderer is canceled out by the error of not correcting the rendered image before displaying it.
Some other notes:
- This post assumes your monitor is calibrated for sRGB, and that any RGB colors are specified using the sRGB primary colors as well. Octane currently doesn't support other color spaces like Adobe RGB.
- Photo editing applications usually don't do any corrections, but usually the errors are subtle enough to go unnoticed. Resize or blur this test pattern in Photoshop or GIMP, or just zoom the page in your browser, and see what happens. Note that the value of the solid grey patch is 186 and not 128.
- About comparing colors using LCD monitors: TN monitors have very narrow vertical viewing angles, in the order of a few degrees. Observe the brightness of the grey patch compared to the stripes if it you scroll it up or down. On IPS monitors the brightness of the patch is much more consistent.
More reading here: GPU Gems 3 - Chapter 24. The Importance of Being Linear