Is it possible to read a JPEG file and skip parts that are corrupt? I have three corrupt JPEG files and I can detect the first corrupt block, but can I skip it and continue with the next block?

I can already stop and convert the blocks I've processed so far, but I would like to recover as much as I can. This is not a JPEG in a sequence, so skipping all the remaining blocks wouldn't help.

  • 3
    $\begingroup$ I think you might need to elaborate a little bit on what you mean by "corrupt"... $\endgroup$
    – carlosdc
    Oct 12 '11 at 8:58
  • $\begingroup$ Also, do you expect to still obtain certain decoded image with artifacts, or you would be fine with decoding error so that you could, for example, skip to next JPEG image you might be having in a stream. $\endgroup$
    – Roman R.
    Oct 12 '11 at 22:02

This is a hard problem because the image data is encoded using variable length codes (VLC's). This means that the starting bit of each DCT coefficient is dependent on all of the previous coefficients. A single bit error will often produce a different code length for that coefficient and in turn throw off the alignment for the rest of the image.

I have written automated programs before to toggle bits around where the first corrupt block is and try to find where the errors might be. Basically, it just toggles a bit, redecodes the image, and runs some kind of metric to determine if it helped or not. This method may or may not work if there are multiple bit errors close together. The key is that you don't necessarily need to fix all bit errors, just produce a VLC that is the right length to recover alignment.

  • $\begingroup$ That sounds like a good idea. I'll give that a try. $\endgroup$
    – Jayen
    Oct 15 '11 at 10:40
  • $\begingroup$ In theory, yes. Has anyone really implemented this? Most VLC encoding is far more complex to deal with. $\endgroup$ Jan 27 '12 at 0:05
  • $\begingroup$ I have implemented this. The beauty is that you don't need intimate knowledge of the VLC coding structure, you just need a metric that tells you if one decoded image is better than another. You just flip bits and redecode the entire image. This can be a very time consuming solution so I have used the VLC structure to help me choose which bits to toggle. For instance, if you can determine which bits the macroblocks start on, you can start toggling bits where the first macroblock that looks to be in error is. That way, you can cut down your search space. $\endgroup$
    – Jason B
    Feb 6 '12 at 17:08
  • $\begingroup$ This is fine if you assume that the problem is caused by a single corrupted bit. However, if the error has occurred on e.g. HDD, the file may be missing 512 or 4096 bytes in the middle and there would be 2^4096 or 2^32768 possible bit patterns to test. Both numbers are way too high so there's no way to recover all the data in that case. If one assumes one single bit error in the whole file the fix can be found after 8 times the length of the file in bytes. That may be slow but is still doable. You still need some kind of heuristic to avoid human looking at every generated file. $\endgroup$ Oct 28 '18 at 12:22

VLC encoding in any compressed format makes it almost impossible to recover and it is even theoretical impossible to recover.

However, most file formats take due care about this. So if you are reading JPEG files - a typical .jpg in JFIF format - it is practically very easy.

Basically, there are many markers that are placed in the stream which forms the segments of individual runs in these file which are independently identifiable. The VLC encoding of one segment is independent from the other segment - so if you find that a particular section of bytes broken, you can simply give up on the VLC decoding for that segment and search for the next segment marker. Typically the same concept is used to make MPEG compressed video to allow skipping in the case of streaming error.

For JPEG's JFIF format, there are following markers which helps achieve the above:

a. SOS n (Start of scan) markers b. SOF (Start of frame) markers c. RST n (Restart) markers

See references for more information:

  1. The JFIF file format - http://www.w3.org/Graphics/JPEG/jfif3.pdf
  2. FileFormat.Info - http://www.fileformat.info/format/jpeg/egff.htm or
  3. Book Compressed image file formats: JPEG, PNG, GIF, XBM, BMP by John Miano

Your only real chance of recovering a JPEG image beyond the corrupt spot is if it has restart markers. You will otherwise have no way of knowing if the data is missing or corrupt and how that corruption has affected the DC values. Restart markers were designed to fix this situation by resetting the DC values at regular intervals. The lower 3 bits of the restart marker continuously increment so that you can know the quantity of missing data as well. Unfortunately very few JPEG images contain restart markers because they are assumed to be used on error-free channels.


Often it's possible to detect invalid markers or Huffman decompression errors. If bottom part is grey though, it's most likely invalid marker inside JPEG image data. JPEGSnoop will tell exact byte, edit offending FF xx marker using HxD for example, and rest of image will decode (unless corruption is more extensive). In below example I edit one byte only (FF xx > FF 00) and save file which allows rest of image to be decoded as immediately shown by the old Windows photo viewer.

FF xx is considered a marker by JPEG (known markers). Apart from restart and EOI markers, any other markers in encoded image data will usually make image viewers stop decoding. Random bit corruption can even result in invalid markers. Remove offending marker is some times enough.

enter image description here


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.