GNOME Bugzilla – Bug 673501
Issue with Overlay
Last modified: 2015-04-29 17:34:57 UTC
I found a bug with Overlay: http://i.imgur.com/qdesF.png - Image http://i.imgur.com/TYMPw.png - Image http://www.youtube.com/watch?v=_uO0HCyLsKg&feature=player_embedded - Video http://dl.dropbox.com/u/26887202/123/3dcoat/goat.psd - Test File As it was discussed in mailingList: - When "use GEGL" is selected, GIMP does the layer blending in linear space too, then you get similar results in both applications. Some blending modes like overlay look very different in linear and non-linear space. - 3dCoat is fully compatible with PHOTOSHOP. So, Overlay method works exactly as in photoshop, because it's a standard of CG industry. You already did this with GEGL too. But I cannot save Gegl image. :( I cannot merge layers with Gegl interpolation and I cannot save to PNG/JPG with Gegl interpolation. This is the main problem. - Also, the problem is only with Overlay Method. Multyply, Screen, Dodge, SoftLight, HardLight etc... works ok with Gegl and without Gegl. I showed it on the video. - Note: Overlay in Legacy mode works exactly like Soft Light, if that helps. - At present, I cannot use Overlay for my 3d production. This is the most usable method. I just want to know will you be able to fix it in Gimp 2.8? Overlay without Gegl should be like in Photoshop too.
What do you think is the actual bug here? Note that "Use GEGL" in 2.8 is only a "nice to have", we won't fix stuff there unless it's broken without GEGL too.
*** Bug 679427 has been marked as a duplicate of this bug. ***
Created attachment 228532 [details] fix for overLay mode of layers According to this papper: http://en.wikipedia.org/wiki/Blend_modes I fixed Overlay mode.
Hi guys! I fixed Overlay mode for gimp (non Gegl color management). According to this papper: http://en.wikipedia.org/wiki/Blend_modes Now it's compatible to photoshop and other software which use blend modes. I attached gimpoperatonslayermode.c . I hope you commit it.
Thanks, please attach a patch, not the complete file. Reopening so it's not hidden.
Created attachment 228551 [details] [review] the diff the diff
Ok, i did diff. I attached gimpoperationoverlaymode.diff The main formula is: for (b = RED; b < ALPHA; b++) { gfloat comp; if (in[b] < 0.5) { comp = 2.0 * in[b] * layer[b]; } else { comp = 1.0 - 2.0 * (1.0 - layer[b]) * (1.0 - in[b]); } // gfloat comp = in[b] * (in[b] + (2.0 * layer[b]) * (1.0 - in[b])); out[b] = comp * ratio + in[b] * (1.0 - ratio); }
Files for testing: http://dl.dropbox.com/u/26887202/blender/ee.psd http://dl.dropbox.com/u/26887202/blender/ee.png
Sorry, I removed old testing files. Here I uploaded them again: Example - https://dl.dropboxusercontent.com/u/26887202/blender/goat_test_overlay.png Source File - https://dl.dropboxusercontent.com/u/26887202/blender/goat_test_overlay.psd
Mitch, what do we do with this fix?
We wait until we have a complete plan that keeps old XCF files from looking differently (compat mode) while still having the right formulas for newly created files.
Is it something we want to do within the 2.10 development cycle? Would it be totally bonkers to 1) add a new enum for the new overlay mode, call it 'overlay', and use it by default; 2) rename the old overlay to 'overlay (obsolete)' and only show it when opening old files?
Overlay bugreport from an user with MyPaint/GIMP OpenRaster workflow: https://github.com/mypaint/mypaint/issues/300 If I understand the situation right, we need the mentioned new enum (or another solution) first, and then possibly fix the ORA plugin, too.
The broken GIMP "overlay" mode appears identical to GIMP's Soft Light mode, so ideally no UI changes would be needed to silently remap the old enum value to soft-light's upon loading any XCF file. GIMP would need to add a new true-overlay enum value and UI string, and accept a lack of backwards file compatibility when files using true-Overlay are saved by newer versions and loaded into old versions of the program. Goodness knows there are too many definitions of soft-light, but I hope GIMP uses the Cairo/PDF/W3C version. Who maintains the OpenRaster plugin, BTW? Michael? If there were a new enum value, then ideally the mapping between GIMP and the ORA world would be something like GIMP OpenRaster ------------------ --------------- overlay (broken) ↓ soft light ↔ svg:soft-light overlay (true) ↔ svg:overlay if (and only if) broken-gimp-overlay and gimp-soft-light actually use the same definition as w3c-soft-light of course. Alternatively, if there's inertia in GIMP core on this issue, please could the plugin maintainer investigate coding GIMP OpenRaster ------------------ --------------- overlay (broken) → svg:soft-light soft light ↔ svg:soft-light overlay (true) ↔ svg:overlay as an interim measure to allow artists to switch between apps usefully?
Created attachment 302486 [details] [review] Patch that should fix the problem This feels like a complete solution to the problem, please review and think about places I might have missed.
Pushed to master: commit bc4cf9918ff9e5a3cfbd2a0dd92f919224a8522f Author: Michael Natterer <mitch@gimp.org> Date: Mon Apr 27 17:48:00 2015 -0400 Bug 673501 - Issue with Overlay GIMP's OVERLAY mode was identical to SOFTLIGHT. This commit fixes the issue and introduces a NEW_OVERLAY mode and enum value. - change gimp:overlay-mode to be a real (svg-ish) overlay mode - when compositing, map OVERLAY to gimp:softlight-mode - when compisiting, map NEW_OVERLAY to gimp:overlay-mode - bump the XCF version when NEW_OVERLAY is used - map OVERLAY to SOFTLIGHT when loading and saving XCF - map OVERLAY to softlight in all PDB setters - map OVERLAY to softlight when deserializing a GimpContext - change all paint mode menus to show an entry for NEW_OVERLAY instead of OVERLAY - change PSP, PSD and OpenRaster to use NEW_OVERLAY These changes should (redundantly) make sure that no OVERLAY enum value is used in the core any longer because it gets mapped to SOFTLIGHT at all entry points, with the downside of introducing a setter/getter asymmetry when OVERLAY was set in a PDB api. app/actions/context-commands.c | 2 +- app/actions/layers-commands.c | 2 +- app/core/core-enums.c | 4 +++- app/core/core-enums.h | 3 ++- app/core/gimpcontext.c | 26 ++++++++++++++++++++++++++ app/core/gimpimage.c | 6 ++++++ app/gegl/gimp-gegl-nodes.c | 3 ++- app/operations/gimplayermodefunctions.c | 3 ++- app/operations/gimpoperationoverlaymode.c | 7 ++++++- app/operations/gimpoperationsoftlightmode.c | 16 ++++++++++++++-- app/pdb/brush-select-cmds.c | 6 ++++++ app/pdb/brushes-cmds.c | 3 +++ app/pdb/context-cmds.c | 3 +++ app/pdb/edit-cmds.c | 9 +++++++++ app/pdb/layer-cmds.c | 6 ++++++ app/widgets/gimpwidgets-constructors.c | 2 +- app/xcf/xcf-load.c | 4 ++++ app/xcf/xcf-save.c | 3 +++ app/xcf/xcf.c | 3 ++- devel-docs/libgimp/tmpl/gimpenums.sgml | 1 + libgimp/gimpenums.h | 3 ++- plug-ins/common/file-psp.c | 2 +- plug-ins/file-psd/psd-save.c | 3 ++- plug-ins/file-psd/psd-util.c | 18 +++--------------- plug-ins/pygimp/gimpenums-types.defs | 1 + plug-ins/pygimp/plug-ins/file-openraster.py | 2 +- tools/pdbgen/enums.pl | 6 ++++-- tools/pdbgen/pdb/brush_select.pdb | 6 ++++++ tools/pdbgen/pdb/brushes.pdb | 3 +++ tools/pdbgen/pdb/context.pdb | 3 +++ tools/pdbgen/pdb/edit.pdb | 9 +++++++++ tools/pdbgen/pdb/layer.pdb | 6 ++++++ 32 files changed, 142 insertions(+), 32 deletions(-)