RSS/Atom feed Twitter
Site is read-only, email is disabled
  1. Chat
  2. Useful links
  3. Polls

Featured content

Fwd: GIMP Levels operation fix

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

2 of 2 messages available
Toggle history

Please log in to manage your subscriptions.
Fwd: GIMP Levels operation fix David Gowers 05 Feb 08:20
  Fwd: GIMP Levels operation fix Sven Neumann 05 Feb 08:40
David Gowers
2008-02-05 08:20:42 UTC (almost 17 years ago)

Fwd: GIMP Levels operation fix

Hi, I sent this simple fix to mitch, however I'm too impatient to wait for mitch to check his inbox,
So I'm now passing it onto this mailing list. Basically it fixes over/underflow in the Levels op; with the attached image, the bug gives the appearance of a triangle wave repeating gradient, instead of a readjusted single gradient for the channel being adjusted.

---------- Forwarded message ---------- From: David Gowers
Date: Jan 31, 2008 5:45 PM
Subject: GIMP Levels operation
To: Michael Natterer

I've just found a bug in the Levels op -- if the selected low/hi input endpoints of a channel are
(low -> more than the lowest non-empty histogram entry; or high ->less than the highest non-empty histogram entry for the channel) then underflow/overflow happens.
Adjusting any of the input range sliders to fall into that range will show this behaviour up.
Using the channels dialog to disable all but one channel also helps. I would say you have simply forgotten to clip the input values before mapping them to output values. *pokes around* indeed, I've attached a very short patch that performs correct clipping. With this patch, GEGL levels op matches old levels behaviour in all tests I could contrive.

Sven Neumann
2008-02-05 08:40:17 UTC (almost 17 years ago)

Fwd: GIMP Levels operation fix

Hi,

On Tue, 2008-02-05 at 17:50 +1030, David Gowers wrote:

Basically it fixes over/underflow in the Levels op;

Your approach is not the right way to fix this. There is absolutely nothing wrong with under- and overflows if we are using GEGL. The problem you are seeing is that some of the float->8bit conversions in babl are not handling colors outside the 0..1 range properly. You can fix this by running GIMP with the environment variable BABL_ERROR set to 0.0. This will select correct, but slower, conversion routines and you will notice that this fixes the error.

We need to fix this in babl. Conversions that don't deal correctly with values outside the [0.0;1.0] inverval need to be assigned a large error so that they are not being selected.

Sven