This is the bug which triggered me to do previous commit because the
error message was talking about a procedure name. Now the error message
is right, but let's not have an error at all! ;-)
… of query_procedures().
Since our procedure list is now fully dynamic with runtime check, it's
much better to run it at every startup. Basically if some has updated
libheif with new encoders/decoders, we want GIMP to be aware at it at
next startup even if the plug-in has not been updated.
We didn't check whether TIFFSetDirectory succeeded nor did
we check TIFFReadScanline for failure which can cause
unresponsiveness.
We will not try to read a tiff page if setting its directory fails
and we will stop reading a page if reading scanline fails.
Since obj->type_data is also int anyway, multiplying by a double value
is unneeded anyway. So let's just make an integer multiplication.
Fixes the following warning:
> warning: using integer absolute value function ‘abs’ when argument is
> of floating point type ‘double’ [-Wabsolute-value]
The correct tag for sub images is Exif.SubImage instead of
Exif.Image. I also added Exif.Image.InterColorProfile since
that didn't seem to get deleted when saving without
color profile.
Also added a FIXME note since most of this stuff should be
genealized for all gimpmetadata handling.
libheif pc files provides variables which are actually older than our
minimum libheif requirement (so it's usable generically) to determinate
if libheif was built for HEIC/AVIF support. This is quite useful as we
had our share of annoyance with missing support of some encoder/decoder
even when libheif requirement was alright.
Also adding image/avif (if relevant decoder is present) to list of
supported mimetypes.
User can select color subsampling/pixel format
(YUV444, YUV420, RGB)
User can select encoder speed (Slow, Balanced, Fast)
Lossless option delivers visually lossless output
This is an extension containing a few demo plug-ins. This is good to
demonstrate the extension format. It will also allow to disable these
plug-ins (if at some point, one doesn't want to show these demo
plug-ins anymore).
And finally it deals with the fact that our plug-in code is stupid, as
it just tries to find the first executable with the same name (minus
extension) as the plug-in folder. This doesn't go well on Windows, where
the permission system is non-existent. So our code just ends up trying
to run the first file with a similar name in a plug-in folder. As the C
goat-exercise contains both an exe and the C source (and the system
probably returns files in alphabetic order), GIMP under Windows tries to
run the C source instead of the executable (this obviously doesn't go
well).
We could try to do more complex logics, like not aborting if the first
file run fails and try the next one in the plug-in folder. Or maybe just
rename the C file to another name. But any of these is just in the end
the proof that our plug-in discovery right now is just bogus. The
extension system is explicit, not based on randomly trying out files.
Plug-ins entry points are explicitly listed in the metadata manifest.
Also taking the opportunity to change the minimum size since I
apparently counted it wrong. The size always seems to be 46
starting from psp file-version 4 up to and including the current
version 13.
Even though "Export Image as HEIF" is not technically wrong (AVIF is AV1
encoding inside HEIF container), it is better to be more accurate.
Moreover as Daniel Novomesky was explaining in a MR, nowadays when we
say "HEIF", we usually mean "HEIC", whereas you'd use the explicit
"AVIF" naming for HEIF/AV1 images. This seems confirmed by Wikipedia
which says that HEIC is the "implied default codec for HEIF".
So let's just make the AVIF vs HEIF distinction here (I could have used
AVIF vs. HEIC which is even more explicit but I decided to keep the
less-specific yet more used HEIF naming).
... and also doesn't write out all the data, if it does a "goto out" for
any reason. A leaked file descriptor can prevent a file from being
renamed or deleted on Windows.
See also #3740.
Reviewer note (Jehan): this may not be the main issue as reporters were
not writing about export failure. So there is probably another case even
when the plug-in successfully wrote the TIFF image.
Since meson 0.43.0 (below our current requirement), 'symbol_prefix'
argument of gnome.generate_gir() allows an ordered list. If I prepend
'gimp_ui', it makes any gimp_ui_*() function to not start with 'ui_'.
In particular, GimpUi.ui_init() becomes GimpUi.init() which is much less
redundant.
Orientation is now handled by core code, just next to profile conversion
handling.
One of the first consequence is that we don't need to have a non-GUI
version gimp_image_metadata_load_finish_batch() in libgimp, next to a
GUI version of the gimp_image_metadata_load_finish() function in
libgimpui. This makes for simpler API.
Also a plug-in which wishes to get access to the rotation dialog
provided by GIMP without loading ligimpui/GTK+ (for whatever reason)
will still have the feature.
The main advantage is that the "Don't ask me again" feature is now
handled by a settings in `Preferences > Image Import & Export` as the
"Metadata rotation policy". Until now it was saved as a global parasite,
which made it virtually non-editable once you checked it once (no easy
way to edit parasites except by scripts). So say you refused the
rotation once while checking "Don't ask again", and GIMP will forever
discard the rotation metadata without giving you a sane way to change
your mind. Of course, I could have passed the settings to plug-ins
through the PDB, but I find it a lot better to simply handle such
settings core-side.
The dialog code is basically the same as an app/dialogs/ as it was in
libgimp, with the minor improvement that it now takes the scale ratio
into account (basically the maximum thumbnail size will be bigger on
higher density displays).
Only downside of the move to the core is that this rotation dialog is
raised only when you open an image from the core, not as a PDB call. So
a plug-in which makes say a "file-jpeg-load" PDB call, even in
INTERACTIVE run mode, won't have rotation processed. Note that this was
already the same for embedded color profile conversion. This can be
wanted or not. Anyway some additional libgimp calls might be of interest
to explicitly call the core dialogs.
It's done, all Python plug-ins have been either ported to the new API +
Python 3, or they have been discarded (and moved to gimp-data-extras for
whoever wants to salvage them).
Let's get rid of the outdated pygimp directory (whose code has not been
built in the master branch for years now anyway)! Woohoo!
shadow_bevel.py and sphere.py are unfinished and have been in the
"Unstable" only builds for years. This is probably not worth porting
them. Let's just delete them.
I have actually move these (as well clothify and whirlpinch removed
yesterday) to the gimp-data-extras repository so if anyone wants to
revive them, and port them to GIMP 3, they can start off from there.
Following Elad Shahar advice (cf. #4368), let's delete whirlpinch.py and
clothify.py.
The rational is that whirlpinch.py does the same thing as the existing
"plug-in-whirl-pinch" which is itself a compat plug-in to
"gegl:whirl-pinch" operation. Also the Python file has an explicit
command saying it is exactly the same algorithm, yet with no preview and
slower. Finally it was not even installed on stable build. It doesn't
look like there is any reason to keep it (it was probably a demo/test
Python plug-in).
As for clothify.py, a quick look at the short code shows it is exactly
the same algorithm as clothify.scm, with the same arguments and
installed on the same `Filters > Artistic` menu (except that the Python
version is not installed on stable builds).
So let's just keep the script-fu version as it has been the used version
until now, and there is no deprecation going on in one side or another.
So let's keep what already works.
Since the patch was initially contributed, some parts of the
introspection changed. First all GUI-related code is in a GimpUi module
now.
Also Gimp.get_pdb().run_procedure() is now using a list instead of a
GimpValueArray.
Note by reviewer (Jehan): merging this port as it was in GIMP 2.10
anyway, but is this even still needed code? This plug-in is not even
available on stable release, it looks like for-development only
benchmark, and I'm not sure if it's relevant anymore, especially in our
GEGL-fueled new world.
Please anyone who knows a bit more on the history of this plug-in and
the evolution of our gimp_drawable_foreground_extract() algorithm, feel
free to weigh in and tell us what this was for exactly and if it's still
relevant.
This is a basic port without any UI.
Invoking the plugin will just sort the entire palette based on
default parameters.
The original plugin had several broken options, which I tried to fix.
Plug-ins that work from different bindings probably want to use their
own list-type to specify arguments, rather than working with a more
cumbersome `GimpValueArray`.
This new API should make it less verbose. For example:
```
args = Gimp.ValueArray.new(5)
args.insert(0, GObject.Value(Gimp.RunMode, Gimp.RunMode.NONINTERACTIVE))
args.insert(1, GObject.Value(Gimp.Image, image))
args.insert(2, GObject.Value(Gimp.Drawable, mask))
args.insert(3, GObject.Value(GObject.TYPE_INT, int(time.time())))
args.insert(4, GObject.Value(GObject.TYPE_DOUBLE, turbulence))
Gimp.get_pdb().run_procedure('plug-in-plasma', args)
```
becomes
```
Gimp.get_pdb().run_procedure('plug-in-plasma', [
GObject.Value(Gimp.RunMode, Gimp.RunMode.NONINTERACTIVE),
GObject.Value(Gimp.Image, image),
GObject.Value(Gimp.Drawable, mask),
GObject.Value(GObject.TYPE_INT, int(time.time())),
GObject.Value(GObject.TYPE_DOUBLE, turbulence),
])
```
The XPM export plugin was saving the color `None` (transparency) to the
exported image palette for all images with an alpha channel, even if the
color was not used on any pixel.
Since it's nice to have `None` as the first color on the palette, mapped
to character ' ', and it could be too wasteful to scan all pixels twice,
the approach taken was to just undo it's premature insertion.
(cherry picked from commit 0a9bb2839e)
Existing code was returning only 1 out of 2 expected procedure names.
See !241 for the originally proposed patch by Rafał Mikrut (@qarmin).
Unfortunately the proposed patch also had another bug and was always
returning an empty list instead, and the contributor is unresponsive. So
let's just redo the patch and be done with it.
Also using g_list_prepend() instead of g_list_append() as it's usually
more efficient (to be fair here, for a size-2 list, it doesn't matter
much but it's good practice anyway) and order doesn't matter.
Thanks Rafał Mikrut for noticing the original bug!
Removed the WinMain specific stuff for the plug-in and determine
hInstance in twainMain which made porting a lot easier.
The _DEBUG enabled functions I have mostly left alone and
should be revised at a later time.
The proposed defaults for export should be the less destructive
possible. So for any 16 or 32 bpc GIMP images, since our HEIF plug-in
only supports up to 12 bpc, this should be what we export to.
This adds a blend mode for all known psp blend modes that were not
converted yet except for adjust.
I couldn't find any information about adjust and it's value of
255 suggests that it is not a normal blend mode.
Jehan