Where possible, QIODevice::peek has been used instead of transactions or instead of using ungetchar() for sequential access devices and seek() for random access devices.
Furthermore:
- RAS format gained the ability of read on sequential devices.
- Removed unused code in XCF (still related to ungetchar and sequential devices).
- These changes should prevent errors like the ones fixed by MR !258
While working on MR !230 I noticed that the options read I entered into several plugins could not be read after reading the image.
**The patch fixes problems reading options in plugins and adds option checking in the readtest.cpp.**
In particular, the reading test does the following additional actions:
- reads options before reading the image;
- compare the options read with the options returned by the reader after reading the image;
- compares the format and size of the returned image with the format and size returned by the reader.
This is a patch over MR !108 by @sandsmark. Martin has done a great job implementing support and I find it a shame not to use it.
I made sure that the results are the same as the current version and fixed the problems of pixels with wrong colors with color depth grater than 8 bits. I also fixed conversion errors on mask and gray images (16/32 bits).
Unfortunately the internal rendering engine of the original code is 8-bit so I always forced the output of 8-bit images to correct the problems (see image below). Since it is a plugin with a "rendering engine", the tests to seriously validate it are potentially endless (as the original version is not perfect).
Errors of the original version of the MR (right) which should no longer occur:
* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
To make the plugins fail to allocate if the image size is greater than QImageReader::allocationLimit() it is necessary to allocate the image with QImageIOHandler::allocateImage().
Note that not all plugins have been changed and some others are not tested in the CI (maybe due to missing libraries).
PS: the following message is printed by QImageIOHandler::allocateImage() if the size is exceeded: "qt.gui.imageio: QImageIOHandler: Rejecting image as it exceeds the current allocation limit of XXX megabytes"
- Fix parasite "gimp-comment" not set due to null QImage
- Support to parasite "icc-profile" using Qt 5.14+ API
- Added parasite "gimp-image-metadata" as QImage metadata "XML:org.gimp.xml"
- Added a XCF with XML metadata and icc prifile embedded in autotest folder (generated by GIMP 2.10.30)
- Tested with Qt 5.15.2 and Qt 6.2.3 under Windows and Qt 6.2.3 under macOS
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
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.
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:
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
