Make the flame of a candle more yellow

Question

Here is what I have so far:

The issue is The candle looks like a light bulb... when I tried to make it more yellow via RGB Curves the whole thing got more yellow:

Can anyone help me out? Thanks!

Answer 1

A few options:

Using the compositor, changing the materials for the emissions shader, or harnessing the power of color magangement.

Each one will have a different effect, and can also be combined according to your artistic intentions.

Option 1: Using the compositor you want change the color for the flame so it doesn't look white.

(click on any of the images to enlarge)

To isolate the flame from the rest of the image you can enable the emissions pass on the render layers.

On the compositor you can see that you have a new image that contains only the emissions of the image.

You can then use this information to tint the image, so that only the flame is affected.

Plug the Emit information to a vector normalize node (to bring the values to a scale form 0 to 1), and plug the result to a color mix node's factor. That will allow you set the color you want the flame to be. Ony the flame will be affected by the color selected on the Mix node.

Note that the edges are a bit rough since the emissions pass is not antialiased, so you can add a Dilate/Erode node in Feather node to make the edges smoother:

Adding a blur filter to the emissions pass will allow you to create some glow...

Here's the blend file if you want to download it:

Now in my opinion that still looks like a colored light bulb instead of a flame, so we can try now

Option 2. Using more than one emitter shader for the flame.

The flame material for a candle is hardly ever just a single color emitter.

Here is a different example file to play with:

You can start with a node setup like this for the material of the flame:

(Click on the image to enlarge)

It can be broken in 3 main components:

1. First, a gradient for the different temperatures of the flame.

2. A first emitter that is mixed with some transparency. This is the one that will determine how the flame will look in terms of color, brightness and transparency.

The biggest issue is that with just one emitter is that if you make the flame brighter to illuminate surrounding objects it just becomes white, so you need to add

3. a second emitter that is unseen by the camera, but that illuminates everything else (The light path node prevents the second emitter to be seeing by the camera).

If you look at this example, this second emitter is 100 times brighter than the flame.

Then you can add more effects on the compositor:

Option 3: Using Tone Mapping in the compositor

With a single emission shader, using a gradient to create a more realistic flame.

Again, in order to see the color on the flame, the emission strength would need to be low, but that makes the surroundings very dark.

Bringing up the emission's strength will make the scene look brighter but the flame's gradient is way to bright now, past the 100% clipping point

Looking at the waveform monitor we can see that the flame is way over the 100% mark, so all detail and color is gone, no more information can be displayed on white.

Using a Tonemap node we can try to modify the dynamic range of the scene by remapping of the values to fit on a scale of 0(black) to 1(white):

The colors for the flame are back, but the image looks very washed out and boring because it has a much lower contrast and less color saturation. To fix that we can alter the image values with a color curve.

Lastly just add a glare node:

Option 4 Using color management (as suggested by this answer)

Using a custom 3dLUT (Look Up Table) for the device transform you can use a much wider dynamic range on the scene.

Again, with a single emitter shader on the flame, a LUT used on the color management will allow us to use luminance values much brighter than 1 and re-map them to fit a range between 0 and 1.

For more information read this post.

User @troy_s has created a set of LUTs and OCIO config that greatly enhances blender's cycles rendering and its ability to deal with a wider dynamic range, thus creating more photorealistic results. They can be downloaded here, along with the instructions on how to install and use.

Answer 2

While cegaton's answer will work, I'd like to point out that your question is much more complex than what many folks might see at first glance and is a perfect example to examine the output view transform.

Photorealism and Flames

Flames are, as we all know, bright.

When we say a term such as "photorealistic" we can infer very quickly that the learned aesthetic is referencing something. In this case, it is referencing the learned aesthetic of photography.

Photographic still images hold a good deal of dynamic range, or the entire range of light from darkest to lightest value within a scene. For example, if a particular film stock holds fifteen stops of light, it might mean that it holds 8 stops down and 7 stops above middle grey.

When we consider a flame, we are dealing with a very large ratio of light in the flame itself, possibly four to five stops or more over middle grey. The log encoding of film, at certain exposures, may retain enough stops to hold and delicately roll off the highlight from a candle in many instances. Digital CGI though doesn't have an automatic and "native" dynamic range like film, but rather relies on a uniquely crafted display referred transform to map these ranges of light.

So what is happening in your image if you manage to get the emission correct on the candle? The candle can be very obviously emitting a coloured light, but no such colour is captured in the default render? How come?

The Secret Sauce of Views

The secret to this answer is the sRGB EOTF default view transform. This transform was designed for an entirely different purpose, and as a result terminates the dynamic range at a display referred range of 1.0. That is, the sRGB view transform, designed for an entirely different purpose well outside of rendering, uses a range of values that is not useful nor meaningful within the context of ray traced rendering.

In your scene, the linear value of approximately 0.2 will be your baseline middle grey via the default view transform. That leaves a meagre two and a portion stops above middle grey for the entire scene's highlights, something even bright paper can exceed. That is, 0.2 + 0.2 is one stop, 0.4 + 0.4 is two stops, and the remaining 0.2 is a sliver of the next stop. That pathetically small two and a bit stops is obviously not even remotely the amount of latitude required to maintain any semblance of colour in the flame, and not even remotely close to emulating the dynamic range of a photograph.

When we compare that with the amount of light our sample film stock holds, we can see that, because the view transform terminates at a peak of 1.0 scene referred, our candle flame greatly exceeds the limit of our display referred transform long before an equivalent film stock would.

Reconciling Display Referred and Scene Referred

The whole concept of photorealism then, is inherently broken and fundamentally impossible within the default sRGB display referred transform from the scene referred data.

To overcome this problem, a possible solution could be to apply a method to get more stops into a gentle roll-off "under" the scene referred limits of the sRGB view transform. In this case, trying a tone mapping operation or using a custom curve in the Color Management settings that bends roughly six or seven stops of latitude into the range between 0.2 and 1.0 display referred. For the more adventurous artist, they can experiment with crafting their own display referred view transforms that seek to emulate a closer dynamic range of film / digital photography.

Tone mapping however, is extremely sub optimal given the nature of most existing formulas and the methods they use to map the dynamic range to the sRGB view transform. Further, you are still saddled with the characteristic contrast curvature of the sRGB EOTF, which means negotiating contrast can be more complicated than it need be. It could be considered that a more appropriate approach is to use or craft a proper and reliable view transform that more closely emulates a dynamic range that of the photographic medium.

Again, cegaton's answer will obviously work fine, but this question provides a wonderful opportunity to explore the nature of "photorealism" and the OpenColorIO view transformations.