Usually, it is enough to reset the Exif.Image.Orientation and
Xmp.tiff.Orientation tags to neutralize the orientation of an image.
However, some cameras may use non-standard tags. In such cases, merely
setting the standard tags will make the metadata inconsistent. Hence,
it is better to use gexiv2_metadata_set_orientation because it will
take care of the non-standard tags.
Similar to the Photoshop mode of the same name. Assigns
either 0 or 1 to each of the channels, depending on whether the
sum of source and destination channel values is less than, or
greater than (or equals to), one, respectively.
This is equivalent to inverting the source, and using it to perform
per-pixel, per-channel threshold against the destination, which is
useful for various effects.
Largely based on a patch by Ell, with the enum type renamed and
various small changes. Adds another axis of configurability to the
existing layer mode madness, and is WIP too.
C++ won't allow us to use GimpLayerMode in the API where we used to
have GimpLayerModeEffects.
Move GimpLayerModeEffects to libgimpbase/gimpcompatenums.h so it's
not in the API any longer, and instead typedef and define stuff in
libgimp/gimptypes.h, and adapt the compat enum registering code
accordingly.
For operations needing to override default behavior sub-classes should still be
used.
This commit also enables pinligh, vividlight and linearlight blend mode modes
with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.
so the threshold can now be based on the GimpHistogramChannel enum.
Add a channel menu to the threshold dialog and a channel argument to
the PDB procedure (which is new in 2.10).
If I hadn't forgotten what the "RGB" channel is supposed to do I would
have implemented the RGB mode in GimpOperationThreshold correctly.
Right now I'm just guessing. Anyone?
They used to be 0..255, inherited from the old gimp_histogram() and
gimp_threshold() procedures. This commit deprecates these old
procedures and changes the ranges in the new gimp_drawable_histogram()
and gimp_drawable_threshold() to double with a 0.0..1.0 range.
Add property "color-tag" of type enum GimpColorTag to GimpItem so all
layers, channels and paths can be tagged with a color.
For interoperability, use the color list from Krita which is a
superset of Photoshop's colors.
Features a "Color Tag" submenu in the layers, channels and paths
menus, a row of color radio buttons in the properties dialogs,
undo and PDB API.
As a side effect, some common code is now factores out into
items-actions.[ch] and items-commands.[ch] which adds visible, linked
and lock actions for layers and channels.
... standard icon names and GTK+ icon names as second choice.
We should only use GIMP specific icon names as last resort, when there
is no standard or GTK+ names dedicated to the function.
This is made possible thanks to commit 3cc77b0.
s/gimp-document-recent/document-open-recent/
s/gimp-indent/format-indent-more/
s/gimp-next/go-next/
s/gimp-previous/go-previous/
s/gimp-save/document-save/
s/gimp-save-as/document-save-as/
s/gimp-revert/document-revert/
s/gimp-open/document-open/
s/gimp-document-recent/document-open-recent/
s/gimp-quit/window-close/ ou s/gimp-quit/application-exit/
s/gimp-warning/dialog-warning/
s/gimp-edit-clear/edit-clear/
s/gimp-justify-.*/gtk-justify-.*/
s/gimp-font/gtk-select-font/
s/gimp-color-palette/gtk-select-color/
s/gimp-cancel/gtk-cancel/
