For example, the PCX plugin converts all RGB images to RGB(A)32. So if you try to save a 1 GiB RGB888 image, it will be converted to RGB32 image so, you need additional 1.25GiB of ram. The conversion now occurs line by line, significantly saving memory.
Closes#11
Requires MR !279
On formats that does not support CMYK and does not use the ScanLineConverter class during write operation, the CMYK images must be converted using the color space conversion functions of `QImage` (if ICC profile is valid).
Added support for:
- (R/O) 1 bit, 3 planes (ICONDOC.pcx) -> test case from internet archive
- (R/O) 2 bits, 1 planes (CGA_FSD.pcx) -> test case from internet archive
- (R/W) 8 bits, 4 planes (dice_rgba.pcx) -> supported by ImageMagick and GIMP 3
Fix write support for:
- Grayscale 8/16-bits (saved as indexed)
- Alpha 8 (saved as indexed)
- RGB 16-bits depth (saved as RGB 24/32)
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
When reading from a sequential device, the peekHeader() method in
the PCX readers reads the header its defined little endian into
arch-specific endianness for multibyte types.
Being a "peek" method, it then it tries to push back the bytes into
the device after reading for its next use, but it doesn’t convert
multibyte types correctly from arch-specifice endianness to the
initial little endian format.
Subsequent reading of the data from the device will thus lead to
incorrect values for multibyte types on the next use.
This patch reuses the same technique as the TGA reader to read the
whole header as bytes before deserializing it, so that the bytes
can be pushed back into the sequential device in the same order.
- Added support for ```Size``` and ```Format``` options and slightly improved format detection from canRead().
- Added PCXHEADER::isValid() method to consolidate header consistency checks in one place.
* 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
- 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.
- Fix wrong RGB channel order if image format is other than (A)RGB32
- Write right resolution
- Set right resolution on image load
- Return false on write error
- Save images with depth greater than 24-bits
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"
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
Frameworks have a convention of naming uninstalled headers in src/ with
a _p at the end of the name, to make it clear they are not part of the
API. None of the headers in KImageFormats are installed, so it is not
really necessary to follow this convention, but we follow it anyway for
the benefit of both humans and tools (like kapidox).
