I’m using blender 2.7.0. Basically when I render a scene, it looks perfect in blender but if I save it out to a JPEG or PNG or TIFF etc… it loses some saturation and contrast. Looks flatter and duller compared to what I’m seeing in blender. Is there an easy way to match what I’m seeing blender to what gets saved?
What are you viewing this saved file in?
Here is the same image as Blender rendered it. Saved to disk as PNG and viewed in the system viewer and viewed in Photoshop as well. They all look the same on my system.
Have you tweaked your video card to a non-default setting?
Attachments
Not tweaked anything but I have calibrated my iMac 27" screen with an i1Display Pro. I don’t think that would make a difference.
Have you added a 3DLUT to your Blender config ?
Scroll down to the bottom of the page, it will explain how to add the 3D LUT as a colour space. Once you do this, remember to turn off the ‘Save as render’ option when saving renders.
http://wiki.blender.org/index.php/User:Sobotka/Color_Management/Calibration_and_Profiling
Blender will not embed an icc profile so if this is required, you will have to re-save the rendered image in an image editor.
Sorry for the late reply. I’ve been out of town. Thank for the suggestion, will try it and get back to you tomorrow.
Ok I read through the LUT instructions and I’m thoroughly confused. Isn’t there a simple way to get my renders to look exactly like they do in blender once I save them out to say JPEG or PNG etc… I haven’t had this problem Cinema 4D, why is it only happening with blender?
UPDATE: Even if I do a screen capture on my Mac from the viewport render there’s still a colour shift on the saved PNG.
Also, this problem is more obvious on renders that have large areas of a single colour
Photoshop and Blender are both colour managed. If you have profiled and calibrated your monitor, Photoshop is aware of the monitor profile; Blender is not. Following the steps on the wiki page will make Blender aware of the monitor profile.
So can I do this procedure with the i1Profiler software or do I have to use DispcalGUI & Argyll?
Ok please ignore my last comment. I have installed DispcalGUI + Agryll and I have a quick doubt. Since my iMac screen doesn’t have separate RGB controls what do I do on the ‘start measurement’ white point. I have no controls to adjust my RGB levels to get closer to the target. Do I just proceed with calibration?
I’m not familiar with iProfiler, though I would guess it can create a 3D LUT.
Yes, you can go ahead with the next stages. Adjusting the settings at the start just leaves less adjustment for the profile to make after.
I just followed those instructions to to create the 3DLUT but I’m having huge issue. Firstly renders just look wrong. Super dark and contrasty when I switch to ‘Profiled’ in color management settings. Secondly when ‘Profiled’ is selected I can’t activate viewport rendering, blender just crashes. I’ve attached the crash report. What am I doing wrong?
Crash Report: https://app.box.com/s/aahdfo0sa3u0w68hug1s
I don’t have any of those issues. Since I don’t use a mac its probably best if you talk to a developer.
Ask on Blender’s irc channel or file a bug report. You could try #blender or #blendercoders on Freenode.
Hey thank you for all the help. I figured it out and everything is working perfectly now. Basically, I had pasted the code in the wrong place and it wasn’t reading the LUT. Anyway, it’s all sorted now. The only issue I have is with yellows now. Seems like after I’ve profiled I’m unable to achieve bright saturated yellows that could without the profile loaded.
That is good news, I’m glad you got it working. It makes a real difference being able to trust the render window and not have to do any secondary grading after saving the rendered output.
A little further information for those that might be confused by this statement.
Color is loosely two halves:
- The linear / non-linear aspect of intensity that “cheats” intensity so that values can appear closer to expected on low dynamic range devices such as a display.
- The actual color, or chromaticity, of a pixel.
Your observation specifically focuses on the second point, chromaticity.
If we assume that you have successfully and correctly profiled your display, and your colorimeter is reasonably accurate, the actual colors of your display have been measured. The transform you have implemented will take the reference colors of the three lights of the internal sRGB working space and transform them so that they are rendered more or less accurately on your given display.
Most displays are rarely accurately sRGB out of the box, and almost certainly have a broad range of deviation across displays. This is doubly so for wider gamut displays, which have quite radically different colors of red, green, and blues that make up their panel pixels.
In this particular case, it is entirely possible that the red and green primaries of your display were slightly different from sRGB’s theoretical colors. In this instance, the profile is actually converting the internal values to the theoretical values that they were intended to be. In this particular instance, the yellow in sRGB is less saturated than what your display’s raw pixel colors can display. Even if you were working in a wider working space than sRGB, proper color management would reel those values from the wider gamut into sRGB’s gamut, and constrict the yellow to the maximum yellow that sRGB can display.
So where previously your values were being fed raw to the display, and the mixture of red and green was yielding a somewhat random maximum yellow that your display could output, now your display is outputting a yellow that is much closer to the intention of the mixed lights sRGB is actually supposed to be displaying in those quantities.
This is one of the critical reasons for using color management in a pipeline.
I suggest that you go for the data in situations like this. Create a test-image containing, say, four gradient-filled boxes: R, G, B, grayscale. You can measure the value of any pixel in the Blender windows, and you know (because of the gradient, and because of gamma, which is also a known equation) what the values at any point in any output image ought to be. You can also eyeball it.
Render to several different image-file formats, with varying degrees of compression, and measure the numeric value of selected pixels therein using Gimp, Photoshop, Preview, or what-have-you. (Histograms too, of course.) You can calculate what the right-answers should be, and objectively determine what is actually being done to the data.
“Objectively” here is problematic because RGB is a relative model.
That means that any set of values are exactly the same in any given colorspace.
That is, precisely identical values mean entirely different things in different color spaces, and this extends well beyond transfer curves. Transfer curves only apply to the intensity of the color, but tells you absolutely nothing about the chromaticity.
sRGB is a well defined gamut, and there is absolutely no way to “eyeball” color. Given identical values, when displayed across different devices, the results will be different. More specifically, one can sample the precise numerical values of the raw data in Blender and see radically different things.
This is a portion of what color management addresses, and exactly what the OP has begun to address.
Hey,
So sorry for the super late response but I just figured something out today and thought I should share it. I went through the whole calibration process and still had some issue with saturation and contrast but today I realized that the save image dialogue after rendering has an option called ‘Save As Render’ which is ticked by default, unticking this solves 99% of my colour problem. Saturation and contrast are perfect even after saving the renders. Could anyone explain why this setting is messing up my colours?
The only issue I’m still having is with greys. The greys in blender look a little warm even though I’m using neutral grey and white light. However, when I save the render this warm cast on the grey goes away.
Both poorly named features do the same thing, only applied to different aspects.
View as Render and Save as Render apply the display out transform to the data. That is, if you have profile correction on the display output pipe, it will be baked into the data. This effectively bakes your LUT into the data, corrupting the intention of the data.
This takes the RGB data in whatever internal space a system is operating in and transforms it to the unique characteristics of whatever display the profile was generated for; something you must have for a display transform, but completely incorrect for a base transform to an image space.
Ideally, Blender needs more color control via a “baking” interface, but before we get there, we likely need more artists with greater color knowledge.
There is no such creature as neutral. 
Achromatic sensations are created because your eye has adapted.
In color management terms, this is effectively in the domain of rendering intents. That is, the reference space you work in must have whites aligned to your inputs. In the case of ICCs, there is a reference space implied (Profile Connection Space) when you generated your display LUT likely. This ICC reference space aligns all whites to D50, a slightly warmer version of white than the reference ITU standard fpr sRGB / BT.709 of D65.
Relative colorimetric scales all values, and as such, achromatic equal values of RGB will be maintained. Absolute colorimetric attempts to map the original intent to the destination, thereby shifting the appearance of white in some contexts.
In your case, it sounds suspiciously like your display transform is doing an absolute colorimetric from the implied ICC D50 (likely) used to generate your profile to the D65 output. Just a wild guess…
In order to sort out your white issue, I would need to know more about:
- Display profile generation. What did you use and what settings?
- Viewing context. Where are you viewing the work when the issue appears and what are the contexts?
Hope this helps,
TJS