Return to Digital Photography Articles
JPEGsnoop 1.8.0 - JPEG File Decoding Utility
by Calvin Hass © 2017
JPEGsnoop is a free Windows application that examines and decodes the inner details of JPEG, MotionJPEG AVI and Photoshop files. It can also be used to analyze the source of an image to test its authenticity.
Overview
Latest Version: 1.8.0
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.
JPEGsnoop can now also parse and decode Photoshop files!
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.
Trying to Undelete or Unformat your Photos?
If you're interested in trying to recover your deleted / corrupted photos, check out my new page on recovering deleted photos.
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
- .PSD - Adobe Photoshop files
- .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.8.0 Version History Released: 06/26/2017 Downloads: 509279 |
JPEGsnoop by Calvin HassHelp Support JPEGsnoop DevelopmentIf 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! |
Source Code: JPEGsnoop is now Open Source on GitHub!
System RequirementsThis application has been designed and tested to run on Windows XP / Vista / 8 / 10. As of version v1.7, Windows XP SP1 is a minimum requirement. JPEGsnoop is fully portable, so it does not require any installation! LINUX users: JPEGsnoop apparently works on LINUX under wine Mac users: JPEGsnoop works within CrossOver Mac Terms of UseJPEGsnoop is free for personal and commerial use. Commercial users are encouraged to leave me a brief private message so that I can understand your needs and make future versions more useful. |
InstallationNo installation required. JPEGsnoop is very portable. Simply unzip the download and run! Version HistoryFor information about features added in previous versions of JPEGsnoop, please check out the version history page. Feature Requests / Bug ReportsPlease feel free to add your own feature requests or bug reports by submitting to the links on the JPEGsnoop Source page |
Awards and Recognition for JPEGsnoop
|
 
|
|
| 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
- Photoshop PSD decoding
- Batch file processing
- XMP APP1 & ICC Header display
- IPTC and Photoshop IRB / 8BIM parsing
- 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:
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!first of all, u r doing a great job, thanks. now my question:
i'm building a win 10 FE based on the neweset Win 10 ver 1803. when starting jpegsnoop 1.8.0 i get an error "Error setting up splitter frames!" i know from other programs that mostly there is a missing dll or something like that (other programs told me which dll is missing, mostly some vcruntime stuff or similar), can u tell me on which dll's jpegsnoop depends?
Please feature to open and exract ithmb files
I had a couple of JPEG files which got corrupted (unreplacable family pictures of course). First I tried the famous "Stellar Phoenix Stellar Repair" which ran for over ten hours to accomplish almost nothing, but then someone recommended JPEGsnoop on StackExchange. A batch file scan and a couple of minutes later I had readable JPEGs with (presumably) all of their metadata.
I have no idea what they did, but it was no simple file scan. Sorry Stellar Phoneix, your money goes somewhere else ;)
if you want to know how to extract jpeg from Canon CR3, please follow this link:
https://github.com/lclevy/canon_cr3
Kind regards
Laurent
Just trying to diffuse some legal drama for one of my clients.
For certain newer cameras, an integrated GPS may also record a date/time value. If present, it is likely to be more reliable than other fields: the GPSTimeStamp. If you see this in the JPEGsnoop output, there is a reasonable chance that the time is accurate since it is derived from satellite references. Note, however that the timestamp refers to the positioning fix, so it could be lagging depending on the conditions.
if i may ask, i ve a jpeg document which some important part of the paper is been covered with another small paper before scanning, how do i remove the paper covered in the important part. please i need response, thanks.
Regards
Thank you for this terrific software! It was helpful in many ways. I have a question for you, hopefully you will have an answer! With my French partners we are in the process of developing a soft that, amongst many other things, will use the YCbCrSubSampling as written in the metadata for authentication purposes. I have thoroughly dissected metadata with an EXIFTool script and a .csv output file for my hundreds of thousands image samples and didn't manage to find discrepancies in the YCbCr Subsampling process for a given camera. In other words, it appears that there's only one possible chroma subsampling for one camera model. Is that right according to you and your experience? Thank you for your reply
It is not too surprising that you have found the subsampling factor to be consistent across your database of digicam images. We know that cameras tend to provide multiple quality settings, but these often just impact the quantization table that is selected (in some cases the quantization table is defined as a function of some quality factor for cameras with variable quantization). Changing the subsampling factor is a more involved process for the encoder (the encoder hardware may have optimized the compression to favor a specific factor).
However, it is not guaranteed that the subsampling factor is the same for all images from a digicam. It is up to the camera's encoder whether subsampling is used, so it is conceivable that for very low or very high quality settings a camera may choose to change from 4:4:2 (2x1) to 4:4:4 (1x1). I have noted this behavior in Adobe Photoshop's software JPEG encoder, for example. Note that I have not gone through my database of images to see if I have observed discrepancies in the subsampling ratio for a given digicam model.
In summary, a change in subsampling ratio can probably indicate a high probability of non-authentication, but may not be authoritative.
FYI I do lots of coding for fun (C# in Visual Studio) on home automation projects and develop lasers for a living, if you have any questions on those subjects.
Cheers,
Peter Moulton
If you did want to explore this further, perhaps you could send me an example of two failed images and one valid image so that I could take a look.
Thanks for the offer on sharing some of your expertise -- much appreciated! :)
May be you know free program for extracting information about HSV parameters from JPEG images?
Thank you
Thank you for your great software!
Thank you so much for your hard work on your program!
I have a 4GmicroSD that is at full capacity that became corrupted. I ran it through a recovery program and was able to retrieve some of my childs infant photos, which were unfortunately corrupted (i thought all was lost). But low and behold because I found your wonderful program JSnoop I was able to extract thumbnails from over 80 corrupted jpg's!! --Thank you soo much!!
I have a question to ask you if I may...
When running my sdCard through the recovery program only about 1/4 of the pictures on the card were recovered. When I check the memory card details it is still at full capacity with no free space. So my question would be: Where did the rest of the photos go & how might I retrieve them uncorrupted?
Your insight is greatly appreciated.
JPEGsnoop will attempt to locate the embedded thumbnails from the files that it can see on the drive; it's great to hear that the thumbnail extraction was useful.
As for why the card appears full but without any files on it, this is because the directory (called FAT32) has been corrupted. The photos have been fragmented across the card (like cutting a picture into a jigsaw puzzle). The directory is like an answer key for the puzzle as it tells the computer where to find all of the pieces for each photo on the drive. With a bad directory, the computer can't locate the images but knows that it doesn't have room for any more puzzle pieces.
There is still a reasonable chance that you can find an advanced recovery program that will locate more of your photos (uncorrupted). Search for a recovery program that supports "file fragmentation". Good luck!
My name is Lawrence Oyaniyi, a Master student from the Federal University of Technology, Akure, Nigeria. My area of research is photo forensic, I greatly appreciate your software JPEGsnoop.
I wish to request for your assistance in developing a similar software for my thesis.
Thank you
Lawrence
The ZTE Axom Elite phone has the feature of choosing focus and depth of field after the shot is done. Apparently this is based on distance information obtained from the dual camera. This distance information (basically a 3D map) is apparently packed into the jpg file. Do you have any information how this is done and can JPEGsnoop reveal 3D maps from those files? It would be cool to have this 3D map and then play around with the picture in another way than done by ZTE's phone software.
Moving right along.......
I first heard your name in the comment section of an article from a site that I won't give a plug, but its name has direct correlation to a 15 min. car insurance mascot and it's preferred mealtime appeFLYser. Basically, the gentleman, who's name escapes me at the moment but he created the Foto Forensics program. He was very politely correcting the writer of his errors/omissions in the article and threw in a touch of copyright education as well. He mentioned you and how genuinely personable you are in his comments which has led me here. This is such a long winded, random jumbled pile of thoughts turned to words for my question, so my apologies.
My question is a simple one but i was hoping if you had the time, you could give a more detailed answser than would seem to warrant such. I have no experience, knowledge of or basically any real understanding on any aspect of your expertise. Reading the q&a, I was actually awakened to how ignorant I was, regarding, being so unaware of how much technical data goes into this field. Allllllll that said, I have a stronger desire than I can express, to hopefully get to a comparable intellectual level as yourself in understanding the workings of your trade. So my question to you is, Where should I start? Books to read, classes to take, people to follow (in a non creepy way), programs to be helpful or any input at all would be amazing and sincerely appreciated. I may not be the best looking gal in the brothel (metaphorically speaking in regards to intelligence and gender) but you'd be hard pressed to find another, who's willing to take on the workload to satisfy the proverbial client, which is my brain.
exiftool -all= input.jpg
So at least in libjpeg (not sure if it's the intention of ITU T.81's standard, but we knew libjpeg is the de facto standard in implementation), the LSBs are extracted from the original integer, not the binaries after DC magnitude coding.
For example, the 1st number is -272. It's "original" integer should be 0xfffffef0, or 11111111111111111111111011110000 (keep in mind it's two's component), NOT 011101111. So we can clearly see the last bit is 0, not 1.
If we right shift it by 1 bit (1111111111111111111111101111000, or -136) and then apply DC magnitude coding, it will still become 0111 0111, so both way work for *first* scan (I think it can be proved mathematically). But you can see here, for the 2nd scan, there is difference (0 vs. 1).
Essentially, if the original value is odd, LSB in scan 2 should be 1 and if it's even, LSB in scan 2 should be 0.
And it's actually based on absolute number of DC value instead of the difference, which can be observed from libjpeg's code. It can be easily tested too if you create multiple (more than 1) LSB scans. In my example, the Cr-DC of MCU2 is +74, or 135 in abs. since MCU1's is 61). In "original" binary integer they are 0x0000004A (0...0 0100 1010) and 0x00000087 (0...0 1000 0111) respectively. I created 4 scans.
The dump of scan #2-4 are
3f (0011 1111)
0f (0000 1111)
27 (0010 0111)
So we can see here for 6th column it's 111, not 010.
Sorry to bother you again.
Recently I am playing with successive scan decoding, but it doesn't work as what I expect.
I created a file with following scan file
(The test files I was using can be downloaded from https://www.dropbox.com/s/lualvv2fsmprtyq/test%20image.zip?dl=0 )
0,1,2: 0-0, 0, 1 ;
0,1,2: 0-0, 1, 0;
0: 1-63, 0, 0 ;
1: 1-63, 0, 0 ;
2: 1-63, 0, 0 ;
Which means I just leave the last bit of all DCs for 2nd scan.
6 DC coefficients are (extracted from a baseline equivalent):
MCU1 (Y-DC/Cb-DC/Cr-DC):
-272 (011101111) / -16 (01111) / 61 (111101)
MCU2 (Y-DC/Cb-DC/Cr-DC):
76 (1001100) / -26 (00101) / 74 (1001010)
So I got the dump from the 1st scan, which is
9d cf 79 30 b4 bf (1001 1101 1100 1111 0111 1001 0011 0000 1011 0100 1011 1111)
With the help of two DHT:
(Luma)
Expanded Form of Codes:
Codes of length 01 bits:
0 = 06 (Total Len = 7)
Codes of length 02 bits:
10 = 08 (Total Len = 10)
(Chroma)
Expanded Form of Codes:
Codes of length 01 bits:
0 = 04 (Total Len = 5)
Codes of length 02 bits:
10 = 05 (Total Len = 7)
Codes of length 03 bits:
110 = 06 (Total Len = 9)
it can be easily decoded as
01110111, 0111, 11110, 100110, 0010, 100101
Which are exactly the bits of these 6 DC values excluding the LSB (least significant bit).
BUT thing are getting weird in the 2nd scan.
The dump of 2nd scan is just one byte, 27 (0010 0111).
According to ITU T.81 G.1.2.1 and a quick look of function "encode_mcu_DC_refine" in libjpeg (I am no developer so don't quote me on this), I am pretty sure it's supposed to just sent the last bit(s) consecutively, without any modification (which means no category header, no Huffman encoding) but here you can see, the bits' number is right (6) but the values don't look right..
What we are missing should be 1,1,1,0,1,0; but here it's 001001 (+ two filling ones).
Did I miss something here?
Just want to let you know, shortly after I sent the last message, I decided to investigate progressive JPEG by myself because I realize the potential of JPEGSnoop even it doesn't support decoding of progressive JPEG yet. It turns out, the data in each scan is arranged ordered by MCU 1st, then by array index (zigzag): just like sequential JPEG, but just with only selected range of lndex.
Below is my way to test, would also like to share here.
I created an simple B&W image which was 16x8 (2 MCUs) with striped patterns. Firstly I created a baseline JPEG to easily get the DCT matrix from JPEGsnoop.
For 1st MCU, only 5 coefficients are left: (after quantization) DC=-1, AC1=-46 AC6=-36, .. etc.
For 2nd MCU, similar but slightly different coefficients are left: DC=0, AC2=-37, AC9=-36, .. etc.
Then, I built a custom scan table which will do spectral selection on 0, 1-6 and 7-63 and I created another JPEG file from the same source BMP file with same q (thus same quantization tables) via `cjpeg -q 80 -sample 1x1 -scans scan.txt test.bmp > test_p.jpg` in libjpeg-turbo.
I got the dump of 2nd scan from JPEGSnoop, which is
51 cd cd 1f (0101 0001 1100 1101 1100 1101 0001 1111)
and DHT:
Expanded Form of Codes: Codes of length 02 bits: 00 = 00 (EOB) (Total Len = 2) 01 = 06 (Total Len = 8) 10 = 16 (Total Len = 8) Codes of length 03 bits: 110 = 46 (Total Len = 9)Now we can manually decode the Huffman encodings:
So, we can clearly see here, the order is MCU1's AC1->MCU1's AC6->MCU2's AC2, i.e. ordered by MCU firstly, then inside MCU, still same zigzag.
I didn't test Successive approximation yet, but I am pretty sure that should be the same: it will always put coefficients from the same MCU together first in every scan, no matter how many coefficients left (in this case, only 6) in that scan.
Which also means, what Wikipedia claims is wrong (https://en.wikipedia.org/wiki/JPEG#Entropy_coding , read from "This encoding mode is called baseline sequential encoding" paragraph).. unless he is using 64 scans for each coefficients, which is impossible.
I cannot find a more better topic to leave this message, so please forgive me if it's not appropriate.
I knew progressive JPEG is not your focus currently, but there is one small question about JPEG compression that has been bothered me for a long time and I think you may knew the answer considering you're an expert in this field. I looked into every single web source I can find, including JPEG standard by ITU, all of them are vague about this part.
When we're encoding the AC DCT coefficients in a sequential JPEG, it would be encoded in MCU by MCU order and in each MCU, they're arranged in zig-zag order (1 to 63), that is very clear from what I learnt in your brilliant article http://www.impulseadventure.com/photo/jpeg-huffman-coding.html
We know progressive JPEG would separate different coefficients in different scans (I am talking about Spectral selection. Let's omit Successive approximation at the moment). Let's say there are 3 scans, 0 (DC), 1-5, 6-63 (and let's also omitting 3 components and interleaving thing). My question is, when encoding AC parts, for example, the 2nd scan for AC1-AC5, will the coefficient be ordered in MCU first or in index first?
If MCU 1st: A1 A2 A3 A4 A5 B1 B2 B3...
If Index 1st: A1 B1 A2 B2 A3 B3...
It matters because we can see here it will definitely affect the efficiency of RLE encoding.
Multiple sources *imply* it's index first, but I have not yet find a definite answer about that.
Cheers.
Your JPEGsnoop is a very useful tool. I would like to ask- would it be possible that you release a portable version of your program which doesn't write to registry and saves all its data and settings inside its program folder?
Best regards,
Asen
It's crashed a couple times (that's unusual) but I'm glad to have it even halfway working on the "new" machine!
If you need future versions tested on XP64, let me know. I can break anything! :)
Except that it refuses to run at all on my WinXP64 machine! no matter how I set program compatibility, Windows whines "JPEGsnoop is not a valid Win32 application." I thought it was 64-bit compatible??
Thanks, Carsten
At this time I don't have a version of JPEGsnoop targeted to other OSes. However, the latest version of the source (v1.7.5) has been rewritten so that it should be much easier for someone to port the core of it to LINUX or other OS. I have heard in the past that CrossOver Mac enabled JPEGsnoop to run under Mac.
If anyone is interested in porting JPEGsnoop to LINUX or other OS, please let me know and I'll try to help in any way I can.
Good news about new functions, I will try it now !
Can we have updated source on sourceforge ? And can you contact me for a commercial use, please ?
Thanks, a lot !
Best regards
.~.
Thanks
Options -> Scan Segment -> Decode Image
Then select File -> Reprocess File
ERROR: File too large for this version of JPEGsnoop. [Size=0x30002E5AF]
Double thanks for a great program!
Probably the easiest solution is to use a free file splitter utility (eg. http://sourceforge.net/projects/fsplit/ ) to create smaller segments (eg. 2GB) and then feed those into JPEGsnoop in batch mode. JPEGsnoop only works on files up to 4GB.
Is there some way I can determine why most of my photos are being exported with a 1440x1080 resolution vs the 4608x3456 they should be? If we can get this fixed I would appreciate it and will increase my donation.
Thanks
Many thanks for a most useful analytical tool. I'm happy to make a donation to further development. How much do you suggest?
I have one question about JPEGsnoop. I tested the software with an image captured using a friend's Apple iPod. EXIF metadata confirms this. However, the compression signature is for a Konica Minolta camera.. Is it probable that both the iPod and the Minolta both use the same compression algorithm?
Look forward to hearing from you.
What you have noted with the compression signature is exactly as you figured... for the particular image content and camera settings, both used the same compression table.
It is quite common to see a given table appear in multiple camera manufacturers... it could be that they reuse the same hardware image encoder or use the same library / reference tables. The notion of the compression signature being a "fingerprint" is a bit of a misnomer in that regard since there is considerable reuse.
If you don't see the Apple iPod in the list of matching signatures, then it would be best to add it (the result would be that you'll see both cameras listed as possible matches).
Hope that helps,
Cal
I have few photos which are corrupted and cannot be previewed.
the corrupted photos are almost with the same size like the good ones but i cant open the or see the preview.
i have trided to decode or fix with some software but i was not able to.
can you please explain how can i try to cut the header from a good photo and paste it on the other or help me with other solution?
thank you !
I'm trying to detect if a PDF has been photoshopped.
I have a base PDF to compare it to.
What parameters should I be looking at?
In this particular situation, could you clarify what you meant by the "base PDF" -- is it another PDF that should be identical to the second PDF (but you didn't notice any differences?) Sorry if I misunderstood the question.
If the PDF file was edited according to "spec", then it may leave some traces of edits (in a ModDate or generation numbers in the objects), but this isn't guaranteed.
If you are wondering about whether an embedded JPEG within a PDF file has been altered (since originally captured), then you can use the image search function in JPEGsnoop to find the image and then process it as normally (ie. compare compression signatures, etc.).
i would test the version 1.7.4
suggestion:
add parameter to save the file when use
-ext_all
through cmd
also some pictures not ext_all through nogui only when i open it normally
PNG files don't work with this tool right?
I have a microscope-camera gadget called an "EyeClops" (I think it came from Toys R Us) that's not in your ID database -- do you want an image to check out?
I am having a hard time understanding all the codes. If I sent you a photo would you be able to decipher? All I want to know is if the photo is an original? And possibly the region it was taken.
Thank you.
I am trying to use your program to recover some corrupted jpeg. Everytime I try to open the jpeg i get this error "The Parameter is in correct"
can you please help. Thank you
A couple sample images I am trying to recover can be found on my dropbox link at https://www.dropbox.com/sh/c4j0z5o3sy7exnb/AACXfEUOarN9iDu-hnIDsXTDa?dl=0
Great program! Just need to figure out how to get it to fully recover the hi-res versions.
Thanks in advance
Chris
*******************************************
Curious why when I export as JPEG it outputs a much smaller version of what the original image was. The original images are about 8MB in size while the output of snoop is only about 50 KB??
The reason for that is that most JPEG images (from a digicam) contain several versions of the same image. Generally you'll find a full-resolution image, a small thumbnail and sometimes a large thumbnail/preview. What you have encountered is probably a case where JPEGsnoop found the small thumbnail first (and extracted that). If you press "Search Forward" you might find that it could locate one of the larger images, thereby enabling you to extract that as well.
Were the 3 files you posted from the output of a recovery program or were they direct from your hard drive / memory card? These files all exhibit a case of the file being a merge of multiple photos.
Long story short, the original images have been "spliced" causing only a small amount of data to be extracted. More advanced techniques are needed to get at the remainder of the data (dealing with fragmentation). But even then. you would not be able to fully recover the hi-res version -- your original images do not exist within these files.
More detail: JPEGsnoop's image decode only starts when it finds a proper header. When you perform "Search Forward", JPEGsnoop will seek the next valid JPEG header. In doing so, it is skipping over a very large amount of data that is in the file. This extra data is actually the remainder of another image data from your drive/card. It is possible to see this additional image data if one messes around with the headers.
Let's say that the original image was 8.6MB in size. In example "_SCN0336.JPG" we actually skip almost 7MB before we find the start of a valid image. That only leaves us with 1.6MB of image data before we get cut off. If we try to extract the image, we are only left with a small fraction of the original file. The extra 7MB is coming from a completely different hi-res file that happened to be on the card/drive.
NOTE: Image repair requests are not accepted. Thanks for your understanding.