...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.
The hint text was shown on kmax change, but not when it was 0 or 1 from
start (i.e. when previous export was 0/1 so these were the saved
values). Run the callback upon construction to initialize properly this
hint label.
Since libwebp 0.6, the keyframe max distance (kmax) has been changed,
and in particular all special cases are now handled by kmax (it used to
be weird cases of kmin and kmax intertwined with no logics, for instance
kmax == 0 AND kmin > 0 would mean all frames are keyframes).
Now it is much more logical, and kmax == 0 means no keyframes, whereas
kmax == 1 means all frames are keyframes. See also:
2dc0bdcaee
The signature of the original file-raw-save procedure must not change,
so change it to use the old parameters.
Change the other procedure (with additional arguments) to
file-raw-save2.
Otherwise people will install older versions and won't understand why
the plug-ins won't work. It's just a little annoying that these version
strings have to be hardcoded this way. We could add macros in a header,
but that would be only half a solution. Ideally we'd rather have some
discovery logics at some point.
Hopefully it works, since that's untested (I have no MacOS access). This
is mostly code from file-darktable.c, made generic and factorized into
file-raw-utils.[ch]. At least it still builds and work fine on Linux.
I used the CFBundleIdentifier from `tools/osx/Info.plist.in` in
RawTherapee code. I didn't add a Win32 registry key base though, since I
couldn't find any relevant data for this in RawTherapee code.
...with known plugins
Add new plug-in file-raw-placeholder.c that registers itself for
loading all RAW formats from file-raw/file-formats.h, but does nothing
except returning an error message pointing to darktable and
RawTherapee.
When no real RAW loader is installed, this plug-in is selected
automatically as RAW loader, otherwise the first installed RAW loader
is used. Selecting another in prefs still works as before.
... include mouse pointer.
This is working find and tested under GNOME which already had the code
for it (was only missing the GUI). I added the feature in OSX and X11,
though it is untested. Windows does not seem to have the capability (at
least according to screenshot_win32_get_capabilities() in our code).
The new metadata viewer is based on a version of the old metadata
plugin that still contained this bug, and a few other bugs that've
been fixed since then. Reapply those fixes to the new plugin.
This is essentially an adaptation of commits
f8e291bf31,
ce9e7feabd,
38c79600f1,
and 801bd8fb3f.
Currently, toggling RGB565 makes the RLE toggle insensitive, but
if RLE is checked beforehand RLE is used anyway, with incorrect
results.
Fix this by adding RLE support for RGB565 data.
Juan Palacios