Post History

If your only concern is overflowing the 64-bit `pixelCount` value, you can safely forget about it. By the time you are processing an image with 18 quintillion (`2^64`) pixels, you will have bigger problems than a simple loop counter. The [largest images produced so far](https://en.wikipedia.org/wiki/List_of_largest_photographs#Digital_photograph) are approaching 1 terapixel (`10^12` pixels), and you'd need 18 million of these to get anywhere near the limit of a 64-bit value. All the data centers of Google and Facebook combined probably couldn't store such a large image, and no computer in the world could load it into memory as a QImage that you can process pixel-by-pixel. Even if you could load it, iterating over its pixels one at a time would take over 140 years, assuming your loop runs on a 4 GHz CPU and requires at least one clock cycle per iteration.

The more relevant danger with the pixelCount approach is that there is no guarantee that the lines of the image are stored "packed" in memory: in other words, the final pixel of line 0 might not be immediately followed by the first pixel of line 1. There might be some padding bytes in between, especially if the image has an odd size like 639x451 and the QImage implementation wants to keep line start addresses aligned to 4-byte (or greater) boundaries. If this is the case, then your assumption that you can treat the 2D image as a 1D array will not hold, and your loop will end up reading a certain amount of garbage data.

For this reason, I would recommend processing the image one scanline at a time, unless you *know* that successive scanlines are packed together without any padding.