GNOME Bugzilla – Bug 744265
layer mode 'addition' makes wrong gray values
Last modified: 2016-03-16 20:09:56 UTC
Created attachment 296499 [details] images used to show error ------- overview here is an example, where 2 layers, colorspace gray, mode addition, are combined wrongly. ------- steps to reproduce the images to be combined are: img1: 256*256 points, colorspace gray, no alpha channel, content: all gray values black...white, arranged horizontally img2: = img1 rotated by 90 degree (see attachment img[12]__gra[12].png) make 'open as layers' with img2, img1, and add a third layer as follows: layer1 = ( img1 opacity=50 mode=addition ) top layer2 = ( img2 opacity=50 mode=addition ) layer3 = ( (totally black) opacity=100 mode=(any) ) bottom any of the 3 layers has no alpha channel, no layer mask. optional: with 'copy visible' img3 is made. (see attachment img3__add.png) check (color picker tool) the gray values in the 3-layer-image (sample_merged=y) or in the image img3. (the attachment contains also every image in a second version with 'lines of equal gray-value', for clarification; 0=black, 100=white. see files with '+' in name.) ------- actual results the gray values in the left upper half of img3 are correct (0...50), in the right lower half they are wrong, 75...100 are missing, 50...75 are distributed wrongly. ------- expected results the correct result would be img4. (see attachment img4__norm.png) ------- build date & platform athlon64 ms-win-xp-sp3 32bit GNU Image Manipulation Program version 2.8.14 git-describe: Unknown, shouldn't happen using GEGL version 0.2.0 (compiled against version 0.2.0) using GLib version 2.40.0 (compiled against version 2.40.0) using GdkPixbuf version 2.30.8 (compiled against version 2.30.8) using GTK+ version 2.24.23 (compiled against version 2.24.23) using Pango version 1.36.5 (compiled against version 1.36.5) using Fontconfig version 2.11.1 (compiled against version 2.11.1) using Cairo version 1.12.16 (compiled against version 1.12.16) ------- additional builds and platforms the following makes the _same_ result as above. same hw as above. suse-linux-sled-11-sp3 32bit (uname -srvmpio:) Linux 3.0.101-0.42-pae #1 SMP Fri Nov 21 15:47:28 UTC 2014 (4f07b11) i686 athlon i386 GNU/Linux GNU Image Manipulation Program version 2.6.2 using GEGL version 0.0.20 (compiled against version 0.0.20) using GLib version 2.18.2 (compiled against version 2.22.5) using GTK+ version 2.14.4 (compiled against version 2.18.9) using Pango version 1.22.1 (compiled against version 1.26.2) using Fontconfig version 2.6.0 (compiled against version 2.6.0) ------- additional information img4 was made with (only) the following layers: layer1 = ( img1 opacity=50 mode=normal ) layer2 = ( img2 opacity=100 mode=(any) ) addition is commutative (the english manual says this; the german not). the operation here not: swap layer1/2 and the result will change. the above example with colorspace 'rgb' shows the same error. background, actual intention: have n (>=2) images; want make (pointwise) the arithmetic mean. this can be done with mode=normal (all layers) and opacity = 100/1 100/2 100/3 ... 100/n (from bottom to top). it should also work with mode=addition and opacity=100/n (all layers). this is what I would prefer, because it is a bit easier. the latter holds even more in case of the 'weighted average' instead of the arithmetic mean.
If I understand correctly, you want GIMP to permit color levels that exceed 100% when compositing layers. I don't think that's a tenable proposition -- at a minimum it would present a dramatic change to the way this has been handled for nearly 20 years. I personally don't see this as being a bug in GIMP's behavior. Perhaps there would be value in providing a new "Unclipped Addition" layer mode, but I should think it extremely problematic to change the traditional behavior of the "Addition" blend mode.
(In reply to saulgoode from comment #1) > If I understand correctly, you want GIMP to permit color levels > that exceed 100% when compositing layers..... there is a misunderstanding. I do *not* want gray (or r/g/b) values >100 (whiter than white). in my 'steps to reproduce' you can see: 'opacity=50' for both layers to be combined. from this follows, that the combined gray value is in the same range as the given single values are. in other words: 0<=v1<=100 and 0<=v2<=100 implies 0 <= v1 * 50/100 + v2 * 50/100 <= 100 . there can not result a value > 100 . make the 'steps to reproduce', use the formula above, compare with img3 and img4, and you will know, what I mean.
Created attachment 313203 [details] Addition blend mode produces wrong values As per this post to the gimp user's mailing list, there really is a bug in the GIMP code for adding layers together: https://mail.gnome.org/archives/gimp-user-list/2015-October/msg00048.html It's absolutely true that if the layers were added up at full opacity, the RGB values would exceed 1.0f (they'd equal 3.0f). But they aren't added up at full opacity. With reference to RGB values greater than 1.0f, And as noted in the mailing list thread, RGB values less than or equal to 0.55f do add correctly for the opacities in the attached XCF file. But three times 0.55, or even two times 0.55, is more than 1.0f, so it's not clear whether or how values greater than 1.0f even enter into the reason for the failure to correctly add layers for RGB values that are greater than 0.55f. As noted in the mailing list thread, Krita sums the three layers in the attached XCF file correctly, without having to resort to putting each layer in a separate group.
Created attachment 313206 [details] [review] Moves the CLAMP code Removing the CLAMP code does fix the problem. The attached patch doesn't remove the CLAMP code, rather just moves it down to clamp out[b] instead of comp. This also seems to fix the problem, but I haven't tested to see if it introduces other problems.
The original bug report involves grayscale images and GIMP 2.8. The problem also affects RGB images and GIMP 2.9. This means anyone using Addition blend mode in conjunction with layer opacities is getting wrong results, even when the resulting blend really ought not produce out of gamut values. With respect to RGB or grayscale values that are out of gamut (greater than 1.0 or less than 0.00) Krita does allow generating out of gamut RGB values. There are good reasons to allow GIMP to do the same, though providing clipping options to the user would seem like a good idea. See https://bugzilla.gnome.org/show_bug.cgi?id=737925 The problem also affects attempts to add layers at 100% opacity, using masks to control the contributed amount of each layer to the sum. These wrong addition blend mode results seem to be a pretty serious limitation on using GIMP to composite layers together, as it seems likely that other layer blend modes might also be affected.
That makes total sense, why CLAMP an intermediate result when we can also CLAMP the final value (gracefully ignoring the fact that CLAMP is a bad idea in the first place, but if we CLAMP, we should at least CLAMP as late as possible). If I read all the text here correctly, your patch fixes both this bug, and the issue you brought up on the mailing list?
I think so, but I'd like to do some more testing. I'll add a comment when I'm finished going through some test images.
OK, no guarantees, but the patch seems like it does make addition blend mode work properly, fixing the bug and the issue I brought up on the mailing list. Maybe we should also move the CLAMP code in the other blend modes?
Thanks for looking into this, fixed in master: commit e089095631696eab5a329fc5e2a7a68f56f910e3 Author: Elle Stone <ellestone@ninedegreesbelow.com> Date: Tue Oct 13 12:18:14 2015 -0400 Bug 744265 - layer mode 'addition' makes wrong gray values Move CLAMP code in addition blend mode (CLAMP the result, not an intermediate value). app/operations/gimpoperationadditionmode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Not sure about the other modes, but clamping the final value instead of an intermediate result generally makes sense.
Not clamping at all in many of the modes might be desirable - when merging visible layers/flattening in 8 and 16bpc integer modes, the conversion from single precision float to integer would do the clamping for us anyways. Not having a clamp in the innerloop would get rid of two conditionals; which are among the things that tend to make loops slower. The clamps are probably remnants of mistakes/overlooked things from direct porting of the old 8bit GIMP code.
If we remove all that clamping, won't that change how some old XCF files look?
Not *much* if it uses to be more correct in 8bpc code, and a clamping of the final result rather than an intermediate pre-blended result. If that is the case it is the GEGLification that would have temporarily broken it.
Do you mean the final result in *one* op, like in Elle's patch, or the final result as in the projection?
Devil is in the details, I mean that if elles patch - which is obviously more correct - brought things more in line with how things used to be. Then the changes to old XCFs would be small by removing the clamps in the compositing ops completely. There might be some cases where highlights are blown out or shadows are brought below 0, that without clamping for each layer will now result in more details - rather than a solid quantized shelf a little distance from "255" or "0". Not clamping these intermediate results will permit doing things like manually implementing unsharp mask in the layer stack - with the 8bpc era clamping to avoid over/underflows that is not possible.
https://git.gnome.org/browse/gimp/diff/app/operations/gimpoperationburnmode.c?id=23f118632c76dc720489f68dba2e0b90f9ec1388 this hunk is not equivalent to the previous code. before it was inverting, clamping and blending (the inverse 1 - x) now it is blending, inverting and clamping so even when clamping is unnecessary the result could be different
Moving the inversion to be earlier, the clamps are still in place - and I think they should be removed, for the burn tool this should mean that it is possible to rescue blown highlights created when burning. These changes also highlight that it would be good to have more automatic result based regression testing in place for XCFs / ops, similar to what GEGL is doing. commit 8ca9bfc291496c6054bdaa8a9f2cfc883f66ab52 Author: Øyvind Kolås <pippin@gimp.org> Date: Thu Oct 15 13:52:20 2015 +0200 app: burn-mode, invert before blending
The output of burn is still wrong. The clamp is actually part of the color function (as opposed being there just to catch out of range values) and needs to go before the blend to produce the expected output. I'll attached a test case and it's expected outputs.
Created attachment 323231 [details] Test case for burn mode
Created attachment 323232 [details] Burn in Gimp 2.8, Gimp 2.9, and Krita
commit 2b7088f6e903b215f22040c954a3361821958eb8 Author: Daniel Sabo <DanielSabo@gmail.com> Date: Mon Mar 7 13:14:58 2016 -0800 Make Burn mode output match Gimp 2.8 ( partial revert of bug 744265 ) app/operations/gimpoperationburnmode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
*** Bug 762700 has been marked as a duplicate of this bug. ***