RFSH
commented
3 years ago We had a discussion about this and the following are the result of our discussion:
We could thing of this as two separate issues that we can gradually solve:
-
Fix the contrast control so the default is some value in between. And then user can increase or decrease it (the same as brightness.) We could replicate the same contrast control as this page.
-
The first issue will just solve the confusing UI but won't solve the underlying issue that our contrast and brightness controls are not what knowledgable users would expect. Contrast and brightness should not be a simple gain or offset function, and should work together.
The following is a message copied from @karlcz
I think this is the easiest way to understand it, if you can assume real number arithmetic:
- the existing filter functions you described are really
gain(v, g) ==> v * gandoffset(v, o) ==> v + o - I think it is easier to think in terms of normalized ranges, i.e. pretend the image intensity range is [0, 1] rather than 8-bit [0, 255], 16-bit [0,65535] etc.
- you want to define a midpoint which is naively 0.5 for [0, 1] range if we ignore gamma and other non-linear perceptual models
- a pure contrast function shifts back and forth by the midpoint amount when applying gain:
contrast(v, c) ==> offset(gain(offset(v, -0.5), c)), 0.5)with the above, you might define a system like this for normalized [0, 1] inputs:- a contrast control w/ useful control range [0, 10] and default 1 no change
- a brightness control w/ useful range [-1, 1] and default 0 for no change
- a combined filter
output(v, c, b) ==> offset(constrast(v, c), b)==> offset( offset( gain( offset(v, -0.5), c), 0.5), b)==> offset( gain( offset(v, -0.5), c), 0.5 + b)I leave off the implicit clamping that maps output values < 0 to 0 and values > 1 to 1.
if I am not confusing myself, the above works for 8-bit w/o normalization just be redefining the brightness range to [-255, 255] and the midpoint to 128. the contrast range stays [0, 10]: output(v, c, b) ==> offset( gain( offset( v, -128), c), 128 + b) i.e. output = (v - 128) * c + 128 + b
of course, if the working arithmetic has sufficient range you can algebraically reduce the formulas further...
output(v, c, b) ==> offset( gain(v, c), 128 * c + 128 + b)this is relevant for using image-based operators, since only the two func calls operate on the array of pixels and the offset 128 * c + 128 + b only has to be computed once as a constant parameter to the function.
Given this, we might also want to consider using CamanJS instead of the filters that we're using now. I found this library in the demo page of openseadragonFiltering library that we're using. Their contrast and brightness controls are more aligned with what the users would expect from these type of controls. I should investigate this as a solution first since it would solve both of our issues and seems simple enough.
Up until now, we were mainly focused on the hue control. Now, we should spend some time and figure out if the current controls that we have make sense or not.
These are the other controls that we have and their definition based on what I gathered (which might not be accurate) and how they actually behave in the openseadragonFiltering plugin that we're using:
Contrast: applies a scale factor (gain) to the red, green, and blue signals. It affects the luminance (proportional to intensity) that is reproduced for a full white input signal. Code-wise, it will multiply the RGB color value of each pixel with the given factor. Range is from 0 to infinity, although sane values are from 0 to 4 or 5. Values between 0 and 1 will lessen the contrast while values greater than 1 will increase it.
Brightness: shifts the intensity of the pixels by the specified adjustment (between -255 and 255) by adding the given number to the RGB color value of each pixel.
Gamma: Please refer to this wiki page for more info.
I'm not entirely sure what the gamma control does, but contrast and brightness are some of the widely used settings in any displays. Based on what I gathered both are usually presented in a 0-100 scale where 50 is the default (original color) value. But that's not how our controls work.
For contrast we're showing a 0 to 100 scale with steps of 5, where the value is the used scale factor without any change. So it's always increasing the contrast by a lot. The other issue without current control is the default value. Just to make it work, we've set the default to 100, and using 100 will just ignore the filter and show the default image.
For brightness, we're showing a -255 to 255 scale with steps of 5. Although it's showing the right thing to the users, but I feel like the raw values doesn't make much sense to users.
I suggest changing both controls to 0 to 100 scale with steps of 5. Then for each one OSD viewer has to properly match the percentage value to a proper contrast or brightness factor.