Also, quick inline question:

We don't have an issue with the patch; but have the users also accepted the changes (like fsiddi, venomgfx or sebastian_k) at least for the compositor.
Perhaps sergey could have a look to the other code.

Sergey, perhaps you have an opinion on the cycles part.

Will have a look tomorrow morning. Kinda late here already.

Note that I have not changed HSV blending modes in Cycles yet, for I have only done a rough cleanup there. Also, I think it could be good to rework the bytes formulas according to what I have done for the float ones. In that scheme, dealing with the blend operations for vertex and weight painting is also considered.

@Jeroen Bakker (jbakker): I was also thinking that, I might send a mail to bf-compositor to get some feedback from the users.

Nice work. My thoughts:

• Color looks better. Almost like a Vibrance adjustment.
• Hue looks the same?
• Saturation also looks better, because it seems to be both saturating and desaturating according to the image. Some users might like the old mode better, but it can probably be reproduced by bumping the sat on an HSV node.
• Value looks weird. Looks like it's also affecting the saturation and hue. This one would my only complain.

It's hard to say without looking at the original image though.

@Diego Gangl (januz): I uploaded the original image (as well the blendfile used, just for the hell of it).

Hue: almost the same, the colors are just smoother (no artifacts); will try to find a good image to demonstrate that.
Value: I still can't find what exactly is going wrong, as it is basically the same formula as Color but with the input swapped. So this will most likely change.

Thanks. Yeah, it all looks ok to me.

I decided to revert the changes made to some of formulas, and other small ones, for now as these should (and will) be dealt with in a separate patch. Also, there were a bit problematic in some cases, so let's not make things worse.

In all, I think this is ready for final review.

@Antonis Ryakiotakis (psy-fi), mind having your eyes here? :)

I'll check the patch a nit later.

Generally seems good, though didn't check OSL changed much.

One think I'm not so keen on is adding the n argument all over which is only ever checked for 4,
Why not have blend_color_screen_float_v3 and blend_color_screen_float_v4? (the v4 version can just call the v3 one in many cases).

It's indeed important to have OSL and SVM matching as close as possible. It also worth checking if wrapping stuff into for-loops doesn't result in changes in performance.

But IMO main quesiton here should be, how did all this was verified and checked against regressions?

Well, this is quite an old patch (first revision submitted ~20 months ago), so by memory I did some tests by comparing a handful of images. But, apart from an obvious call to a linear interpolation function (e.g. (1.0 - fac) * x + fac * y -> lerp(x, y, fac)) to make the code a bit more readable, only a few functions got the logic rewritten. Namely dodge, burn and soft light. And that's only for Cycles and the GLSL code for some reason (I forgot why). screen also got the math simplified. The Blender side is using the same formulas as master. If you feel a bit worried about it I can revert the formulas in Cycles and GLSL, but still use the lerp function. After all, the goal was de-duplication.

Then for speed regression, I haven't checked though.