...in both the core and libgimp.
Images now know what the default mode for new layers is:
- NORMAL for empty images
- NORMAL for images with any non-legacy layer
- NORMAL_LEGAVY for images with only legacy layers
This changes behavior when layers are created from the UI, but *also*
when created by plug-ins (yes there is a compat issue here):
- Most (all?) single-layer file importers now create NORMAL layers
- Screenshot, Webpage etc also create NORMAL layers
Scripts that create images from scratch (logos etc) should not be
affected because they usually have NORMAL_LEGACY hardcoded.
3rd party plug-ins and scripts will also behave old-style unless they
get ported to gimp_image_get_default_new_layer_mode().
Streamline the layer-mode mapping code, to reduce duplication.
Add mappings for the following modes: Subtract, Divide, Luma/
luminance darken only (Darker Color), Luma/luminance lighten only
(Lighter Color), and Luminance (Luminosity).
Use SRC_OVER, instead of SRC_ATOP, as the composite mode for all
layers (or use AUTO, when it results in SRC_OVER), to match
Photoshop's behavior. Use RGB_PERCEPTUAL as the blend and composite
space, instead of AUTO, whose interpretation depends on the specific
layer mode, to match Photoshop's behavior for RGB images. Use NORMAL
mode, instead of NORMAL_LEGACY, with the above properties, for normal
layers, for consistency with the other layer modes, which don't (and,
indeed, can't) use the legacy modes.
The section-divider (lsct) layer resource may contain blend mode
information, which apparently overrides the blend mode specified in
the layer record. When reading such a resource, replace the layer's
blend mode with the one specified by the resource.
It seems like pass-through group layers specify normal mode in their
layer record, but pass-through in their section-divider resource, so
this commit allows correctly loading such layers.
... 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.
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.
...not divisible by 4 are incorrectly reported as corrupt
file-psd: Do not round up the extra data length field when reading
layer info.
Fixes the PSD layer extra information handling in read_layer_info() by
not rounding up the data length field to a multiple of 4.
Layers can contain extra data, which is encoded at the end of layer
records. The length of this data should always be stored rounded up to
an even byte count. When loading a PSD file, it can be expected that
this value is already rounded up and this operation should not be
necessary. If an uneven byte count is encountered, a warning is
emitted but the loading process is not aborted.
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.
... (read PSD file from PS CS3)
use a position of 0 when inserting normal layers
as they're always inserted on top of their group
-1 means inside the group when the active drawable is
a group or above it when it's not. This used to work
before layer groups or in simple cases.
Layer name source (id on 4 characters encoded in MacRoman).
psd from PS>5 have "luni" (Layer Unicode)
See https://bugzilla.gnome.org/show_bug.cgi?id=753986#c4 for more details
Janitorial on lyvr:
move IFDBG at the beginning of the function
+change the content of it
GIMP's PSD plugin was assuming that colors in PSD files are linearly interpolated
on both export and import. This commit fixes the issue by doing the following:
- when importing, assume the colors are gamma interpolated in the entire image
- when importing and exporting, treat the colors in each layer as gamma interpolated
- when importing and exporting, treat indexed colors as actually indexed colors
- when exporting, treat the interpolation in the channels and masks as linearly interpolated
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.
which share the psd.c file for query() and run(), instead of having
save's stuff commented out in psd.c, and having it duplicated in
psd-save.c for the separate binary.
Using the right Babl format (JPEG previews don't have an alpha
channel), and fixing the main scanline loading loop (which was totally
busted) make the PSD previews look like images.
...file-psd-load segfault.
Fix loading of PSDs where the number of "end group" markers doesn't
match the number of "start group" markers, which seems to be what is
saved by Photoshop in some cases/versions/whatever.
Juan Palacios