- Added support for writing EXR files
- Large image support (tested with 32GiB 16-bit image)
- OpenEXR multithreaded read/write support through the use of line blocks
- Build option to enable conversion to sRGB when read (disabled by default)
- Multi-view image reading support
- Options support: Size, ImageFormat, Quality, CompressRatio
- Metadata write/read support via EXR attributes
The plugin is now quite complete. It should also work on KF5 (not tested): if there is the will to include this MR also on KF5, let me know and I will do all the necessary tests.
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.
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
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)
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.
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.
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
The JSON file argument is passed to Q_PLUGIN_METADATA, which is a no-code
macro at the C++ level and only used to note information used by moc
for the generated moc file.
So when the content of the JSON file has changed, this will not change
anything in the preprocessed source file itself. It only has an effect on
the content of the moc file generated based on it, which is either included
and thus already triggers a dependecy or generated by automoc and compiled
separately into the target with the needed dependencies.
It is automoc which needs to properly trigger a recreation of the moc
file when checking the sources (and at least in 3.9 & 10 does),
and this is nothing that can be influenced by dependency rules.
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
3d45b270ea8341d1516d5863cc49884c2744f2f2 because Qt has better plugins
for those image formats. Now that we depend on Qt 5.3 we can remove
them.
REVIEW: 124636
QtImageFormats 5.3 comes with DDS and JPEG-2000 plugins that support
more options and are generally better than our plugins. The only
advantage our plugins offer is that the Qt DDS plugin does not work on
sequential devices, while ours does. This is outweighed by other
improvements, though, such as supporting more variants.
REVIEW: 119590
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
This prevents a clash with kde-runtime 4, and is a better naming scheme
anyway (to prevent accidental clashes with mime packages from other
software).
REVIEW: 115913
This both excludes the autotests and tests subdirs if the user sets
BUILD_TESTING off, and makes sure we do not run tests for formats that
were not built due to dependencies not being found.
REVIEW: 115504
This includes the detection magic and an alias for image/webp. It
should be in shared-mime-info 1.3.
Proposed by Jerome Leclanche <adys.wh@gmail.com>.
REVIEW: 115355
The plugin export mechanism has been patched up (including the addition
of the JSON file), and the FindWebP.cmake file is new.
Writing is currently disabled, as it produces broken images.
Autotests are generated using the cwebp and dwebp utilities distributed
with the libwebp reference library.
REVIEW: 115355
It appears to be some internal format of xview, although I cannot find
any mention of such a thing on the internet. There does not appear to
be any sort of mime type to associate with this file format, either.
Therefore, I think it is reasonable to declare it obsolete.
REVIEW: 115768
src/imageformats/CMakeLists.txt is now much clearer and more consistent.
Also, removed an unnecessary/unimplemented method from exr.cpp.
REVIEW: 115120
