When reading from a sequential device, the peekHeader() method in
the PCX readers reads the header from its defined little endian
endianness into the arch-specific endianness of the current
architecture for multibyte types.

Being a "peek" method, it then tries to push back the bytes into
the device after reading for its next use, but it doesn’t convert
multibyte types correctly from arch-specifice endianness back into
the initial little endian format.

Subsequent reading of the data from the device will thus lead to
incorrect values for multibyte types on the next use, where
quint16 types in the header have their bytes swapped.

I’ve proposed an MR here with a fix :
https://invent.kde.org/frameworks/kimageformats/-/merge_requests/258