- Progressive load from file
- Added support for 1-bit image
- Images with palette are now Index (instead of RGB32)
- Added options support (Size, Format)
- Added some test cases
- Improved performance by directly accessing the scanline
- Support for more RAS extension (taken from GIMP)
The code should works "as is" also on KF5.
- Support for images with transparency
- Precise colorspace conversion using QT color spaces
- Set the correct resolution
- Set useful metadata
- Support for RGBX16FPx4 format in Qt 6
- Speed improvements
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:
- 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
- Standardized the quality parameter between 0-100
- The value -1 is the default value of Qt plugins and is managed
- Negative values other than -1 are used as flags to activate the custom mode
- 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
PSD files are saved with as alpha premultiplied. The problem is that alpha refers to white instead of black so it requires transformation formulas. Then, to conver PS premultiplied to QImage premultiplied you have to use the following formula:
* V = Alpha + Vps - Max (C, M, Y, K, R, G, B, Gray, L\* components)
* V = Vps + (Alpha - Max + 1) / 2 (a\*, b\* components)
Where Max is the maximum value depending on the image depth and Vps is the valued read from the file.
libraw uses fseek when doing files, which allows seeking past the end
without problems, so do the same, otherwise when we report oss-fuzz
issues they say "give me an example to reproduce" and since our seek
and their seek don't behave the same it's hard to convince them
to fix their code
Using C-API instead of C++ libheif API has following advantages:
- More libheif features available (for ex.: strict decoding)
- Linking with static build of libheif is possible
- No need to enable exceptions
- If the size of an item is greater than 1 byte, it must be ensured that it is not partially read.
- In many readings, LibRAW gives an error if a partial number of items are read so I always try to read everything.
