... 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.
Fix the other pixel format issue in this bug: split up
get_pixel_format() into 3 functions get_layer,channel,mask_format() so
we use the right one for the right drawable type, get_layer_format()
has an "alpha" parameter that is taken from the loaded layer instead
of from the PSDimage struct.
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.
Ell