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.
There are now (up to) three steps to locate an installed darktable used
to load raw files:
1. The environment variable DARKTABLE_EXECUTABLE. It should point to the
main darktable executable without any file extension. So on Windows
leave the ".exe" away!
2. If the environment variable isn't set there is a platform dependent
part. On OSX it uses Kris' code to look for installed app bundles, on
Windows it checks for the registry key written by darktable's installer.
3. Last but not least we fall back to crossing our fingers and hoping
that darktable is in PATH.
query() is run only the first time for efficiency. Yet this plugin is
dependent on the presence of `rawtherapee` which may be installed or
uninstalled between GIMP startups. Therefore we should move the usual
gimp_install_procedure() to init() so that the check is done at every
startup instead.
Tobias Ellinghaus