A recent addition to load layers in Sketchbook TIFFs contained a typo in
code specific to big endian machines, making it fail to build there,
which wasn’t caught in CI.
In addition to this fix, use the appropriately named macro to convert
from little endian to big endian.
Signed-off-by: Nils Philippsen <nils@tiptoe.de>
This patch adds support for loading Sketchbook
TIFF layers.
Alias/Autodesk Sketchbook used metadata tags
to store information about layers. This is a
separate implementation compared to Adobe,
stored in TIFFTAG_ALIAS_LAYER_METADATA.
The first directory contains the image metadata
and the layers are stored in SubIFDs, using the
same metadata tag for layer-specific properties
such as opacity and visibility.
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!
Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.
As an aside, this also fixes#10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.
Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.
Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
...in non-interactive cases.
gimp_export_image () handles various
tasks like rasterizing NDE filters. It only
runs in interactive cases however, so if the
users calls gimp-file-save the filters are
not exported.
Since Jehan removed the hidden dialogue
in 0dc9ff7c, we can now safely call
gimp_export_image () in all cases to make
image export more consistent. This step is
also preparation for setting up the new
API with GimpExportOptions.
...to paths
Follow-up to d0bdbdfd. Changes all
gimp_vectors_* () PDB to gimp_path_* ()
and renames relevant PDB files from
vectors to path.
The next step will be to rename
GimpVectors in libgimp to GimpPath,
removing the last (public) trace of it.
...to paths
The first step in converting GimpVectors
to GimpPath. The PDB API for any
gimp_image_*_vectors () is now
gimp_image_*_paths ().
This commit only covers libgimp, and
the app/core versions will be renamed in
a following commit.
With the new API introduced int d1c4457f,
we next need to port all plug-ins using
the argument macros to functions.
This will allow us to remove the macros
as part of the 3.0 API clean-up.
Port all plug-ins to retrieve the layers
directly from the image rather than
having them passed in. This resolves some
issues with introspection and sets the
foundation for future API work.
Though it's not visible and could happily wait for after GIMP 3 release, this
was annoying when grepping. Just did a quick cleanup.
I also removed gimprc.common which is a forgotten remnant from the autotools
build.
Resolves#10932
Since GIMP distinguishes between saving
XCF and exporting image like PNG,
we should change the PDB to show
export rather than save in the function
calls.
When loading Photoshop metadata from TIFF images, the size of the data
in the temp file was often incorrect.
This happens because run_mode is usually GIMP_RUN_INTERACTIVE when
run from within GIMP. In interactive mode, the last saved config values
take precedence over the ones set in the function call, which is not
what we want in this case.
We would prefer to use interactive here, because then we can show a
dialog with a list of unsupported Photoshop features that were found
inside the image.
For now, we will use GIMP_RUN_NONINTERACTIVE and accept that we can't
do that at this time. This way we will at least have the correct values
when processing the Photoshop data.
If we leave a space between the macro name and opening parenthese for argument
lists, the args are not considered macro args (which will be discovered when
using it). I experienced this issue while testing code on some plug-in
yesterday, so thought I might as well fix all these broken macros for casting to
the specific GimpPlugIn subclass, so that we won't have a next time.
The gimp_procedure_run() already existed, though it was with an ordered
GimpValueArray array of arguments. Its usage feels redundant to the series of
gimp_pdb_run_procedure*() functions (which is confusing), but
gimp_procedure_run() was actually a bit more generic, because it does not
necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a
local GimpProcedure, such as the case of one procedure which would want to call
another procedure in the same plug-in, but without having to go through PDB. Of
course, for local code, you may as well run relevant functions directly, yet it
makes sense that if one of the redundant-looking function is removed, it should
be the more specific one. Also gimp_procedure_run() feels a lot simpler and
logical, API wise.
A main difference in usage is that now, plug-in developers have to first
explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when
they wish to call PDB procedures on the wire. This was done anyway in the
gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name
directly).
Concretely:
* gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and
gimp_pdb_run_procedure_valist() are removed.
* gimp_procedure_run() API is modified to use a variable args list instead of a
GimpValueArray.
* gimp_procedure_run_config() and gimp_procedure_run_valist() are added.
* gimp_procedure_run_config() in particular will be the one used in bindings
which don't have variable args support through a (rename-to
gimp_procedure_run) annotation.
Passing (name, type, value) triplets is actually useless because we can get the
type information from the procedure/config anyway. That only adds one more
verification to do. Let's just change the function so that we pass (name, value)
couples instead, pretty much like in `g_object_set()`.
As far as plug-in API is concerned, at least the calling API, order of arguments
when calling PDB procedures doesn't matter anymore.
Order still matters for creating procedures with standard arguments (for
instance, "run-mode" is first, then image, or file, drawables or whatnot,
depending on the subtype of procedure), but not for calling with libgimp.
Concretely in this commit:
- gimp_pdb_run_procedure_argv() was removed as it's intrinsically order-based.
- gimp_pdb_run_procedure() and gimp_pdb_run_procedure_valist() stay but their
semantic changes. Instead of an ordered list of (type, value) couple, it's now
an unordered list of (name, type, value) triplets. This way, you can also
ignore as many args as you want if you intend to keep them default. For
instance, say you have a procedure with 20 args and you only want to change
the last one and keep the 19 first with default values: while you used to have
to write down all 20 args annoyingly, now you can just list the only arg you
care about.
There are 2 important consequences here:
1. Calling PDB procedures becomes much more semantic, which means scripts with
PDB calls are simpler (smaller list of arguments) and easier to read (when
you had 5 int arguments in a row, you couldn't know what they refer to,
except by always checking the PDB source; now you'll have associated names,
such as "width", "height" and so on) hence maintain.
2. We will have the ability to add arguments and even order the new arguments in
middle of existing arguments without breaking compatibility. The only thing
which will matter will be that default values of new arguments will have to
behave like when the arg didn't exist. This way, existing scripts will not be
broken. This will avoid us having to always create variants of PDB procedure
(like original "file-bla-save", then variant "file-bla-save-2" and so on)
each time we add arguments.
Note: gimp_pdb_run_procedure_array() was not removed yet because it's currently
used by the PDB. To be followed.
This is not the main reason for the specific output in #9994. These ones are
more probably because of similar usage in GTK (which updated its own calls to
g_file_info_get_is_hidden|backup() in version 3.24.38). But we should likely
also update the various calls we have to use the generic
g_file_info_get_attribute_*() variants.
To be fair, it is unclear to me when we can be sure that an attribute is set.
For instance, when we call g_file_enumerate_children() or g_file_query_info()
with specific attributes, docs say that it is still possible for these
attributes to not be set. So I assume it means we should never use direct
accessor functions.
The only exception is that I didn't remove usage of g_file_info_get_name(),
since its docs says:
> * Gets a display name for a file. This is guaranteed to always be set.
Even though it also says just after:
> * It is an error to call this if the #GFileInfo does not contain
> * %G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME.
Which is very contradictory. But assuming that this error warning was
over-zealous documentation, I kept the direct accessors since they are supposed
to be slightly more optimized (still according to in-code documentation) so
let's priorize them when we know they are set for sure.
GLib has a specific type for byte arrays: `GBytes` (and it's underlying
GType `G_TYPE_BYTES`).
By using this type, we can avoid having a `GimpUint8Array` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GBytes`, we allow other languages to pass on byte arrays as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with byte arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
This allows file-psd-load-metadata to show a warning message like the
PSD plug-in does when unsupported features are loaded.
As PSD metadata does not store rasterized versions of fill layers,
a new option is added to show these layers are dropped entirely unlike
with PSDs.
The dialog title changes based on which plug-in called it.
This adds the PSD metadata plug-in procedure call to the TIFF
plug-ins, as part of implementing issue #7549.
Also implements the import part of issue #2921.
TIFFs can have both image and layer-level metadata.
The load_paths() function was removed, as the PSD plug-in should
handle this now.
- This is unneeded in all import procedures. See previous commit. Note though
that this is not because of a change in previous commit. This was already
useless previously. The file set with this PDB function was overridden by the
core anyway (i.e. even before the previous commits).
In app/file/file-import.c:file_import_image(), the imported file is correctly
set (so there is no need to set it from plug-in, which anyway libgimp's
gimp_image_set_file() was not doing) and the XCF file is reset to NULL
(rendering the call to gimp_image_set_file() in a GimpLoadProcedure useless).
- Similarly, this is a useless call in export procedures because
app/file/file-save.c:file_save() overrides such call too. I could only see one
such case for JPEG export, which was quite useless.
- Finally in other types of plug-ins, setting a non-XCF file extension was
interfering with the save feature (similarly to commit e6e73e14c7). I only
fixed the screenshot implementations doing such a thing.
- I left a few usages which will have to be looked at more in details later.
I had a TIFF file which would crash while triggering an error, inside g_logv()
code (and according to the stacktrace, even probably inside some lower level
printf implementation code).
The reason was that I already processed the variable list with
g_strdup_vprintf() and printf didn't like this va_list being reused, then
segfaulted with some "Cannot access memory at address" error.
The alternate fix was to first copy the va_list in the first use with
va_copy()/G_VA_COPY, yet since we already processed the format data, I thought
it was useless to do this. Let's just directly use the formatted string.
Adds a toggle to let users load TIFF pages with FILETYPE_REDUCEDIMAGE
tags. The specs do not state that these are always thumbnails, and they
may have other uses. We assume that if only one page with this metadata
exists then it is a thumbnail; otherwise, the toggle option is
enabled on load.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
created by Adobe Lightroom 5.1
Adobe products are known to write incorrect RichTIFFIPTC tags in TIFF
images.
Since libtiff correctly detects and handles this there is no real need
for end users to be warned. So instead of a warning we will only output
a message to stderr.
This is essentially the same check as done in gimp_image_set_resolution,
but doing it here means we can load the image instead of throwing an
error.
We still need to get replacement xres and yres values, because these are
used to compute layer_offset_x_pixel and layer_offset_y_pixel.
Image m2-d0f86ab189cbe900ec389ca6d7464713.tif from the imagetestsuite
is a fuzzed image with an invalid very high number for the channel count.
This causes GIMP to become unresponsive for a very long time. Possibly
trying to allocate memory for all channels or another cause related to
the high number of channels.
Let's go for a more "reasonable" limit of 99 channels like we also do
for Photoshop images and show a message when we find an image with more
channels.
When loading a TIFF image using a script/plug-in in non interactive mode,
we did not initialize the list of pages, causing a crash when trying to
access it.
So, always initialize this list when non interactive.
Due to a change in the format string in libtiff, warnings about unknown
fields were not filtered out anymore.
Adjust our filtering of warning messages so we catch this again since
end-users don't need to worry about this and we don't need the
possible extra issues.
Now that images can contain their simulation profile,
we can use gimp_image_set_simulation_profile() to retain
the CMYK profile when a TIFF image is loaded.
It will then be accessible in GIMP's Image menu.
Nils Philippsen