https://bugs.kde.org/show_bug.cgi?id=400353
--- Comment #4 from Bob <chockablock...@outlook.com> --- I've downloaded the nightly build that contains the above commits, and while it works for the provided example, it fails on others, especially on straight copying one channel to another. Channel pixelData now appears to be four times longer than needed (A 2x2 image will now return a QByteArray with 16 bytes rather than 4). Channel data for non-blue channels seems to be offsets of blue channel as well: A 2x2 image will print out (for each channel) Blue: b'\x00\x00\x00\xYY\x00\x00\x00\xYY\x00\x00\x00\xYY\x00\x00\x00\xYY' Green: b'\x00\x00\x00\xYY+1\x00\x00\x00\xYY+1\x00\x00\x00\xYY+1\x00\x00\x00\xYY+1' Red: b'\x00\x00\x00\xYY+2\x00\x00\x00\xYY+2\x00\x00\x00\xYY+2\x00\x00\x00\xYY+2' Alpha: b'\x00\x00\x00\xYY+3\x00\x00\x00\xYY+3\x00\x00\x00\xYY+3\x00\x00\x00\xYY+3' where YY+Z can overflow into the byte before it. e.g., If the image has xFF blue, the alpha channel will be four copies of \x00\x00\x01\x02 This overflowing also affects the filling. If we have a white 2x2 image, and just simply copy the blue channel to the red with rect = QRect(0,0,doc.width(),doc.height()) channels[2].setPixelData(channels[0].pixelData(rect), rect) the image should stay white but becomes three teal pixels and a white pixel. It also appears can't retrieve channel data for any channel but blue. Also, while I believe it's just a manifestation of the above overflowing, copying the blue channel into another channel on a larger image causes an odd stretching and wrapping effect (see attachments) -- You are receiving this mail because: You are watching all bug changes.
