… is set.
The order for thumbnail creation in gimp_imagefile_create_thumbnail() is now:
1. If there is a GimpThumbnailProcedure, it is run first.
2. Otherwise we check if a thumbnail is in the metadata.
3. As last resort, we just load the full image.
Part of the fix was to copy gimp_image_metadata_load_thumbnail() into the core
code. I have been wondering if we could not drop the same function from libgimp
and remove the GimpThumbnailProcedure frome file-jpeg, since it just uses the
metadata thumbnail and it is the only plug-in using this code.
Also it is much faster to run this in core and it's generic function which makes
thumbnail loading from Exif data working for every format supported by Exiv2.
On the other hand, the file-jpeg thumbnail procedure also gathers a few more
useful information, such as the color model (in a reliably manner, since based
on JPEG header, unlike from metadata which may be wrong).
Certain XMP metadata tags currently can't be saved by us until we get
support in gexiv2 for adding new structs not present in exiv2.
We remove these tags from the exported metadata because the XMPSDK in
exiv2 would otherwise fail to write all XMP metadata.
Examples are the newer (2019, 2021, 2022) sample images from the
IPTC Photo Metadata Standard.
We also add all the static functions present in gimpimagemetadata-save
at the top, which had been forgotten in the past.
1. gexiv2_metadata_has_tag with gexiv2_metadata_try_has_tag;
2. gexiv2_metadata_set_exif_thumbnail_from_buffer with the "try" version.
For a while now the minimum gexiv2 version for the master branch is 0.14.0,
which means we can replace these deprecated functions, since the new
versions were added in 0.14.0.
GIMP was saving the last changed/saved date to IPTC tag DateCreated,
which should only be used for the original creating date of the image
and thus should not be changed by GIMP.
After discussion in the cited issue, there is no tag in IPTC that we can
use, so we remove saving modified date from the IPTC metadata.
Instead we add two XMP tags, one for modified date and the other for the
date that metadata was changed. Since we do both when exporting, both are
saved with the same date/time in ISO 8601 format.
This also fixes another issue where we were not storing the timezone offset
for Xmp.tiff.DateTime. Since this has the same format as the other
XMP tags, we fix this together with this issue.
When overwriting the same file when exporting, we didn't check if the
image previously had a thumbnail. If the default setting in Preferences
is to add a thumbnail, then it would add one where it shouldn't.
Since thumbnails get saves as part of the EXIF metadata, we need to check
that to see if there was a thumbnail in the original image.
However, we were always removing the thumbnail from the metadata on import.
Let's delay removing this metadata until we need to, which has the
advantage that the metadata in our viewer is more complete.
When exporting starts, we add a check in gimp_image_metadata_save_prepare
to see if there was a thumbnail in the EXIF metadata. If not, then we
disable the thumbnail flag.
In gimp_image_metadata_save_filter we remove the thumbnail metadata when
the user doesn't want to save a thumbnail, or when the image format
does not support EXIF.
This new function is an alternative to existing
gimp_image_metadata_save_finish, when you want to save metadata
yourself and you need only filtering processing.
It returns filtered metadata allowing the caller
to save the finalized metadata via other means
(via native format’s library for example)
This API can be used to support metadata saving of image formats
not directly supported by gexiv2/exiv2.
Last deprecated usages in this file. Actually there are a few other
calls but deprecated on GExiv2 0.14.0, hence over our current
requirement. So we'll have to handle these later.
Replace functions gexiv2_metadata_set_xmp_tag_struct() and
gexiv2_metadata_get_tag_type() with their _try_ variants.
Note that I print to stderr rather than raising a warning here as I am
quite unsure where the list of XMP metadata we are gathering comes from.
Is it fully validated by GExiv2, and therefore no errors are ever
supposed to happen? (in such case, we should raise a warning if it does)
Or is it user-provided data (e.g. from a file loaded in GIMP which can
contain broken metadata)? In such a case, we should probably handle the
error slightly differently to warn for non-processable data (hence
possibly metadata loss at export time).
For the time being, then go with this weak handling and take care of
this better when we can look further into this.
… gexiv2_metadata_try_set_tag_string().
These are usage where we have full control over tag names and values so
no error is supposed to happen. This is why we use them as code warnings
and not returned error (because if an error did happen, this would be a
bug rather than a user error or a system error).
Saving a thumbnail is closely related to the other metadata preferences,
but so far this was the only one that didn't have a preference for a
default user value.
This commit adds a preference in the metadata section where a user can
select whether thumbnail saving is enabled by default or not.
s/gimp_image_base_type/gimp_image_get_base_type/
s/gimp_image_width/gimp_image_get_width/
s/gimp_image_height/gimp_image_get_height/
Sorry plug-in developers, more porting work! But really this seems like
the right thing to do in order not to get stuck with inconsistent naming
for many more years to come.
1. Convert xmp /Iptc4xmpExt tag parts to /iptcExt because
exiv2 fails when we try to use the default namespace.
2. Don't only set structs from a fixed list but find all
xmp array elements and check what the best struct
type is: bag or seq.
3. Work around a sorting issue in (g)exiv2 by using a natural
sorting algorithm ourselves.
4. Added some g_debug statements to make it easier to
determine the cause of issues.
Existing implementation was repeating the hours and minutes. This was
obviously not what the format asked. The last hour and minutes are the
ones from the timezone offset. Also rather than playing with snprintf()
and various calls to get each component, let's use g_date_time_format()
which is done exactly for such use case.
It is to be noted that there seems to be a bug in Exiv2 such that the
date and time set through Exiv2 return an error when read back, still
with Exiv2. Read and write use different format. I have reported this
issue, together with a patch (hopefully a good one).
https://dev.exiv2.org/issues/1380
So once this patch (or another) gets merged upstream, the following
warnings (e.g. when reopening a PNG created by GIMP) should disappear:
> ** (file-png:176245): WARNING **: 02:43:25.204: Unsupported date format
> ** (file-png:176245): WARNING **: 02:43:25.204: Unsupported time format
Add gimp_procedure_config_begin_export() and end_export() which
are wrappers around begin_run() and end_run() and additionally
pretty much completely manage GimpMetadata handling.
A GimpProcedureConfig can provide boolean properties "save-exif",
"save-xmp" etc. in order to have them automatically managed by
begin_export() and end_export(). This also restores the feature of
overriding the procedure's saved default values with export
preferences, but not the values from the last export, like it
used to be in 2.10.
Move gimp_image_metadata_save_prepare() and save_finish() (which are
now completely handled by GimpProcedureConfig) from libgimpui to
libgimp, but keep their declarations in the libgimpui header. Not
perfect, but not finished either.
Also fix gimp_image_metadata_save_prepare() to set the affected
GimpMetadataSaveFlags to 0 when the image has no metadata at all.
Jehan