Return to Digital Photography Articles

JPEGsnoop - JPEG File Decoding Utility

JPEGsnoop is a free Windows application that examines and decodes the inner details of JPEG and MotionJPEG AVI files. It can also be used to analyze the source of an image to test its authenticity.

Overview

Latest Version: 1.4.1

Introduction

Every digital photo contains a wealth of hidden information -- JPEGsnoop was written to expose these details to those who are curious.

Not only can one determine the various settings that were used in the digital camera in taking the photo (EXIF metadata, IPTC), but one can also extract information that indicates the quality and nature of the JPEG image compression used by the camera in saving the file. Each digical cameras specifies a compression quality levels, many of them wildly different, leading to the fact that some cameras produce far better JPEG images than others.

What can I do?

Check out a few of the many possible uses for JPEGsnoop!

One of the latest features in JPEGsnoop is an internal database that compares an image against a large number of compression signatures. JPEGsnoop reports what digital camera or software was likely used to generate the image. This is extremely useful in determining whether or not a photo has been edited / tampered in any way. If the compression signature matches Photoshop, then you can be pretty sure that the photo is no longer an original! This type of analysis is sometimes referred to as Digital Image Ballistics / Forensics.

JPEGsnoop reports a huge amount of information, including: quantization table matrix (chrominance and luminance), chroma subsampling, estimates JPEG Quality setting, JPEG resolution settings, Huffman tables, EXIF metadata, Makernotes, RGB histograms, etc. Most of the JPEG JFIF markers are reported. In addition, you can enable a full huffman VLC decode, which will help those who are learning about JPEG compression and those who are writing a JPEG decoder.

Other potential uses: determine quality setting used in Photoshop Save As or Save for Web settings, increasing your scanner quality, locating recoverable images / videos, decoding AVI files, examining .THM files, JPEG EXIF thumbnails, extract embedded images in Adobe PDF documents, etc.

File Types Supported

JPEGsnoop will open and attempt to decode any file that contains an embedded JPEG image, such as:

.JPG - JPEG Still Photo
.THM - Thumbnail for RAW Photo / Movie Files
.AVI* - AVI Movies
.DNG - Digital Negative RAW Photo
.CRW, .CR2, .NEF, .ORF, .PEF - RAW Photo
.MOV* - QuickTime Movies, QTVR (Virtual Reality / 360 Panoramic)
.PDF - Adobe PDF Documents

* Note that video file formats (such as .AVI and .MOV) are containers, which can include video streams encoded in one of a wide variety of codecs. JPEGsnoop can only interpret this video footage if the codec used is based on Motion JPEG (MJPG).

Download the Latest Version of JPEGsnoop!

Click to Download .ZIP

Version: 1.4.1
Version History

Released: 05/28/2009
Downloads: 53942

JPEGsnoop by Calvin Hass

Help Support JPEGsnoop Development

If you have found JPEGsnoop useful and would like to support its continued development, consider making a small contribution. Donations will help encourage me to add new and interesting features. Found an interesting use for the tool? Let me know!

System Requirements

This application has been designed and tested to run on Windows XP and Windows Vista, but it should also work for Windows 95/98/NT/2000.

LINUX users: JPEGsnoop apparently works on LINUX under wine

Terms of Use

JPEGsnoop is free for personal and commerial use. Commercial users are kindly suggested to leave me a brief message so that I can understand your needs and make future versions more useful.

Installation

No installation required. JPEGsnoop is fully portable. Simply unzip the download and run!

Version History

For information about features added in previous versions of JPEGsnoop, please check out the version history page.

Awards and Recognition for JPEGsnoop

CHIP.de Magazine - Program of the Month - April 2009
Computer Bild Magazine - Issue 10/2009
Win Magazine - May 2009

Main Window


Channel Histograms

MCU Grid & Positioning

Documentation

Please see the options page for information on how to use JPEGsnoop and other interesting uses for the tool

Recent Features

XMP APP1 & ICC Header display
GPS EXIF metadata display
Full detailed Huffman VLC decoding output for those interested in writing a decoder or learning JPEG compression
Automatic display of YCC DC block values (16-bit)
MCU Grid overlay and automatic display of mouse MCU position and file offset in image display window.
Test overlay function enhanced to allow quick apply and binary code readout.
Image zoom level from 12.5% - 800%.
Extract embedded JPEGs -- can be used to extract thumbnails, hidden JPEG files, as well as frames from Motion JPEG AVI files.
Compression detection enhanced to detect rotated signatures, comment field.
Full AVI file parsing (to identify MotionJPEG)
DQT table searches in Executables (for "hackers")
Detect edited images or identify original digital camera that took a photo!
Integrated database of thousands of compression signatures (image fingerprint) for digital cameras and editing software
File overlay test function
Multi-channel preview: RGB, YCC, R/G/B, Y/Cb/Cr
Pixel position lookup into file offset
Examine Motion JPEG .AVI or .MOV (Quicktime) files (MJPG or MJPEG) and play through!
Examine any file fragments that may contain a JPEG image
YCC to RGB Color correction / clipping statistics reports
Command-line execution
Huffman variable-length code statistics
Expansion of DHT (Huffman Table Expansion into bitstrings)
Determine IJG JPEG Quality factor

Background Material

If you want to understand some of the technical details reported by JPEGsnoop, I suggest that you read through my articles on JPEG compression:

* Users of Digicams with In-Camera Editing Functions *

If you own a digital camera that provides in-camera editing functions, and would be interested in helping me out, please leave me a brief message with your contact information.

Suggestions

As this is a work in progress, I would be very interested in hearing from you, particularly for feature requests, suggestions, comments, bug reports, etc. If you currently use JPEGsnoop and find it useful, let me know!

Reader's Comments:

Please leave your comments or suggestions below!

2009-06-15	Claudio
	Yeah, absolute cool utility! And consider, that since I'm a Unix freak I don't say that often for Windows tools :-P My problem's that I have/want to convert JPEGs without huffman tables to ones with (thousands of them; and nope, haven't got the RIFF header of the video ;-) So I basically just wanted to know how to add such a huffman table (see DHT) and think I've found it out now... well, gonna try automated conversion tomorrow, here its 04:00 a.m. yawn (beside your en-depth background information) a nice source for some info about the JPEG format is en.wikipedia.org ^^
	Thanks! You may be in luck and find that the standard JPEGsnoop's MJPG huffman table insert (via Export option) gives you what you need.
2009-05-04	Rafael
	Saludos, please help me, how i know? quisiera saber cual es el codigo que podria decirnos si una fotografia ha sido manipulada en corel, ya que mi inexperiencia no me permite darme cuenta y el programa no me dice que ha sido editada. De antemano Gracias. thank you so much.
2009-05-04	Kir
	Hello, Calvin. Your JPEGsnoop is the very helpful tool for many people, for me also. Thank you. But I have a little trouble: I found a thing, that I cann't understand, in a report of your program, in this point: [0x000002C0.1]: ZRL=[ 1] Val=[ 2] Coef=[39..40] Data=[0x 6E FF 00 BE] [0x000002C2.0]: ZRL=[ 9] Val=[ 2] Coef=[41..50] Data=[0x 00 BE 96 BD] (value 0x6E passed normally, but 0xFF wasn't processed) Possibly that I'm wrong, of course. JPEGsnoop version: 1.3 and 1.4. I'm waiting for your answer. If you would mail me - I should send you a tested picture. Thank you
	Hi there Kir -- In the huffman bitstream, a 0xFF00 sequence is treated as a "stuff byte" which represents an encoded 0xFF byte. If it doesn't look like this is what you are observing, then please email me your sample image. Thx.
2009-05-02	Joen
	"Note that the encoding of the SubjectDistance parameter has evolved in newer cameras to become a proprietary measurement with unknown units -- hence it may not always be possible to relate this value to the real-world distance to your subject." I've seen it expressed in meters or millimeters, so wouldn't these be actual measurements? If I take a macro shot that is out of focus, I'm hoping that this measure tells me if I was outside the limits of focus.
	Despite a field that is normally represented by m or mm units, the actual encoded value may not necessarily be using this unit. You can find some discussion on this topic in a dpreview posting. So, the short answer is that depending on which camera model you are using, you may or may not be able to extract the focus measurement you're looking for.
2009-05-02	Dave_R
	Hello Calvin, I see that you mention 12bit JPEG in your latest version of JPEGsnoop. It always seemed to me that 12bit would solve the main problem of 8bit JPEG: excessive quantisation error. Particularly when you allow for the mismatch between the sRGB and the YCC space which is also 8bit. But, apart from DICOM, I can't find any source of 12bit JPEG. As always it is "supported" by Imagemagick like JPEG-LS which also looks interesting, and EXR. But supported just means you have to recompile the program to add the feature. Not within my capabilities... I wonder whether, the lack of support is because there is some good reason why 12bit JPEG won't work well with camera images. Perhaps encoding all of the low level noise would degrade the visible image quality. All I was looking for was a sensible format, where the files are not too much larger than the DNG that they are created from. After all, the DNG contains all of the information and noise of the image. The theoretical advantage of JPEG-LS is that you can set the precision you want from the compression. But I haven't found a way of testing it. Do you have any thoughts on this? Thank you.
	Good questions Dave... I agree that 12-bit baseline JPEG doesn't appear to have found much usage outside of DICOM / medical imaging (I had a very difficult time finding test samples). Theoretically, it would appear to offer better accuracy in the 2009-04-29
	Hi calvin, Can this software be use to check whether it has stenographic in the image, like the quantization table has been changed. Please advice
2009-04-26	joen
	One of the Exif fields that I found in an image editor but was unable to find in JPEGSNOOP is "Subject Distance." Is that the same thing as focal length?
	The EXIF SubjectDistance is not the same as the focal length. For some camera models, this field reports a value that represents the actual distance from the camera to the autofocus target (ie. the subject), which can be useful for flash intensity calculations, for example. In simplistic terms, the FocalLength field can be thought of as representing the field of view of your lens or the magnification at a given subject distance. This quantity is more of an lens parameter than a distance that you might physically measure. Note that the encoding of the SubjectDistance parameter has evolved in newer cameras to become a proprietary measurement with unknown units -- hence it may not always be possible to relate this value to the real-world distance to your subject.
2009-04-23	Tom O'Krinsky
	I have a question about Black & White JPEG's. If a photo is taken in B&W mode is the color info still there, hidden in the coding? Can it be easily recovered? TY
	Hi Tom -- unfortunately, no. Unlike Photoshop PSD documents which may store additional information to describe how to display the underlying image layers (eg. remove saturation, etc.), JPEG (JFIF) files don't contain any such directives. Therefore, recovering a color photo from a greyscale image is not directly possible.
2009-04-05	Dave_R
	Hello Calvin, I'm pleased to see that you are back from your travels and still interested in JPEG... I made this suggestion about a year ago, but it was just before you were leaving, so you didn't have time to look into it. It's my pet topic of EXIF 2.2 camera JPEG sYCC colourspace. Most software, and I expect JPEGsnoop, treat JPEGs as JFIF (from 1992) but camera JPEGs are EXIF 2.2 (from 2002) i.e. IEC 61966-2-1 EXIF 2.2 calls up the sYCC colourspace which conflicts with JFIF and the ICC specification. This is because sYCC specifies that RGB values are not clipped to 0 to 1, but the whole range is encoded unclipped during conversion from XYZ to rgb to r'g'b'to YCC. A free version of the equations are in this document: http://www.color.org/sYCC.pdf This gives a gamut about 50% larger than sRGB. The problem is that, clipping is not a valid way of dealing with intentional out of range values, because it does not even maintain the correct hue. It was JPEGsnoop that originally alerted me to what was happening. I was wondering whether you would add decoding of camera JPEGs in accordance with EXIF 2.2 to JPEGsnoop? This would need conversion from YCC to r'g'b' to rgb to XYZ without clipping intermediate values to 0 to 1. The whole process would probably be best done in the highest convenient precision, but rgb and XYZ are linear so they need at least 16bit. It is not possible to use ICM for the conversion because the ICC specification requires RGB to be clipped on input. If JPEGsnoop could save the XYZ image as 16bit TIFF then it would be useable in other colour managed tools. Or it could display the gamut of the image on an xy chart, although I suspect that is significantly more work. But it would show users of JPEGsnoop that there is a significant issue with camera JPEGs. The sample below is the most extreme that I have seen, partly because it contains fluorescent colours, but natural colours like leaves and flowers also produce out-of-range values. It also shows up a bug in the latest version: JPEGsnoop 1.3.0 gives 0 for RGB clipping in DC even though there are huge numbers for this photo: http://www.steves-digicams.com/2007_reviews/c875/samples/100_0178.jpg RGB histogram in DC (before clip): R component histo: [min= -38 max= 308 avg= 144.2] G component histo: [min= -25 max= 266 avg= 169.6] B component histo: [min= -107 max= 308 avg= 181.4] RGB clipping in DC: R component: [<0= 0] [>255= 0] G component: [<0= 0] [>255= 0] B component: [<0= 0] [>255= 0] RGB histogram in DC (after clip): R component histo: [min= 0 max= 255 avg= 144.1] G component histo: [min= 0 max= 255 avg= 169.6] B component histo: [min= 0 max= 255 avg= 181.6]
	Hi there Dave -- You've raised an interesting issue. I will take a look at the spec and color conversion in greater detail and see what I can do. At this time, I do have a number of new features on my short-list, but if it seems practical, I'll bump this one up. I have not yet written a TIFF export feature, so I'd need to look into that first. Thanks for providing all of the references and example image.
2009-04-01	dimitar
	Hi can you tell what was the problem of jassy because i have the same Here is Jassy's post: It seems JPEG Snoop also uses APP3 marker (for EXIF) essentially to decode correctly. It seems even if APP2 is absent, its ok, but if APP3 is not present, it gives error, saying "expected marker 0xFF at offset ---"
	Hello dimitar -- I don't believe I received a test image from Jassy so if you could email me one, that would be great.
2009-03-24	Demetrakopoulos Yiannis
	Hello, How can I find the image resolution in terms of dpi when my image only reports 1700x2233 pixels and aspect ratio 1:1. I can not find anywhere either original size or resolution information. Thanks in advance.
	Hi -- You can find the DPI settings in "XResolution" and "YResolution" under the section entitled "EXIF IFD0". The image pixel dimensions are described in "Image Size" under the heading "Marker SOF0". While this may not be intuitive, it is the arrangement often found within a JPEG file. In a later version, I intend to create an overview section with the most common characteristics listed.
2009-03-21	Mike
	Cal - This is tremendously useful. I'd really like to see a command-line version of this, especially one that runs under linux. I know the GUI runs under wine in linux, but a command-line based executable would really aid in batch processing. Thanks for the great utility! Mike
	Hi there Mike -- Some of the functionality is currently available through command-line invocation. Hopefully that can tide you over until I implement more batch-oriented functionality into the application.
2009-03-21	Andrew Spinner
	Thanks very much for this program - looks good. I do have a similar problem to solve where a number of .mov files were corrupted by the digital camera that took them. I believe the frames should still be recoverable, since the preview is visible on the camera itself, but the videos do not play. Now I believe these are not MJPEGs but MPEGs. Do you know of any similar program that can extract frames from MPEGs? Thanks, Andrew
	I would expect that there are many free utilities for extracting MPEG frames. I haven't done this yet, but have already planned to add in an MPEG I-frame extraction feature into JPEGsnoop. I have seen some postings elsewhere suggesting that the free ffmpeg utility can be used with the following command-line options to extract a frame: ffmpeg -y -i <filename.mpg> -vframes 1 -ss 00:00:10 -an -vcodec png -f rawvideo -s 320x240 x.png The parameter after ss is the timestamp.
2009-03-04	mikel262
	Hello Many thanks for great tool which jpegsnoop really is! I use it for JPEG FPGA hardware compressor and it helps a lot in debugging and understanding JPEG standard. I have one issue too: in detailed dump I can see DCT matrix for each 8x8 block. It seems to me that you show DC sample already after differential encoding. I think that at DCT stage DC component is still not-yet-differential, this happens after RLE. Michal
	Hi there Michal -- Thanks for the comments! The DC value shown in the matrix represents the DCT coefficients after JPEGsnoop has performed the huffman decode, zigzag reordering and dequantization of coefficients. At this point no offsets have been made to the DC values to adjust for differential run-length coding -- I perform this step next just before the correction for subsampling and the final IDCT in the decoder process. If I have misunderstood your question, please feel free to let me know!
2009-02-28	Damon Sanchez
	Dude I am in debt to you, for life... I've been trying for months to retrieve the Data from a RAID 0 setup. I finally got the Data off with a program call Disk Internals RAID recovery and SATA to USB cables, only to find that the Data I retrieved was all damaged due to a bad sector on one of the drives. You've just helped me get back pictures of my daughter that I thought were lost forever... You are a Wizard, a King, and my Friend. Thank you,
	Hey Damon -- I am so thankful that it worked out for you. I really appreciate hearing successes like this!
2009-02-18	Phil
	Great tool! Any plan to incorporate in Konvertor ?
2009-02-18	westworld
	A Linux version could be handy for people analyzing websites. (I've seen web pages with jpeg compression at 100%.) Maybe the good people at http://www.smushit.com/ could include it. Thnx for this great tool Westworld
	Actually, a lot of people are currently running JPEGsnoop under LINUX using wine. Maybe I should post a page showing a simple how-to. You're right... there are certainly a number of websites that are created with JPEGs of unnecessarily low compression factors.
2009-02-17	andy
	Hi Calvin, can check with u whether jpegsnoop can check on the image got stenographic. Will there be a change in the quantization table for such image. Please advice.
	JPEGsnoop does not currently attempt to detect steganography, but that would be an interesting feature. Often this additional "data" may appear in the high frequency content of an image, by overwriting the lower-order bits of the coefficients, not a change in the actual quantization table themselves.
2009-02-14	MiKiL
	Hi, JPEG Snoop is great tool, but found one 'might be bug', it doesn't open files that has longer filename than 62 characters. :)
	Hi Mikil -- you're right, this is a known problem. Microsoft MFC's CFileDlg() only supports 64 chars. It's not obvious to me how I can work around this, but I have it on my fix list. thx.
2009-02-11	Linda
	Hi, I like your tool. But, as far as I know, many photo-editing softwares and cameras use similar/same quantization tables. So, how using the quantization table is possible to say if the photo was edited? Maybe, the camera has a same quantization table like some photo-editing software..?? Linda
	Good question, Linda. While there are some digicams that use a quantization matrix common with software packages, these tend to be in the minority. If one simply based the assessment only upon the primary image quantization tables alone, then one would have an "uncertain" result (ie. cannot prove/disprove the originality of an image). However, after combining several other traits into the analysis process (eg. presence of makernotes, embedded thumb quantization, etc.), any ambiguity is usually eliminated.
2009-02-09	Bill
	Cal, Thanks for the reply, in the meantime I tried some more and solved my problem - you were absolutely right, the problem is in the sub-sampling. The JPEGs converted on the Sandisk device have the following component information: Comp[1]: ID=0x00, Samp Fac=0x21 (Subsamp 1 x 1), Quant Tbl Sel=0x00 (?] Comp[2]: ID=0x01, Samp Fac=0x11 (Subsamp 2 x 1), Quant Tbl Sel=0x01 (Lum: Y) Comp[3]: ID=0x02, Samp Fac=0x11 (Subsamp 2 x 1), Quant Tbl Sel=0x01 (Chrom: Cb) whereas the ones I've been producing have either Comp[1]: ID=0x01, Samp Fac=0x11 (Subsamp 1 x 1), Quant Tbl Sel=0x00 (Lum: Y) or Comp[1]: ID=0x01, Samp Fac=0x22 (Subsamp 1 x 1), Quant Tbl Sel=0x00 (Lum: Y) for luminance. I can fix this using cjpeg -sample 2x1: Comp[1]: ID=0x01, Samp Fac=0x21 (Subsamp 1 x 1), Quant Tbl Sel=0x00 (Lum: Y) Comp[2]: ID=0x02, Samp Fac=0x11 (Subsamp 2 x 1), Quant Tbl Sel=0x01 (Chrom: Cb) Comp[3]: ID=0x03, Samp Fac=0x11 (Subsamp 2 x 1), Quant Tbl Sel=0x01 (Chrom: Cr) ...and this works! According to the cjpeg docs this option adds more time and size for little difference in quality. The Sandisk device also starts counting at 0 not 1 which seems to be outside the JPEG standard, but regardless of that I can now do a bulk convert. I don't know why all the options are reported as subsamp 1x1 but I guess the difference is in the sampling factor. Thanks for your help and for a great program.
	Great news! Glad that we got that figured out. Most digicams will use "2x1" chroma subsampling by default, as the human eye is less attentive to detail in the color channels (chrominance) versus changes in intensity (luminance). Therefore, most digicams will effectively cut the color "resolution" in half prior to compression. It appears that the Sandisk Photo Album slideshow had optimized their decoder to support only the most common subsampling ratio.
2009-02-05	Dave
	Very nice tool, thanks for making it freely available! Any chance of my getting a peek at the source code?
	Thanks Dave! At the present time I have not opened up the source code but may decide to later. While the codebase shares nothing with my own, the IJG source code is a pretty common startpoint for many others looking to write their own decoders. It is also written from the perspective of performance optimization, which may be more useful in most cases.
2009-02-04	Steven
	I found your utility after trying to find something to fix a broken mjpeg "video" file. All the video tools I've tried say it's not an avi & all the picture tools I've tried say it's an avi with out an index... which it is. Whatever happened to the video file all I have left are about a dozen frames of which your tool is able to view & export the only thing that's worked so far. However it'd be nice if you could enable batch exporting of frames from avis in the command line...
	Great to hear that JPEGsnoop was able to work in this way for you! I have often considered expanding the functionality of the AVI parsing / extraction, and will give it some thought. thanks.
2009-02-04	aramus
	Hi calvin, I have same situation with Denisse, Could you please give the deep describe in step2 (for replace the JFIF header - how to extract from the good header and how to replace in the currupt header) May i need the hex editior to do this process Thank you
	Hi aramus -- sure. I will write up a page soon to describe this. The first approach will require a hex editor. Later on, I plan to add this as a feature to JPEGsnoop, which will mean that you won't require a hex editor at all :)

2009-02-04	Bill
	Calvin, Thanks for a really useful program. I have a Sandisk photo album which displays images on a TV, either by scrolling through them manually or displaying them automatically as a slideshow. The slideshow mode is highly dependent on the image format: you have to convert images one by one on the device to set it up. In slideshow mode it simply skips over images not stored in its chosen format, although in manual mode it displays all pictures OK. It takes a very long to convert each image manually on the device so I'm trying to do bulk conversion on a PC. I've inspected the JPEGs that the device produces and the differences from my normal JPEGs (produced by GIMP or Paintshop Pro) are: no APP0 (JFIF) marker at the start, although it seems to work OK if I add one only one DQT and DHT marker per file with respectively 2 and 4 tables in them: my normal JPEGs have multiple DQT and DHT markers each with a single table the SOF0 comes before the DHT: my normal JPEGs have it after the details of the Img sub-sampling components are different I'm assuming the device is checking something in the JPEG headers to decide whether or not it is going to include it in its slideshow any ideas what it might be doing? Trial and error is taking me too long! Many thanks for any help.
	Interesting question... several others have tried to solve similar problems -- modifying the image formats for compatibility with various hardware viewers / HDTVs, etc. Besides the chroma subsampling, I don't think the other points of difference you list above are likely to be real limitations of the Sandisk photo album's slideshow JPEG decoder. Without seeing some examples of the before & after conversion process, it would be hard for me to determine the exact limitation and therefore deduce the method by which we can pre-convert for faster display. If you can send me an example photo (before conversion) and result after conversion, I'll see if I can help solve this for you. Thanks, Cal.
2009-01-19	Denisse
	Hi, I have downloaded your tool but don't know how to use it and have to fix my photos urgently... Could you help me or show the way to use it efficiently please.. Thank you
	Hi Denise -- recovery of corrupted photos is usually a custom process. JPEGsnoop can sometimes help recover certain types of corrupted images, but the rest require a detailed analysis that is not practical for the majority of users. The two methods that you can try are: open the image in JPEGsnoop and see if the image is visible. If so, use the Export option to save out the image to another file. If not, try pressing Ctrl-+ to advance to the next internal image within the file. Again, use Export if you are able to view an image in its entirety. use the JPEG header replacement method. This is fairly complex but can resolve certain types of image corruption. The idea is that you want to find another image from the same camera (not corrupted), extract the JFIF header, find the start of the image data in the corrupted file (search for SOI marker, start of scan segment) and then concatenate the good header with the corrupted image's scan segment. This is not a very easy process, but I intend on writing up a page someday soon that will show how you can do this with JPEGsnoop. use a custom image repair service. At this time, due to personal time constraints, I am unfortunately no longer able to offer these repairs. Thanks for your understanding.
2009-01-11	Rcmaniac25
	Hey, thanks for responding. I don't think I noticed the delete entry, have to look for that later. One other thing with the "last software" piece. I have some JPEGs that I took with my camera phone and when I take them, still on the phone without editing them of anything, and open them up in JPEGsnoop it says that they were edited with software that matches Photoshop and that the photo was "most likely" edited. Why might I get that message when the image was not edited? (I know it would be difficult to code everything but just out of interest.)
	For your first question: the delete feature is available under "Tools->Manage Local DB..." if you press the Remove button. When processing your image (from a Blackberry Storm cellphone), JPEGsnoop is indicating that it is "likely edited". Unfortunately, some older digicams and cellphones will currently report "likely edited" because of the lack of makernotes and/or presence of EXIF software field info. I have plans to completely rewrite the image assessment algorithm to handle the various scenarios a bit better. Thanks for pointing this out and stay tuned for an update.
2009-01-09	haz
	program is really helpful did fix 95% of my corrupted pic
	Great to hear it!
2009-01-07	raja pallela
	how can i use this tool with command line. I am trying to automate image quality verification. so wondering if i can use this tool with command line -Raja
	Hello Raja -- I have provided some command line options documented here. Hopefully that helps you do what you need.
2009-01-07	Rcmaniac25
	This software is great. I have two suggestions.: The ability to modify your custom camera/software database (I have a couple of entries that I entered in without knowing the exact settings), when you enter in what software you modified the image with, have the ability to enter in multiple different software packages/prgrams (I have an image that I edited with Photoshop then with MS paint). Just some suggestions otherwise great software. Rcmaniac25
	Hey there -- I could certainly enhance the "Manage Local DB" feature. Right now it just lets you list and delete the entries. So, if you wanted to correct an entry, you could delete the relevant entry and then resubmit it to the database with different options. I have added this to my feature request list. With regards to the addition of signatures for modified images, it's important to keep in mind that only the last software program to resave will ultimately dictate the JPEG compression settings. So, even though you edited with Photoshop then MS Paint, the MS Paint settings will dictate the compression signature in the resulting file.
2008-12-20	Kelly
	Calvin, this software is amazing, I have been trying to open some corrupt jpegs for a while, all hope was lost till a friend suggested jpeg snoop. I can now open and export majority of pics. Thank you PS. I would like to make a donation, but it appears you do not accept pay pal???? any other means of donating other then credit card??
	Hi Kelly -- I'm really pleased to hear that it helped you out! Thank you so much for sharing your positive experience with the tool. PS> The donation button is actually for PayPal, but PayPal also accepts credit cards.
2008-12-16	emrah
	Hi, first of all, cheers for this sw. It is indeed helpful. I am trying to analyze the output of a 12-bit jpeg encoder. When I use the DHT table below for the encoding, I receive the following error: (DC) list of code lengths 0x00, 0x01, 0x05, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x00, 0x00, 0x00, set of values 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F AC) list of code lengths 0x00, 0x02, 0x01, 0x03, 0x02, 0x04, 0x06, 0x03, 0x00, 0x00, 0x01, 0x01, 0x00, 0x01, 0x01, 0xC9, ...(snip)... 0xDD, 0xDE, 0xEB, 0xEC, 0xED, 0xEE, 0xFB, 0xFC, 0xFD, 0xFE Error: Attempt to set DHT entry out of range If I keep ignoring the errors, sw analyzes the data and on the report I see this error * Decoding SCAN Data * OFFSET: 0x0000018C * ERROR: Decoding image before DHT Table Selection via JFIF_SOS * * Marker: EOI (End of Image) (xFFD9) * OFFSET: 0x000124C3 BUT The image seems alright when I check it with a viewer I use. So my question is: Is this problem relaying on JpegSnoop or my way of Jpeg encoding? Looking forward to your reply
	Hi there emrah -- If you can email me the sample image I should be able to determine this for you. thx.
2008-12-15	tariq
	can i use multiple scan for the same component in jpeg..say if i want to use different quant table for differerent portions of the image....
	I don't believe the standard baseline JPEG supports this. Other alternatives, such as JPEG2000 support some variability in this regard, but I am not yet familiar with the algorithm.
2008-12-14	Alex
	I just get this: JPEGsnoop 1.2.0 by Calvin Hass www.impulseadventure.com/photo/ ------------------------------- Filename: [F:\Greenwich Village.JPG] Filesize: [883402] Bytes Start Offset: 0x00000000 NOTE: File did not start with JPEG marker. Consider using [Tools->Img Search Fwd] to locate embedded JPEG. No other tools change anything.
	Unfortunately, if you have tried using the "Tools->Img Search Fwd" command and it still doesn't find any JPEG markers then it is very likely that your file is quite corrupted and no easy means will recover it. Recovery may still be possible, but it would be a manual process that could be very difficult.
2008-11-17	Gururaja
	Hi, Thanks for the wonderful software. Small issue : I am not able to see the text inside the UI Properly. Its somewhat Garbeled. I think there is some issue with the font. i will try to update a snapshot but i just wanted to bring this to ur notice. Regards Gururaja
	Hi Gururaja -- please email me a screen snapshot so that I can help figure out what may be causing that for you. Do you have a different language setting in your operating system? thx.
2008-10-16	Frank
	Hi Calvin, one of my tools generated the Huffman table below. In my opinion this is not a valid jpg Huffman table (the code "1" is not allowed). JPGsnoop reads and displays such a jpg image fine. Maybe it should complain about such an invalid Huffman table? Great tool! Frank * Marker: DHT (Define Huffman Table) (xFFC4) * OFFSET: 0x000000B1 Huffman table length = 21 ---- Destination ID = 0 Class = 0 (DC / Lossless Table) Codes of length 01 bits (002 total): 08 00 Codes of length 02 bits (000 total): Codes of length 03 bits (000 total): Codes of length 04 bits (000 total): Codes of length 05 bits (000 total): Codes of length 06 bits (000 total): Codes of length 07 bits (000 total): Codes of length 08 bits (000 total): Codes of length 09 bits (000 total): Codes of length 10 bits (000 total): Codes of length 11 bits (000 total): Codes of length 12 bits (000 total): Codes of length 13 bits (000 total): Codes of length 14 bits (000 total): Codes of length 15 bits (000 total): Codes of length 16 bits (000 total): Total number of codes: 002 Expanded Form of Codes: Codes of length 01 bits: 0 = 08 (Total Len = 9) 1 = 00 (EOB) (Total Len = 1)
	Interesting! You're right in that that should be an invalid code, but I don't explicitly check for that. I can add the check, but won't prevent the decode. Thanks.
2008-09-18	Abdolhosein Vakilzadeh Ebrahimi
	Is it possible to extract Photoshop quantization tables and put them in some other software, e.g. VueScan? Thanks for very great job!
	It is certainly possible to do this, but it is much easier if the scanner software provides an advanced feature to use custom quantization tables (highly unlikely). Otherwise, the only other option is to modify the quantization tables that are hardcoded within the software's JPEG libraries -- this is the approach I have taken to modify my own scanner driver successfully.
2008-07-25	George
	I ran JPEGsnoop on an image and got a report, then found the markers with a Hex Editor and found the JPEG signature that way and compared them from the same file. Perhaps I don't know how to read the signature properly, because the two look different to me. Can you explain the difference that I see? Here's the data: Data copied and pasted from a hex editor: FF DB 00 C5 00 04 03 03 03 03 02 04 03 03 03 04 04 04 05 06 0A 06 06 05 05 06 0C 08 09 07 0A 0E 0C 0F 0E 0E 0C 0D 0D 0F 11 16 13 0F 10 15 11 0D 0D 13 1A 13 15 17 18 19 19 19 0F 12 1B 1D 1B 18 1D 16 18 19 18 01 04 04 04 06 05 06 0B 06 06 0B 18 10 0D 10 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 02 04 04 04 06 05 06 0B 06 06 0B 18 10 0D 10 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 FF C4 Copy and paste from JPEGsnoop: * Marker: DQT (xFFDB) * Define a Quantization Table. OFFSET: 0x00001C49 Table length = 197 ---- Precision=8 bits Destination ID=0 (Luminance) DQT, Row #0: 4 3 2 4 6 10 12 15 DQT, Row #1: 3 3 3 5 6 14 14 13 DQT, Row #2: 3 3 4 6 10 14 17 13 DQT, Row #3: 3 4 5 7 12 21 19 15 DQT, Row #4: 4 5 9 13 16 26 25 18 DQT, Row #5: 6 8 13 15 19 25 27 22 DQT, Row #6: 12 15 19 21 25 29 29 24 DQT, Row #7: 17 22 23 24 27 24 25 24 Approx quality factor = 88.05 (scaling=23.90 variance=1.21) ---- Precision=8 bits Destination ID=1 (Chrominance) DQT, Row #0: 4 4 6 11 24 24 24 24 DQT, Row #1: 4 5 6 16 24 24 24 24 DQT, Row #2: 6 6 13 24 24 24 24 24 DQT, Row #3: 11 16 24 24 24 24 24 24 DQT, Row #4: 24 24 24 24 24 24 24 24 DQT, Row #5: 24 24 24 24 24 24 24 24 DQT, Row #6: 24 24 24 24 24 24 24 24 DQT, Row #7: 24 24 24 24 24 24 24 24 Approx quality factor = 87.95 (scaling=24.11 variance=0.22) ---- Precision=8 bits Destination ID=2 (Chrominance) DQT, Row #0: 4 4 6 11 24 24 24 24 DQT, Row #1: 4 5 6 16 24 24 24 24 DQT, Row #2: 6 6 13 24 24 24 24 24 DQT, Row #3: 11 16 24 24 24 24 24 24 DQT, Row #4: 24 24 24 24 24 24 24 24 DQT, Row #5: 24 24 24 24 24 24 24 24 DQT, Row #6: 24 24 24 24 24 24 24 24 DQT, Row #7: 24 24 24 24 24 24 24 24 Approx quality factor = 87.95 (scaling=24.11 variance=0.22) * Marker: DHT (Define Huffman Table) (xFFC4) * Thanks! George
	Hi George -- When JPEGsnoop generates and compares a signature, it is considering a number of characteristics about the image in addition to the DQT. However, the DQT tables do make up the majority of this comparative data. You correctly identified the DQT section within the JFIF file in your hex editor output. If you skip past the marker (FF DB) and additional data (00 C5 00), you begin the raw table contents. The part that may not be immediately obvious is that the sequence of bytes in the file does not match the matrix representations that most people use to document the quantization tables. That is because a zig-zag ordering method is used (please refer to my page on JPEG compression for some further detail on it). In essence, you'll still identify the table's bytes in the file bytestream if you traverse them in the following order: Start at the 04 (top left corner of DQT matrix), then across to 2nd column (03). Advance diagonally down and to-the-left (only one move brings us to 1st col, 2nd row = 03). Now we drop down one row (to 1st col, 3rd row = 03) and head back up diagonally up and to-the-right (03 02). We continue this zig-zag sequence until we've hit all entries in the matrix! Hopefully this makes it a little clearer. Ideally, I should draw up a diagram to help indicate the sequencing.
2008-07-15	xxkO
	Is there a tool like yours but compatible with BMP, GIF, PNG formats ? I know it's too much, but I'm curious if there's a too for all formats, or separate tools for each format.
	To be honest, I haven't seen many of these analysis tools for other formats as the appeal is somewhat limited. With BMP & GIF it would be far easier to write because they lack a complex compression scheme like JPEG. Nonetheless, if someone knows of a good tool to analyze these other formats (or all at once), please feel free to post it here.
2008-06-15	giritharan
	hi calvin, thks for replied , I finished my dec/enc but i am facing problem while in Linux Platform, The output of the encoder is showing 0 byte file, plz tell is it any specific writing format in linux or JPEG header may i have to change.. waiting for reply.. regards, giri
2008-05-02	anurag
	i want to convert my own videos
	Can you be specific about what type of conversion you're trying to do, and what video format you have?
2008-04-21	Dave_R
	Hello Calvin I was wondering whether you would consider adding the ability to export the image to a file in XYZ colourspace, decoded in accordance with the sYCC specification, i.e. using unclipped rgb values and the gamma encoding mirrored about zero. Ideally calculated with 16bit precision to a 16bpc tiff. Since I posted here last summer I have only found two programs that seem to understand the sYCC colourspace. It is strange when more than 100million cameras are produced each year that encode to this space. I don't know whether it is the NIH factor or just that the camera makers speak Japanese and the sofware writers speak English and they don't understand each other. One issue is that the ICC specification annex F requires clipping of rgb, so sYCC cannot be handled directly in a colour managed system. The two programs are Silkypix (which is Japanese) and QPcolorsoft which I am using. QPcolorsoft is software for color matching to a target. It simply adjusts the colours and saves to AdobeRGB colourspace as a JPEG or TIFF. Because it removes the oversaturation and saves to a larger colourspace it reduces the clipping. But it is noticeable that it will still save out-of-range colours back to a JPEG. So it seems to understand sYCC for both loading and saving. If JPEGsnoop could export an XYZ tiff, it should be possible to load it into a colour managed application. Or failing that, use TIFFICC to convert to another colourspace and do gamut checking to see how much damage was being done. It would be interesting to be able to compare a camera JPEG "perfectly decoded" by JPEGsnoop with the clipped version most programs produce.
	Hi Dave -- That is really quite surprising. Other than the Nikon D2Hs what other cameras are producing images in this color space? Sounds like an interesting feature to add. I'll add it to my list and take a look at what would be involved.
2008-04-18	Jassy
	It seems JPEG Snoop also uses APP3 marker (for EXIF) essentially to decode correctly. It seems even if APP2 is absent, its ok, but if APP3 is not present, it gives error, saying "expected marker 0xFF at offset ---" I tried to disable "show maker notes", but nothing changes. Do you have a hint?
	Hi Jassy -- JPEGsnoop should not require APP3 or APP2 markers in the decode. Many images do not contain these at all and should decode correctly. Sounds more like your file is corrupted. Can you send me an example so that I can take a look? Thanks.
2008-04-01	Michael
	Hi, I found your JPEGSnoop tool two weeks ago, and it is quite exactly what I need to analyze problems with JPEG codecs. The format of the detailed decode with the bitstream is very useful. The only problem is that the detailed decode sometimes stops to consume bits and to decode at places where there is not even an error in the stream. E.g. I have some images where it stops at a certain point when I make a detailed decode from beginning, but when I start the detailed decode at a later MCU, it decodes this part correctly. If you are interested I can send you such an image with details how to reproduce this problem. Many thanks & best regards, Michael
	Hi Michael -- Great to hear that it has been useful! If you can send me an example image with steps to reproduce the problem, I should be able to get it corrected for you. Thanks!
2008-01-26	_Winnie
	I have tryed to use JpegSNOOP and to produce same jpeg as Photoshop SaveForWeb, but the attempt failed. I saved file to m_sfw.jpg with quality 60, extracted tables with JpegSNOOP, and use them as input for cjpeg.exe. ..\cjpeg.exe -sample 1x1,1x1,1x1 -qtables sfw_60.txt -optimize -dct float m.bmp result.jpg But cjpeg version still has much more noise then photoshop version. Which another tricks does the SFW use? images, .bat conversion file - http://files.shapegame.ru/fileshare/public/compare_cjpeg_sfw.zip
	You're right -- this is very interesting. While you did manage to produce the same compression settings as Photoshop, the resulting image definitely differs. The only possible conclusion to draw from this is that Photoshop and the IJG-based applications differ in how they generate the YCC input data to the JPEG compression process. The actual JPEG compression is identical in your two examples, so it is the input to the compression that is different. The differences are especially noticeable in some of the MCUs near the bottom of the girl's pink dress (beside the yellow trim). It looks like Photoshop is doing a better job at avoiding some of the compression artefacts that cjpeg is producing. It is possible that Photoshop might be doing some smoothing on the bitmap data before passing it to the compression routine (even though Photoshop's Blur setting in the Save for the Web dialog may be set to 0). It is also possible that the color conversion algorithm (RGB -> YCC) differs, but that doesn't appear to be the cause.
2008-01-15	justin
	Bravo, Calvin: Do you have a plan on MPEG/H.264 for the same thing? I can not find a competent product in the market. Considering the amount of video streams that torture my hard disk everyday, it would be good to have MPEGsnoop.
	On my to-do list, I was planning to add in video decoding as well, including DV, MPEG2 Program Stream and possibly MPEG4/H.264. When I get some real time to put into this, I may get started. :)
2008-01-08	Madhu Pankaj
	Hi Calvin, JPEG Snoop has helped me a lot while trying to create a binary to JPEG image converter. But i have some skewed images being created. I am writing the code in matlab and am not able to find the error. Whats ur email, as I would like to email you the image to see if you can find the where the errors are created.
	Sure, I'll take a look!
2008-01-07	Shobana
	Hi Calvin, Am currently studying about jpeg images.I think it wud great if decoder supports also non-interleaved and progressive images.In non-interleaved images,i see that its able to decode only the luminance part and not the chrominance part Cheers Shobana
	Hi Shobana -- A few people have also requested that I build a decoder for lossless JPEG, so I will need to decide which to develop first. I was originally intending to add support for progressive JPEG decoding as I thought it might be interesting to see a separation of the multiple image passes. Non-interleaved support would probably be the easiest for me to add, although I don't think I have ever encountered any real-life example images. Thanks for the suggestion!
2008-01-01	john
	Mr Hass, I would like to convey what your work has enabled me to accomplish. Some months ago, I had a fairly bad disk crash that resulted in a bunch of jpg files being concatenated as lost clusters and recovered by Norton Disk Doctor upon reboot (98SE/FAT32 here). At the time, I had little clue as to how to proceed with them, so I just archived the lot and stuck them away, practically forgetting them in the interim. Later, I found jpeg analyser console app, which at least gave me the offsets to look for in a hex editor, and through a series of copy and paste operations was able to recover the images out of two of the concatenated .ndd files. It took so long though that it was easier to just put the whole matter off. Then I found your site, and impressed as I was with the general knowledge, had my sox blown off by the presence of JPEGSnoop. It wasn't until a couple days later even that I decided to load one of the .ndd files in it, then got to poking around in the menus and found a dedicated function to seek to the next SOI marker, and yet another to save as a separate file. I actually couldn't believe it; almost turned inside out (ewww!). Well, I got the job of recovery done in around two hours over 16 or so .ndd files, recovering some 170 usable jpgs, thanks to JPEGSnoop. Had it been left to the hex editor method, the .ndd files would in all probability be still sitting there, waiting for me to complete a job for which the word "tedium" is a underscored understatement. Many thanks!
	Thanks John -- Considering that the Norton Disk Doctor output files (.ndd) can actually represent a concatenation of recovered clusters, the SOI Search function plus Export could certainly be a handy solution! Thanks for pointing this out!
2007-12-16	Sunwukong
	JPEGsnoop is one of the most exciting little programs I have come across. I often wondered how someone could just off hand say that a photo was not original. Now I too can examine photos to a greater depth than before. My wife often asks me to digitize some of her photos and now I have a much better idea of what is going on. Is there any way to detect the brightest pixel using JpegSnoop? Im looking for a command line tool that will allow me to screen images for the brightest pixel and dump those coordinates to a file or db.
	Hi Sunwukong -- Thanks! There certainly is a lot of interesting information captured in JPEGs files apart from the image data. In the process of digitizing files, one definitely needs to keep a watch out for the image quality (via Quantization Tables), as some scanner programs default to fairly poor quality JPEGs. As for detecting the brightest pixel, I can definitely add this. A few others have asked for something similar -- it may even allow for the image whitepoint / white balance to be determined. I'll add it to my list.

NOTE: I am on vacation, so comments will not be posted until I return. Thanks!

Leave a comment or suggestion for this page:
Name:
Email:	(Never Shown - Optional)
Comments: