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)
- 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
Unfortunately none of them pass since it seems they can't load a png,
save it to their format with loseless quality and read it back and get
exactly the same contents than the png
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
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.
We now support up to and including version 11 of the XCF format, earlier
it only supported version 1 (from 1997, according to the XCF spec).
Biggest difference seems to be that they changed to 64bit for offsets
from version 11 and upwards, otherwise it's mostly just newer enum
values and theoretically major stuff that we don't really need to care
about to get a thumbnail (e. g. linear vs. perceptual RGB).
We still don't support all features, but now it handles that more
gracefully and should at least create thumbnails that are usable. It
should also be easier to update in the future if/when there comes new
versions.
Also added a test file created with the latest version of Gimp
(2.10.18).
Reviewed By: aacid
Differential Revision: https://phabricator.kde.org/D25937
Tested with HDR images from hdrihaven.com
* Loading in KolourPaint works
* Thumbnails in Dolphin work
Reviewed by: aacid
Differential Revision: https://phabricator.kde.org/D23811
Qt also has a tga image plugin so unless we make sure ours is used first
tests are not testing what they should
On a side note their plugin fails our tests so someone with enough time
should report the failures to them
This fixes the xcf test that was failing, i guess at some point someone
run optipng or something over the expected result and that was causing
the test to fail
kra is the native format for Krita and ora the interchange format
for krita, gimp and mypaint (it's also mypaint's native format).
Both formats are simply zip containers with an embedded png.
REVIEW:126675
They were already disabled when building with Qt >= 5.3 in commit
3d45b270ea because Qt has better plugins
for those image formats. Now that we depend on Qt 5.3 we can remove
them.
REVIEW: 124636
By using the same strategy as the SoftImage PIC handler (and sharing
some code with it), we should avoid reading the image data incorrectly
on big-endian architectures.
REVIEW: 122650
BUG: 337918
It now uses QDataStream to deal with endianness. It also supports
several QImageIOHandler options.
This comes with a more comprehensive test suite than the old code. Note
that the old test suite was incorrect as the old code wrote the floats
in the header out incorrectly (although no-one noticed because no
software seems to care about those values).
All the test PIC files in the test suite appear correct according to the
specification (by inspection with Okteta). Unfortunately, there is a
lack of other freely-available software that reads and writes PIC files
(the main application that uses them is proprietary), and so this is the
best I can do.
REVIEW: 117944
Images are converted to ARGB32 format, then each byte (ie: each pixel
channel) in the read image is allowed to deviate by some specified
amount from the corresponding byte in the expected image, to allow for
rounding errors etc.
By default, no deviation is permitted, but the XCF tests are allowed a
deviation of 1, as the alpha blending can result in rounding errors
(depending on whether hardware acceleration is used, for example). In
the end, we are not too concerned about a small deviation that is
invisible to the human eye.
REVIEW: 116567
