It really wants to have a filename
Also it uses seek and tell a lot so sequential devices are for now not
supported
BUGS: 494571
(cherry picked from commit 3489806ae2568b4aba1167b29828dfb745231fb5)
Backport of MR !254 (According to the libraw documentation, the sizes are available directly after open_datastream.)
One benefit is that it doubles the speed of preview creation in Dolphin.
Code aligned with KF6 (MR !210) to mitigate CCBUG: 413801 and CCBUG: 479612
- Added Size and Format options support
- Fixed a double image allocation when reading RGBA images (RGB was always allocated and then replaced by RGBA one)
- Fixed the code for sequential devices
Fixes not loading a second image in the file. This patch allow code like the following.
QImageReader r(file);
do {
auto qi = r.read();
if (!qi.isNull()) {
qi.save(QString("/tmp/%1_%2.tif")
.arg(QFileInfo(file).baseName())
.arg(r.currentImageNumber()));
}
}
while (r.jumpToNextImage());
m_startPos is used to reposition the device if you decide to do a subsequent read: libraw wants it to be at the beginning of the RAW stream
(cherry picked from commit 18ea0492bc)
Fixes the following error:
| /src/kimageformats/src/imageformats/hdr.cpp:56:31: runtime error: shift exponent 32 is too large for 32-bit type 'int' |
|------------------------------------------------------------------------------------------------------------------------|
This patch Fixes crash when RLE data is corrupted (test cases attached).
Should also fixes (no test cases available):
- Issue 62044 in oss-fuzz: kimageformats:kimgio_hdr_fuzzer: Undefined-shift in RGBE_To_QRgbLine
- Issue 62057 in oss-fuzz: kimageformats:kimgio_hdr_fuzzer: Heap-buffer-overflow in Read_Old_Line
[crash-646a4364479f54278ff8c30c69b0c9665e5869af.hdr](/uploads/44760f0286cde4236feab8e352493556/crash-646a4364479f54278ff8c30c69b0c9665e5869af.hdr)
[crash-88c33e2b49e57e6d1d4ec6945476f605f00e714a.hdr](/uploads/e35bf53ee717134a796c4b17cfacca42/crash-88c33e2b49e57e6d1d4ec6945476f605f00e714a.hdr)
The code is the same of MR !170 (master) but test cases are slightly different due to rounding.
* Support for images with transparency
* Precise colorspace conversion using QT color spaces
* Set the correct resolution
* Set useful metadata
* Creates 16-bits images
* Speed improvements
Backport of MR !167:
- fix buffer overflow with corrupted images without image data
- fix unable to read very small images (e.g. 1x1 px)
- new test cases added
- detect incomplete files by checking the end of streams as written in the specs
* 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
(cherry picked from commit 34ed3bad27)
- 1-bit writer: checks where is black and use NOT operator only if needed
- Fix images with witdh == 65536(*)
- Checks result of disk writes and reads on all formats
(*) PCX formats support images with with of 65536 but only if the header field bytesPerLine is valid (no overflow). This means that the width 65536 is supported on 1bpp images only.
The previous version of the plugins wrote an image with width of 65536px in the wrong way and it was unable to read it (wrong image returned). I verified that Photoshop and Gimp weren't able to read the image either.
(cherry picked from commit d57ff91f8b)
