Topic: blender 2.64 color management

[ratty redemption]

today i've installed 2.64 and am having trouble matching the 3d windows, compositor and renders to be the same as 2.63 and earlier. there doesn't even appear to be a way to turn off the color management in 2.64.

can anyone help?

[kat]

"Scene" Properties, "Color Management" ("Scene > Color Management"). You mean that?

[ratty redemption]

yes.

[ratty redemption]

apparently if we set "scene > color management > display device" and "color space" to "srgb" then it's meant to be the same as 2.63 with cm on, but all my wok to date has not used cm.

and if we set "scene > color management > display device > none" then my renders don't match 2.63 or earlier,

there are two sliders  "scene > color management > exposure" and "gamma" but i can't find values to use with them that again match my previous renders.

[kat]

Does 2.63a have any CM options? I just had a look and could find any.

[ratty redemption]

yes in "render properties > shading > color management" although that is only a single tick box.

i've spent hours today trying to render stills that have the same looking "exposure" and "gamma" settings as my previous 2.6x renders. i've got the results close, but not close enough for those to produce seamless animations. for example i tried to render the 2nd half of an animation in 2.64 and the results looked like a skipped frame when playing back.

i don't mind the blender devs giving us a more powerful cm system. but they should of made it completely backwards compatible imo. even the wiki page says this:

Compatibility with existing files should mostly be preserved. Files that had color management enabled should be entirely compatible, while older files with the color management option disabled are mostly compatible but different for vertex colors and viewport colors.

what they don't mention is with "scene > color management > display device > none" the compositor now looks about half the brightness/gamma as it did before, and the saved images/animations are the same. so i've been test rendering with gamma set to about 2.1

[kat]

I suspect, and I'm purely speculating here, that in older versions the colour management system wasn't a 'true' colour-space based system (using colour profiles). It appears on inspection to simply do a gamma and contrast adjustment in a similar way to ydnars old "Gamma+" tool which would change the gramma of your screen to match that of OpenGL (bumped by 1.2 iirc).

Cue Blender 2.64a and it appears now that they've introduced proper colour management and all the differences that go along with that. This probably means that Blender has an default profile when set to "none", not that it has 'no' profile (one absent of anything). That would account for the differences you're seeing - if an old file is loaded it's going to default to the base profile regardless.

I don't know if this is correct or not but it would seem the most logical exploitation as to why there is a difference between the two. So if you were wanting to preserve the previous look it may mean more extensive experiments to match, not using 2.64, or using 2.64a and seeing if you can capitalise on the difference.

[ratty redemption]

thanks and that does make sense.

i'm using 2.64a and i can get some renders almost the same as 2.63a but not all of them, the worst problem is with the compositor, as soon as i start mixing render layers or image sequences together then the result don't match 2.63a or earlier versions.

[ratty redemption]

i've been posting about this over at ba:

http://blenderartists.org/forum/showthread.php?271065-2-64-vs-2-63-lighter-render-using-same-scene

another artist came to the same conclusion that backwards compatibility is now broken from 2.64 onwards. so we are sticking with 2.63 for our current projects.

[kat]

Ah yes, looking at those shots it's more than just a simple case of contrast and gamma, so yep, you'll need to stick with 2.63a for consistency (even if you could process the images externally before compositing you're still up the creek as the old images aren't rendered against a colour profile, that means you could adjust colour et-al to match a particular sequence, but those very same settings might not look right elsewhere).

[ratty redemption]

agreed.

[ratty redemption]

over at the ba forums we have had some success with this:

the good news is i don't think it's a bug, it's more likely a design feature that wasn't mentioned in the wiki, at least not as far as i could find. however in the various tests i've done today it seems straight forward to fix older .blend files to work in 2.64

apparently we can now set the color spaces for the individual composite input nodes, via the node properties panel (which i normally have hidden) as well as the documented scene color spaces for display device, render and sequencer.

in my tests, if i set the inputs to use "raw" color space my renders match 2.63. if i load in a previous .blend then they are automatically set to "srgb", which i assume was over riding my scene display set to "none"

also setting display to "srgb" and render to "raw" seems to produce the same results as display set to "none"

i've done several more tests today using both the file i sent bgrg and my main .blend file.

both 2.63 and 2.64 are now matching 100% for me, as long as i set the input nodes to "raw" but every time i load a new image into them manually (as opposed to an image sequence being incremented during animation rendering) then the color space is set back to "srgb".which produces the different results.

[ratty redemption]

frustratingly, i just found one of my compositor node setups does not produce the same results in both 2.63 and 2.64, no matter what cm settings i use.

compare the watermark on these two images. the same .blend file was used in both blender versions.

[ratty redemption]

i reported this to the official bug tracker and it's been fixed in the latest builds, apparently was the blur node in 2.64a not using gamma correctly.