CGImageRef width doesn't agree with bytes-per-row

Question

I'm trying to read pixels out of the screen buffer, I'm creating a CGImageRef with CGDisplayCreateImage, but the values for CGImageGetWidth and CGImageGetBytesPerRow Don't make sense together, dividing the bytes per row by the bytes per pixel gives me 1376 pixels per row, but the width of the image is 1366.

What's going on here? Is there some kind of padding in the image? How do I read from the data I'm getting out of it safely, and with the correct results?

Edit: The minimal code needed to reproduce this is the following:

#import <Foundation/Foundation.h>
#import <ApplicationServices/ApplicationServices.h>

int main(int argc, const char * argv[])
{

    @autoreleasepool {
        CGImageRef image = CGDisplayCreateImage(CGMainDisplayID());

        size_t width = CGImageGetWidth(image);
        size_t bpr = CGImageGetBytesPerRow(image);
        size_t bpp = CGImageGetBitsPerPixel(image);
        size_t bpc = CGImageGetBitsPerComponent(image);
        size_t bytes_per_pixel = bpp / bpc;

        NSLog(@"%li %li", bpr/bytes_per_pixel, width);

        CGImageRelease(image);

    }
    return 0;
}

Answer 1

The bytes per row (also called the “stride”) can be larger than the width of the image. The extra bytes at the end of each row are simply ignored. The bytes for the pixel at (x, y) start at offset y * bpr + x * bpp (where bpr is bytes-per-row and bpp is bytes-per-pixel).

Notice that 1376 is exactly divisible by 32 (and all smaller powers of 2), while 1366 is not. The CPUs in modern Macs have instructions that operate on 16 or 32 or 64 bytes at a time, so the CGImage algorithms can be more efficient if the image's stride is a multiple of 16 or 32 or 64. CGDisplayCreateImage was written by someone who knows this.