Add flag GIMP_METADATA_SAVE_COLOR_PROFILE to GimpMetadataSaveFlags and
initialize it from gimp_export_color_profile() in
gimp_image_metadata_save_prepare().
Adapt all plug-ins to use the bit from the suggested export flags and
pass the actually used value back to
gimp_image_metadata_save_finish().
This changes no behavior at all but creates hooks on the libgimp side
that are called with the context of an image before and after the
actual export, which might become useful later. Also, consistency
is good even though the color profile is not strictly "metadata".
(cherry picked from commit c667fdc5c0)
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)
Various plug-ins exporting metadata should now follow preferences, which
would override any default. Of course these preferences can still be
overriden by saved settings (global parasite), previous run settings,
and finally through the GUI when interactive.
This is a privacy concern. Whereas importing metadata is usually a good
idea, exporting it should be a conscious action. A lot of private data
can be leaked through metadata and many people don't realize it (which
also usually means they don't need it). On the other hand, the people
who realize it are the ones who would explicitly edit the metadata and
check what they want to be exported or not.
This is only a first step. Some people may want to always export the
metadata and for these people, there should be abilities to change the
default.
...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().
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.
Completing fix from commit 3cb70e6.
Checking further into libtiff logs, I can see another version of the
warning message for private tags which was used before libtiff 3.7.
For sake of completeness, let's check against this version of the
warning as well.
This is a regression from bug 131975. Any unknown tag over 32768 is not
an error. This is a reserved zone where it is allowed to create custom
tags.
The warning indeed changed since libtiff 4.0.0alpha where it has become:
"Unknown field with tag %d (0x%x) encountered"
This explains why it was not recognized anymore.
tiff GIMP saved
the plugin unconditionally used to add a TIFFTAG_SUBIFD
whose number_of_sub_IFDs was wrong when the user asked
not to include a thumbnail.
Reloading the file in GIMP resulted in:
** (file-tiff:1): CRITICAL **: Directory SubImage1 with 18761 entries considered invalid; not read.
Using code from gegl:tiff-load and gegl:tiff-save which has a mode for
local buffering if the input/output streams don't support seeking.
Unfortunately this code is broken and is disabled for now.
so file-tiff-load and file-tiff-save are always built. Also move them
to their own folder plug-ins/file-tiff/ because they will soon share
some common GIO code.
