with many Xmp.photoshop.DocumentAncestors tags
This is similar to #7464, but in this case the XMP metadata was already
included in an XCF image.
We check for the occurrence of Xmp.photoshop.DocumentAncestors and stop
handling values when there are more than a 1000.
It would be easier to just check length for all tags and always
ignore when there are more than a 1000 values.
But in that case we would need to be sure there are no valid reasons for
tags to occur more than a 1000 times. So let's just limit it to this
specific tag.
(cherry picked from commit cadf485299)
# Conflicts:
# libgimpbase/gimpmetadata.c
Some images have huge amounts of XMP tag Xmp.photoshop.DocumentAncestors.
In certain cases more than 100000 values. This is apparently due to a bug
in certain versions of PhotoShop.
This makes deserializing it in the way we currently do too slow, probably
because of continuous reallocations after adding each value. Until we can
change this let's remove everything but the first 1000 values when
serializing. I think it is very unlikely there are any real cases where
more than a 1000 ancestor documents are referenced in an image. Testing
shows that this amount doesn't cause any serious slowdowns.
(cherry picked from commit b2c715b52b)
In cases where the whole EXIF MakerNote is invalid we still load that
MakerNote data and export it too, causing partial invalid EXIF metadata.
We don't need to explicitly save Exif.Photo.MakerNote at all, because
as soon as we try to save a brand specific tag exiv2 will create that
MakerNote tag itself.
So from now we don't save the MakerNote but only the tags that go in it.
In issues like #2159 where exiv2 doesn't parse all tags inside certain
brand specific MakerNotes correctly, we will still export invalid EXIF.
That is an exiv2 issue that we can't do much about unless we remove all
MakerNote metadata including those that we can read, which doesn't seem
like a good idea at all.
(cherry picked from commit 6840bb9eba)
On Windows when exporting an image saving the exif and other metadata fails
if the path or filename includes non ASCII characters.
Reason is that gexiv2 changed to using utf-8.
In the past we had to convert the filename to current locale on Windows,
but since it now also expects utf-8 there, just remove the special
handling of filename there.
(cherry picked from commit 8e1f982945)
When saving XMP metadata were using gexiv2_metadata_get_tag_string for all
tags, even those that can have multiple values. This caused those values
to be saved as one value instead of multiple.
To fix this we use gexiv2_metadata_get_tag_multiple, except for XmpText.
Then we add all returned values for that tag separately to our metadata.
(cherry picked from commit af888e481f)
On Windows loading metadata from images with non ASCII characters in their
path failed. Part of the fix is in gexiv2 that now converts the path from
utf-8 to utf-16 on Windows.
However we were still sending a localized path to gexiv2 where it was
expecting utf-8. This caused the conversion and thus loading of metadata
to fail. Fix is to remove the special handling for Windows and use the
utf-8 filename.
(cherry picked from commit 65950de735)
Argh I should have properly reviewed !392 (commit c264f0b705).
It was leaking the return value of a g_path_get_basename().
(cherry picked from commit 1873f0d65c)
This is one of the problems mentioned in issue #5863. This commit only fixes
our loading (and saving) of this metadata.
Certain iptc tags like "Keywords" can appear multiple times. We were using
gexiv2_metadata_get_tag_string to get the value but that always returns
the first value so we replaced that by gexiv2_metadata_get_tag_multiple.
(cherry picked from commit d0f67faf29)
`man snprintf` clearly says (in NOTES) that when source and target
overlap, the result in undefined.
g_snprintf() conforms to the same standard hence would not get the
expected result. In my case, the result was just tzstr (e.g. "+01:00").
(cherry picked from commit 435d5ce83a)
Partially based on the comments of Massimo Valentini we block all Pentax and PentaxDng
exif Preview tags from being exported. We leave finding a more flexible solution for
problematic tags to a future contributor.
(cherry picked from commit 9069d812ef)
... by qualifying them with "extern", in addition to
"__declspec(dllexport)". Omitting "extern" happened to work in the
past, but recent GCC versions require it.
(cherry picked from commit b2e223813b)
The second parameter should be GStatBuf*, which will be defined to be
the right struct depending on the actual platform. Using `struct stat*`
was good on Linux but was outputting warnings on other platforms (at
least on Win32).
(cherry picked from commit 6bc6a07b7e)
Pass the swap-compression option set in the preferences down to
plug-ins, so that they use the same swap-compression algorithm as
the main app.
(cherry picked from commit 5cc289b642)
paste as brush, paste as pattern, select to new brush, select to new pattern
fill selection outline, fill path, stroke selection, distort, rounded rectangle
indexed color conversion, merge visible layers, new guide, new guide (by percent)
image properties, newsprint, fractal explorer, sample colorize, new layer
metadata editor (just a button), spyroplus (only common buttons)
Add a new gimp:offset operation, which implements equivalent
functionality to gimp_drawable_offset(), in preparation for adding
an interactive offset tool.
To simplify things, add a GIMP_OFFSET_WRAP_AROUND value to the
GimpOffsetType enum, to avoid the need for a separate wrap-around
flag. This makes the gimp-drawable-offset procedure parameters a
little superfluous, but whatever.
(cherry picked from commit 40fefb6076)
Older --enable-binreloc configure option had basically the same purpose
as the newer --enable-relocatable-bundle, though the old binreloc was
only used for gimpenv.c code.
As a consequence, commit 10ce702188 was still not working fine since
gimp_installation_directory_file() also need binreloc enabled (to be
actually relocatable).
Let's get rid of this whole mess, by implying we want binreloc code to
be used when --enable-relocatable-bundle is ON. We don't need the
m4macros anymore, since AM_BINRELOC was basically just checking that
`/proc/self/maps` was present. But anyway being present at compile time
does not mean it will be at runtime (nor the opposite). So this test is
not that useful. The binreloc code will anyway fallback gracefully to
the non-binreloc code (i.e. trying to use build-time install paths) if
the procfs is lacking at runtime.
(cherry picked from commit 4d84c1d7ee)
Fix previous commit.
Ahahah! Mitch, you didn't test your code before pushing! Bad boy! :P
(cherry picked from commit db00616888)
(Bad Jehan didn't pick this to 2.10)
... on macOS.
The debugger running on macOS is usually lldb and (from the reports we
get) it looks like lldb displays the tid as hexadecimal on macOS
(whereas lldb displays decimal tid on Linux! I know, it's confusing, yet
consistent with crash report experience!). So let's just do the same,
making it easy to quickly copy-search in order to look up the crashing
thread (without having to convert from decimal to hexa).
This is a bit of an approximation as I imagine we could have gdb on
macOS or whatever edge case. Let's say it's good for the common case and
still not an error otherwise (just a base conversion away).
(cherry picked from commit 8e0135362e)
gimp_metadata_add() which is used to set blobs or EXIF, XMP and IPTC
on a GimpMetadata also needs the logic to set "multiple" tags in one
go, or it will lose all but the first one.
(cherry picked from commit 479fd5b24b)
We were not taking into account tags that can appear multiple times,
such as "keyword", they are handled by gexiv2 with the
get_tag_multiple() and set_tag_multiple() functions.
gimp_metadata_deserialize_text(): when deserializing our XML format,
check if a tag is already set on the metadata as "multiple" and if yes
retrieve it, append the new value and set it again.
gimp_image_metadata_save_finish(): take care of "multiple" values when
copying tags to new metadata created for saving.
This should preserve all values across an "import, edit, export".
Thing will still break when using the metadata editor, it doesn't
handle multiple values at all, but that code is very hard to
understand.
(cherry picked from commit d708ac0b21)
The whole bucket fill specific enum stuff is on its way out, so let's
keep this one out of libgimp for now until we decide how to present
line art filling in the PDB.
(cherry picked from commit 368f2e596a)
This was my initial choice, but the more I think about it, the less I am
sure this was the right choice. There was some common code (as I was
making a common composite bucket fill once the line art was generated),
but there is also a lot of different code and the functions were filled
of exception when we were doing a line art fill. Also though there is a
bit of color works (the way we decide whether a pixel is part of a
stroke or not, though currently this is basic grayscale threshold), this
is really not the same as other criterions. In particular this was made
obvious on the Select by Color tool where the line art criterion was
completely meaningless and would have had to be opted-out!
This commit split a bit the code. Instead of finding the line art in the
criterion list, I add a third choice to the "Fill whole selection"/"Fill
similar colors" radio. In turn I create a new GimpBucketFillArea type
with the 3 choices, and remove line art value from GimpSelectCriterion.
I am not fully happy yet of this code, as it creates a bit of duplicate
code, and I would appreciate to move some code away from gimpdrawable-*
and gimppickable-* files. This may happen later. I break the work in
pieces to not get too messy.
Also this removes access to the smart colorization from the API, but
that's probably ok as I prefer to not freeze options too early in the
process since API needs to be stable. Probably we should get a concept
of experimental API.
(cherry picked from commit cd924f453a)
This commit implements part of the research paper "A Fast and Efficient
Semi-guided Algorithm for Flat Coloring Line-arts" from the GREYC (the
people from G'Mic). It is meant to select regions from drawn sketchs in
a "smart" way, in particular it tries to close non-perfectly closed
regions, which is a common headache for digital painters and colorists.
The implementation is not finished as it needs some watersheding as well
so that the selected area does not leave "holes" near stroke borders.
The research paper proposes a new watersheding algorithm, but I may not
have to implement it, as it is more focused on automatic colorization
with prepared spots (instead of bucket fill-type interaction).
This will be used in particular with the fuzzy select and bucket fill
tools.
Note that this first version is a bit slow once we get to big images,
but I hope to be able to optimize this.
Also no options from the algorithm are made available in the GUI yet.
(cherry picked from commit 8ed12b1b98)
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)
Pass the GEGL tile-cache size, swap path, and thread-count to plug-
ins as part of their config, and have libgimp set the plug-in's
GeglConfig accordingly upon initialization.
Move swap/cache and temporary files out the GIMP user config dir:
libgimpbase: add gimp_cache_directory() and gimp_temp_directory()
which return the new default values inside XDG_CACHE_HOME and the
system temp directory. Like all directories from gimpenv.[ch] the
values can be overridden by environment variables. Improve API docs
for all functions returning directories.
Add new config file substitutions ${gimp_cache_dir} and
${gimp_temp_dir}.
Document all the new stuff in the gimp and gimprc manpages.
app: default "swap-path" and "temp-path" to the new config file
substitutions. On startup and config changes, make sure that the swap
and temp directories actually exist.
In the preferences dialog, add reset buttons to all file path pages.
(cherry picked from commit a29f73bd9a)
... to make multi-color hard-edge gradient fills possible
Add a new "step" gradient-segment blending function, which is 0
before the midpoint, and 1 at, and after, the midpoint. This
creates a hard-edge transition between the two adjacent color stops
at the midpoint. Creating such a transition was already possible,
but required duplicating the same color at the opposing ends of two
adjacent stops, which is cumbersome.
(cherry picked from commit 68bf99e806)
In gimp_metadata_add_xmp_history(), make sure the string returned by
strftime() has a terminating \0 after we mess with its format.
(cherry picked from commit 8421221b60)
It seems that calling `lldb` when it is absent triggers some popup
proposing to install Xcode on macOS. This is obviously not good. Let's
check presence with g_find_program_in_path() instead. I was refraining
from doing so until now, because this function allocates memory, hence
may not do well during a crash.
Fortunately we don't need to check for lldb during crash (unlike gdb
which has some unacceptable behavior for older versions, at least on
FreeBSD) so that should be ok.
(cherry picked from commit 04bbe941d5)
This is my attempt to get better labels, shorter and also (hopefully)
improved English.
As Mitch states though, this is a Japanese-French-German conspiracy! So
any of you native English speakers out there, please review and suggest
proper English if needed. :-)
(cherry picked from commit 9cdedc98f8)
