PM sent, thank you!
got it, thanks.
as i stripped down a .blend file to send bgrg, i noticed my render was looking the same in both 2.63 and 2.64. i decided to do more tests, as my original .blend file still looked different in 2.64 so i thought maybe it was a specific composite node that was buggy?
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”
hope this helps others here who were struggling with the new color management. it sure confused the hell out of me.
So, I rendered both ratty’s and Kiver’s file in v2.63 and v2.64. I could not find the problem with ratty’s, but indeed found it with Kiver’s. There is a slight but obvious difference between the renders of the bridge scene in the two versions. The histograms show it clearly, too.
Kiver, I assume this .blend file is already tweaked for the best possible match you could achieve, right?
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.
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.
bgrg tested another .blend file i sent him and confirmed the cm settings aren’t working for all nodes, at least in the compositor.
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.
i’m aware it’s been out a while but i’ve just tested 2.65a with some of my compositor nodes, and most things appear to be working accept the color ramps, which appear not to be gamma corrected in a similar way that the blur node was in 2.64 can anyone else confirm this?
i’m attaching two images, both use the same color ramp settings, but the 2.65a one is much darker with some of the lower shades than the 2.63a.
Attachments
i spent quite a lot of time yesterday preparing a .blend file and screen shots, with detailed descriptions to report this to the official bug tracker, and today i see that Ton Roosendaal closed my report without even properly reading it. he seems to think i want to use 2.63 with files i created in 2.65 which is the opposite of what i want.
i am so pissed off right now, especially as i don’t want to have to rebuild all my compositor nodes just because the devs can’t be bothered to fix all the gamma issues they created with the new cm system.