by using gimp_image_get_effective_color_profile() instead of just
_get_color_profile(). Don't look at the preference setting because PSD
should behave more like "save" than "export" and save everything.
(cherry picked from commit a35b243f9b)
I am going to forbid plug-ins from being installed directly in the root
of the plug-ins/ directory. They will have to be installed in a
subdirectory named the same as the entry point binary.
This may seem useless for our core plug-ins which are nearly all
self-contained in single binaries, but this is actually a necessary
restriction to eliminate totally the DLL hell issue on Windows. Moving
core plug-ins in subfolders is only a necessary consequence for it.
(cherry picked from commit 870ca6334d)
... depending on UI language
Use gimp_register_file_handler_priority(), added in the previous
commit, to increase the priority of the merged PSD loader, so that
the non-merged loader is always preferred over it (unless
explicitly chosen), regardless of the UI language.
(cherry picked from commit 0320126254)
PSD files may include a "merged", pre-composited, version of the
image (in Photoshop, this is the case when saving files with
"Maximize Compatibility" enabled; GIMP always saves the merged
image data in exported PSD files.) This commit adds support for
loading the merged image version from PSDs, instead of the full
layer hierarchy. This is useful when loading PSD files that use
features that we don't currently support, and therefore can't
render correctly, such as adjustment layers.
When loading the merged image version, we avoid loading certain
additional data from the file, such as channels, paths, and
guides, while still loading metadata, making this akin to loading
other "flat" image formats.
This option is currently exposed as an additional file type
("Photoshop image (merged)"), which has to be explicitly selected
from the file-type list when opening the image.
(cherry picked from commit 1d9a8a91ab)
In the file-psd plug-in, ignore the 'irrelevant' flag of layers
when loading PSD files; in particular, don't hide such layers
unconditionally. The 'irrelevant' flag seems to indicate that the
layer's content can be entirely derived without using the layer's
pixel data, and not that the layer itself it irrelevant.
Our composite modes don't correspond directly to the Porter-Duff
operators after which they're named, and these names aren't too
descriptive anyway.
Rename the composite modes as follows:
Source Over => Union
Source Atop => Clip to Backdrop
Destination Atop => Clip to Layer
Source In => Intersection
Update relevant code, including UI text, enumerator names, function
names, and action names.
When loading PSDs, insert layers to the image as the last step of
layer creation, after writing the pixel data to their buffers, so
that the data of child layers is available when their parent
group's projection is subseqeuently invalidated; otherwise, we'd
need an additional gimp_drawable_update() call after writing the
data to the buffers.
Photoshop CS5 adds support for layer groups whose nesting depth is
above 5. The end markers of these groups use an undocumented
"lsdk" key for their section dividers, rather than the usual
"lsct". This caused the PSD plugin to treat them as regular
layers, resulting in wrong layer-tree structure.
Add support for "lsdk" section dividers upon loading, and also
generate "lsdk" section dividers upon saving sufficiently-deep
groups.
When loading a PSD, set the active layer after adding all the
layers to the image, instead of at the time of its creation, since
the active layer may change when adding subsequent layers.
Tweak the layer group saving code so that the saved PSDs match
Photoshop-produced PSDs a bit more closely. For the most part, it
doesn't seem to matter much, but it does somewhat improve
compatibility with other programs that read PSDs.
And: Bug 593251 - Mask positions may be incorrect when opening a PSD
The position-relative flag of layer masks doesn't specify how the
mask position is represented in the PSD -- it's always absolute --
but rather whether the layer and the mask are linked or unlinked.
Since masks are always linked to their layers in GIMP, just ignore
this flag (and, when saving, clear the flag so that the mask is
linked to layer when loaded in PS.)
Set the layer name of group layers early on, while processing their
end marker, so that the default group name won't collide with the
names of subsequent layers, leading to wrong layer names. The real
name of the group layer is set again when processing its start
marker.
...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.
