09-25-2023, 05:51 PM
I think clamping is hardcoded to TRUE when invoked via colors-levels gui.
That explains why attempting to see what it does is fraught.
Noted is that clamping is not provided in the color-levels gui interface in earlier gimp versions.
Also in other areas within the gimp source code are comments about using CLAMP to avoid error conditions created by other buggy parts of the code. I suspect it was an overzealous coder.
Analysis of the code shows that clamping must be hardcoded to TRUE.
What is the intent of the code?
A) The code is allowing a user to limit the range of intensities from INPUT low to INPUT high.
B) Gamma is then applied to that range: new=old ^ (1/gamma). This entails the INPUT range to be normalized onto the unit interval 0 to 1 where INPUT low maps to 0 and INPUT high maps to 1. Intensities below INPUT low are clamped to low and intensities greater than INPUT high are clamped to high.
C) Then the gamma adjusted intensities now represented as a number between 0 to 1 are made to represent intensities from OUTPUT low to OUTPUT high.
The first clamping (line 109) implies that clamp input is hardcoded to TRUE. Otherwise, by picking INPUT high very close to INPUT low, the computations (item B above) can be made arbitrary large. 0 is darkest and 1 is brightest. Greater than 1 has no interpretation in this context. Also, values below INPUT low become negative in the computation although there is some defensive code to avoid gamma adjusting a negative number. The only way the code makes sense is if clamp_input is TRUE. Lets put it this way........IF clamp_input is not hardcoded, there is some code somewhere else handling absurb conditions.
Having established that clamp_input hardcoded to TRUE, the second clamping (line 121 output_clamped) has no effect. The numbers already range 0 to 1.
That explains why attempting to see what it does is fraught.
Noted is that clamping is not provided in the color-levels gui interface in earlier gimp versions.
Also in other areas within the gimp source code are comments about using CLAMP to avoid error conditions created by other buggy parts of the code. I suspect it was an overzealous coder.
Analysis of the code shows that clamping must be hardcoded to TRUE.
Code:
static inline gdouble
gimp_operation_levels_map (gdouble value,
gdouble low_input,
gdouble high_input,
gboolean clamp_input,
gdouble inv_gamma,
gdouble low_output,
gdouble high_output,
gboolean clamp_output)
{
/* determine input intensity */
if (high_input != low_input)
value = (value - low_input) / (high_input - low_input);
else
value = (value - low_input);
if (clamp_input)
value = CLAMP (value, 0.0, 1.0);
if (inv_gamma != 1.0 && value > 0)
value = pow (value, inv_gamma);
/* determine the output intensity */
if (high_output >= low_output)
value = value * (high_output - low_output) + low_output;
else if (high_output < low_output)
value = low_output - value * (low_output - high_output);
if (clamp_output)
value = CLAMP (value, 0.0, 1.0);
return value;
}What is the intent of the code?
A) The code is allowing a user to limit the range of intensities from INPUT low to INPUT high.
B) Gamma is then applied to that range: new=old ^ (1/gamma). This entails the INPUT range to be normalized onto the unit interval 0 to 1 where INPUT low maps to 0 and INPUT high maps to 1. Intensities below INPUT low are clamped to low and intensities greater than INPUT high are clamped to high.
C) Then the gamma adjusted intensities now represented as a number between 0 to 1 are made to represent intensities from OUTPUT low to OUTPUT high.
The first clamping (line 109) implies that clamp input is hardcoded to TRUE. Otherwise, by picking INPUT high very close to INPUT low, the computations (item B above) can be made arbitrary large. 0 is darkest and 1 is brightest. Greater than 1 has no interpretation in this context. Also, values below INPUT low become negative in the computation although there is some defensive code to avoid gamma adjusting a negative number. The only way the code makes sense is if clamp_input is TRUE. Lets put it this way........IF clamp_input is not hardcoded, there is some code somewhere else handling absurb conditions.
Having established that clamp_input hardcoded to TRUE, the second clamping (line 121 output_clamped) has no effect. The numbers already range 0 to 1.