Before the rush

Before the rush
by evan-pak

Submit your Photo
Hall of Fame

Please participate in Meta
and help us grow.

Photography Stack Exchange is a question and answer site for professional, enthusiast and amateur photographers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Sometimes when you're downloading an image and the connection breaks mid stream, you are left with a half downloaded image. If you try to view it you get the upper part of the image and the bottom part is usually coloured grey or green or some other color. In other words, it is corrupted.

Is there a way to check whether the image is damaged in that way or otherwise corrupted?

share|improve this question

If you are talking about JPEG files, then the utility jpeginfo is exactly what you're looking for. It can check files for different types of JPEG errors and corruption and either return an error code (the most useful thing for scripting), or just delete files with errors.

I use this as part of my initial file transfer, to make sure everything copied okay without relying on manual checking. (After that, I make sure their checksums don't change as part of my normal backup/bitrot protection.)

The program is command-line, and comes as source code, but it should be easy to build and use on any Linux distribution or on a Mac with a development environment set up properly. I'm sure you could even do it on Windows with Cygwin or MinGW. (For example, although I can't vouch for its integrity, this blog post seems legit and includes a precompiled download.) To build it yourself:

$ git clone
Cloning into 'jpeginfo'...
Checking connectivity... done
$ cd jpeginfo/
$ ./configure && make

This should create a jpeginfo command which you can either run in place or copy wherever you want (possibly using make install).

Then, you run it like this:

$ ./jpeginfo -c *.jpg
test1.jpg 1996 x 2554 24bit Exif  P 6582168  [OK]
test2.jpg 1996 x 2554 24bit Exif  P 6582116  Premature end of JPEG file  [WARNING]
test3.jpg  Corrupt JPEG data: 1 extraneous bytes before marker 0xe2 1996 x 2554 24bit Exif  P 6582169  [WARNING]

Here, test1.jpg is perfectly fine, and test2.jpg I deleted a few bytes from the end, and test3.jpg I changed some random bytes in the header.

If you have RAW files, check out this page from the American Society of Media Photographers on DNG Validation, or one on data validation details, which covers using Adobe's DNG converter to batch-validate proprietary RAW formats. (Unfortunately, this is a GUI operation and not necessarily easily scriptable.)

If you have a camera which natively outputs the 1.2 version of DNG, that's even better, as this includes a built-in MD5 checksum of the image data. Unfortunately, this doesn't seem to be stored with the normal image metadata — or at least exiftool and exiv2 don't recognize it, and they do read 1.2 DNG files in general — which means that as far as I know currently the Adobe validation tool is the only way to take advantage of that too.

share|improve this answer
Do you know whether Windows binaries for jpeginfo exist somewhere? – Rook Aug 25 '15 at 13:47
Using jpeginfo tool by git clone doesn't seem to be possible on Windows, because 'aux' seems to be a Windows reserved name, and git cannot clone the aforementioned directory into existence. – Rook Aug 30 '15 at 10:25
--- resuming the conversation from the other post here; Unzipping the archive gives an error because of 'aux'. Renaming 'aux' within the archive helped with unzipping and then renaming it back to 'aux' within cygwin solved that problem. But running make from cygwin resulted in numerous errors still; something about wrjpgcom.c:87:54: warning: incompatible implicit declaration of built-in function 'exit' [enabled by default] #define ERREXIT(msg) (fprintf(stderr, "%s\n", msg), exit(EXIT_FAILURE)) (just one of many) – Rook Aug 30 '15 at 15:02
@ldigas I built a MinGW binary which you can find at I built this on Linux as a cross-compiled executable, so haven't tested it, but it seemed to build okay. I can't promise that it works, but I do promise that it just the upstream code and has no viruses or anything. :) – mattdm Aug 30 '15 at 15:04
Upvoted this a few minutes ago for the effort you're making, but it doesn't seem to work all that well on Windows. jpeginfo -c any_jpeg_file.jpg I provide it, it seems to report Premature end of JPEG file JPEG datastream contains no image [ERROR]. – Rook Aug 30 '15 at 15:20

ImageVerifier does what you want.

ImageVerifier (IV for short) traverses a hierarchy of folders looking for image files to verify. It can verify TIFFs, JPEGs. PSDs, DNGs, and non-DNG raws (e.g., NEF, CR2).

IV is designed to process large numbers of images. Folder hierarchies with 100,000 images or more should be no problem. In one test run, IV ran for 14 hours.

There are two kinds of verification that IV performs: Structure checking and hash checking.

share|improve this answer
It sounds like you are associated with the ImageVerifier, if so, can you please disclose this in your answer. – damned truths Aug 31 '15 at 1:01
I am not associated with the product at all. I had need to verify some image files after a NAS crash and used this tool. I just cut pasted the text from the site to give a description. – Kez Aug 31 '15 at 13:39
FWIW - Its good for camera files (jpgs and various RAW formats - its primary intended use) but not so good for other file types without codecs, etc. The -identify function of ImageMagick is another option – Kez Aug 31 '15 at 13:42

If this is not about downloading images from your camera, but a computer-to-computer transfer, a common approach to file integrity are checksums.

Unfortunately, as far as I know, common "end user" image formats (jpeg, png, gif, …) are not integrity-checked on their own. But as I understand the question to imply automated processing, integrating checksum tools (CRC32, MD5, …) into the workflow could be a viable solution. A common approach to store the checksum is to have a file with the same filename, just with an added extension, like: img123.jpg → img123.jpg.md5.

This approach has the added benefit that you can also check the integrity of (for example) sidecar files or anything else you want to transfer in a similar mechanism. And if you keep the checksum files around, even in the future. (And it has the downside of not being integrated in PS, LR, or the other common tools to the extent of my limited knowledge.)

share|improve this answer
It is worth noting that DNG does contain a checksum, and can be verified directly in Lightroom. – Hampus Nilsson Jan 15 '14 at 18:53
I was not aware of that! Excellent. Makes sense, too. I edited the answer to make clearer I aimed for "end user" formats more than archival formats, though it's sweet that DNG helps with checksums. – Cornelius Jan 16 '14 at 11:41

Just viewing your images in either a browser or Photoshop is a good way to check for download issues. Usually these are very easy to find. Pixel peeping methods abound for checking retouching and any image editing that can cause image quality issues, but just standard viewers can be used for macro image container integrity.

share|improve this answer
Valid approach, but impractical for any larger collection. – Rook Aug 25 '15 at 14:52

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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