Found incorrect QImage class work. Here is a snippet of code:

 QImage imgImg; pixImg.load( imgName ); //JPG 2160*1560 imgImg = pixImg.toImage(); imgImg.bytesPerLine(); //8640 Format ARGB imgImg = imgImg.convertToFormat(QImage::Format_Mono); imgImg.bytesPerLine(); //272 Format Mono

The bottom line is that after converting an image to Format_Mono, there are extra 2 bytes (272 instead of 270 (270 * 8 = 2160)). Before the conversion, everything is fine, because 8640/4 = 2160. I mean that after the conversion, there are 8 bits in each byte, which define the color of 8 pixels. But this theory does not fit with reality. Knowledgeable people - tell me :)

  • What is the value of these bytes? 272 is divisible by 4, so it can be added to a string with zeros up to a multiple of four bytes. - ߊߚߤߘ
  • I do not quite understand. 272 is the number of bytes of a monochrome image. Each byte describes 8 pixels (1-black, 0-white). Therefore, we can suggest that to get the width in pixels you need 272 * 8 = 2176! = 2160. Ie 2 bytes (16 pixels) are clearly superfluous - Cat Gray
  • These last two bytes do not belong to the image. The converter encoded one line of the image and turned out the resulting array with zeros to a multiple of four bytes. Then he took the next line and also finished it off with zeros. Therefore, both bytesPerLine() and width() are stored in the image explicitly - one of the other is not displayed just because of these “tails”. - ߊߚߤߘ
  • I understand you) As I come home, I will test this theory) - Cat Gray
  • one
    Yes, indeed, you were right. These images are indeed aligned on 4 bytes line by line. But what is it for? - Cat Gray

0