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)
Squashed commit of the following:
commit ee1ff7d502658cfa1248a13a3f0348495db07eda
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sun Jul 29 00:31:47 2018 +0900
Fixed that gimp-text-dir-ttb-* icons are lacked in Symbolic.
commit d87d012d697628da28fe90199cc04b95b72ba8ef
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 16:23:10 2018 +0900
Fix a typo.
commit cf0238bf7df56c384cdf3b7ec69557d14740f853
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 15:50:57 2018 +0900
Fixed seg fault error.
commit b07f60d06fa1a753fda5b4d46af01698c344154e
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Fri Jul 27 17:15:34 2018 +0900
Add support for vertical text writing.
https://gitlab.gnome.org/GNOME/gimp/issues/641
(cherry picked from commit 587d9bbb03)
- "LCh" intead of "LCH"
- "CIE LCh" instead of "CIELCh"
- "HSV Hue" instead of "Hue (HSV)" for all models/components
(cherry picked from commit 926dc070ef)
In gimp_metadata_set_from_{exif,iptc,xmp}(), gracefully reject data
of invalid size, returning an error instead of raising a critical.
In particular, this avoids a CRITICAL when loading an XCF with an
empty exif-ata parasite.
(cherry picked from commit eafefc7d81)
The flag `free_selection_string` is used to track an array of strings
with some of them being static and others allocated. This should have
been an array of boolean but we can't change it because it is public API
(though it should really not have been!).
So let's just allocate every string of the `selection` array instead,
which makes the boolean flag useless now.
... after each successful read().
I completely missed this declaration after a statement during the review
of !13 even though I saw another similar issue!
Also let's reset the error counter to 0 each time a successful read()
happens so that we can continue reading even if a lot of EINTR were to
happen, as long as we globally go forward. Only consecutive errors
increment the counter.
Finally add a small comment to explain why we let EINTR pass instead of
breaking directly.
(cherry picked from commit 49b4b1a5c2)
When lldb attaching to the process it triggers few "-1" errors on read with
EINTR error. After 1-2 errors read() call works again.
Also this patch fixing TID detection, syscall SYS_gettid is oficially deprecated
now and does not work. Also adding safecheck to avoid enldless loop.
(cherry picked from commit 559d9b89e3)
...upon exporting an image
Step 1: make it configurable just like "Export EXIF" etc.
app, libgimp: add "export-color-profile" config option
Add it to the preferences dialog, and pass it on to plug-ins in the
GPConfig message. Add gimp_export_color_profile() to libgimp.
Nothing uses this yet.
(cherry picked from commit 8c9c091021)
Pass the current icon theme directory to plug-ins through the
config message, and add a gimp_icon_theme_dir() libgimp function
for retrieving it. Note that we already have a similar
gimp_icon_get_theme_dir() PDB function, which we keep around, since
it can be used to dynamically query for the current icon dir,
unlike the former, and since it returns a dynamically-allocated
string, while the rest of the config-related functions return
statically allocated strings.
Use the new function, instead of gimp_get_icon_theme_dir(), in
gimp_ui_init(). This allows gimp_ui_init() to run without making
any PDB calls. Consequently, this allows us to start plug-ins that
call gimp_ui_init() without entering the main loop in the main app.
We're going to add a plug-in that displays an interactive dialog
while the main app is blocking waiting for an operation to
complete, and we need to be able to start the plug-in without
entering the main loop, to avoid the possibility of arbitrary code
being executed during the wait.
Bump the protocol version.
Let's make our various usages of this broken function more robust, or at
least return with errors when we can. But this is still seriously
broken. Inside gimp_locale_directory() though, there was nothing I could
do, so I just added a FIXME for at least keeping an eye on it.
I could not find for sure what to use on FreeBSD instead, so let's just
not get this information there. It is quite useful information to know
where thread traces were asked from, but it is more important to make
sure the program can be compiled everywhere. Also we can just check
which thread has gimp_stack_trace*() calls. Thus it can be seen as
redundant information in any case.
SYS_gettid is apparently defined as a macro, so let's simply check for
it being defined.
First WIP commit, adds:
- enum GimpGradientBlendColorSpace { RGB_PERCEPTUAL, RGB_LINEAR }
- linear blending mode for gradient segments
- tool options GUI for the blend and paint tools which use gradients
Since commit bb52431cdd, we get multi-thread traces in functions
gimp_stack_trace_*(). Adding now the LLDB equivalent improvement.
Also adding the process and thread id information, from which the trace
order was made, atop the listing, as well as the thread list. This would
allow to easily find and associate the threads.
The problem is that sometimes the thread where we got a trace from may
not matter (for instance signals, even such as SIGABRT or SIGSEGV, seem
to sent a bit randomly to either the thread which provoked them or the
main thread; there is a bit of contradictory info on this when reading
on the topic, in my case I experienced this), in such case, getting all
thread stack is important to find the origin of the signal.
Other times it will highly matter, in particular when getting a trace
for a WARNING or CRITICAL. This information will help to discriminate
between thread traces.
Last commit caused -xobjective-c to be passed during linking on
Mac, causing object files to be treated as source files. Add a
-xnone flag to AM_LDFLAGS, canceling the effect of -xobjective-c.
Additinally, add a -xobjective-c++ flag to AM_CXXFLAGS, so that we
can use Objective-C in C++ files on Mac, if we ever need to.
On Mac, pass -xobjective-c to the compiler through AM_CFLAGS, not
AM_CPPFLAGS, so that it's only used for C sources, and not C++
sources. In the latter case, it clashes with the -std=... flag,
spewing an error. Thanks, Partha :)
... non-latin unicode path.
g_win32_locale_filename_from_utf8() was sometimes returning NULL for
some paths on Windows. Then the call to gexiv2_metadata_open_path() with
a NULL value was crashing plug-ins.
This commit only prevents from crashing by simply failing to load
metadata when this occurs, which means losing metadata support on
Windows depending on filenames. A proper solution will have to be
implemented.
It seems old blend tool (from GIMP 2.8) was using manhattan distance,
whereas the new one uses euclidean. I guess there must be use cases for
both. In any case, it is a good idea to simply propose the option since
the property exists in the "gegl:distance-transform" operation.
See also bug 781621.
Reap the child *after* we're done reading its output, so that we
can disable ptracing after reading, but before reaping. This
avoids a window during which the child is gone, but ptracing using
its PID is still allowed.
Clear the ptrace permission given to the child after it terminates,
so that a future process that happens to have the same PID the
child had can't ptrace us.
On Linux, when /proc/sys/kernel/yama/ptrace_scope is 1, a process
may only ptrace its descendants by default, which prevents the GDB
process spawned by gimp_stack_trace_print() from attaching to, and
producing a backtrace for, the calling process.
Use prctl() with PR_SET_PTRACER, when available, in the parent
process, to allow the child process to ptrace it.
It seems that older GDB (under version 7) are not handling very well
some common debug information format, in particular DWARF > 3. Such
version of GDB is usually not a problem since it is quite old (more than
10 years old, it would seem) so you don't see it anymore on any modern
GNU/Linux distribution. On FreeBSD on the other hand, it is still
available (probably for license reasons) and even installed by default!
As a consequence, it makes debugging fail, even though LLDB is also
installed by default.
That is even more of a problem because it would seem that GIMP is killed
(most likely by FreeBSD kernel according to the reporter tests) as a
side-effect of GDB failing, which is seriously bad, in particular since
we also use the debug dialog for non-fatal errors (which could therefore
end up killing GIMP as side effect of a bad GDB!).
So I add some GDB version check. I implement this without any dynamic
memory management, as usual, since this needs to happen also during
crash handling where the state is unstable and prone to memory
allocation failure.
I also add gimp_utils_backtrace_available() public API which can be used
by the Preferences.
