struct QoiHeader is initialized to invalid values prior use,
it’s good to detect situations when we read incomplete data.
Add include in scanlineconverter.cpp so it can be used without
change in kf5 branch.
Added support for RLE compressed images. This patch makes the player almost complete allowing to read all type 1,2 and 3 RAS files. Only types 4 and 5 are missing which are images converted from TIFF and IFF.
As a base I used the reference implementation found on the official site at https://qoiformat.org/ (MIT license).
I added a class to convert scan lines in scanlineconverter.cpp. The class takes advantage of the QImage conversion and contrary to what one might expect, with large images it improves performance (compared to converting the whole image) 😄
In progressive mode, for each line, the following conversions (only if needed) are made before saving:
1. If the icc profile is set, the line is converted to sRGB or sRGB Linear.
2. The line is scaled to 8 bits with RGBA order.
- 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.
libavif 0.11.0 uses new default dimension limit 32768 pixels,
we allow 65535 which was used by us previously.
Minor tweaks in jumpToNextImage, jumpToImage
to handle rare situations.
In recent libheif, application should use
heif_init/heif_deinit calls. Unfortunately, these calls are
not thread-safe in released 1.13.0 version yet (will be in the
future) and HEIFHandler is often created in different threads.
So we have to guard their use with a mutex.
Plugin to read RAW camera images based on LibRAW.
- Supersedes MR !86
- Support to LibRaw 0.20 and 0.21-Beta
- Support to multi-shot images: use imageCount(), jumpToImage() to select the wanted shot
- By default generates 16-bits sRGB images using camera white balance and interpolation AHD
- Should fix CCBUG: 454208: on my Debian with KF5.96 and the pulgin installed, I see the preview of all my RAW files (ARW included) in Dolphin
News compared to V1 (MR !86)
- Fix possible stack overflow due to the huge size of LibRaw class
- Fix image allocation with Qt 6 (make use of QImageIOHandler::allocateImage())
- Support to XMP metapacket
- Support to quality option. For e.g. you can focus on quality (q = 10) or speed (q = 1)
- oss-fuzz available [here](https://github.com/mircomir/oss-fuzz/tree/raw_fuzz/projects/kimageformats)
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"
New libjxl API changed the way how lossless 16bit depth images
must be encoded: codestream level 10 must be set,
which implies use of container format.
Unfortunately, there isn’t version number inside libjxl header yet,
so we must detect new version on cmake/PkgConfig level.
Instead of resizing the bytearray to the potential size and then reading
into it, ask the device to read into a bytearray, this way instead of a
crash because we're trying to resize to a too big number we get a nice
maxSize argument exceeds QByteArray size limit
warning
oss-fuzz/46664
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
