compositor blown out highlights

hey, has anyone had this issue where when you start playing with levels in the compositor, blown out highlights turn horrible strange colours?

yeah , the trick is to not turn them that high :wink:
you should try playing with rgb curve nodes and contrast settings :slight_smile:

yes i’m already having to make complicated work arounds with duplicate lights exclusive to different materials to get nice rim lights on some objects while preventing others from blowing out.

but what exactly is the benefit to having colours invert when they become too bright rather than just have them clip at white?

I second Casio23, you should just use curves. With curves you can clip out bright whites, control any range of color and have more power than most any other adjustment tool. The trick is learning how to use it, but once you know how it works it’s indispensable. Curves works the same way in almost any image editing program, so you can look at any tutorial.

Check this out:

I think you can easily fix your issue with just simply using a curves node correctly.

When you say “blown out highlights,” my gut feeling is that you’re not using Blender 2.5x with the “Color Management” feature turned on.

You’ll need to measure the RGB values in the data to determine where the unwanted colors are coming from. A color cast caused by “overexposure” seems strange to me. I’ll be watching this thread with curious interest.

@sundialsvc4, actually i am using the latest graphicall build of 2.56, and colour management is turned on.

i should clarify, as i’ve been playing around a bit more. the image coming out of the renderer has highlights looking as they should. furthermore, i was incorrect when i initially said that it was level adjustments that were causing the highlight problems. the issue is the result of a mix node, where the rendered output is mixed with itself using the “soft light” blending mode.

i was attempting to duplicate a treatment that one of the designers had been doing in photoshop for another part of this project i’m working on. however i’m guessing since the rendered image in the compositor stores a wider dynamic range of luminance, it creates wonky inverted colours for certain blending modes.

i’m familiar with curves, and i’ve placed a curves node ahead of the mix node to try to clip the highlights, but it didn’t seem to work. the only workaround seems to be to export the image to a png or similar and then perform the operation within the 0-255 luminance range that my coworker had been doing in photoshop.

there’s no way to restrict the dynamic range like that internally within the compositor without having to save an intermediate image, right?

I presumed you knew all that, yes. :yes:

There are nodes that will map or clip values to a specified range . . . it doesn’t seem right to me that you’d have to pass through a restrictive file-format to get this job done. Hmmm… hope others chime-in on this one.

soft light hard light screen are all blend modes for a gamma encoded workflow if your using a linear color managed workflow and the workflow ia also 32bit float you’ll get wrong results

the png you exported was 8bit gamma encoded

Yeah I always wondered why transfer type effects came out different to photoshop/after effecst. If some nodes use Linear Workflow and others don’t, how should you composite? In LW or not?

Own choice I guess but Linear is the way. re Photoshop / AE, LW only appeared properly in CS4, CS3 partially I think.

You want to “get it to be linear,” do your stuff linear, and then output to whatever the downstream client expects to see. Of course. And I know that “Color Management” is supposed to do a lot of that for you. Of course. What puzzles me is the appearance of a color cast, or downright distortion, which almost makes me wonder if the downstream client is interpreting the file data correctly. (Either software ('s settings) could be the source of such a problem.) If the number got large enough that it “spilled into the next number” when seen the wrong way. And so on. I am certainly not well-versed in these areas; I just wonder if such a thing might be the root cause of such a problem. The colors, you say, are not merely being blown-out, but not-quite garbage is showing up in what should be unrelated (though parallel…) channels of data.

The data “always looks right in Blender, but it looks wrong downstream?” All of these files are “only 1’s and 0’s,” after all, so if the file’s format were being misinterpreted by the downstream client … I think we can exclude “bugs” in either product from serious consideration here.

“Hmmm… curious, curious,” he said, putting on his digital thinking-cap…

Colour cast and distortion could be as a result of clipping off values above a certain range rather than accomodating them. Tone mapping will allow you to ‘squeeze’ what you want in the 8bit images and what to throw away with more control over the gamut mapping. Blender doesn’t offer much in that respect so maybe use an external tonemapper by exporting .exr’s

Thankyou so much for all the replies everyone!

I’m happy to report I’ve found a solution to the issue.

@Yellow, tonemapping was my first inclination for clipping luminance, and it did eliminate the colour cast issue, but even with fiddling, I found it was changing the overall tonal qualities that I didn’t want altered. I’m sure with more knowledge and experience I could compensate better, but for the time being I’ve got a solution that delivers exactly what I want!

To clip values, all you need to do is run the luminance through a “map value” node and make sure “Use Maximum: 1.0” is selected. so basically you add 3 nodes:
-separate HSVA node
-run the “V” through the map value node
-combine HSVA node to recombine the clipped “V” with the unmodified H,S,A channels

the output looks exactly your original image but the highlights will not clip when you use mix nodes!

Good you found an answer and yes blender offers little in tone mapping, why I suggested external app offering more choice, like a lightness perceptual tone mapping algorithm, maybe try out this: free beta and runs on Linux with wine, just about. :slight_smile:

I’m not really upto speed on the tech but in a 32bit float workspace should clipping happen at all unless done deliberately as you have, values should be able go negative and over 1 without clipping and slide back into gamut as adjustments are done allowing not so heavy handed gamut mapping. I think blender desaturates brightness first before clipping as well.

Talking about clipping. I notice on the Prolost blog from Stu, that Red Giant had a algorithm for their colour correction tools that would fix clipping by stealling information that may remain in the other colour channels. Pretty amazing to see detail re-appear in faces.

That’s just the full range workflow for 8bit video really, done in 32bit float workspace, where as this thread is about clipping values in high dynamic range images. :slight_smile: Same ugly results if clipped, just different source media.

Oh ok. I didnt pay enough attention, i thought it was all 8bit input.