GNOME Bugzilla – Bug 470499
when 16 bits do come, other enhancements needed (esp. no. of digits)
Last modified: 2007-09-11 10:54:23 UTC
No, this isn't just yet another bug #74224 dupe. ;) It occurred to me that, where currently most controls that take a value as a percentage to be (usually) multiplied by an 8-bit value only allow three significant digits (one after the decimal point), and that's just fine, because that's almost four times the precision you get in 8 bits, that's going to change dramatically when people can start using 12, 16, or more bits per channel. Then, more places beyond a tenth of a percent would mean something. As a case in point, consider trying to adjust layer opacity so that three layers are equally represented in the merged image. 100%, 50%, and 33.3%... which will usually come out the same as 1/3 for 8 bits, but vary significantly at 16 bits. I would suggest that, at the same time GEGL (or other approach to more depth) is implemented, there might be a new option in the Interface branch of the Preferences tree. Ideal might be something like having a checkbox or radio button for something like "adjust the number of digits to suit the channel depth", which would automagically give you one place after the decimal when you're in 8 bit, two places after the decimal when in 12 bit, three places when in 16 bit, etc.; and then, if that option is not selected, a spinner to let you simply set a fixed number of places. Obviously, this would be simplest to implement if you could make a change to the GTK widgets themselves, but I doubt that's a practicable approach, so probably someone would have to make a list of all the dialogs and other places that use a control in such a context, and fix them one by one. That's why I think we (you?) should start planning ahead now, instead of waiting until 16 bits is a fait accompli. If, as I believe I read somewhere about more bits or GEGL, there's a possibility that floats will be another form of depth, I don't know how that would best be handled. Quick table of bit depths, significant digits (for values 10%-99.9...%), and decimal places after the point in a percentage (I hope Bugzilla preserves enough of the formatting): Bits Digits Places 8 3 1 12 4 2 16 5 3 24 8 6 32 10 8
One thing I forgot to add: If the "automagic" number of places works and is selected, extra (hidden) places should probably be retained, just in case someone does something odd like changing a picture from 16 bit to 8 bit back to 16 bit. For instance, combining with an above example, opacity might go from 33.333% to showing 33.3% (perhaps still calculating as 33.333%, perhaps as 33.3%; shouldn't make much difference), back to 33.333%. But if you then changed to 24 bit (if such a depth is enabled), you'd then see 33.333000%.
The idea behind working in higher bit depths is not that it gives you more precision. What you gain is less rounding errors. There is no advantage in providing the user more precision in the controls such as the opacity slider. The internals are already all handled by double values. If it turns out that we need to change a widget, then we will do that. There's no need to keep a bug report for this.
I think that this enhancement proposal made sense: in order to provide a better user experience, it would be nice if all widgets displaying information about things related to bit depth would use a variable number of significant digits depending on the bit depth of the image. Displaying too many significant digits while working on a 8 bits image would be almost as annoying as not having enough digits while working on higher bit depths. But I will leave this bug report closed anyway.