read_orientation_helper() mapped the irot/imir properties to an EXIF
orientation with a list of conditions that misses several combinations,
e.g. a 90 degrees counterclockwise rotation followed by a mirroring,
which is how iPhone front-camera photos are stored. For those it still
returned true, so libheif was told to ignore the transformations while
Qt got no orientation either, and the image was shown sideways.
The orientation is now chosen by a switch on the rotation and, in each
case, on the mirroring, which is applied after the rotation as MIAF
requires. Other rotation values are left to libheif.
The new read tests cover the twelve rotation and mirroring combinations,
named like the AVIF ones. All of them display the same picture (colored
corners and an "F"): the stored pixels are that picture with the
transformations undone, written as uncompressed HEIF with libheif. Four
of them fail without this change.
Current cmake module assumes the headers are installed in $(INCLUDEDIR)/jxrlib, which is only true if using a custom CMakeLists (as provided by eg. Fedora)
Fix detection of jxrlib compiled with the upstream Makefile by checking the pc file first, and fallback to manual detection as before.
libjxl with SIMD disabled (HWY_COMPILE_ONLY_SCALAR) and with
O1 optimization level is very slow for real use,
leading to timeouts.
HWY_COMPILE_ONLY_STATIC enables baseline SIMD, which should be
always supported by current arch. (for example SSE2 on x86_64)
Fixes kimageformats-write-exr test on Alpine Linux armhf, armv7,
loongarch64, ppc64le, riscv64 and s390x.
Working alternatives are increasing fuzziness to 10 or using 64bpp
formats as compareFormat.
In practice UTF-16 (especially from windows) uses little-endian without
a BOM. By default Qt uses host endianess which causes TIFF_XPTITLE and
TIFF_XPKEYWORDS to not be read correctly.
Fixes c21b50d699
Qt accesses the data of QImage::Format_RGBX64 and QImage::Format_RGBA64
as host-endian quint16. Having BODYChunk::deinterleave write the data
with host-endian to fix parsing on big-endian systems.
Despite the QImage::scanLine doc only warning about byte order issues
for 32-bpp formats[0] the same warning seems to apply to 16BPP formats
like QImage::Format_RGB555 as well.
[0]: https://doc.qt.io/qt-6/qimage.html#scanLine
Q_LITTLE_ENDIAN was used incorrectly, it should have been
"#if Q_BYTE_ORDER == Q_LITTLE_ENDIAN"
Use qFromBigEndian since it is more explicit.
Fixes 6d5e61f0b0
BUG: 495686
IMG_20241019_195232.heic stopped decoding recently because
buffer.contains("Xiaomi") is almost all the time false
(only start of the file is stored now),
except sequential devices (full file is stored).
The start table is stored as file offsets. We subtract the
header+table size to get an index into the remaining data.
If the file offset is smaller than that, the subtract wraps
and the later start+length check can wrap too.
Drop the file instead of walking off the buffer.
- ORA/KRA: merged in a single plugin (KRA)
- ORA: removed standalone plugin
- KRA: use of logging category
- KRA: add metadata support by processing the embedded `documentinfo.xml`
- Improved signature lookup (see MR !17) and added test case
When 1st parsing ends with invalid EXIF payload error,
we try 2nd time again while ignoring the EXIF metadata.
Dropped support for legacy 0.x libavif versions,
libavif 1.0.0+ is now required for the AVIF support.
Roland BusaandDaniel Novomeský
Mirco MirandaandMirco Miranda
Antonio Rojas
Albert Astals Cid
Sertonix NorsonandMirco Miranda
Aljo Joby