In an animated WebP, chances that layers/frame have the same size is
high. It is uneeded to free then malloc again a buffer at each frame,
unless we need more allocated memory.
This is probably not so significant, but still feels nicer.
(cherry picked from commit 0b68ce8182)
This argument should actually say "Do not store premultiplied channel
values", which is what the TIFF spec calls "Unassociated alpha" (vs.
"associated alpha" when values are stored premultiplied by alpha).
Now I can see where the current description is coming from, which is
that any color with alpha 0 (totally masked) ends up as RGBA value (0,
0, 0, 0), in other words, the color information is completely lost. Yet
this label is not very helpful to understand what the checkbox really
does. I decided to not just change it altogether as people would have
gotten used to this for years, but at least adding completary
information in API and tooltip in GUI.
Not sure what this @image_types parameter of gimp_install_procedure() is
used for. Exporting was working find with INDEXEDA image even when not
advertized by this function. Let's update this anyway.
Commit dc069e424a removed the
assumption that 1-bpp PCX files are B&W, in favor of using the
provided palette, which is (supposedly?) the correct behavior.
However, there are evidently B&W files that do not specify a
palette, resulting in an all-black image (i.e., a 2-color indexed
image, whose both palette entries are black). Since other
software, including older versions of GIMP, load such files
"correctly", let's fix this by falling back to a B&W palette when
the provded palette is uniform.
(cherry picked from commit 11defa4271)
(cherry picked from commit 582801ccc5)
(cherry picked from commit b44c2e9352)
(cherry picked from commit cdd686f752)
(cherry picked from commit 3b818f6a9b)
(cherry picked from commit c7d5438b49)
Note from reviewer: sorry, this was not squashed on master! Gitlab
failed to squash even though the "squash commits" checkbox was checked!
So it ended as a 5-commit 1-line change!
:-/
but only the actual saving code, not the export magic and dialog.
Add new internal procedure file-pat-save-internal which is not
registered as a file procedure and always works non-interactively on
the passed arguments and only saves the passed drawable. Use the new
internal procedure from the file-pat-save code and remove all file
writing code from the plug-in.
This way all pattern file writing code duplication is killed, while
the whole export mechanism is completely unchanged.
(cherry picked from commit b29ecfb5da)
We currently have brush and pattern I/O code in both the core and
plug-ins. This commit starts removing plug-in code in favor of having
one copy of the code in the core, much like XCF loading and saving is
implemented.
Add app/file-data/ module with file procedure registering code, for
now just with an implementation of file-gbr-load.
Remove the file-gbr-load code from the file-gbr plug-in.
(cherry picked from commit a4e77e57f6)
In pygimp/plug-ins/Makefile.am, fix the rule for the generated
plug-in files, so that they're re-copied to the build dir upon
changes to the source plug-in files.
(cherry picked from commit 95044d86b3)
Pickle gimp.GroupLayer the same way we pickle gimp.Layer, so that
layer-group parameters can be properly saved.
All credit goes to Ofnuts :)
(cherry picked from commit b295a33aaf)
This plug-in failed to cross-build because these macros were not defined
in the `float.h` of my MinGW64 environment (and they are used in some
ilmbase headers). Just define them ourselves if they are absent. I do
this only on MinGW environment because these should really be defined on
Linux (and other UNIX-like, I guess?) and if they are not, we may have a
bigger issue.
(cherry picked from commit 7a7ecda4f1)
When initializing a pygimp plug-in derived from gimpplugin.plugin,
only pass the plug-in's init() and quit() functions to gimp.main()
if the plug-in actually implements them, instead of passing the
default NOP versions. This avoids plug-ins that don't implement
init() from being registered as having an init function, causing
them to be run at each startup.
(cherry picked from commit 9851bc8962)
... from menus.
The script-fu version is still available through pdb (for scripts) and
even in the action search. But in menus, only the new Python version
will be shown. Also update the description and name of the old version
to make clear it is deprecated in favor of the new plug-in.
Finally rename the new version to simply "plug-in-spyrogimp" (dropping
the "-plus" part as we should consider it as a replacement rather than
as another plug-in, which the "plus" would imply). Anyway the old one
was called "script-fu-spyrogimp", so there is no name clash.
While at it, do some trailing whitespace cleaning in the new plug-in.
Comment by reviewer (Jehan):
This was submitted through gimp-developer mailing list, by the same
author as the original Spyrogimp in script-fu, but this time in Python.
It does more than the original plug-in, with some automatic preview (by
drawing directly on a temporary layer, not as a GEGL preview), and using
the current tool options (current brush, etc.). The new API is similar
yet different. The much evolved possibilities makes that I don't think
it is worth trying to map 1-1 the new API to the old one, so I just let
the old plug-in next to the new one, with a different name.
Note finally that the author also contributed a new Spyrograph operation
to GEGL, yet with the comment: "The GEGL spyrograph operation is very
basic, and untested from gimp. I intend to keep developing it, since I
thought that on-canvas interaction would be very user-friendly. However,
I am not sure I will be able to get it work in a way that makes the
on-canvas interaction interactive enough.
Even if I do, it will not do what the Python plugin can do. It will be
much more basic."
So let's just integrate this evolved version of Spyrogimp for now. :-)
See: https://mail.gnome.org/archives/gimp-developer-list/2018-September/msg00008.html
Several en_GB to en_US.
Also "Show a preview of the transform_grided image". "grided" should be
"gridded", but I also have a problem with the underscore. Should it be
"transform-gridded"? Even so, does it really make sense?
I chose to just read "Show a preview of the transformed image", which I
think is simpler and the most understandable (we don't need to leak the
implementation with a transform grid into the human read text IMO). If
anyone think that was not the right choice, feel free to propose
otherwise.
Thanks to Bruce Cowan for noticing these.
(cherry picked from commit f9c170dfbd)
I am unsure of the problem, but it is fixed by using
poppler_document_new_from_gfile() instead of giving the contents of a
GMappedFile to poppler_document_new_from_data().
Using GFile is anyway usually prefered so I don't dig up more and just
make this change.
(cherry picked from commit a89e503054)
Still a lot more to do but pushing WIP to not have it wasted if more
commits come in from others.
Also got rid of some global variables.
(cherry picked from commit ff2d22d915)
As correctly spotted by Royce Pipkins, the buffer for the drawable's
pixel lines was too small.
Also fix the plug-in to hardcode "R'G'B'[A] u8" so it won't misbehave
on high bit-depth images, and make it work on all sorts of drawables,
not only "RGB*" (it will still always export RGB images).
(cherry picked from commit 74c9d835e8)
None of our load plug-ins have such a checkbox, so this is not
consistent. Moreover one you uncheck it, you just can't get back the
dialog until next GIMP restart. That's very bad usability.
(cherry picked from commit 948608e658)
This commit fixes the following error:
> attempted to install a procedure with a full menu path as menu label,
> this is not supported any longer.
Instead, if we want new items in menu, we should use
gimp_plugin_menu_register(). I add the calls, yet comment them out,
since I don't think we want these various conversion calls into the
provided filters. The proper way for data conversion should be through
babl/GEGL.
(cherry picked from commit 67a80c8667)
This is still very broken and it doesn't load well. But at least it
compiles!
All build errors (and a few warnings though not all) fixed.
(cherry picked from commit df8a20956b)
