Looks like we should use L*, C*, and h° to stay consistent (in
particular Lab L* and LCH L* are the same value), and also to allow for
future implementation of variants of LCH.
Value "h°" was the hardest to choose since we sometimes see just "h",
sometimes with a star, and other times with a degree. Even reference
documents display the 3 versions in the same documents! I just went with
a 2-letter version with degree, as seen on Wikipedia, and to align
better with other 2-letter LCh values. That's pretty arbitrary and can
be changed if another shortened name is considered better.
Elle Stone says (cf. bug 791484, comment 9):
> there are several variants of "Lab" out there, with the most commonly
> used (and the version GIMP currently uses) being the 1976 version,
> which uses asterisks to differentiate it from the earlier "Hunter"
> version. So yes, asterisks are technically correct.
Better use the most conventional naming. And as a side effect, it makes
differentiating Lab a* and Alpha shortened names more obvious, while not
making them that much bigger (2 characters instead of one for "a*").
To mark them as different strings with a context, otherwise "B" for Blue
and "B" for Lab b* cannot be translated separately (for instance).
See commit 7ac7b9519f and previous commit.
These labels were shortened but it's difficult for translators to know
what they are, especially when same shortened labels are common to
different concepts.
See commit 7ac7b9519f.
After discussing with Mitch and understanding better the X bitmap/pixmap
history, I make the warning more specific to X bitmap cursors only (not
pixmap).
Also I can see our code always exports RGBA data, so I am not quite sure
if this warning even makes sense since X bitmaps are bicolor maps. On
the other hand, Mitch tells me that "these days gdk turns pixbufs into
bitmaps if the x server doesn't support rgba cursors", so maybe that can
still be of use to warn cursor designers for max compatibility.
Still that's pretty old compatibility stuff, so let's replace "may" by
"might".
Leading 0s have no special value, we use base 10 anyway. Removing
leading 0s allows to not trigger the 8-digit test, hence modify a valid
cursor size unecessarily.
We were basing our max export size on a macro value defined in
libXCursor code: MAX_BITMAP_CURSOR_SIZE. This macro is still defined in
libXCursor and still has the same value (64), yet it is unsure how far
or even where this is enforced since it seems we can get at least 96px
cursors in GNOME/X11.
As a consequence, this commit:
- still warns when cursor size is over this value, with more explicit
text, yet does not change the cursor size anymore! So it is now
possible to export bigger cursors, but you still get a warning.
- only changes the cursor size for the existing more-than-8-digits test
and I add a warning when it does so (we should never modify an image
silently!).
- adds the size 96 as not triggering the warning about GNOME Settings
since it definitely looks like this size is valid there (according to
my own empirical tests). Also since 96 is higher than the libXCursor
current MAX macro value, this really raises the question to where this
max is enforced and whether we should not just drop the first warning.
Note that it breaks a bit the string freeze since I modify one string
and adds one. Sorry for this!
... removed by commit 0f9da165e0, and
improved by this commit.
Our foo-light modes aren't really prepared to handle out-of-range
input. Make sure that in-range input doesn't result in out-of-
range output.
Looks like ender's name can't be used verbatim in the encoding used
for the Polish translation. Use his name as previously appeared in
the Polish translation.
Add a safe_div() function to gimpoperationlayermode-blend.c, and
use it in the relevant blend funcs, instead of plain division.
This function clamps the quotient to some reasonable range, to
avoid infinities, and maps epsilon/... to 0, to avoid NaN. The
latter part results in similar qualitative results to the
corresponding legacy modes, when calculating 0/0.
After commit f51acf3bfb the python console no longer
initialized gimpui, because it is no longer part of module
initialization.
If the plug-in is run noninteractively and it imports
gimpui explicitely it is now necessary to call gimp_ui_init ()
at the right time
Oh blasphemy! The Wilber logo in the toolbox can now be disabled
directly via the Preferences dialog (on the Toolbox page).
The logo is staying enabled by default though. Long live Wilber!
...and present linear RGB Histograms
This is step one: implement the feature at all (without new defaults
or proper GUI, cough).
Add boolean "linear" properties to GimpOperationPointFilter,
GimpCurvesConfig and GimpLevelsConfig.
In the filter, simply set the input/output formats to linear in
prepare().
In the curves and levels tools, add "Linear" toggles from hell,
like in the histogram dockable, and make sure things work right
wrt changing and resetting the property, switching from levels
to curves, and picking colors.
The result currently changes when switching a non-nop curves/levels
between perceptual and linear, because adjusting the parameters
between the spaces is not implemented yet.
