GIMP was exporting certain BMP images with 1, 4, 8 and 24 bpp
with an incorrectly set value of BI_BITFIELDS for compression,
see issue #6144.
According to the specification this is not supported but testing
shows that many image viewers and editors load these
images correctly.
Since allowing these unsupported values for bpp does not
seem to have any negative side effects and is easy to
implement let's add this.
(cherry picked from commit e55e078245)
The Microsoft specification for BITMAPV5HEADER says that
BI_BITFIELDS is valid for 16 and 32-bits per pixel, but we
were also using this flag for other values of bpp when
no rle compression was used.
Since this specification doesn't mention 24 bpp or other
values use BI_RGB instead.
(cherry picked from commit d8c164ced3)
Information in issue #6200 revealed that 0 as default value for
the blue channel is a lot more common than 255 so let's use
that instead. The discussion and testing revealed no negative
effects for the other formats that use the same code to
initialize the memory to read blocks of image data.
(cherry picked from commit 691548579a)
Since older versions of our GIMP dds file exporter incorrectly
saved BC5 dds images with the red and green channels
swapped we should fix that. Since the exporter already
wrote the plug-ins version number and that it is written by
GIMP we can check for these incorrect images.
To enable that we increase the plug-ins revision in this
commit and swap red and green channels for images
that have an older version number and are of the
correct type.
(cherry picked from commit a4cc8b7070)
# Conflicts:
# plug-ins/file-dds/dds.h
When the "Omit hidden layers and layers with zero opacity" option is
set, this property was only checked on non-group layers. So if we had
non-hidden layers inside hidden layer groups, they ended up exported,
which is not the expected behavior.
See https://gitlab.gnome.org/GNOME/gimp/issues/4425#note_675350
(cherry picked from commit 24a0b0c53a)
If we were loading multi page tif images as layers then only the tif pages
that had a color profile attached would get set as linear (and each tiff page
can have a color profile). Since most of the time only the first page has a
color profile this caused us to load linear tiff pages incorrectly.
Also we were overwriting the color profile if there was more than one since
GIMP can only load one per image. Instead of using the last one we see
use the first one and notify if we encounter more than one.
(cherry picked from commit c05abcefc6)
# Conflicts:
# plug-ins/file-tiff/file-tiff-load.c
My fix in commit 9e4aa586f7 was not enough because CLEANFILES apparently
would only be processed on Makefile.am (i.e. with automake). Just remove
the file explicitly in the distclean rule.
(cherry picked from commit dfc4ecfc4c)
Now the distcheck job fails with the following error:
> ERROR: files left in build directory after distclean:
> ./po/.intltool-merge-cache.lock
> ./po-plug-ins/.intltool-merge-cache.lock
> make[1]: *** [Makefile:1155: distcleancheck] Error 1
There is definitely some change which happened on Debian packages,
either on intltool-merge itself, or something around, because these are
behavior breakage. We never set such `.intltool-merge-cache.lock` lock
files ourselves, so obviously we should not be the ones to clean these.
This is only a workaround which should be removed once upstream fixed
the issue.
(cherry picked from commit 9e4aa586f7)
We have a sudden CI failure which is maybe because of a change of
intltool-merge. We believe it might be because of a missing directory.
Let's test making it before running the command.
Fixes:
> /usr/bin/intltool-merge ../../../po-tags
> ../../../data/tags/gimp-tags-default.xml.in gimp-tags-default.xml -x -u
> -c ../../po-tags/.intltool-merge-cache
> No such file or directory at /usr/bin/intltool-merge line 396.
(cherry picked from commit 845f1c81ed)
This fixes issue #6065 and part of #2680.
Sometime after GIMP 2.8 loading of 2 and 4 bit tif images,
both grayscale and indexed, got broken.
I added routines for handling 2 and 4 bit tifs based on
the handling of 1 bit images.
(cherry picked from commit 991e99f08a)
By using a logging domain we can filter the messages and can choose to
only see them when needed. They seem to be leftovers from coding or
debugging but I don't wanna invest too much time into this.
(cherry picked from commit 08afb7d03b)
metadata-editor and metadata-viewer did return GIMP_PDB_SUCCESS when
loading the dialog ui failed, we changed this to GIMP_PDB_EXECUTION_ERROR
and now use a GError to report it back to GIMP.
In metadata-editor also improve the error handling when loading the calendar
dialog fails.
The error also only showed in the console so change that to show a dialog
or the error console.
(cherry picked from commit 0ffee001bf)
# Conflicts:
# plug-ins/metadata/metadata-editor.c
# plug-ins/metadata/metadata-viewer.c
The string parsing for gps longitude/latitude was not taking all
possible values into account and also the seconds part was
not saved with enough detail.
For altitude lets also increase the detail a bit from .1m to
.10m.
(cherry picked from commit 3d9a9fbbf3)
# Conflicts:
# plug-ins/metadata/metadata-editor.c
By using g_log with G_LOG_LEVEL_MESSAGE and empty domain
name we make sure the failure to write a tag will be seen by
the user in GIMP's user interface (error console or error
dialog).
(cherry picked from commit c4fa4fcda0)
Adding metadata-tags to Makefile.am for
the metadata-viewer since until now it was only used in
the metadata-editor.
The Exif gps metadata tags for longitude, latitude and
altitude get special handling to show them with more
precision and let the string parts be translated.
(cherry picked from commit 34407a6b7e)
# Conflicts:
# plug-ins/metadata/meson.build
# plug-ins/metadata/metadata-viewer.c
The abbreviations M for meter and FT for foot/feet were written in uppercase.
However the offical abbreviations are lowercase so let's just follow that and
make them lowercase here too.
Above and Below Sea Level were using camel case with every word starting
with an uppercase letter and were used on the label of a combobox option
for gps altitude reference. Using standard casing with only the first word
using a capital seems better in this case.
a capital
(cherry picked from commit 23fa5c7ef7)
