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.
Adds support for saving 8 and 16 BIT CMYK/A TIFF files using the
image's simulation profile. If no profile or a non-CMYK profile
is set for the simulation profile, naive conversion is used instead.
This is the consequence of previous commit. Plug-ins' label and
documentation are now localized before sending these data to GIMP core.
In other words, we replace N_() macros with basic gettext calls.
We only set tiff_mode for images with bps < 8, but we also use it for
8 bps grayscale images to detect if MINISWHITE needs to be converted.
So, let's always set tiff_mode for PALETTE, MINISBLACK and MINISWHITE.
generated by matlabs blocproc function
Based on the suggested solution by Massimo, we should not compute the
remaining pixels per line but only at the end of the whole block, be it
tile or scanline.
I have not been able to find bw or palette examples that use load_separate
instead of load_contiguous, so that case is not tested. But, it also
doesn't make much sense to have planar when you have just one plane.
In a previous commit 1, 2 and 4-bit B/W images were converted to grayscale.
However, it seems that there is more of a use case for these images to be
handled as indexed, even though technically they can be considered
grayscale.
Also, the only way to export these images again in the same format, is to
have them as indexed.
So, let's change this back, so that these kind of images will be opened
as indexed. With a reminder that in the future we could add an option
at loading time where the user can choose whether they prefer it to be
loaded as indexed or grayscale.
We use grayscale mappings, that we moved in the previous commit, to
add a palette to these grayscale images.
In preparation of using some of them earlier, we move the variables
used for grayscale mapping of 1, 2 and 4-bit per pixel images to the
top of file-tiff-load.
Hence avoiding the stderr messages. These are going to be localized with
centrally installed catalogs "gimp*-std-plugins", "gimp*-script-fu" and
"gimp*-python".
We now handle core plug-in localizations differently and in particular,
with kind of a reverse logic:
- We don't consider "gimp*-std-plugins" to be the default catalog
anymore. It made sense in the old world where we would consider the
core plug-ins to be the most important and numerous ones. But we want
to push a world where people are even more encouraged to develop their
own plug-ins. These won't use the standard catalog anymore (because
there are nearly no reasons that the strings are the same, it's only a
confusing logic). So let's explicitly set the standard catalogs with
DEFINE_STD_SET_I18N macro (which maps to a different catalog for
script-fu plug-ins).
- Doing something similar for Python plug-ins which have again their own
catalog.
- Getting rid of the INIT_I18N macro since now all the locale domain
binding is done automatically by libgimp when using the set_i18n()
method infrastructure.
As raised on social networks, the big label grows the horizontal size of
the dialog. Make the label wrappable and give it a smaller wanted size
(otherwise, just making it wrappable is not enough and the dialog is
still too big when first appearing, because of how GTK handles such
widgets :-/).
Actually I realized that using BigTIFF is not the only valid alternative
here. We can also try to use a better compression algorithm (or any if
"None" were selected) and try again to export as ClassicTIFF.
So don't check the option ourselves and don't set it insensitive. Let
one choose fully what they prefer to do.
… because we reached max TIFF size.
We detect the specific TIFF error (by string comparison so it's a bit
weak IMO yet it doesn't seem like libtiff provides anything better;
let's trust they don't change their error strings), then we reopen the
export dialog, pre-checking the BigTIFF checkbox newly created (and
making it insensitive). We still fail with error if an error happens the
second time (even for the same error).
Recent libtiff supports loading BigTiff automatically so we didn't have
anything to do there (as long as a recent libtiff was used). For
creating a BigTIFF though, we simply needed to add a "8" flag to
TIFFOpen/TIFFClientOpen when creating a new image (i.e. using "w8"
mode) as explained here in the "Implementation Strategy" section:
http://www.simplesystems.org/libtiff/BigTIFFProposal.html
What this commit does:
- Explicitly bump our libtiff requirement to version 4.0.0 or higher
(which is where BigTiff support appeared).
libtiff 4.0.0 was apparently released on 2011-12-22 and is available
on all current distributions, so it's probably not a problem.
- Switch to detect libtiff with a pkg-config test (added in libtiff
commit faf5f3eb before 4.0.0 release, so it's fine) instead of
function checks.
(Note: meson was already detecting for libtiff-4 with pkg-config,
which was obviously wrong since it should have mimicked autotools, but
well… then changes were minimal on meson)
- Add a new "bigtiff" boolean argument to the "file-tiff-save" PDB
procedure, FALSE by default. I set this as the first argument as I
figure that choosing the format you want is quite a major choice.
Unless I misunderstood something, since BigTIFF is really designed to
be an evolution of TIFF with a "minimum change strategy", i.e. mostly
using 64-bit instead of 32-bit offsets, everything which is possible
in TIFF will be in BigTIFF (and oppositely as well, except of course
having huge files) so there is no need to have 2 separate procedures.
- Adding this new argument to the GUI dialog as a checkbox.
- Tweak the load and export procedures' documentation strings to make
clear we support both TIFF and BigTIFF.
Note: interestingly there doesn't seem to be a separate mimetype for
BigTIFF so nothing to update on this side.
- Tweak the procedure labels too to mention BigTIFF. Since BigTIFF is
still a different format (though very closely resembling) from TIFF,
unlike some others which are just extensions embedded in a TIFF file
(like GeoTIFF we recently added), I figure it deserves to be
explicitly cited.
GLib has a specific type of NULL-terminated string arrays:
`G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`.
By using this type, we can avoid having a `GimpStringArray` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GStrv`, we allow other languages to pass on string lists 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 string 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
If you first open a multi page TIFF, exiv2 generates EXIF tags for the
first 3 pages in the form of Exif.Image.<tags>, Exif.Image2.<tags>,
Exif.Image3.<tags>. When exporting with EXIF saving enabled, exiv2 thinks
it needs to save TIFF pages for the EXIF metadata of the second and third
page too. Those pages saved by exiv2 contain only metadata no real image
data and give warnings when loading.
The EXIF tags read from page 2 and 3 are only the basic image specs. We
don't use those, nor do we add tags to it. Until we support handling of
metadata for those pages and exiv2 has better support for all TIFF pages
beyond the first few, I see no reason to save this information.
So for now lets just delete all tags that start with Exif.Image followed
by a number.
On Windows there is a long standing issue in its File Explorer. When
GIMP exported as a multi page (multi-layer) TIFF with thumbnail saving
enabled, then the Windows thumbnailer apparently gets stuck and does not
close the TIFF file when browsing a folder. Because those files are not
closed it is impossible to delete them. This issue has been reported
many times over the years to Microsoft without any reaction.
Investigation showed us that this lock up only happens when we save the
thumbnail as a subifd. To resolve this issue we change this and now let
exiv2 handle our thumbnail saving, just as for other image formats. For
TIFF this means the thumbnail is saved as the second page of a TIFF.
Previous commits have made sure that it is now easier to recognize a TIFF
page as a thumbnail and to make sure we don't load thumbnail TIFF pages.
Since saving as a subifd is what made TIFF thumbnail saving different
from other formats, this commit consists of only removal of code.
TIFF image pages can specify what type of image that page represents.
If the page is marked as FILETYPE_REDUCEDIMAGE we will consider it to be
a thumbnail and filter that out of the list of pages that can be selected
to be loaded.
In addition to that we will try to recognize certain pages as thumbnail
that don't have the subfiletype tag set.
We will consider it a thumbnail if:
- It's the second page
- PhotometricInterpretation is YCbCr
- Compression is old style jpeg
- First page uses a different compression or PhotometricInterpretation
If these conditions are true the page will also be filtered out.
We could consider having an option whether to filter out thumbnail pages.
Since in the situation up until now we also don't load thumbnails, I think
this should be considered as a separate feature.
In PNG, JPEG and TIFF export plug-ins which use the new API, use our new
function to set widget sensitivity.
Note that part of it is similar to commit 6a2910bd3b on `gimp-2-10`,
making "Save GeoTIFF data" checkbox insensitive when there are no such
data available (this feature was late on the main branch as we rushed
for 2.10.24 release).
The gimp_drawable_type() is an issue though as gimp_drawable_get_type()
is already defined as a common GObject API.
Though I'm actually wondering if GimpImageType is well called. Rather
than Type, shouldn't we go with ColorModel?
sed -i 's/\<gimp_drawable_bpp\>/gimp_drawable_get_bpp/g' "$@"
sed -i 's/\<gimp_drawable_width\>/gimp_drawable_get_width/g' "$@"
sed -i 's/\<gimp_drawable_height\>/gimp_drawable_get_height/g' "$@"
sed -i 's/\<gimp_drawable_offsets\>/gimp_drawable_get_offsets/g' "$@"
s/gimp_image_base_type/gimp_image_get_base_type/
s/gimp_image_width/gimp_image_get_width/
s/gimp_image_height/gimp_image_get_height/
Sorry plug-in developers, more porting work! But really this seems like
the right thing to do in order not to get stuck with inconsistent naming
for many more years to come.
- Miniswhite and Minisblack TIFF images with bps 1, 2 and 4 were loaded as
indexed. We change this to grayscale since that's what they are.
- Fix not handling of miniswhite for 8 bps.
Fixes issue #1838 Tiff image display wrong (tiff tags not interpreted), black
line instead of white line.
Fixes issue #2680 Failure to load 4-bit grayscale TIFF layers.
Testing some fuzzed TIFF images from the imagetestsuite
revealed we should add some more checks for valid input
and function returns.
We now stop whenever the reported bps is above 64.
Even if it is valid we can't handle it anyway and I'm not
aware of any actual valid image like that.
Make sure the image dimensions are valid and in the range
that GIMP can handle.
Return directly when TIFFReadRGBAImage fails instead
of doing further processing and improve the error message.
Check result of TIFFReadTile and return if it fails.
Certain broken tiff fax images can cause a huge amount of warnings
which on Windows eventually causes GIMP to run out of resources
and then crash.
Since the avarage user won't have much use for these warnings
let's just only send them to stderr.
Similarly to the previous commit, it is not only about using the new
API. I also make sure we do not assume that parasite data is
nul-terminated. In many places, we were just assuming so because these
were supposed to be parasite our code set. Yet these are data input
contained in files which can be wrong for any reason (corrupted file,
bugs, other scripts/plug-ins editing these parasites…). So instead of
assuming string parasites are always correctly formatted, I make sure
they are nul-terminated by passing them through g_strndup() when
necessary.
Sabri Ünal