Update processing has to be done on the main thread to avoid
problems with GTK thread safety.
(cherry picked from commit 7f257a3a33)
Conflicts fixed:
app/gimp-update.c
We were using GIMP_UNSTABLE extensively to differentiate development
from stable code. But there is actually another level of development
code. Basically GIMP_UNSTABLE tells you are on the development branch,
e.g. for current branches, that you are on 2.99.* versions (vs. 2.10).
This depends on the minor version oddness.
GIMP_RELEASE will tell you if it's a release or a in-between-releases
code. This works with the micro version which must be even on release.
Any odd number means you are basically using random git code.
There can be any combination of GIMP_RELEASE and GIMP_UNSTABLE. For
instance 2.99.12 is a release of the unstable branch, whereas 2.10.33 is
development code of the stable branch.
I use this first in the update code as we were using GIMP_UNSTABLE for
both concepts but it made it harder to test. Now:
* GIMP_DEV_VERSIONS_JSON environment variable is only available on
development code, not on release (whether stable or unstable).
* The weekly check limitation is also only for releases (dev code just
check at every startup to quickly detect issues and regressions).
* Whether to look on testing website or public website json file depends
on the code being a release or not.
* Finally only whether to check "DEVELOPMENT" or "STABLE" sections in
the json file depends on whether we are on stable or unstable
branches.
(cherry picked from commit fbb5b40345)
I.e. non-macOS and non-Windows. For these, we don't really care about
the startup check usually (which is normally disabled anyway, at least
as a default), but we still care about the version check to work when
explicitly requested through the "About" dialog's button.
and import as inches
When GIMP's display unit was mm, our PSD export converted the X and Y
resolution as if a conversion from mm to inch was needed.
However, PSD's resolution is always measured in pixels per inch, so a
conversion is never necessary.
Removing the conversion, resolves the issue.
(cherry picked from commit 24886f91b1)
Add the info about max dimension of WebP with WEBP_MAX_DIMENSION macro.
There is also a test about (picture->width / 4 > INT_MAX / 4), resp.
height, but this should anyway never happen as the C spec says the
smaller range for int is [-32767, 32767], which is an order bigger than
the current WEBP_MAX_DIMENSION (16383).
So we are probably fine assuming all VP8_ENC_ERROR_BAD_DIMENSION errors
will happen because of WEBP_MAX_DIMENSION.
(cherry picked from commit dfb7d2543a)
Actually our X11 implementation is right, and the implementation from
the Freedesktop portal is "as far as it can do", i.e. that we get the
returned RGB value, which is unfortunately in display space. And it
doesn't return any space information together (we don't even know which
display the color comes from, in multi-display setups).
Therefore let's check if we are running GIMP on X11 and if so, let's
call this implementation first.
See this report on xdg-desktop-portal to get proper space info:
https://github.com/flatpak/xdg-desktop-portal/issues/862
(cherry picked from commit 9b21688501)
Cherry-pick note: GIMP 2.10 on Linux will just run on X11 even inside
Wayland (XWayland) so there is no need to check anymore if we are
actually running on X11 with GDK_IS_X11_DISPLAY() (to be more accurate:
you can't on GDK 2!). So now if X11 is compiled in, we simply use the
default color-picking implementation and drop portal calls. As simple as
that.
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.
(cherry picked from commit 0ad54f863a)
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.
(cherry picked from commit ced071a8ee)
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.
(cherry picked from commit 18d466df7f)
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.
(cherry picked from commit 853e9d5cb4)
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.
(cherry picked from commit ac5a6e56b7)
Apparently some layers in PSD files can have extra channels which we
did not account for when computing destination offsets, causing crashes.
So let's make sure we don't include the "extra" channels when computing
the offsets by introducing base_channels. We also move the alpha channel
in the spot of the first extra channel (even though it seems, based on
the one example we have, that the extra channel might be the same as
the alpha channel).
(cherry picked from commit 5fbd06629d)
# Conflicts:
# plug-ins/file-psd/psd-load.c
Just use the image format as-is. The only problem now is that we don't
support all formats for loading in file-raw yet.
(cherry picked from commit 01e0675f67)
Conflicts:
plug-ins/common/file-raw-data.c
