# jpeg compression: necessity of dividing input image into 8x8 blocks

For jpeg compression, is it necessary to divide the input image into 8x8 blocks and perform a DCT on each of the 64 blocks? If your input image is mxn, could you just have 1 mxn DCT coefficient matrix? Would jpeg compression still work the same?

## 2 Answers

I believe that you want to exploit local statistics (small block size) and to have long runs of zero in your run-length encoding (large blocks). Large lossy transform coding could possible show artifacts far away from high contrast edges. 8x8 was probably considered a reasonable trade off back in ~1990 with typical image resolutions and available compute.

You could probably easily redesign JPEG to use 4x4 or 16x16 DCTs. Or you could use a modern codec like HEIF (based on h26x intra) where a multitude of block and transform layouts are possible.

The most widely applied JPEG scheme is on $$8\times 8$$ blocks. Some extensions outside the standard have used other sizes like $$4\times 4$$ or $$16\times 16$$ blocks.

And yes, you could turn $$m\times n$$ pictures into an 1 $$m\times n$$ DCT coefficient matrix. Whether this yields better compression can be discussed, because:

• there are several ways to turn a 2D matrix into a 1D one
• the $$n\times n$$ idea uses the notion that image data can be stationary, at least locally.

Without blocking, there is a risk that your data is not so stationary, and you will pay that in DCT coefficients encoding

• I think that the core, baseline jpeg is limited to 8x8 DCTs. A MCU can be 16x16 if 4:2:0 encoding is used, but then it is further subdivided into 4 8x8 luma blocks, one 8x8 Cb block and one 8x8 Cr block. I dont know about possible annexes and modern developments Apr 19 at 22:00
• My memory is possibly leaking. Apr 20 at 10:02