Dynamic exception specification is not allowed in c++-17. The enforcement needs
to be relaxed for the kimg_exr plugin when using openEXR versions older than 2.3.0.
New libavif 0.9.1 apply some very strict standard compliance
checks by default. Unfortunately, it rejects many files made by
libheif-based apps (GIMP, ImageMagick) in the past.
libheif 1.12.0 (released on May 5, 2021) addressed the problem,
but it would be good to extend grace period, allowing other
projects and distributions to upgrade to fixed version.
Allow saving Qt-unsupported variants of ICC profiles, they could be
correctly handled by apps with wider color management support.
Change way how QColorSpace is created to avoid
rare problems in some apps.
It's not a huge problem since QIODevice::seek() is a noop on negative values but it's
just better to bail out as soon as possible when we realize the file is
broken
The formula was found in Qt's qt_pixelMultiplier (qpagesize.cpp)
as called by the deprecated setPaperSize method (when the unit is
DevicePixel)
NO_CHANGELOG
The HDR QImageIOHandler plugin only supports the default image orientation (-Y +X) in .hdr files. It mixes up the width and height however, resulting in non-square images not loading.
This fix adds a check for the standard image orientation in the file and returns false (with error message) if that fails.
If it succeeds, it takes the height from the -Y component, and the width from the +X component, resulting in successful loading of the image.
Add autotest images for landscape and portrait HDR (Radiance RGBE) loader
BUGS: 433877
Due to various double vs float arithmetic,
some primaries could be rejected by Qt.
If necessary, we adjust the values so they
will be accepted by Qt.
Remove newline from the ends of error strings.
According to relicensecheck Brad is OK with changing LGPLv2 to LGPLv2+,
which is required to be compatible with the LGPL-2.1-or-later licensed
source files.
Since QImage does sanity checking for overflows and stuff wrt.
dimensions and depth, check for QImage::isNull() as early as possible to
see if there's some funky business going on.
Also tried to add some checks wherever we wrote to "raw" memory.
Unit tests pass, and tested converting some files from
https://samples.ffmpeg.org/image-samples/ to pngs, and that seemed to
work.
Reviewed By: aacid
Differential Revision: https://phabricator.kde.org/D24367
We added our own implementation of rand_r to make sure we use the same
as Gimp, and to make Windows work. But we need to actually use it
everywhere.
Discussion in Differential:
Differential Revision: https://phabricator.kde.org/D25267
We now support up to and including version 11 of the XCF format, earlier
it only supported version 1 (from 1997, according to the XCF spec).
Biggest difference seems to be that they changed to 64bit for offsets
from version 11 and upwards, otherwise it's mostly just newer enum
values and theoretically major stuff that we don't really need to care
about to get a thumbnail (e. g. linear vs. perceptual RGB).
We still don't support all features, but now it handles that more
gracefully and should at least create thumbnails that are usable. It
should also be easier to update in the future if/when there comes new
versions.
Also added a test file created with the latest version of Gimp
(2.10.18).
Reviewed By: aacid
Differential Revision: https://phabricator.kde.org/D25937
Summary:
Instead of directly casting the quint8 to PicChannelEncoding we just store the quint8
and compare it to the possible PicChannelEncoding values when needed
oss-fuzz/19344
Reviewers: dfaure
Reviewed By: dfaure
Subscribers: dfaure, security-team, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D25937
Summary:
The fact that we don't know the property is most of the times not fatal,
so what we have to do is just "skip" the property and hope for the best
BUGS: 411327
Reviewers: cfeck, apol, vkrause
Reviewed By: vkrause
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D24114
Summary:
QDataStream reads 64 bits when reading into a float unless you tell it to use SinglePrecision,
since floats in xcf are 32 bit, do that
Reviewers: cfeck, apol, vkrause
Reviewed By: vkrause
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D24113
Tested with HDR images from hdrihaven.com
* Loading in KolourPaint works
* Thumbnails in Dolphin work
Reviewed by: aacid
Differential Revision: https://phabricator.kde.org/D23811
Summary:
Make sure whole of pixel_size in pixel has data either because it was
read or because we set it to 0
oss-fuzz/14565
Reviewers: dfaure, apol, vkrause
Reviewed By: vkrause
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D23739
