I was googling in search of some filter for Gimp being able to fill the gaps in the histogram which are created when using Colors>Levels adjustments.
I didn't find one (maybe, there is...).
But surfing, I encountered a link which advertises this capability in Power Retouche filters
see PR histogram repair.
Does anybody know whether there is something similar for Gimp?
btw, PR plug-ins are not free...

Mathematically you can't.... Each color is represented by a set of 256 values. All the color adjustments (levels, brightness/contrast, saturation, curves...) just map the 256 possible input values to some other values. But there is a rather strong constraint: unless you want special effects (solarization) the possible output values should have the same order as those of the input: if in the input V1 is higher than V2, then in the output the corrected V1 should be higher than the corrected V2 (in the Curves tool this means the curve never has a top-left->bottom-right slope). And this implies means that you cannot use the 256 possible output values(*), you will always end up with less values. In 16-bit processing (on a 16-bit image) this also happens but is much less visible because the gaps are much lire likely to be below our perception (and fewer pixels are impacted). And of course, if you cumulate color corrections the problem worsens...

But can it be "corrected"? The only thing you can do is locate the gaps, locate pixels with values around the gaps, and randomly alter these values so that some pixels get a value in the gap. So, your histogram looks better, but is the image better?

Also, do this quick test: in the page your refer to, get the two 8-bit pictures of the guy, before and after histogram fixing. Load them in Gimp. Check their histograms. Gaps? Peaks? None whatsoever in both pictures... Strange? Not really. When you scale down, the pixel interpolation generates intermediate values and this evens out the histogram.

Personally, I don't use Gimp for color corrections, I use 16-bit capable software and when possible I work from the raw photo (theoretically 14-bit, on practice more like 10-12 but still better than 8 for this). And if I have to start with an 8-bit image (JPEG) I try to do everything in one single correction.

(*) assume the middle of the range (127) is mapped to something bigger (150). In the low range, values 0-127 in the input get all mapped to values in 0-150 (there will be 23 unused values). In the high range, values 128->255 (128 values) are mapped over output values 151-255 (105 values) so some of the input values end up mapped to the same output value. Hence you create gaps at one end, and over-used values at the other. This is the origin of the "haircomb histogram".

Have you tried using GIMP-2.9? I haven't but it may be a better result as it handles more than 8 bit.

@Ofnuts
thanks for your detailed explanations. Now come my "stupid" questions: (I'm not a mathematician, so many of my questions could be "stupid"):
- assume the levels are adjusted such that they are just reduced 1:2 (for simplicity), so resulting values between 0 and 127 become values between 0 and 254, with "gaps" inbetween (0-2-4-6-....with values; 1-3-5-7...with no values); now:
1-how are the values "modified"?
2-why is it mathematically impossible to generate values inbetween? applying some kind of a smoothing mechanism like (for instance): there are 50 original pixels with values of 1 which should become values of 2, couldn't be a solution to keep 25 pixels at 1 and moving 25 pixels to 2? (on a specific request of the user, of course, because the resulting image looks a bit different )

@Rod
thanks, not yet, I didn't try it; but what you are saying is that in 2.9 even images 8-bits based are processed as if they were 16-bits based?

I do not know. As i stated i never used it before.

it seems that version 2.9 is -at the moment at least- only for 64-bits systems

good news by googling:
found a FREE PS plugin compatible with Gimp-PSPI which performs what I was looking for:
ThePluginSite - Photo Freebies - Histo Fix:
the description says: "It fixes a chopped histogram by interpolating lost image information. You can regain 1/2 bit, 1 bit or 2 bit of image information. Works only on 8bit images, because 16bit images do not have this problem."
Tested, no bad effects on the image, gaps filled

1) I don't understand the question

2) Because information is lost... the plugin just adds noise... Assume your image initially had better precision (12-14bits), so you can add some decimal places to the 1-255 values. The values that are at 120 in the 8-bit image would range from 119.5 to 120.5 in the original image. Now you apply some processing that stretches the values, so that 119 is converted to 128, 120 to 130 and 121 to 132. The gaps will be filled by taking some pixels with value 130 and assigning them values 129 or 131. But value 130 comes value 120 which itself represents the 119.5-120.5 range in the original image. So you can fill the gap at 131 with values that could originally be 120.5 (fine) but also with values that were 119.5 and would be much more accurately represented by 129 (ouch). And, of course, vice-versa.

To answer for Rod, in 2.9 when you process 8-bit images in 16-bit, you also initially start with 256 distinct values, but the problem is much less, because even if you create gaps, you don't lose colors. To use the example in the footnote my first post, in the high range your image starts with 128 distinct values, but you can map them anywhere in 26880 values instead of 105, so they remain distinct...

Advertisement lies... you don't regain information.

OK, you filled the gaps, so what?

Photo Freebies: They are actually, not bad, little .8bf PS filters, once you have jumped through hoops giving a throw-away email addy to download them.

Even work with my linux pspi - and not many do these days.

I can see Ofnuts argument about regaining data that is not there in the first place.

but

Why not try delaboratory for some preprocessing, the compiled win versions are on Partha's site or here

http://code.google.com/p/delaboratory/

Compiles easily in linux. Worth a try.

@Ofnuts
I understand: what is lost is lost. And certainly it's better not to have lost too much.
Simply, I don't like the gaps...
And -as per your example- I don't feel too much uncomfortable with a 131 value which can come from a value half-a-bit lower or half-a-bit higher
Thanks again for your help
(btw, you answered also my first question: how the values are moved...)

Would Gaussian blur with radius of 1 can help? Random mapping gives you noise, as it is not influenced by it's neighbor pixels.

@oky
I didn't see any noise in my trials with histo fix;
maybe that plug-in is more clever than we suspect and takes into account not only the "value" in general but also each single R,G,B value, so to interpolate between similar tones, not "randomly"
I don't know...
Yes, Gaussian blur can do its job, but it's certainly a ...blurring mechanism; I don't think that -for example- when upscaling an image the "new" pixels are creating by a simple blurring mechanism.
Again, I'm not so expert to understand the underlying mechanisms, I just look at the results.