brightness-contrast unintuitive

[Harry79]

ImageMagick version

7.0.10-24

Operating system

Windows

Operating system, version and so on

11

Description

ImageMagick has the brightness-contrast command line option which is quite unintuitive for non-obvious reasons.

Had to look up the implementation to find how it actually is producing the results it outputs.

MagickCore/enhance.c in BrightnessContrastImage:

slope=tan((double) (MagickPI*(alpha/100.0+1.0)/4.0));

I would propose the following more intuitive definition by attaching it to the histogram:

• +50 would have slope 2 so all input values would be mapped to half of the output value range.
• -50 would do the opposite, half the input values would be mapped to the full output value range.

more formally:

slope = contrast/100+1 if contrast < 0
slope = 100/(100-contrast) else

Steps to Reproduce

magick convert test.ppm -brightness-contrast 6x-20 out.ppm

Images

No response

[urban-warrior]

Both algorithms return similar values 6x-20 returns 0.8 for your algorithm, for the existing, 0.727. For 20x-80, we get 0.2 vs. 0.16. For 30x-90, 0.1 vs. 0.08. Let's get @fmw42 to comment, our resident image processing expert.

[fmw42]

The current algorithm is designed to map contrast=-100 (actually -99.9) to slope=0, contrast=0 to slope=1 and contact=100 (actually 99.5) to slope 100 (or 99.9) to slope 500. The slope was designed to pivot about mid-gray when the brightness=0 and contrast adjusted. So the intercept changes rather than having the intercept at 0,0.

pi=`echo "scale=10; 4*a(1)" | bc -l`
arg=`echo "scale=5; $pi * ((($con * $con) / 20000) + (3 * $con / 200)) / 4" | bc`
slope=`echo "scale=3; 1 + (s($arg) / c($arg))" | bc -l`
echo "con=$con; slope=$slope"

con=-99.9; slope=0
con=0; slope=1.000
con=99.5; slope=100.900
con=99.9; slope=501.000

Please show your expression for computing the intercept. One needs to define both the slope and intercept and how they relate to brightness and contrast.

[Harry79]

I did some calculations, found some non-working solutions, and after some math ended up where you already have been.

intercept=brightness/100.0+((100-brightness)/200.0)*(1.0-slope);

So, your current intercept calculation is the best I could find. In essence it is pivoting about the gray value of the defined brightness. This maps the input brightness range values to meaningful and distinct transformations.

[fmw42]

Perhaps you should write a script and show some results or show the transformation (output vs input) as you change brightness and contrast. See http://www.fmwconcepts.com/imagemagick/bcimage/index.php which was my prototype for -brightness-contrast.

[fmw42]

When I get a chance, I will try to script them both to see the difference in the effects. Sorry, but I am busy with a paying contract right now and cannot spend any time on this at the moment.

[fmw42]

I have programmed this alternate (as bcimagex) and find the following comparison to my original script (bcimage)

Brightness Comparison:

bcimage -g 50,0 lena.png x.png
slope=1.000
intcp=.500
Break Points = 0,50 50,100 100,100

bcimagex -g 50,0 lena.png x.png
slope=1
intcp=0.5
Break Points = 0,50 50,100 100,100

bcimage -g 100,0 lena.png x.png
slope=1.000
intcp=1.000
Break Points = 0,100 0,100 100,100

bcimagex -g 100,0 lena.png x.png
slope=1
intcp=1
Break Points = 0,100 0,100 100,100

bcimage -g 25,0 lena.png x.png
slope=1.000
intcp=.250
Break Points = 0,25 75,100 100,100

bcimagex -g 25,0 lena.png x.png
slope=1
intcp=0.25
Break Points = 0,25 75,100 100,100

Contrast Comparison:

bcimagex -g 0,50 lena.png x.png
slope=2
intcp=-0.5
Break Points = 0,0 25,0 75,100 100,100

bcimage -g 0,50 lena.png x.png
slope=1.820
intcp=-.410
Break Points = 0,0 22,0 77,100 100,100

So at bri=0 and con=+50, the two produce very similar break points

bcimagex -g 0,-50 lena.png x.png
slope=0.5
intcp=0.25
Break Points = 0,25 100,75

bcimage -g 0,-50 lena.png x.png
slope=.466
intcp=.267
Break Points = 0,26 100,73

So at bri=0 and con=-50, the two produce very similar break points

bcimagex -g 0,100 lena.png x.png
slope=1e+14
intcp=-5e+13
(standard_in) 1: parse error
expr: syntax error

bcimage -g 0,100 lena.png x.png
slope=501.000
intcp=-250.000
Break Points = 0,0 49,0 50,100 100,100

At bri=0 and con=100, the new algorithm blows up with huge values for slope and intercept and cannot compute the break points, whereas my original algorithm was designed to stay finite up to +-100

However, if back off by 1 to con=99, both algorithms produce finite results.

bcimagex -g 0,99 lena.png x.png
slope=100
intcp=-49.5
Break Points = 0,0 49,0 50,100 100,100

bcimage -g 0,99 lena.png x.png
slope=50.950
intcp=-24.975
Break Points = 0,0 49,0 50,100 100,100

At bri=0 and con=99, the new algorithm slope is about twice my original algorithm. So the new algorithm slope rises faster above con=50. But a slope of 100 and slope of 50 are both very vertical. And the break points are identical.

So since brightness is the same in both algorithms and for contrast at con=+-50 produces very similar results (which was your main requirement), I am not inclined to recommend any change to the current -brightness-contrast.

[fmw42]

The new proposed algorithm does have some nice features. Brightness values produce the same results and Contrast values produce similar results. So I am not opposed to this change. However, I leave it up to the IM developers if they have time and interest in changing the code and if it is not going to cause issues with backward compatibity.

[dlemstra]

Maybe we could introduce this under a flag?

[fmw42]

Dirk, do you mean a -define?

[dlemstra]

Yeah that is what I meant. Not sure if that is a good idea or how we should call that define.

[fmw42]

Both algorithms produce very similar results. I am not sure it is worth having options for both. I think we should just decide to either switch or keep the old one.

[dlemstra]

Maybe you and @urban-warrior can talk about this and decide what to do?

[urban-warrior]

Give us a few days, we'll export a patch soon.

[fmw42]

Do you need me to send you some equations or my script for the new method?

[urban-warrior]

Per the usual @fmw42, forward the equations and use cases, we'll implement, and you will review and approve before we release the change.