Return to Digital Photography Articles

JPEG Minimum Coded Unit (MCU) and Partial MCU

This page should gives some background on how JPEG images are actually defined by 8x8 pixel blocks called the Minimum Coded Unit. This article should help one understand what happens with lossless rotation on odd-sized images.

The breakdown of an image into MCUs

Every JPEG image is actually stored as a series of compressed image tiles that are usually only 8x8 pixels in size. The proper name for one of these tiles is the MCU or Minimum Coded Unit. When one refers to image blocking artifacts, they are really talking about visual discontinuities observed between one or more of these tiles. You can see the edges or boundaries of these tiles in JPEG images that have been compressed at a very low quality.

JPEG Image   JPEG Image at Low Quality

The images below show the 8x8 boundaries of the MCU tiles

If you look carefully at the low-quality JPEG image, you will notice some of the boundaries of the MCU, as you will see abrupt changes in color and / or intensity. This is because each of these MCU tiles is compressed separately and different amounts of information is discarded from each tile.

Demonstrating the MCU boundaries

The Minimum Coded Unit size for JPEG images is usually 8x8, 16x8 or 16x16 pixels in size. The variations here (more specifically 16x8 and 16x16) are due to an optimization called chroma subsampling.

For JPEG compression and decompression algorithms to work, an image must be represented by an integer number of complete MCUs. In other words, the X and Y dimensions typically need to be a multiple of 8 pixels. Therefore, an image that is sized 501 x 375 must be first changed into an image sized 504 x 376 before it can be compressed. In this example, 501 = 62 horizontal MCUs + 3 extra pixels and 375 is 46 vertical MCUs + 1 extra pixel.

Partial MCU and Odd-sized JPEG images

In the case where there are not enough pixels in a row or column to complete a full tile, a partial MCU is used. A partial MCU is automatically extended to be the size of a full MCU but then the overall image dimensions are used to indicate where to cut off the extra later. This extension is generally done by repeating the last pixel of the row or column as necessary.

For the purposes of this discussion, I refer to images that contain partial MCU as an odd-sized image. In other words, if an image's overall dimensions are not a multiple of 8x8, then it is likely to contain partial MCU and therefore be termed an odd-sized image.

For more information about partial minimum coded units and how they affect image rotation, please see: Lossless rotation & Partial MCU and Digicams and Lossless Rotation.


Reader's Comments:

Please leave your comments or suggestions below!
I am implementing error detection module after decoding process to detect the transmission errors for decoded JPEG image, we compute Average Intersample Difference(AID) of all 8x8 blocks and if AID value of any 8x8 block becomes greater than 45 for Y component and 25 for UV component we say image is corrupted.
So how can we distinguish Y & UV components in the decoded blocks of pixel data ?
 Your description about JPEG MCU is highly appreciated, and its clear enough. I also have a question, in what order the 8x8 blocks of MCU are saved in the JPEG file
for example if we use 16x16 size with (4:2:0) sampling. and we assume we have 3 image compoenents (YCbCr).
which order the blocks in each MCU are saved in the JPEG file?

 In general for a 4:2:0 (2x2), you'd find YYYYCbCr. I have put more information on my Huffman coding tutorial page.
 Hi, very interesting article.

Could be interesting to take blocks of another size? Is there anything done about that?

Thanks in advance.
 Thanks Claudia -- to my knowledge, the block size in baseline JPEG is always 8x8 pixels. However, through chroma subsampling, we sometimes perform compression at the larger 16x8, 16x16, etc. MCU dimensions. I'm not sure if I may have misunderstood your question?

first i would like to say that these sites helped me very much to understand the JPEG format. and i agree thats very helpful.

i have a question related to the post from 2007-12-15:

it has to do with the SOF C0 marker

for example i have a jpeg with color sampling 4:2:0 then i see in a
hex editor ... 01 22 00 02 11 00 03 11 01 ...
then i examined a jpeg without color sampling 4:4:4 and i expected it to be
... 01 11 00 02 11 00 03 11 01 ...
but it is the same like 4:2:0
... 01 22 00 02 11 00 03 11 01 ...
then i examined a 4:2:2 , which as i expected is:
... 01 21 00 02 11 00 03 11 01 ...

does anybody know why 4:4:4 and 4:2:0 are coded hex as the same in the SOF C0 marker ?
2011-10-19Veeranjaneyulu T
 Could you state the difference between MCU and block? How the representation of MCU is? is it combination of all the components that are present?

Its really descriptive and helpful article about MCUs.
I have a question and that is even if we can't extract the exact MCUs from the encoded JPEG but is there any possibility with the help of some special strings or any other specialty that at least we come to know that we are in a new MCU data now.Thanks in advance.
 Thanks! Unfortunately, there is no easy way to determine that you've advanced to a new MCU unless you happen to locate the EOB huffman bit string, but this is sometimes omitted and it is highly dependent upon the bit alignment. Essentially, you have to write a full huffman code detector to know where you are. RST markers can also indicate position, but they are not commonly used.
 could u pls provide me jpeg compressor source code n proper jpeg header format..
thanks in advance
 JPEGsnoop source code is now available, which demonstrates the decode function. A good example of a compressor function can be found in the IJG JPEG libraries.
How can arrive at 1MCU is 16x16 for yuv420 & 16x8 for yuv422 & 8x8 for yuv444?
 A wonderful reference for other details on subsampling can be found in Charles Poynton Subsampling Notation (PDF).
 First of all thanks for good explpanatiopn about MCU.
How do we calculate the total number of MCU in a image?
For example:
1.640x480 (yuv 420 compressed Jpeg image)
2.640x480 (yuv 422 compressed Jpeg image)
3.640x480 (yuv 444 compressed Jpeg image)
Is there any standard method available for this?
 We begin with the assumption that each block is 8x8 pixels. With chroma subsampling, each MCU may encompass one or more 8x8 pixel blocks. Once we've determined the horizontal and vertical pixel dimensions of the MCU, we can then divide the image dimensions by these two values to determine the total number of MCUs in the image.

YUV 420 - 16x16 (total 40x30=1200 MCUs)
YUV 422 - 16x8 (total 40x60=2400 MCUs)
YUV 444 - 8x8 (total 80x60=4800 MCUs)
 Thanks a lot!
 Thank you ! This article is very informative and it help me a lot when I was trying to read IJG source codes...
 First of all thanks for the MCU explanation.
I have a question about the luma (Y) and two chrominance (UV) components, how they are related to MCU? Each YUV component will have one MCU each? How can we find the total number of MCU in image corresponding to luma (Y) and two chrominance (UV) components.
 I have one more question about getting the MCU data from the stream. I was looking all over the internet but I can't find any usable informations on how to decode the jpg scan data. First of all I need to get the RLC-coded data of the first MCU. I know that this data are Huffman encoded and I know that the first information in the scan should be the first MCU's DC + 63 AC values (RLC-coded). But I can't find the way to decode them.
I have all the informations extracted from the jpg header and now I would need to know what should I do. I mean "You should read the first bit from the stream and than...".
Could you please help me or give me some pages where to find this informations ? Thanks.
 The best source of this information is to have a read through the ITU-T spec which is freely available on the web, and then experiment from there to get your decoder working. There are some examples of source code for decoders elsewhere, but you'll get a much firmer understanding by developing your own from the spec. Besides, some of these are complicated greatly by attempts to incorporate performance improvements into the code. Good luck!
 I have allmost the same question as Mark. If there are no tags for MCU, how do you find out the MCU length ? How can I find out how many bytes will the MCU have in the data stream ?
 Unfortunately, you will need to perform the huffman decoding in order to find out the individual MCU boundaries. The boundaries can occur on any bit alignment in the data stream (not byte).
 How do you find the beginning and end of each MCU in the data stream? Is there a tag or a marker? Or are they encoded in a standard length?
 Generally, no. The JPEG bitstream has nearly all redundancy removed, which makes it very hard to delineate the boundaries of MCUs. However, some digital cameras do take advantage of the Restart markers, which may appear every X MCUs (eg. every 4 MCUs). You can use these to regain position, but even then they only reflect a position in sequence 10 markers long, so there is no absolute positioning.
 Thank you for your information!
I have a question, if a mcu is equal to a block, i can use a block instead of mcu ,what's the mcu existing for? Is there other function on mcu?
Thank you!
 The MCU is used in the JPEG compression format to help keep all of the sub-sampled image components together. If there is no chroma subsampling, then the MCU can be treated somewhat similarly to a block.
 it was very useful na di think it helped in deoding jpeg image files
 Thanks for the article. How can it be determined (for example, programmatically) the dimensions of the MCU for a particular jpg file.
 The best way is to search for the JFIF SOF0 marker (0xFFC0), and about 9 bytes later you will find a list of entries, one per component that indicate the sampling factor. With a byte sequence of 0x 01 22 00 02 11 01 03 11 01, you can interpret this as:

CompChanHex ValuesIndSFQTbl
In the above, you want to look for the SF (Sampling Factor) values. It actually tells you the number of entries per MCU of that channel (in both Horizontal and Vertical dimensions). Thus, for the above, we see that Y appears 4 times per MCU (2x2) before each of the chrominance components.

To get the dimension, multiply this by 8x8 pixels for each block. So we end up with a 16x16 pixel MCU. Hope that is helpful!
 Good, to-the-point introduction to MCUs.
 very informative article, very well explained.
2007-05-31Manish Kumar
 I find that usually it use 8x8 MCU. Which applications do we use 16x16 or 16x8?
 Images without chroma subsampling generally have an 8x8 MCU. With chroma subsampling on low-end digital cameras (4:2:0 or 2x2), we'll see 16x16, while most other digital cameras (4:2:2 or 2x1) we'll see 16x8.
 Very good, I'm learning for my test and it helped me a lot! Thx
 Hi there
You explain so well on JPEG MCU,
I learn a lot from it, THANKS !!!

However, I got a question here

Is it necessary to define MCU?
why don't we just apply DCT on the whole image?
I guess i miss something in the middle.

Thanks in advance ,
 Performing the DCT transform is a computationally difficult task. By breaking the original image down into smaller blocks, the calculation can be dealt with much more easily. Plus, it allows decoders or encoders to reduce the amount of image information that they need to keep in memory at one time. Some algorithms use larger blocks, such as 16x16 (some forms of MPEG compression), which helps compress larger regions of similar color, but that's about as large a block size as you'll find.

By using a much larger block size (or the full image size!), you would not easily be able to achieve the same compression quality.

In hardware implementations, the breaking down of the image into blocks has the added advantage of enabling the encoder or decoder to work on several blocks in parallel, thereby increasing compression performance significantly.
Its really good explanation, One can easily understand about MCU.
 did you know wikipedia does not have an article on MCU? have you considered submitting your article to wikipedia as i think it is an excellent explanation.
 Thanks for the comment! You're right -- I am surprised to see no definition there. I'll look into it, as it may help others as a starting point. Thx, Cal.
 Good. It is esay to be understood.

really interesting and informative stuff about jpeg. learnt quite a bit.


Leave a comment or suggestion for this page:

(Never Shown - Optional)