The data is perceptually identical or off-by-one pixels, which means
these are very likely consequence of float computation slight
differences, which make off-by-one u8 integers when converted back.
This way, we can have the CI run data comparison for layer mode unit
testing without pushing huge data file in the repository. I don't add
any textual output about this feature though, because it's not like
anyone else but maintainers/admins can upload any files there anyway.
There were just too many possible cases, so I created a script
tools/compute-layer-mode-digests.py which I am going to commit in the
`gimp-2-10` branch.
These are the digests generated this way with GIMP 2.10 with SSE2.
"Color Erase" testing is disabled currently because it is very broken
(digests are different at each export!).
Some modes (Anti Erase and Replace) are not introspected, therefore they
cannot be tested. Pass-through is not tested right now because it
requires special-casing and a little more thought.
"Behind" is not in the list of layer modes in the Layers dockable, and
it could not be set in GIMP 2.10 API, but it could be set in GIMP 3.0
API. So I don't have GIMP 2.10 data. Let's use GIMP 3 data as our
baseline for this blending mode testing, from now on.
Some operations generate slightly different pixels but all differences
are minimal (in worst case, barely 0.3%) and the pixels are perceptually
identical, with basically off-by-one differences (e.g. in some case, I
had pixels whose value when converted to u8 would be 91.4999999…, which
meant that slight float computation different are enough to make it be
either 91 or 92).
Even more, in 2 builds of GIMP 2.10 (flatpak or custom build), I had
either the same result as 2.99 in one of the build, or sometimes a third
result.
But any case, none of these differences warrant being qualified as a
change in the render. Therefore I make the digest to compare to into a
list of digests. Hopefully we won't have to edit this list too often
with more slight variant renders.
I add a feature so that one can drop a data file of the result as
expected in the build folder. Then the unit testing framework will
compare it to the layer mode render and will list of the problematic
pixels, additionally to some statistical data to discover if we are
likely just dealing with off-by-one issues, or some more drastic render
differences.
One of the points we care most about is for XCF code stability over
time. In particular, loading an old XCF should render visually the same.
This unit-testing infrastructure allows testing that we do not deviate
when editing layer mode code. It works on u8 so that float computation
precision does not come into account as well.
For now, I only run it on legacy layer modes.
Note that 6 legacy modes have different hash from their 2.10
counterparts (difference, subtract and all 4 HSV/HSL layer modes). In a
next step, I will look more closely into them to determine if we are
talking of minor, not-too relevant, differences or if we broke their
implementations somehow.
Right now, running GIMP non-interactively (i.e. either as gimp-console
or with --no-interface) without --quit, the process was still exiting
immediately, yet not properly cleaning after itself. This is a
regression, since there used to be use cases with people wanting
long-running GIMP (for instance with a long-running plug-in waiting for
input through whatever inter-process communication method).
With this commit:
* GIMP now continues running when run non-interactively without --quit;
* It will catch SIGINT (typically Ctrl-C) and will quit cleanly when the
signal happens.
* At the end of the normal process (processing command line options,
such as opening images or running batch commands) and before going
on-hold, it will display some info text saying that the process can be
exited with SIGINT and informing that --quit exists if you were in
fact intending to quit immediately after the normal process actions.
* This also fixes the "gimp_finalize: list of contexts not empty upon
exit" WARNING we had when it was exiting without --quit (because of no
proper cleanup).
Note that I add some CLI text which ideally should be localized. But
since we are in string freeze, I am letting them untranslated with a
TODO (also assuming CLI-using people have more chances being used to
English, which may be or not a wrong assumption; but anyway most people
don't read the terminal output, and people running GIMP
non-interactively are even less).
Since this was not just an enhancement but also really a regression fix,
I prefer to do this now despite the string freeze and lack of
localization.
No intended change to function.
Style changes for easier reading.
Use v3 binding of PDB returns (elide many car), TRUE=>#t, etc.
Also condense trailing right parens to one line
Was "GRAY" without alpha.
Now "*" i.e. any image mode, w or w/o alpha.
The effect is more or less the same,
and should be exactly the same if the user submits a GRAY.
When the user does not choose a file of a secondary image,
use a copy of the primary image as the secondary image.
Rather than throw an error.
The filter still has effects, if not quite the same as when user
chooses a secondary image that is not the primary image.
Represent passed Gfile args having unknown files
or invalid GFile by an empty string.
Instead of by an error string.
A script can treat an empty string as a None choice of file,
or as a user error.
This was mixing 2 features: the debug on crash and performance logs in
the Dashboard dockable.
1. DrMingw is for debug on crash on Windows and has already a report in
the meson summary. So I remove it from the test.
2. Linux specifically with libbacktrace and/or libunwind and Windows but
only x86 (32/64) only are supported. Test updated.
3. Summary field updated to "Detailed backtraces (Dashboard)" for more
clarity.
Script authors declare defaults by name strings.
Which can be valid name, or empty string, or "from context".
ScriptFu declares formal arguments to the PDB,
either with a default GimpResource, or defaulting dynamically from context.
Works with both new-style dialogs (ProcedureDialog and ProcedureConfig)
or with old-style dialog (script-fu-interface.c)
This feature was broken during the initial
port to GimpProcedureConfig, due to the
Out Level parameters not being properly
clamped when interacted with. This patch
fixes the clamping and restores the call
to level_in_draw () to show the arrows.
It also sets the gamma widget's increments
to match 2.10's range.
Since the port to GimpProcedureDialog,
the Threshold label was not being shown
due to it accidentally having an invalid
tag, <-->.
This patch renames it to just "Threshold"
and updates the range to be clearer,
which was the purpose of the original
extended label.
Resolves#12034
Previously, we used the Filter Tool's drawable when updating an
existing filter. However, if the user has a different layer selected than
what the edited filter is attached to, the edited filter is always put at
the top of the filter stack.
This patch retrieves the drawable from the existing filter itself, rather
than assuming the filter tool's drawable is the same one.
Jehan