After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 776113 - when not color managed, negative values produce solarization instead of black
when not color managed, negative values produce solarization instead of black
Status: RESOLVED FIXED
Product: GEGL
Classification: Other
Component: babl
git master
Other Linux
: Normal normal
: ---
Assigned To: Default Gegl Component Owner
Default Gegl Component Owner
Depends on:
Blocks:
 
 
Reported: 2016-12-14 22:42 UTC by Øyvind Kolås (pippin)
Modified: 2016-12-15 11:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Øyvind Kolås (pippin) 2016-12-14 22:42:59 UTC 
When moving only the low/black input of levels on a 32bit floating point image what should end up as pitch black gets solarized to a gray color. If one chooses edit these settings as curves; the edited curve and result is close to expectations.
Comment 1 Øyvind Kolås (pippin) 2016-12-14 23:19:15 UTC 
It is GIMPs general display of negative values in floating point buffers that is amiss, this is just a reliable way of producing such values. When letting color management try to use the system profile (and presumably also if one sets a explicit profile). Negative values get correctly clamped to 0.0, black.
Comment 2 Øyvind Kolås (pippin) 2016-12-15 00:20:13 UTC 
it is the fast-float LUT based conversions that do this, removing that extension fixes the problem.
Comment 3 Øyvind Kolås (pippin) 2016-12-15 00:36:37 UTC 
commit a88612d501153b6d3511043506683b8b88a364c1
Author: Øyvind Kolås <pippin@gimp.org>
Date:   Thu Dec 15 01:34:53 2016 +0100

    extensions/fast-float: temporarily disable
    
    Disable this floating point LUT for now, it treats negative values as their
    positive counterparts, see bug #776113.
Comment 4 Øyvind Kolås (pippin) 2016-12-15 11:02:10 UTC 
Other fill-in fast paths have been added, closing the bug, since performance has returned to a similar level for 32f linear display in GIMP.