[qt/qt/qtimageformats]: Summary of bulk changes made

Git repository change summary for qt/qt/qtimageformats
Pushed by mirror-service into branch 'dev'.
Changed from a5925c5053893ddfa9df2affc65048c60850eb24 to 31d9120b59d844c3bea01894e68da58274a89818
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit 686ec710a3499b8fa77eb0b7387c688f80e2579a by Marc Mutz on 21/07/2026 at 06:24..
QTiffHandler: fix default strip sizes for 64-bit and float images

Commit 8455ab6cb29fcccf44977c517689a8ad26781140 (5.11.3) replaced all
TIFFDefaultStripSize() calls with a new file-static defaultStripSize()
function call, stating

> libtiff's default stripsize is tiny (8KB), so splitting the image
> into such strips on writing would significantly hurt the compression
> rate. Aim for 4MB strips instead.

When commit 2842212e88afb200a0fcfda7d306c4e8eee26407 (5.12) added
support for RGBA64, it was forking off a version of qtiffhandler.cpp
that was pre-8455ab6cb29fcccf44977c517689a8ad26781140¹, so it
continued to use the TIFF default strip size of 8KiB.

When the two were merged together², the two commits didn't conflict
and so RGBA64 continued unchanged. The later float format additions
inherited it by cut'n'paste.

¹ youngest common ancestor: 55904e9671f4e927308a78d217c0069528ba7f49
² oldest common decendant: a9be081dacbd307eb277ef1fe6c095677e00248f

Fix by applying the 4MiB strip size to the RGBA64 and float format,
too.

[ChangeLog][TIFF plugin] Fixed a bug that caused RGBA64 and
float-based formats to be written with 8KiB strips, severely limiting
the compression achievable, compared the 4MiB strip size that the TIFF
plugin uses for all other formats.

Pick-to: 6.12 6.11 6.8
Change-Id: I0af7ae6a0fbccce20e61492a36346548d612a04e
Reviewed-by: Allan Sandfeld Jensen <[email protected]>
https://invent.kde.org/qt/qt/qtimageformats/-/commit/686ec710a3499b8fa77eb0b7387c688f80e2579a

Git commit 62ebe2184f84a407aa82730b5f30889c18b45c32 by Marc Mutz on 21/07/2026 at 06:25..
QTiffHandler: close() also corrupt files early

Every other early return in read() does

  d->close();
  return false;

except the "Corrupt image" one. While the file will eventually be
closed by the dtor, the asymmetry is raising eyebrows and can delay
freeing resources, so restore the class' former "failed read → handle
closed" invariant.

Expand the comment a bit to ensure readers understand why this check
is up-front.

Amends 4f83c3ebfdb2bc97162ac1065091c195b60ff5fb (picked to 5.15).

Picking all the way as a fixup to QTBUG-107223, which has a
SecurityIssue label.

Task-number: QTBUG-107223
Pick-to: 6.12 6.11 6.8 6.5 5.15
Change-Id: I900d327f2e8d68241dc658d1b3c32cbc7687e42b
Reviewed-by: Allan Sandfeld Jensen <[email protected]>
https://invent.kde.org/qt/qt/qtimageformats/-/commit/62ebe2184f84a407aa82730b5f30889c18b45c32

Git commit 31d9120b59d844c3bea01894e68da58274a89818 by Marc Mutz on 21/07/2026 at 07:09..
QTiffHandler: fix nullptr deref on read() after certain failed read()s

It's probably an API misuse, but if a user called read() without
intervening jump*(), it will deref Private::tiff == nullptr:

   first read()
     readHeaders() sets headersRead = true;
     ~~~ failure, causing:
       close() sets tiff = nullptr;
       return false;

   next read()
     readHeaders() finds headersRead == true, returns true
     read() calls TIFFIsTiled(tiff) while tiff == nullptr → Boom

The fact that makes this a problem in practice is that the nullptr
deref also happens if the user calls jumpToImage(current image
number). Added a corresponding AI-generated test case which crashes
without this fix.

Amends d2306d74850986692c02b70df0d7a6a6e933d0dc (5.9), which replaced
openForRead() in read() with readHeaders().

Pick-to: 6.12 6.11 6.8 6.5 5.15
Change-Id: I6088cc0f212a1a0b4482da9295736002b57714f2
Reviewed-by: Allan Sandfeld Jensen <[email protected]>
https://invent.kde.org/qt/qt/qtimageformats/-/commit/31d9120b59d844c3bea01894e68da58274a89818