Hi Bill, here it's working perfect. If you are running control-client without a running magnifier, make sure that the magnifier started by bonobo is one that support these methods. Try the following:

#1: checkout gnome-mag from cvs and compile it
#2: enter in the magnifier folder and run ./magnifier -vmz 2
#3: enter in the test folder and run ./control-client C 0.5 0.5 5.0

If this also fail, please report. Something very wrong is happening.

OK, this was a versioning problem, fortunately.

However, the results seem odd to me; the 'contrast' values don't really seem to change contrast, but instead they seem to multiply the R,G,B values.  That's not true contrast, as it also makes the display darker/lighter in the process.  For real contrast control I would expect

R_out = (R_in - R_mid)*contrast_multiplier

instead of

R_out = R_in * contrast_multiplier.

What means R_mid for you?

R_mid = "middle" value of Red, i.e. midway between "max red value possible in visual" and "R==0".  In a 24-bit RGB, R_mid would be 127...

(In reply to comment #2)
> OK, this was a versioning problem, fortunately.
> 
> However, the results seem odd to me; the 'contrast' values don't really seem to
> change contrast, but instead they seem to multiply the R,G,B values.  That's
> not true contrast, as it also makes the display darker/lighter in the process. 
> For real contrast control I would expect

I think that the two methos below multiply R,G,B values and the two makes the display darker/lighter in the process, since change contrast has influence in darkeness and lighteness. You can think in histogram equalization to illustrate it, since if a image is so dark or so bright you can equalize it to improve it's contrast and make it not so dark and not so bright.

> 
> R_out = (R_in - R_mid)*contrast_multiplier

This appear to do the same thing as the below, since what (R_in - R_mid) does is shift the histogram to the left and then multiply it by a contrast factor.

> 
> instead of
> 
> R_out = R_in * contrast_multiplier.

This, instead only multiply the histogram by a contrast factor. I implemented this way, because I think that is simplest to think in percentage of a color. Think in the following use case:

#1: Oh, my image is so much red
#2: I want only 80% of the current red

So the contrast_multiplier is setted to 0.8 and the red contrast is reduced in 20%. How this interface is represented to the user is client decision.

I don't think this is what is usually understood by contrast.  And without a corresponding "brightness" parameter, I don't think this meets a user need.

Thanks for the comments Bill. I'm trying to clarify it with gimp developers and what I could percept is that contrast isn't an easy thing to define.

Hi, this was a message that I received from one gimp developer:

"We have had some difficulties with the implementation of this
ourselves.  You might be interested in looking at these bug reports:

Bug 89022 – Brightness & contrast could be improved:
http://bugzilla.gnome.org/show_bug.cgi?id=89022

Bug 332068 – Contrast tool gives unexpected results:
http://bugzilla.gnome.org/show_bug.cgi?id=332068

Bug 337055 – Brighten/darken should be more realistic:
http://bugzilla.gnome.org/show_bug.cgi?id=337055"

The method that implement contrast manipulation in gimp also uses a brightness parameter that we could incorporate in the interface.

The Bug 332068 has the implementation used in the gimp code. That code is not consensus for all the developers, but this make the behavior consistent with the standard contrast formula.

I have to study a little more to understand better the issues discussed in that thread, since I'm not an expert in maths and color space transformations.

Hi Bill, the constrast manipulation formula that you cited is right. I'm very ashamed for make idiot comments about it, sorry for this.

The brightness manipulation is simpler, since it's only involves addition. I will correct this as soon as possible.

Created attachment 77084 [details] [review]
patch the way contrast is applied

This patch change how contrast is applied, but in a different manner than the comment made by Bill.

After implement the way that Bill spoken I percept that the contrast change was not linear, making the colors near the edges being more affected by the multiplication.

In this patch I make the contrast be additive and subtractive. setContrast can receive values between the range -1 and 1, where -1 means reduce the contrast by 100% and 1 increasing the contrast by 100%.

The zoom_region_process_pixbuf is the function where the contrast is manipulated. This manipulation is done by multiplying the setContrast input by 127, obtaining this way a value in the range -127 and 127 and this value is subtracted from the pixel if the pixel value is less or equal a 127 and clamped between 0 and 127 or added to the pixel if the pixel value is greater then 127 and clamped between 127 and 255. I think that look at the patch is more straightforward then put this on words.

Created attachment 77136 [details] [review]
correct some details of the last patch and generalize some aspects antecipating the brightness add

Fixed in the development version. The fix will be available in the next major release. Thank you for your bug report.