It was agreed that we should write "plug-in" consistently. Only possibly
user-visible strings were updated.
Thanks to scootergrisen for a first patch which could not make it
after changing decision on the canonical writing.
... since that's the color space it actually works in.
Keep the legacy "Color (HSV)" mode's name as is, wrong as it is,
since, well, that's what it used to be called...
Merge mode lays the source layer on top of the destination, same as
normal mode, however, it assumes the source and destination are two
parts of an original whole, and are therefore mutually exclusive.
This is useful for blending cut & pasted content without artifacts,
or for replacing erased content in general.
Calculates the dot product of the two input colors, and uses that
as the value for all the output color's components. Basically,
a per-pixel mono mixer.
Useful for custom desaturation, component extraction, and crazier
stuff (bump mapping!)
Include erase mode in the menu for layers and general paint tools.
This makes the eraser tool somewhat unnecessary, but allows for
interesting use cases (e.g., airbrush eraser, etc.)
... and get rid of the dedicated op. This gives us support for all
the blend/composite options for this mode.
Rename COLOR_ERASE to COLOR_ERASE_LEGACY, with perceptual blending/
compositing and immutable everything, and add a new COLOR_ERASE
mode, defaulting to linear blending/compositing, with mutable
everything. Modify affected code.
Try to sort all GIMP_ICON_* defines into FDO categories like in
https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html
Add defines for all icons we override, rename some icons to their FDO
standard names, and mark the ones we duplicate with a comment so we
don't forget to rename those to standard names in 3.0.
being exported to libgimp, and having a non-exported value, this is a
horrible mess like with GimpLayerMode, but at least the cruft value
names are deprecated now.
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/
Rather than just discovering them by chance, a simple grep and some
search and replace are much more efficient! :-)
Cleaning only done on C and automake files.
Gamma correction refers to correcting how an image is displayed on
various devices. Gamma adjustment is a more general phrase that also
applies to adjusting gamma as a step in image enhancement in a
color-managed workflow.
Something must have changed in GTK+, probably a long time ago, because
this code definitely used to work in the past.
Anyway, change gimp_ui_init() in libgimpui to use gtk_rc_parse()
instead of gtk_rc_add_default_file() which fixes the plug-in's initial
theme, and install a GFileMonitor on themerc which calls
gtk_rc_reparse_all() when themerc changes.
Add PDB sample point API similar to how the guide API works. Add core
API similar to the core guide API to make guide and sample point APIs
as similar as possible.
Allow to set profiles on grayscale images. Change profile validation
to check for image type and profile type. Actually the patch simply
makes some pieces of code less restrictive. Change user-visible
strings in the profile dialogs accordingly. Change PDB docs
accordingly.
Add gimp_stock_set_icon_theme() which can be called at any time, also
before gimp_stock_init(), in which case we avoid setting the configured
icon theme twice on startup. Call it from libgimp/gimpui.c and
from app/gui/icon-themes.c so the app and plug-ins use the same
icon theme.
Add new PDB procedures gimp-context-get/set-stroke-method and honor
the new setting in gimp-edit-stroke and gimp-edit-stroke-vectors.
Internally, keep a GimpStrokeOptions around in GimpPDBContext to keep
track of the newly added PDB state, and use it for the stroke
operations instead of creating a scratch GimpStrokeOptions.
Blurbs use third person and need a final point.
Some description were wrong or inaccurate. Add also units where
needed (radius in pixels, angle in degrees).
Some returned values have to be freed.
Some refactoring: add gimp_metadata_get,set_colorspace() and a new
enum GimpMetadataColorspace which so far can be one of { UNSPECIFIED,
UNCALIBRATED, SRGB, ADOBERGB }. The setter is untested and I don't
know if it's doing the right thing, please review. Use the getter in
gimp_image_metadata_load_finish(), so complex metadata logic and
profile creation/setting are separated.
Copy a ton of logic from darktable and libkexiv2 and parse more
metadata tags which contain colorspace information, namely:
Exif.Photo.ColorSpace
Xmp.exif.ColorSpace
Exif.Nikon3.ColorSpace
Exif.Canon.ColorSpace
In e61b1f76 things were changed to return string arrays that can be
freed with g_strfreev(), but that returned a one-element array
containing a NULL pointer for zero-length arrays. Fix the code
to return NULL again for zero-length arrays. See bug #751584.
to not return a reference that has to be dropped. Also allow NULL to
be returned if the managed cannot have a profile. If it can have one,
get_color_profile() still always returns a profile (either the
assigned one, or a generated built-in one).
Add flag GIMP_METADATA_LOAD_COLORSPACE which defaults to TRUE, and in
gimp_image_metadata_load_finish(), assign AdobeRGB to the image if
Exif.Iop.InteroperabilityIndex says "R03". This is most likely very
incomplete because there are quite some other colorspace tags in
various parts of the image metadata.
it used to be a typedef to gpointer and actually was a cmsHPROFILE.
Change its API to be more "standard", remove the public close()
function. The object caches both the cmsHPROFILE and the data/length
ICC blob, so conversions between the two become obsolete (simply call
get_lcms_profile() or get_icc_profile()).
Adapt everything to the new API, but port it in a naive way for now,
the code doesn't take advantage of the new possibilities yet (like
refcounting).
Which will have proper API to deal with an image's color profile (no
parasites, no ICC blobs). So far contains gimp_image_get_color_profile()
and gimp_image_set_color_profile().
because it confuses gtk-doc and breaks some links. Also change the
"Index of new symbols in GIMP 2.x" sections to be what seems to be the
modern standard (looked at the GLib and GTK+ docs), and update some
other stuff.
Looks like they were forgotten so messages from libs went to stdout
instead of being routed through the log handlers, which would show
them in a dialog, or in the error console.
GIMP's OVERLAY mode was identical to SOFTLIGHT. This commit fixes the
issue and introduces a NEW_OVERLAY mode and enum value.
- change gimp:overlay-mode to be a real (svg-ish) overlay mode
- when compositing, map OVERLAY to gimp:softlight-mode
- when compisiting, map NEW_OVERLAY to gimp:overlay-mode
- bump the XCF version when NEW_OVERLAY is used
- map OVERLAY to SOFTLIGHT when loading and saving XCF
- map OVERLAY to softlight in all PDB setters
- map OVERLAY to softlight when deserializing a GimpContext
- change all paint mode menus to show an entry for NEW_OVERLAY
instead of OVERLAY
- change PSP, PSD and OpenRaster to use NEW_OVERLAY
These changes should (redundantly) make sure that no OVERLAY enum
value is used in the core any longer because it gets mapped to
SOFTLIGHT at all entry points, with the downside of introducing a
setter/getter asymmetry when OVERLAY was set in a PDB api.
With this patch, there should be no more need to set PATH on Windows
before running GIMP.
This patch was tested by me and drawoc, but there could be some
undetected issues lurking. Revert if any problems arise.
It is advised to use the more accurate g_io_channel_win32_new_fd() or
g_io_channel_win32_new_socket() because GLib can't differentiate between
file descriptors and sockets on Windows, which outputs a warning when
there is ambiguity.
- Move all GimpGuide members to a private struct
- Remove cruft checks for position < 0, we don't keep removed guides
around in the image's guide list since a long time ago
- Add #define GIMP_GUIDE_POSITION_UNDEFINED G_MININT and use that
instead of -1 (this is also a prerequisite for having guides
outside of the image)
Return flags based on what metadata is actually present in the image.
Returning of a suggested value for GIMP_METADATA_SAVE_THUMBNAIL needs
support from gimp_image_metadata_load_prepare() and is still missing.
Port all plug-ins to use the new API, the suggested values are however
overridden by parasites and whatever special code was devised for the
individual plug-ins. This needs to be fixed.
Jehan