Created attachment 177070 [details] A tar file with the original and (kitty and iterm2)-encoded form, as well as a screenshot SUMMARY The image in the attached tar file is corrupted when emitted on konsole. Tested with 24.12.0, but also verified with an older (23.08.x version). (I am on NixOS if that is relevant) STEPS TO REPRODUCE 1. Unpack tar file. It contains the same image in multiple forms; the *-encoded.cat contain kitty and iterm2 encoded images, so can be directly cat-ed to the terminal. 2. cat bug/kitty-encoded-bug.cat bug/iterm2-encoded-bug.cat OBSERVED RESULT The output looks garbled and not in the right aspect ratio. I've added a screenshot bug/garbled-output-screenshot.png how it looks on my machine. EXPECTED RESULT The expected output should look like bug/original-image.png SOFTWARE/OS VERSIONSLinux/KDE Plasma: NixOS on plasma 6 and 5 ADDITIONAL INFORMATION The corresponding images look correct on other terminals; e.g. catting the bug/kitty-encoded-bug.cat on a kitty terminal shows the correct image. I am maintaining https://timg.sh/ and I discovered it during some manual testing. I suspect there is some buffer overflow corruption going on, so this might as well be a security issue.
This seems to me to be a Qt6 bug. Trying to open the PNG file in kolourpaint (Fedora 40) results in the same garbled image. Converting the file from png to png using graphics magick results in a slightly smaller file that works in konsole (and in kolourpaint).
Interesting. I can also confirm that Version 24.12.1 of `kolourpaint` also shows the png garbled ... but only on one of my machines, but correctly on another machine (Both running NixOS. Both machines show the issue on the konsole). Might indicate some non-initialized value/buffer overflow somewhere ? To test if this is an issue with Qt `QImage`, I've compiled the following super-simple program in Qt5 and Qt6 to see if the image loading is an issue there. Both show `bug/original-image.png` correctly. So it does _not_ look like something with basic QImage. I made it as self-compiling c++ 'script', for ease of reproducability (Replace Qt6 with Qt5 in the pkg-config call to compile with qt5): ```c++ #if 0 // Invoke with /bin/sh or simply add executable bit on this file on Unix. B=${0%%.cc}; [ "$B" -nt "$0" ] || c++ -o"$B" "$0" $(pkg-config --cflags --libs Qt6Widgets) && exec "$B" "$@"; #endif #include <QApplication> #include <QLabel> #include <QPixmap> int main(int argc, char *argv[]) { QApplication app(argc, argv); const char *path = argc > 1 ? argv[1] : "bug/original-image.png"; QPixmap image(path); QLabel imageLabel; imageLabel.setPixmap(image); imageLabel.show(); return app.exec(); } ``` So maybe not a Qt issue, but whatever image loading `kolourpaint` and `konsole` use to decode images is the culprit. And the inconsistency
above I say QImage, but use QPixmap for the label. But the same successful outcome is with QImage.
(In reply to Henner Zeller from comment #3) > So maybe not a Qt issue, but whatever image loading `kolourpaint` and > `konsole` use to decode images is the culprit. And the inconsistency This PNG file is also corrupted on konsole/kolourpaint 23.08.5 with Qt5. Konsole gets a byte stream from the program running in the terminal, and passes it to Qt. Maybe it is better to report this bug to kolourpaint. Displaying an image is more of a core functionality for them, so they might have more experience with handling such bug.