Sherlock Forensics · Metadata Inspector
The number grid that survives a metadata wipe
Strip every EXIF tag out of a JPEG and one thing stays behind, because the picture cannot be decoded without it: the quantization table. It is the encoder's own handwriting, and it is still there after the metadata is gone.
Samsung Galaxy screenshot
Luminance table, as found in the file
Stock libjpeg, quality 100
fingerprint 95c217cd9e231954
Apple iPhone photograph
Luminance table, as found in the file
Custom tables, estimated quality 83
fingerprint b5cad184d607f656
Every value is a one. That is not a photograph.
A quantization table is how a JPEG encoder decides what detail to throw away. Sixty-four numbers, one for each frequency in an 8×8 block: divide, round, discard the remainder. Big numbers mean aggressive discarding. A table of all ones means discard nothing.
No camera does that. Sensors produce noise, and encoding that noise losslessly wastes enormous space for no visible gain, so camera firmware ships quantization matrices tuned by its manufacturer. The all-ones table on the left is what you get when software is told to re-save an image without degrading it further: a screen capture writer, an export step, a "save at maximum quality" path.
The table on the right is an Apple matrix: uneven, hand-tuned, larger values towards the high frequencies at the bottom right. Two files, two different stories, and neither one is told by a metadata tag.
How the standard tables scale
The JPEG specification publishes an example table. Libraries built on it, libjpeg and everything downstream, take that table and scale it by a quality setting, using a documented formula. Which means the arithmetic runs backwards: given the table in a file, the quality it was written at can be recovered exactly.
Move the dial. The grid is the specification's table put through that formula live.
Push it to 100 and every cell collapses to one, the left-hand specimen above. Pull it down and the bottom-right corner climbs fastest, because that is where the detail the eye misses least is discarded first.
When a file's tables match this formula exactly, the tool says so and names the quality. When they do not, the tables were computed by the writer itself, which is what cameras and Adobe products do. Both answers are useful; they just point in different directions.
Why it outlives the metadata
-
The tables are not metadata
They sit in a DQT segment, and a decoder cannot reconstruct a single pixel without them. Remove them and the file stops being an image.
-
Stripping tools leave them alone
A metadata remover drops EXIF, XMP and the vendor blocks. It has no reason to touch the compression tables, and every reason not to.
-
Re-encoding replaces them, and says so
Software that genuinely re-compresses the picture writes its own tables. That is not concealment: it is a new signature, recorded in place of the old one.
What it does and does not establish
What you can say
That two files were quantized identically. That a file carries stock library tables at a recoverable quality, or custom ones. That a file's tables changed between two copies, so it was re-encoded rather than merely re-tagged.
- Not a nameA fingerprint is a measurement, not an attribution. Saying "Photoshop quality 8" requires reference files of known origin to compare against. The tool reports the measured value and stops there.
- Not uniqueTwo files from the same version of the same program will match. A shared fingerprint is consistent with a common source; it is not proof of one.
- Not tamper detectionIt identifies the last writer. It says nothing about whether the content was altered before that writer touched it.
On error level analysis
ELA is often reached for to answer this same question, and it should not be. It has no threshold, texture drives it harder than editing does, and one re-save erases it. The quantization tables answer "was this re-encoded, and by what" with a measured value that can be stated in a report. ELA cannot.
On a real exhibit
A JPEG produced in a matter carried an Android build string and a Samsung trailer marking it a screen capture. Its quantization tables read as stock libjpeg at quality 100, the all-ones grid at the top of this page, while its Huffman tables were custom, computed for that image.
That pairing is libjpeg with optimised coding switched on, which is what Android's screen capture writer does. It is a sharper identification than either table gives alone, it is independent of every EXIF tag in the file, and it would still have been there if somebody had stripped the metadata first.