Afrikaans
Akan
Albanian
Amharic
Arabic
Armenian
Azerbaijani
Basque
Belarusian
Bemba
Bengali
Bihari
Bosnian
Breton
Bulgarian
Cambodian
Catalan
Cebuano
Cherokee
Chichewa
Chinese (Traditional)
Corsican
Croatian
Czech
Danish
Dutch
English
Esperanto
Estonian
Ewe
Faroese
Filipino
Finnish
French
Frisian
Ga
Galician
Georgian
German
Greek
Guarani
Gujarati
Haitian Creole
Hausa
Hawaiian
Hebrew
Hindi
Hmong
Hungarian
Icelandic
Igbo
Indonesian
Interlingua
Irish
Italian
Japanese
Javanese
Kannada
Kazakh
Kinyarwanda
Kirundi
Kongo
Korean
Krio (Sierra Leone)
Kurdish
Kurdish (Soranรฎ)
Kyrgyz
Laothian
Latin
Latvian
Lingala
Lithuanian
Lozi
Luganda
Luo
Luxembourgish
Macedonian
Malagasy
Malay
Malayalam
Maltese
Maori
Marathi
Mauritian Creole
Moldavian
Mongolian
Myanmar (Burmese)
Montenegrin
Nepali
Nigerian Pidgin
Northern Sotho
Norwegian
Norwegian (Nynorsk)
Occitan
Oriya
Oromo
Pashto
Persian
Polish
Portuguese (Brazil)
Portuguese (Portugal)
Punjabi
Quechua
Romanian
Romansh
Runyakitara
Russian
Samoan
Scots Gaelic
Serbian
Serbo-Croatian
Sesotho
Setswana
Seychellois Creole
Shona
Sindhi
Sinhalese
Slovak
Slovenian
Somali
Spanish
Spanish (Latin American)
Sundanese
Swahili
Swedish
Tajik
Tamil
Tatar
Telugu
Thai
Tigrinya
Tonga
Tshiluba
Tumbuka
Turkish
Turkmen
Twi
Uighur
Ukrainian
Urdu
Uzbek
Vietnamese
Welsh
Wolof
Xhosa
Yiddish
Yoruba
Zulu
When we looked at path tracing, we skipped over one major step in the creation of the
final render.
We covered how rays bounce around the scene, and how each ray will contribute some amount
of light to a certain pixel.
By the end of this process, we know how much light reached each pixel, but this isn't actually
enough to give us a usable image.
The issue is that the amount of light that reached each pixel can be anywhere between
zero, meaning no light at all, up to an unlimited amount of light.
Meanwhile, a screen can only emit light within a certain range.
So we need some way to map the unbounded amount of light for each pixel to a bounded image
color that can be displayed on a screen.
Perhaps the simplest way is to set a limit, and just clamp all the light above that limit.
This way, all the values within the range of the screen correspond exactly to an equivalent
light intensity.
If we plot the clipped values, it looks something like this.
As we'll see, this is a pretty terrible approach.
Let's first take a look at this black and white scene.
Here we can see that the sky reflected on the sphere is all clipped, and we can't see
any detail there.
We also see the reflection of the sun on the plane, which has a harsh edge where it starts
clipping.
This is not how our eyes perceive bright spots in a scene, there is no clearly defined boundary
where our eyes start clipping, in reality there is a much softer transition.
If we increase the brightness of the picture a bit, all the issues get even worse, now
we also have this harsh edge around the ambient occlusion under the sphere, where the plane
started clipping.
If we increase the brightness a bit more, the cone also gets a hard clipped edge.
And if we keep increasing the brightness, these clipped zones keep growing until most
of the picture is white.
Note that with each increase in brightness, the picture didn't really look like it was
getting brighter in a natural way, rather, it just looks like the clamped areas are growing
and flooding the image.
If we introduce color, the issues are even worse.
We still have the clamped sky and the sun reflection on the plane, but now there is
already a hard edge on the cone.
If we look at just the Red channel, we see that it's because it reflects so much red,
that the Red channel already clipped, meanwhile, the green and blue channels are still in range.
Here on the Blue channel it's also notable that the ground is already clipped, and the
cone doesn't reflect any blue light at all.
Now if we increase the brightness a bit, we see that the plane starts shifting to cyan,
because the Blue channel couldn't increase in brightness anymore as it was already clipped,
meanwhile, the Green channel kept getting brighter, so it changed the color ratios,
and shifted the hue.
The cone, and the leaves in the background also started shifting to yellow for the same
reason.
If we increase the brightness again, we see that the cone and the leaves clipped completely
to yellow.
At this point, the ground has clipped on all channels, but there is still this strange
harsh sliver of blue at the dark parts under the sphere.
And if we really bump up the brightness, almost everything goes to white, except the cone,
and the leaves in the back.
That's because they don't contain any blue, which means that with the red and green channels
clipped, we get this harsh yellow, as the Blue channel remains on zero, no matter how
much we increase the brightness.
The problem is that this is not at all how our eyes perceive brightness.
When we see something very bright, even if it's saturated at some specific hue, it starts
looking white.
Note that I'm showing these very extreme examples, just to illustrate the issue, but this problem
is still present even with much less bright images, and images can often also have a wide
dynamic range, with some parts being very bright and others very dark.
So it's important to properly convert the light intensity values from the render into
colors, in a way that's closer to how our eyes perceive the world.
To deal with the hard clipping issue, we can come up with a function where the output starts
off following roughly along the input values, but which slows the output down, as the inputs
get higher.
The idea is not necessarily to avoid clipping altogether, but rather to slowly ease into
it.
If we plot this function, we see that it has a softer high end.
But this function is only part of the solution, we'll also need to desaturate colors, as the
light intensity goes up, so that it clips to white, and not some harsh yellow or cyan.
If we run our brightness values through this function, and look at the black and white
example, the first thing we notice is how we have a wider usable dynamic range, and
we can even see details in the sky.
The reflection of the sun on the plane also has a much softer falloff.
Now if we bump up the brightness, it just looks like a brighter version of the image,
no hard edges, or noticeable flooding of clipped areas.
And we can keep increasing the brightness, and it still looks reasonable.
There can still be clipping, be we don't see the clipped boundaries, as we're softly rolling
into it.
Now looking at the color version, the cone doesn't have that hard red edge.
And if we increase the brightness, the plane starts getting desaturated, just like our
eyes would do, rather than shifting completely into cyan.
If we increase the brightness again, the cone starts losing saturation as well, and we still
don't see any hard clipped edges.
And if we really push the brightness, we see that we shift everything into white, even
the cone, which didn't contain any blue.
This looked much better, but there is a lot of maths and color science involved.
But luckily, we don't have to implement this stuff ourselves, Blender has this color transformation
that we looked at built-in.
It's applied by selecting Filmic in the color management options, but you don't even need
to do that, as it's already the default.
It's just important to be aware of this.
When you output a color, for instance, with an emission shader it'll look a bit different
in the render due to the color transformation.
When doing any sort of 3D rendering, you almost always want to have a color transformation
like Filmic being applied to your output.
The only case I can think of where you wouldn't want such a transformation, is when doing
flat rendering for something like motion graphics, where all the shaders in the scene are flat
emission shaders, and you want to control the output colors directly, in which case
you'd select the Standard output transform, which just clamps the values.
But as soon as you are applying any sort of lighting to your scene, you'll want to have
a proper color transformation applied.
This was an overview of color transformations, and how we get a proper color from a light
intensity value.
But we are barely scratching the surface of the color science required to actually make
an image.
If you want to have more understanding of the whole color pipeline, and how colors get
from a source all the way to the displayed output, I can highly recommend The Hitchhiker's
Guide to Digital Colour, which incidentally is written by Troy Sobotka, who is also the
author of the Filmic color transformation.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.