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
- 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
In Qt5 converting a QByteArray to a QString stops at the first null byte,
in Qt6 the QByteArray size is respected, and trailing null bytes are
therefore included in the final QString. Explicitly determine the length
of the string data to deal with that.
Enable decoder to use more threads.
8bit YUV->RGB conversion is significantly faster
when AVIF_RGB_FORMAT_RGBA format is used,
because libavif can use libyuv to perform conversion quickly.
Prefer faster AVIF_CHROMA_UPSAMPLING_FASTEST when decoding animation.
Encoder speed changed from to 8 to 7.
Recent AV1 encoders got faster,
so it is OK to switch to better compression quality.
Remove obsolete image/avif-sequence mime-type
as it was merged with image/avif.
The moc process already rebuilds the plugin when the JSON file changes, consequently the additional parameter is not needed.
Task: https://phabricator.kde.org/T14649
Dynamic exception specification is not allowed in c++-17. The enforcement needs
to be relaxed for the kimg_exr plugin when using openEXR versions older than 2.3.0.
New libavif 0.9.1 apply some very strict standard compliance
checks by default. Unfortunately, it rejects many files made by
libheif-based apps (GIMP, ImageMagick) in the past.
libheif 1.12.0 (released on May 5, 2021) addressed the problem,
but it would be good to extend grace period, allowing other
projects and distributions to upgrade to fixed version.
Allow saving Qt-unsupported variants of ICC profiles, they could be
correctly handled by apps with wider color management support.
Change way how QColorSpace is created to avoid
rare problems in some apps.
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
The formula was found in Qt's qt_pixelMultiplier (qpagesize.cpp)
as called by the deprecated setPaperSize method (when the unit is
DevicePixel)
NO_CHANGELOG
The HDR QImageIOHandler plugin only supports the default image orientation (-Y +X) in .hdr files. It mixes up the width and height however, resulting in non-square images not loading.
This fix adds a check for the standard image orientation in the file and returns false (with error message) if that fails.
If it succeeds, it takes the height from the -Y component, and the width from the +X component, resulting in successful loading of the image.
Add autotest images for landscape and portrait HDR (Radiance RGBE) loader
BUGS: 433877
Due to various double vs float arithmetic,
some primaries could be rejected by Qt.
If necessary, we adjust the values so they
will be accepted by Qt.
Remove newline from the ends of error strings.
