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

Git repository change summary for qt/qt/qtimageformats
Pushed by mirror-service into branch '6.11'.
Changed from f9342fa4954d270beb5aae0abae33e6713c533cf to c9e62455c3e5abd49d8088c2c2e9fc326fbbed49
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 a174ae9841845a4aa10d1966eb6bcd94cdc8dce9 by Marc Mutz on 21/07/2026 at 07:09..
QTiffHandler: port Private to NSDMI

This is simpler, and lets readers confirm with one look that all
fields are properly initialized (QSize has a default ctor itself). It
also fixes a 0 used as nullptr.

Amends various commits, so just picking back to avoid conflicts in
this security-critical component, so any security fix can later travel
back faster.

Manual conflict resolution for 6.11:
- rebased to before conflicting change
  5b1d401a523a229e0523e06a591ab3d447e84916 (turning the `compression`
  member from an int to an enum type; keep the int here, and renaming
  NoCompression to Compression::None (scoped enum); keep the old name
  here)

Pick-to: 6.8
Change-Id: I27dbc218612d63c34609573f86b230da29ad3ad5
Reviewed-by: Allan Sandfeld Jensen <[email protected]>
(cherry picked from commit 5417d0685d31fd8f529b9ec300fe1173cafe85d6)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
(cherry picked from commit b2bd79492236cce1553c5fe8104acd0996790869)
Reviewed-by: Marc Mutz <[email protected]>
https://invent.kde.org/qt/qt/qtimageformats/-/commit/a174ae9841845a4aa10d1966eb6bcd94cdc8dce9

Git commit c5f06c8c9baad54f4b4c01bb7f8da0bd8082374f by Qt Cherry-pick Bot (on behalf of Marc Mutz) on 21/07/2026 at 07:37..
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.8
Change-Id: I0af7ae6a0fbccce20e61492a36346548d612a04e
Reviewed-by: Allan Sandfeld Jensen <[email protected]>
(cherry picked from commit 686ec710a3499b8fa77eb0b7387c688f80e2579a)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
(cherry picked from commit 49475e4831975c8df6e339a56286bd19ae8507f9)
https://invent.kde.org/qt/qt/qtimageformats/-/commit/c5f06c8c9baad54f4b4c01bb7f8da0bd8082374f

Git commit 28a9011acbeb821b8c84073bc374f406dc9428b4 by Qt Cherry-pick Bot (on behalf of Marc Mutz) on 21/07/2026 at 07:37..
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.8 6.5 5.15
Change-Id: I900d327f2e8d68241dc658d1b3c32cbc7687e42b
Reviewed-by: Allan Sandfeld Jensen <[email protected]>
(cherry picked from commit 62ebe2184f84a407aa82730b5f30889c18b45c32)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
(cherry picked from commit e37ce9604a8bf78d9cc11053de78dd56d523de90)
https://invent.kde.org/qt/qt/qtimageformats/-/commit/28a9011acbeb821b8c84073bc374f406dc9428b4

Git commit c9e62455c3e5abd49d8088c2c2e9fc326fbbed49 by Qt Cherry-pick Bot (on behalf of Marc Mutz) on 21/07/2026 at 08:13..
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.8 6.5 5.15
Change-Id: I6088cc0f212a1a0b4482da9295736002b57714f2
Reviewed-by: Allan Sandfeld Jensen <[email protected]>
(cherry picked from commit 31d9120b59d844c3bea01894e68da58274a89818)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
(cherry picked from commit 8ad2b3812cfb0ea8ee28173964b6ab1757b7ccdd)
https://invent.kde.org/qt/qt/qtimageformats/-/commit/c9e62455c3e5abd49d8088c2c2e9fc326fbbed49