The first two articles calculated "how many GB saved and how much money that's worth." This article doesn't talk about the bill; it only answers the one question photographers really care about: When you hand a JPEG to ImgZilla, what exactly does it change, and what is the price you pay for those changes in Lightroom / Photoshop / Capture One? The data comes from the same batch of 32,188 camera / phone direct JPEGs tested in the previous two articles, plus byte-by-byte comparisons of 200+ file pairs.
1. First, the sharpest question: Is bit depth being cut?
The most common suspicion in the photography world about "compression" is: Will my 12-bit or 14-bit data be crushed down to 8-bit?
This worry targets the wrong object. First, separate two things:
- Color Bit Depth (bit depth): How many bits are used per color channel. 8-bit = 256 levels per channel, 14-bit = 16,384 levels. Bit depth determines how far you can push into the shadows or sky in post-processing without hitting a color band.
- File Density (bits per pixel / bpp): File size ÷ number of pixels. The previous article looked at this by grouping by bpp—it measures "how many bytes this image uses per pixel to store," which is the object of compression; it is completely separate from color bit depth.
ImgZilla compresses the latter (density) and does not touch the former (bit depth). Moreover, for JPEG, the bit depth issue simply doesn't exist:
Sampling 209 pairs of original / compressed images and reading JPEG SOF markers byte-by-byte: The precision before and after compression is 8-bit across the board.
The reason is simple—Baseline JPEG is defined by the standard as 8-bit per channel. Camera direct JPEGs have never had 12-bit to speak of, so ImgZilla has nowhere to "reduce" it.
Where are the 12 / 14-bit data? Only in RAW files. And the formats ImgZilla supports are gif / png / jpg / jpeg / svg / heic / heif / webp / avif—none of which are RAW formats (CR2, CR3, NEF, ARW, RAF, DNG are all excluded; dragging them in will simply be ignored). Your digital negatives don't enter its processing pipeline at all, so they are naturally safe.
Conclusion of this section: JPEG has no bit depth to reduce; 8-bit in, 8-bit out. RAW is not touched. Bit depth is not something to worry about in this article—what you really need to look at is the next two sections.
2. So, what exactly changed: A complete lossy re-encode
ImgZilla's way of handling JPEG is not "lossless optimization on the original file," but rather decoding the entire image and re-encoding it from scratch. The complete process is:
Read in JPEG
→ Decode into 8-bit RGB pixels
→ Re-convert to YCbCr
→ Re-quantize with fixed quantization tables (effective quality ~70)
→ Recalculate optimal Huffman tables
→ Output as Progressive JPEG
The "re-quantization" step here is lossy. The coarser the quantization table, the more high-frequency details are discarded, and the smaller the file. Using the quantization table strength (sum of quantization steps; larger number = harsher quantization) from the sampled files:
| Quantization Table Strength (Median) | |
|---|---|
| Camera / Phone Direct Original | 1858 |
| ImgZilla Compressed | 6852 |
Quantization strength is about 3.7 times the original. This is real second-level quantization—not "lossless rearrangement," but a fresh round of high-frequency information loss.
Two things do not change:
- Resolution: One pixel does not move. Across all 32,188 images, the
dimensions_changedfield is unanimously false. ImgZilla does not resize or crop; all saved volume comes from re-encoding. - Bit depth remains unchanged (see previous section), 8-bit in, 8-bit out.
One thing changes but doesn't affect image quality: The output is Progressive JPEG (originals are mostly Baseline). Progressive is better for web loading experience and has no cost to image quality; Lightroom / Photoshop / Capture One can all read it normally—only some very old software might not recognize it.
3. The item that affects post-processing the most: Chroma subsampling is forced down to 4:2:0
This is the most important piece of information for photographers in this entire article.
JPEG uses "chroma subsampling" to save space—human eyes are sensitive to brightness but not to color resolution, so color information resolution can be lower than luminance:
- 4:4:4: Chroma and luminance at the same resolution; color information is most complete.
- 4:2:2: Chroma resolution halved horizontally. Many cameras, and some phones, use this for direct JPEGs.
- 4:2:0: Chroma resolution halved both horizontally and vertically, only 1/4 the resolution of luminance. Most JPEGs "optimized for size" use this.
Sampling 209 file pairs to look at chroma subsampling before and after compression:
| Chroma Subsampling | Original | ImgZilla Compressed |
|---|---|---|
| 4:4:4 | 1 | 0 |
| 4:2:2 | 128 (61%) | 0 |
| 4:2:0 | 80 (38%) | 209 (100%) |
After compression, 100% is 4:2:0. Among them, 61% of images dropped from 4:2:2—chroma vertical resolution is halved, and this is irreversible.
Where does this show up in post-processing?
Reduced chroma resolution is mostly invisible when looking at an unedited image with the naked eye. The problem arises when you start editing it:
- Color Grading / Split Toning: When increasing saturation, pulling HSL, or doing color grading, the boundaries of chroma blocks start to appear, especially in smooth transitions like skin tones and gradients from sky to horizon.
- Color Selection / Masking / Keying: Lightroom's color range masks, Photoshop's Color Range, green screen keying—all of these rely on the precision of chroma edges. After 4:2:0, edges become fuzzy and jagged.
- High-contrast colored outlines: Red-black text, neon lights, backlighting on branches—4:2:0 leaves behind colored "overflow" in these areas.
Additive Effect
With effective quality ~70 + 4:2:0, this is a "compression-heavy" operating point. A direct output image that was originally quality 92, 4:2:2 can withstand significantly more push and pull in post-processing than the same image compressed to quality 70, 4:2:0. Adding in the fact that you compress, then edit and save again—that is two rounds of lossy re-encoding stacked on top of each other.
When is this item irrelevant?
If your original image is already 4:2:0 (many mid-to-low-end phones, older cameras, and any images already optimized for the web), ImgZilla's re-encoding doesn't incur additional chroma loss—it just converges the image to a similar operating point as before. This is also why the compression ratio for these types of images is relatively low (see Section 6 for resolution tiers: iPhone direct output only saves 70.7%, while "fatter" generic 12MP saves 80%).
4. Metadata: EXIF / XMP / ICC All Lost
ImgZilla removes metadata by default. Sampling 209 file pairs for before and after compression:
| Metadata | Present in Original | Retained in Compressed |
|---|---|---|
| EXIF (Shooting parameters) | 204 | 0 |
| XMP (Rating / Keywords / Copyright) | 134 | 0 |
| ICC (Color Profile) | 2 | 0 |
Let's clarify what is lost item by item:
- EXIF: Aperture, shutter speed, ISO, focal length, lens model, camera body model, shooting time, GPS coordinates, copyright fields—all gone. For photographers doing cataloging, reviewing by shooting parameters, or needing copyright info to travel with the file, this is a hard hit.
- EXIF Orientation: This is singled out because it directly affects display. Many cameras and old phones do not physically rotate pixels when shooting, only writing an orientation tag. Once the tag is removed, vertically shot photos may appear sideways in some software—the libjpeg re-encoding does not rotate the pixels for you. Most modern flagship phones have already physically rotated + tagged correctly, so they are not affected; but if you use a camera or an old device, it is best to check before compressing.
- XMP: The star ratings, flags, keywords, titles, and copyright statements you set in Lightroom / Bridge—if they are written to the XMP in the file (not a sidecar or catalog database), they are gone after compression.
- ICC Color Profile: There were almost no embedded ICCs in this sample set (mostly unmarked sRGB), so this item was basically not triggered in this test. However, if your delivery uses Display P3 or Adobe RGB wide color gamut, the embedded ICC will be removed, and the playback end can only interpret it as sRGB, resulting in muted or shifted colors. Be particularly careful with this if you work in a wide gamut workflow.
There is an option to "Keep Metadata" in the settings, but if metadata is important to your workflow, the safest approach is: for images that need metadata, do not compress them in place—keep the original.
5. When can these costs be accepted?
Putting the previous three sections together, ImgZilla's handling of JPEG is: 8-bit unchanged, resolution unchanged, chroma dropped to 4:2:0, quality clamped to about 70, metadata cleared, in exchange for an average volume reduction of -76.8%.
This trade-off makes sense in the following scenarios:
- Delivering to clients for viewing, web portfolios, or social media submissions. These images are going to be compressed again by the platform anyway. 4:2:0 + quality 70 is almost unnoticeable on a pure viewing end, while the volume can be cut by three-quarters—uploading is faster, loading is faster, and image hosting and CDN bills are lower (calculated in the first two articles).
- JPEGs that are to be archived long-term after selection and culling. Kept as records, images not intended to be edited again.
- Sending images via WeChat / Email or sending assets to colleagues—transfer time is basically shortened proportionally to the volume.
The prerequisite is: First use the built-in comparison window (⌘D) to verify it yourself. ImgZilla will split the screen into before/after, allowing you to zoom in to actual pixels to check point by point. For quality-sensitive people, don't listen to the "you can't tell the difference" line—zoom in to 100% and look at the part you care about most—skin tones, sky, hair edges.
6. When not to use it for compression
- JPEGs that will undergo major adjustments in Lightroom / Photoshop / Capture One—especially JPEG-only images (no RAW). Every bit of editing headroom in these images is precious; don't use it up in advance. Keep the original, and compress the exported version when you are done editing.
- Catalog libraries that require retaining EXIF / copyright / GPS / star ratings / keywords.
- Display P3 / Adobe RGB wide gamut delivery—ICC will be removed.
- Your RAW files—they are not affected (ImgZilla doesn't touch them), but don't expect this tool to help shrink RAW files; that's not its job.
In short: ImgZilla is suitable for compressing "output products," not for compressing "intermediate files that will be processed further."
7. Data Appendix: This batch of 32,188 direct JPEGs
Same sample as the previous two articles, 16 subdirectories, no filtering, compressed in place.
Overall
| Volume | Relative to Original | |
|---|---|---|
| Camera / Phone Direct Original | 99.9 GB | — |
| ImgZilla Compressed | 23.1 GB | -76.8% |
Average per image: 2.96 MB → 0.69 MB. The arithmetic mean file compression ratio saved is 76.6%, median saved is 77.3%, basically consistent with the 76.8% calculated by total bytes.
By Resolution Tier: Different devices save very different amounts of space
| Output Size | Count | Percentage | Avg File Savings |
|---|---|---|---|
| 4000×3000 (Generic 12MP, mostly Android / point-and-shoot) | 19867 | 61.7% | 80.1% |
| 4032×3024 (iPhone Main Camera 12MP default size) | 3529 | 11.0% | 70.7% |
| 3456×4608 (16MP vertical) | 2631 | 8.2% | 76.9% |
| 4608×3456 (15.9MP) | 903 | 2.8% | 54.8% |
| 1600×1200 | 257 | 0.8% | 51.4% |
(Device types are inferred from output resolution, not reading EXIF—the EXIF is no longer available in the compressed data.)
The same tool, same batch of untouched original images—the easiest to compress tier (80%) and the hardest to compress tier (55%) differ by 25 percentage points. The difference lies entirely in the original image itself: Apple's camera JPEG pipeline uses more aggressive quantization and tighter encoding, already close to the reasonable lower limit at the factory; many cheap / old devices use conservative fixed quantization tables, so the "fat" parts haven't been touched yet. The newer large-sensor flagships have even thinner direct output, leaving less room for secondary compression—this isn't a bad thing; your original just wasn't that wasteful to begin with.
File-by-File Distribution
| Saved Percentage | Count | Percentage |
|---|---|---|
| 90%–100% | 866 | 2.7% |
| 80%–90% | 11375 | 35.3% |
| 70%–80% | 15244 | 47.4% |
| 60%–70% | 3349 | 10.4% |
| 50%–60% | 398 | 1.2% |
| Below 50% | 956 | 3.0% |
82.7% of photos save 70%–90%. By percentile: more than half save 77% or more; even the worst 10% save about 68%; only about 1% (p99) save less than 40%.
A few extremes
| Original | Compressed | Saved | |
|---|---|---|---|
| Highest compression ratio | 3.55 MB (4000×3000) | 100 KB | 97.2% |
| Most bytes saved single file | 17.9 MB (4000×3000) | 1.13 MB | 16.8 MB |
| Lowest benefit | 70 KB (1242×1242) | 68.8 KB | 2.1% |
8. Data and Test Notes
- Sample Scope: The numbers for overall compression ratio, resolution tiers, and file-by-file distribution come from this batch of 32,188 camera / phone direct JPEGs. They reflect the results of this specific batch and do not equal "ImgZilla can compress by an average of 76.8%." Results will vary with different cameras, models, and export settings.
- Sample Selection: The entire batch of files was not filtered or cleaned; compressed in place according to the original 16 subdirectories.
- Device Attribution: Device determination in the resolution tiers is inferred from output size, not reading EXIF (EXIF is no longer available in compressed data); the same resolution may come from multiple devices.
- Byte Comparison is Sampled: Conclusions on chroma subsampling, bit depth, quantization tables, and metadata come from randomly sampling 209 pairs of original / compressed images and parsing JPEG markers byte-by-byte; this is a sampled scope, not the full 32,188 images.
- Statistical Scope: The overall 76.8% is "total saved bytes ÷ total original bytes"; the arithmetic mean file compression ratio saved is 76.6%, median saved is 77.3%, as listed in the body. Volume units converted using 1 GB = 10⁹ bytes.
- Compression Parameters: Parameters are fixed; there is no quality / sampling slider on the interface. This is a design choice—parameters have been tuned to a balance point in the "visually lossless" range. Photographers used to manually adjusting quality / sampling need to be aware of this.
- "Visually Lossless" does not equal "Lossless": True losslessness (pixel completely unchanged) only exists for PNG and SVG; JPEG is a lossy re-encode, and parameters are chosen in a range that is almost imperceptible to the naked eye. The built-in comparison window allows for pixel-by-pixel verification.
- Runtime Environment: Completed entirely locally; images do not go online or upload (except for App Store purchase verification).
Want to verify it yourself? ImgZilla's free version compresses 10 images per day, only deducting quota upon successful compression. Take a few of your most挑剔 images—portraits, blue skies, backlighting hair—and compress them, then use the comparison window to zoom in to 100% to check yourself before deciding whether to hand your entire library over to it.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Learn more: https://imagetool.app/ImgZilla
System Requirements: macOS 12.3 or later.
}