Images are allocated without being initialized, so a reader must write
every pixel of every line. The IFF reader did not always:
- Maya: nothing checked that the tiles cover the image: areas no tile
covers are now opaque black.
- readStandardImage(), readCDIImage(), readRGFXImage() and
readDEEPImage() copied min(bytesPerLine, decoded line) bytes, and some
decoded lines are shorter than the image line:
- a PBM with 8 bitplanes and a 64 color CMAP was taken for HAM and
allocated as RGB888, while PBM data are one index per pixel: HAM is
no longer applied to PBM images;
- other mismatches (e.g. HAM without CMAP, RGB8 with 32 bitplanes, CD-i
CLUT3 or RGB888, a truncated CD-i line) are now an error: a decoded
line that does not cover the image line is refused.
Added the read test pbm_64colors.iff, which fails without this change.
Images are allocated without being initialized, so a reader must write
every pixel of every line. The PCX reader did not always:
- readImage2() and readImage4v2() decoded width / 4 and width / 2 bytes,
so the last pixels of lines whose width is not a multiple of 4 (2 bits)
or 2 (4 bits) were not set. They now decode every pixel.
- With a BytesPerLine smaller than a line of pixels, readImage1(),
readImage8() and readImage24() left the end of each line unset: such
headers are now refused by isSupported(), which replaces the check
readImage4() had.
Added the read tests indexed2_w13.pcx and indexed4_w13.pcx, which fail
without this change.
1-bit images with a color map are loaded as Indexed8, but their lines
were copied packed: the first (width + 7) / 8 bytes (rounded up to an
even number) of each line held packed bits read as indexes, and the rest
of the line was not set, so it kept whatever the memory held (images are
allocated without being initialized). The bits are now unpacked to one
index per pixel.
Added the read test pal1bit.ras, which fails without this change.
Originally we uses getNormalZ() for the image, which treat the
image as a normal map. Visual Studio simply fill the blue channel
with 0 instead. Since DDS is for DirectX which is a MS stuff, align
to Visual Studio might be a good idea.
Also, red and green channel should be swapped.
DX10 DDS files using the BC (block compression) formats were reported as
unsupported: knownDXGIFormat() only mapped the floating point DXGI
formats, so getFormat() returned FormatUnknown and ensureScanned() failed,
e.g. for a BC7_UNORM_SRGB (dxgi 99) image.
The following changes have been made:
- Added a self-contained BC7 decoder following the "BC7 Format"
specification, supporting all 8 modes, for both the UNORM and the
UNORM_SRGB variants (loaded as ARGB32)
- Added BC4 support (single channel, loaded as Grayscale8)
- Added BC5 support, reusing the existing ATI2/3Dc normal map decoder
- Added DX10 mappings for BC1/BC2/BC3, which were previously handled only
as the legacy DXT1/DXT3/DXT5 fourCC formats
- Added read tests for BC4, BC5, BC7 and BC7_UNORM_SRGB, plus DX10
variants of the existing BC1/BC2/BC3 test images
BC6H (HDR) is not supported.
The test data was generated from the existing rgba.png test image, encoded
with bc7enc_rdo and decoded with bcdec.
BUG: 524495
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).
Ana BobilloandMirco Miranda
Mirco MirandaandMirco Miranda
Wang ZichongandMirco Miranda
Nicolas FellaandMirco Miranda
Roland BusaandDaniel Novomeský
Antonio Rojas
Albert Astals Cid
Sertonix NorsonandMirco Miranda