This is the same issue as with IM000001.dcm mentioned in issue #313.
There are two problems: incorrect endian conversion for 16 bits per pixel,
and not handling photometric interpretation "MONOCHROME1", which means
minimum value is white instead of black.
The endian conversion was fixed as suggested in issue #313.
For "MONOCHROME1" we added a variable bw_inverted and we invert the pixel
value if that variable is true.
(cherry picked from commit e51ca66ee5)
Just like COLOR targa MAPPED (indexed) images with a size of 32 per
index should also have alphaBits set to 8 or else the images get
loaded incorrectly.
(cherry picked from commit a77131db3c)
Exporting an image to TGA fails with a crash when it's an indexed image
with alpha channel. We were not taking into account that even though
the output is 1 byte per pixel, the input should allocate memory for
2 bytes per pixel (1 color index and 1 alpha channel).
(cherry picked from commit 059599fc78)
Some images have huge amounts of XMP tag Xmp.photoshop.DocumentAncestors.
In certain cases more than 100000 values. This is apparently due to a bug
in certain versions of PhotoShop.
This makes deserializing it in the way we currently do too slow, probably
because of continuous reallocations after adding each value. Until we can
change this let's remove everything but the first 1000 values when
serializing. I think it is very unlikely there are any real cases where
more than a 1000 ancestor documents are referenced in an image. Testing
shows that this amount doesn't cause any serious slowdowns.
(cherry picked from commit b2c715b52b)
The gimp-2-10 patch contributed as !514 was slightly different from the
master one as !515, especially since the last one got the reviews. This
syncs the 2 codebases (making it easier to backport future patches on
the same piece of code) and do a few fixes.
- Syncing alignments.
- Fix a comment.
- Use g_build_filename() for properly creating paths rather than string
concatenations.
… rather than generic "gegl:load" and "gegl:save".
In particular, it means using "gegl:rgbe-load|save" for RGBE images and
"gegl:exr-save" for EXR exporting.
Without this, we could encounter weird run cases where for instance, we
would detect a RGBE image through the file magic number in GIMP,
redirect the load to file-gegl, but "gegl:load" only relies on file
extension. So if the file extension was not ".hdr", "gegl:load" could
redirect to a different handler operation meant for another format,
hence break proper loading. If no extension was matched, it could even
redirect to a fallback handler, such as Image Magick.
This breaks loading or saving images which we would be otherwise able to
load/save. And it could also have some security implications. So let's
fix this by setting the accurate operations to use for each specific
file formats we want to support through the file-gegl plug-in.
Note: this is the gimp-2-10 version of commit e8a31ba4f2 (`master`
branch) adapted to the older 2.10 API.
Note that the full magic should be "#?RADIANCE". Not sure why we only
use the first 2 characters. Do some software create these RGBE files
with just "#?" and we want to be able to read these? No other image
format use these 2 characters as the start of their own magic numbers?
Anyway let's keep like this for now. We'll see. If it makes a problem,
we might update to more accurate magic later.
(cherry picked from commit d5164072e0)
… implementation and Freedesktop portal.
This is an alternative to commit ef9c483771 (`master` branch) for the
2.10 series. On the dev branch, we simply get rid of the KDE portal
implementation, on the basis that by the time that GIMP 3 gets released,
most KDE users will have a recent-enough KDE with featureful Freedesktop
portal.
Yet for the 2.10 series, I am wary that there might still be many KDE
installations where maybe there is not even a Freedesktop portal. So I
just switch the test order. Now we use the X implementation in priority,
if we are running in X (it's still the most featureful and robust
version anyway). Then we test the Freedesktop portal. And finally we
test the KDE portal. I am guessing that if we encounter a KDE
installation with no Freedesktop portal but a KDE one, it's an old
version so we won't have permission issues.
See issue #5785.
When a channel is selected as bumpmap, the bump_format can be different
than it was before. However, we always kept the first bump_format, which
could be RGB, in which case trying to use it with a channel caused a
crash in GIMP.
To fix this we always update the bump_format if bumpmap is enabled.
(cherry picked from commit 7b7d616358)
# Conflicts:
# plug-ins/lighting/lighting-image.c
Freedesktop (XDG) portals are a collection of D-Bus APIs that work
across desktop environments, display servers and work within
containerized applications, like Flatpak. The internal implementation
can then choose to implement these in such a way that takes into account
security considerations, as well as making sure the user consents to
certain actions.
One such portal is the `Screenshot` portal, which contains a
`Screenshot()` method as well as `PickColor()`. We already use the
former for taking a screenshot, and this commit makes sure our color
picker also makes use of the latter.
By doing this, color picking is now possible on the major Wayland
compositors.
(Honestly, we should remove DE-specific backends like that of KWin, to
have less variation on the possible results of a color picking
operation).
Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/1074
(cherry picked from commit e82f6d5b0f)
See the comments in MR!424.
Basically realpath relies on false assumptions (probably ones which used
to be true when the API got created) on the max size of a path. Actually
nowadays paths can be much bigger than what the macro advertizes or can
even be unbounded.
The Linux version of realpath() allows the second parameter to be NULL,
in which case it would allocate the buffer, exactly for this reason
(written in the BUGS section on the man). Unfortunately this behavior is
not standardized in POSIX and the man from Apple I found does not
indicate it will do this.
So let's use g_canonicalize_filename() instead, which seems to do the
right thing. Similarly use g_strdup_printf instead of g_snprintf().
Cherry-picked from commit 6f4fac7715eb66a90727f931246c93cd8e13a819 with
some conflict resolution.
GNOME Shell has started restricting access for it's Screenshot D-Bus API
to internal components only [1] for security reasons. In other words,
this will start failing, so remove it in favor of just using the
freedesktop portal, which should always work.
[1]: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970
(cherry picked from commit 62953e6830)
This proved to be both an import and export issue.
Our import set expected format as RGB, causing garbled image output.
Our export for indexed images converted to grayscale first, although the
palette was correctly saved. This caused wrong palette indexes on import.
For indexed images, on import, we request the actual indexed format after
creating the layer with gimp_drawable_get_format, which gives us a correct
indexed Babl format.
Also added logic for indexed with alpha, although I have no sample images
to test this.
For indexed images on export we do the same: use gimp_drawable_get_format
to get an actual indexed Babl format.
(cherry picked from commit dec5ca2219)
# Conflicts:
# plug-ins/file-dds/ddsread.c
… series as well (it was already so in the `master` branch).
See discussion:
https://gitlab.gnome.org/GNOME/gimp/-/issues/7515#note_1318891
Basically it's probably possible to backport some changes and still
support an older version, but we clearly lack contributors on macOS so
the current unique one's decision matters most.
In cases where the whole EXIF MakerNote is invalid we still load that
MakerNote data and export it too, causing partial invalid EXIF metadata.
We don't need to explicitly save Exif.Photo.MakerNote at all, because
as soon as we try to save a brand specific tag exiv2 will create that
MakerNote tag itself.
So from now we don't save the MakerNote but only the tags that go in it.
In issues like #2159 where exiv2 doesn't parse all tags inside certain
brand specific MakerNotes correctly, we will still export invalid EXIF.
That is an exiv2 issue that we can't do much about unless we remove all
MakerNote metadata including those that we can read, which doesn't seem
like a good idea at all.
(cherry picked from commit 6840bb9eba)
Fix as suggested by Massimo with formatting adjustments by me.
The use of gulong and glong is not cross platform safe: on Windows it is
32-bit and on most other platforms 64-bit.
Let's use guint64 and gint64 instead.
(cherry picked from commit d2c5591088)
