The previous article tested finished images that had already been compressed once by a website, and ImgZilla still saved an additional 46.8%. This time we move to the opposite extreme: original photos straight out of a camera or phone, never processed by any tool. Once again, no industry statistics are cited—just the results from one real test run, along with the comparison method.
1. This Test’s Subject: True “Original” Images
There’s a premise behind the last test’s sample: those images were compressed once by the website before being stored, so they were no longer untouched originals. This time we remove that premise and test JPEGs exported directly from a camera / phone—no compression tool, no resave, no re-encoding.
Sample size: 32,188 JPEGs, archived in 16 bucket subdirectories. Nothing was selected or cleaned for the test.
The total volume of these files is 99.9 GB (approximately 93 GiB).
The image specifications are also typical—all are standard output resolutions from cameras / phones:
| Resolution | Count | Share |
|---|---|---|
| 4000×3000 (12MP) | 19867 | 61.7% |
| 4032×3024 (12MP, iPhone) | 3529 | 11.0% |
| 3456×4608 (16MP, portrait) | 2631 | 8.2% |
| Others (3120×4208, 4608×3456, 2448×3264…) | 6161 | 19.1% |
Average: 11.5 megapixels and 2.96 MB per image; the largest single image is 18.3 MB at 30 megapixels. These are the photos a phone or camera produces and you never touch.
The question is: just how much can a dedicated compression tool pull out of these “never touched by anyone” originals?
2. Results: 76.8% Saved—99.9 GB Becomes 23.1 GB
All 32,188 images were individually compressed in place, with file names, directory structure, and resolutions unchanged:
| Size | vs. Original | |
|---|---|---|
| Straight-out-of-camera originals | 99.9 GB | — |
| After ImgZilla compression | 23.1 GB | -76.8% |
One compression pass saves about 76.7 GB, leaving less than a quarter of the original size. The relative paths, file names, and directory hierarchy of all 32,188 files are identical before and after compression—this is directly verifiable with real data.
For comparison with the previous article:
| Test batch | Image source | ImgZilla compression rate |
|---|---|---|
| Previous article (4,624 images) | Finished images already compressed once by the website | -46.8% |
| This article (32,188 images) | Straight-out-of-camera / phone originals | -76.8% |
The conclusion is straightforward: the more untouched an original is, the more room there is to compress. The compression run when a website stores images already ate part of the redundancy, leaving 46.8% for ImgZilla. Camera-original JPEGs have never had that redundancy touched, so ImgZilla can take 76.8% in one pass.
3. Why Camera Original Images Save So Much
When cameras and phones export JPEGs, their priority is “don’t lose detail,” not “make the file as small as possible.” That is why straight-out-of-camera JPEGs contain plenty of bytes that do no good for image quality:
- Conservative quality parameters: Direct-output JPEGs often use quantisation tables in the quality 90–98 range. At these levels, the eye cannot see the improvement of higher quality, but the byte count differs a lot.
- Generic, non-optimal entropy coding: Direct output uses fixed standard Huffman tables. It doesn’t compute optimal codes per image, and it doesn’t apply trellis quantization or progressive scan optimization.
- A pile of ancillary data: EXIF, GPS, vendor-private fields, embedded full-size preview thumbnails, color profiles—these frequently amount to tens or even hundreds of KB.
ImgZilla applies visually lossless re-encoding to JPEGs: it re-orders entropy coding with a better encoding strategy, pulls quantization parameters into a range the human eye cannot discern, and strips redundant ancillary data. Pixel values do change, but the parameters are selected where differences are practically invisible. So for an image with ample redundancy—like these originals—it can remove three-quarters of the size in one pass.
One easily confused term must be clarified: “visually lossless” does not equal “lossless.” Losslessness (pixels completely unchanged) exists only for PNG (oxipng) and SVG. JPEG, WebP, AVIF, HEIC, and GIF are all lossy re-encoding in principle; the only difference is that compression parameters are chosen in the visually-lossless range. If you don’t want to take that statement on faith, ImgZilla has a built-in comparison window—split-screen before/after, zoomable to full size for per-pixel comparison. Judge for yourself.
4. A Closer Look: Per-File Compression Ratio, Pixel Dimensions, and Extreme Cases
The 76.8% above is a total-volume comparison across the entire batch of 32,188 images. At the individual-file level, several more specific things appear.
The Vast Majority Save 70%–90%
Pair all 32,188 images by “bytes before → bytes after compression,” then group by the percentage saved:
| Percentage saved | Count | Share |
|---|---|---|
| 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 the photos saved 70%–90%. The arithmetic mean of the per-file compression ratio is 76.6% saved, almost identical to the 76.8% computed from total bytes. That shows the high-savings and low-savings files are distributed fairly evenly by volume, not skewed by a few oversized files.
By percentile: more than half of the photos save at least 77%; even the worst 10% in terms of savings still save about 68%; only about 1% of the photos (p99) save less than 40%.
Pixel Dimensions: Not a Single Pixel Changed
Looking at resolution changes for all 32,188 images: dimensions_changed is false for every single one—100% kept the original resolution. ImgZilla does not resize or crop. The entire 76.7 GB of savings comes from re-encoding, not from taking pixels away. This is an easy half to overlook in “in-place compression”: not only are file names and paths unchanged, resolution is completely unchanged too.
Some Extreme Cases
| Case | Original | After compression | Saved |
|---|---|---|---|
| Highest compression ratio | 3.55 MB (4000×3000) | 100 KB | 97.2% |
| Most space saved on one image | 17.90 MB (4000×3000) | 1.13 MB | 16.8 MB |
| Least gain | 70 KB (1242×1242) | 68.8 KB | 2.1% |
The files with the highest compression ratios (95%+ saved) are usually camera shots with extremely high quality parameters and metadata-heavy files. The ones with the least benefit are already very small and had been processed before. On average, each image saved 2.38 MB.
5. Converting to a Monthly Bill: What Is This 76.8% Worth?
Saving space only becomes tangible on a bill. Below, we won’t cite any “compression improves conversion” type statistics. We’ll only do one thing: take the measured 76.8% and multiply it by current public prices from several cloud providers, in a pure arithmetic calculation.
Storage savings = space saved (GB) × unit price (¥ or $ per GB per month)
Egress traffic savings = space saved (GB) × download count for that month × unit price (¥ or $ per GB)
Storage Fees
| Original library size | Space saved | Alibaba Cloud OSS Standard ¥0.09/GB/month |
AWS S3 Standard $0.023/GB/month |
Google Cloud Storage $0.020/GB/month |
Cloudflare R2 $0.015/GB/month |
|---|---|---|---|---|---|
| 10 GB | 7.68 GB | ¥0.69/month | $0.18/month | $0.15/month | $0.12/month |
| 100 GB | 76.8 GB | ¥6.91/month | $1.77/month | $1.54/month | $1.15/month |
| 1 TB | 786 GB | ¥70.8/month | $18.1/month | $15.7/month | $11.8/month |
| This tested batch (99.9 GB) | 76.7 GB | ¥6.90/month | $1.76/month | $1.53/month | $1.15/month |
This fee recurs monthly. Compress once and every following month is billed on the new, smaller size—a one-time effort with long-term savings.
Traffic Fees: The Real Cost Driver
Traffic fees are volume × number of downloads. The more often images are viewed, the bigger the compression benefit. For example, a 100 GB image library generates 500 GB of outbound CDN traffic in a month (roughly the library being fully downloaded 5 times). Traffic shrinks by the same 76.8% as the volume:
| CDN egress price (entry tier) | Monthly traffic fee before compression | After compression | Monthly savings | Yearly savings |
|---|---|---|---|---|
| Alibaba Cloud CDN, China (¥0.15/GB) | ¥75.0 | ¥17.4 | ¥57.6 | ¥691 |
| AWS CloudFront, Asia-Pacific ($0.12/GB) | $60.0 | $13.9 | $46.1 | $553 |
| Google Cloud CDN, North America/Europe ($0.08/GB) | $40.0 | $9.3 | $30.7 | $369 |
These are the lowest published tiers for each provider; actual tiered pricing is usually higher, and the larger the bill, the more meaningful the absolute savings. Cloudflare R2 is an exception: its egress traffic is $0, so nearly all of the benefit is in storage fees.
Unit prices above are compiled from each platform’s public pricing in 2026. Actual prices vary by region, account discount, and pricing tier; check each platform’s official website for current prices. Download counts are illustrative assumptions—replace them with the real numbers from your own bill.
6. Local Scenarios: How Much Waiting Time Does Moving This Data Set Save?
A 76.8% reduction in volume shrinks transfer time by roughly the same proportion. That holds without a cloud bill, and it shows up directly in copy and backup wait times.
- USB3 portable mechanical hard drive: sustained throughput assumed to be 120 MB/s.
- USB3 portable SSD: assumed to be 450 MB/s.
- Gigabit wired network: 105 MB/s after protocol overhead.
| Scenario | Space saved | USB3 HDD | USB3 SSD | Gigabit network |
|---|---|---|---|---|
| This tested batch | 76.7 GB | ≈11 min | ≈2.9 min | ≈12.5 min |
| 10 GB library | 7.68 GB | ≈66 s | ≈17 s | ≈75 s |
| 100 GB library | 76.8 GB | ≈11 min | ≈2.9 min | ≈12.5 min |
| 1 TB library | 786 GB | ≈112 min | ≈30 min | ≈128 min |
As with storage fees, this is a one-time effort with long-term payoff: copying to/from a portable drive, syncing a NAS, running Time Machine, migrating to a new machine, or sending files to a colleague—whenever you still move this data, every transfer saves time by the same proportion.
7. If Compression Happens Before the User Uploads
Everything above is the accounting “after the image is stored.” There is another stretch worth calculating: the time between a user pressing “upload” and the progress bar finishing. This part runs on the user’s own upload bandwidth, and upload is almost always the slowest link in the whole chain. A camera-original photo is usually several MB per image—an order of magnitude larger than the “already compressed by a website, ~299 KB average” images from the previous article—so the difference in that time is far more obvious.
Using this batch’s measured per-image averages: camera originals are 2.96 MB on average, and after ImgZilla they average 0.69 MB, saving about 2.27 MB per image.
| Upload bandwidth (typical ranges from public speed tests, for reference only) | Single image 2.96MB→0.69MB |
Upload 50-photo album ≈148MB→34MB |
Upload all 32,188 from this batch 99.9GB→23.1GB |
|---|---|---|---|
| Mobile network (combined 4G/5G, assumed 30 Mbps) | Saves ≈0.6 s | Saves ≈30 s | Saves ≈5.7 hours |
| Typical home broadband upload (assumed 25 Mbps) | Saves ≈0.7 s | Saves ≈36 s | Saves ≈6.8 hours |
| Gigabit symmetric broadband upload (1000 Mbps) | Saves ≈0.02 s | Saves ≈0.9 s | Saves ≈10 min |
Saving 0.6 seconds per image isn’t very noticeable, but when you upload an entire album or batch-import hundreds of camera originals, the minutes saved are clearly noticeable—especially for mobile users with slow uplinks.
These range figures come from publicly available speed-test statistics in China. Actual speeds vary significantly based on carrier, region, device, and network congestion, so treat them as order-of-magnitude references only.
8. Data and Test Notes
- Sample scope: The data in this article is from an actual test of this batch of 32,188 camera/phone JPEG originals. It reflects the result for this particular sample, not a guarantee that “ImgZilla can compress 76.8% on average.” Different cameras and models will produce different results. If an image has already been highly optimized, the remaining compressibility will be much lower.
- Sample selection: The whole batch was compressed as-is in the original 16 subdirectories, with no selection or cleaning. There is no cherry-picking of favorable samples.
- Comparability with the previous article: The previous article’s 46.8% versus this article’s 76.8% is almost entirely due to whether the source images had already been compressed. Most libraries will fall between these two numbers—images that were compressed on ingest are closer to 46.8%, while fresh originals uploaded by users for the first time are closer to 76.8%.
- Terminology: The 76.8% in this article is “total bytes saved ÷ total original bytes.” The arithmetic mean of per-file compression ratios is 76.6%, and the median is 77.3%; both metrics are listed in the body above. Volume units are converted by 1 GB = 10⁹ bytes.
- Compression parameters: The parameters are fixed; there is no quality slider in the interface. This is a deliberate design trade-off—the parameters for each format have been tuned to the balance point of the visually-lossless range. Users who like manual tuning should note this.
- Runtime environment: Everything ran locally on this machine; images never leave this Mac, and no network connection is needed (except for App Store purchase verification).
Price references (2026 public pricing; for current prices please see each platform’s official website): AWS S3 Pricing, Alibaba Cloud OSS Pricing, Google Cloud Storage Pricing, Cloudflare R2 Pricing, Alibaba Cloud CDN Pricing, AWS CloudFront Pricing, Google Cloud CDN Pricing.
Want to verify it yourself? Download ImgZilla from the Mac App Store, run a real test on a few already-processed images from your own website, then decide whether to compress more.
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.