GNOME Bugzilla – Bug 777836
auto stretch-contrast sometimes produces unexpected and unuseable results
Last modified: 2017-05-06 12:43:40 UTC
Created attachment 344426 [details] image turns to solid gray after stretch-contrast Sometimes auto stretch-contrast in GIMP produces odd results, such as the entire image turning a solid color. The attached tiff turns to solid gray.
(In reply to Elle Stone from comment #0) > Created attachment 344426 [details] > image turns to solid gray after stretch-contrast > > Sometimes auto stretch-contrast in GIMP produces odd results, such as the > entire image turning a solid color. The attached tiff turns to solid gray. The current implementation does not take care of pixels with values outside the [0, 1] range (the image attached has several ones, for example in 102,144 x,y position). An easy fix would be to only use pixels with values in the [0,1] range to find the min/max values (https://git.gnome.org/browse/gegl/tree/operations/common/stretch-contrast.c#n38) and apply the 'stretching' only for pixels in the [0,1] range, keeping oog/hdr pixels unchanged.
The code does not special for values in the 0.0-1.0 range either. So in a sense I think it is currently behaving correctly. With continued manual one-shot being the aim, perhaps it couldbe slightly improved by automatically discarding the 0.1% highest and lowest values. Side note: Various forms of auto-stretch contrast actions would be nice to have implemented in the levels dialog. Similar to the color picker for white-point.
Created attachment 351252 [details] There is an extremely oog pixel in the image.
(In reply to Thomas Manni from comment #1) > (In reply to Elle Stone from comment #0) > > Created attachment 344426 [details] > > image turns to solid gray after stretch-contrast > > > > Sometimes auto stretch-contrast in GIMP produces odd results, such as the > > entire image turning a solid color. The attached tiff turns to solid gray. > > The current implementation does not take care of pixels with values outside > the [0, 1] range (the image attached has several ones, for example in > 102,144 x,y position). My apologies, I didn't realize there were "hot" out of range channel values. If we already had an extended histogram then I could have checked for these extreme outliers and removed them using some sort of impulse/hot pixel/heal/clone algorithm. > An easy fix would be to only use pixels with values in the [0,1] range to > find the min/max values > (https://git.gnome.org/browse/gegl/tree/operations/common/stretch-contrast. > c#n38) and apply the 'stretching' only for pixels in the [0,1] range, > keeping oog/hdr pixels unchanged. Well, the current implementation does Normalize the image RGB range, which is exactly what I use auto stretch-contrast for. If auto stretch-contrast is modified to no longer Normalize the image, then we would need a new operation for normalizing the image.
(In reply to Øyvind Kolås from comment #2) > The code does not special for values in the 0.0-1.0 range either. So in a > sense I think it is currently behaving correctly. Yes, it's working correctly. Normalizing an image or a layer mask is a very useful step in advanced workflows - see Use note 4 in https://www.gimp.org/tutorials/Tone_Mapping_Using_GIMP_Levels/ . For my editing puposes the current implementation is correct. There is no bug. My apologies, I didn't realize there were "hot" pixels in the image, or I would have dealt with them before doing any further processing. Blinking OOR indicators would be nice, and/or an extended histogram. Sometimes I've ended up with solid gray layer masks after auto stretch-contrast, and just didn't stop to think "oh, there might be extreme outliers". So when this image produced gray after auto stretch-contrast, I filed this bug report. But now it's obvious the problem is "user error", I simply didn't think about extreme outliers being a possibility. > With continued manual > one-shot being the aim, perhaps it couldbe slightly improved by > automatically discarding the 0.1% highest and lowest values. I don't know what "manual one-shot" means. But PhotoShop had an over-rideable auto-discard and it was very annoying to have to continually override/reset back to the complete display range. Also, in the current case, "discarding" needs to be done by replacing the affected "outlier" pixels. > Side note: Various forms of auto-stretch contrast actions would be nice to > have implemented in the levels dialog. Similar to the color picker for > white-point. Whatever new code might be added whereever in GIMP, GIMP needs the option to Normalize to the display range. Also it would be nice to have warnings for out of range channel values (on masks, too), which sometimes come right from the raw processor, and also can easily be generated using various GIMP algorithms and blend modes. Sometimes OOR values are useful and should be kept/normalized as the user wants. And sometimes they need to be dealt with either immediately (as in "hot" outliers) or else later in the workflow, for example to preserve hue during editing, as discussed in this tutorial: http://ninedegreesbelow.com/photography/high-bit-depth-gimp-tutorial-edit-tonality-color-separately.html .