L'articolo precedente aveva testato le immagini finali già compresse una volta dal sito, e ImgZilla ha risparmiato un altro 46,8%. Questo articolo sposta l'attenzione sull'estremo opposto: foto originali appena esportate da fotocamera e smartphone, mai elaborate da alcuno strumento. Anche qui niente statistiche di settore: solo il risultato di un test reale, con il metodo di confronto.
1. L'oggetto del test: i veri “originali”
I campioni dell'articolo precedente partivano da un presupposto: quelle immagini erano già state compresse una volta dal sito al momento dell'archiviazione, quindi non erano più foto originali. Questa volta il presupposto viene eliminato: il test riguarda JPEG esportati direttamente da fotocamera o smartphone, senza passare per strumenti di compressione, senza “Salva con nome” e senza una seconda codifica.
Dimensione del campione: 32188 JPEG, archiviati in 16 sottodirectory “bucket”, senza selezioni o ripuliture per il test.
Il volume complessivo di questi file: 99,9 GB (circa 93 GiB).
Anche le specifiche sono tipiche: tutte risoluzioni di output standard di fotocamera o smartphone:
| Risoluzione | Numero di foto | Percentuale |
|---|---|---|
| 4000×3000 (12MP) | 19867 | 61,7% |
| 4032×3024 (12MP, iPhone) | 3529 | 11,0% |
| 3456×4608 (16MP verticale) | 2631 | 8,2% |
| Altre (3120×4208, 4608×3456, 2448×3264…) | 6161 | 19,1% |
In media 11,5 megapixel per foto, 2,96 MB, con il singolo file più grande da 18,3 MB e 30 megapixel. Sono le foto che hai scattato con il telefono o la fotocamera e di cui non ti sei mai occupato.
La domanda è: quanto può recuperare uno strumento di compressione specializzato da questi originali che “nessuno ha mai toccato”?
2. Risultato: risparmiati il 76,8%, 99,9 GB diventano 23,1 GB
Le 32188 foto sono state compresse una per una in place, lasciando invariati nome file, struttura delle directory e risoluzione:
| Volume | Rispetto all'originale | |
|---|---|---|
| Foto originale dalla fotocamera | 99,9 GB | — |
| Dopo compressione ImgZilla | 23,1 GB | -76,8% |
Una sola passata di compressione ha risparmiato circa 76,7 GB, lasciando il tutto a meno di un quarto delle dimensioni originali. I percorsi relativi, i nomi dei file e la gerarchia delle directory di tutti i 32188 file sono rimasti identici prima e dopo: questa è una differenza misurabile direttamente sui dati reali.
Confronto con l'articolo precedente:
| Lotto di test | Provenienza delle immagini | Percentuale di compressione ImgZilla |
|---|---|---|
| Articolo precedente (4624 foto) | Immagini finali già compresse una volta dal sito | -46,8% |
| Questo articolo (32188 foto) | Foto originali da fotocamera / smartphone | -76,8% |
La conclusione è diretta: più il file originale non è stato toccato, maggiore è lo spazio recuperabile. La compressione fatta dal sito al momento dell'archiviazione aveva già assorbito parte della ridondanza, lasciando a ImgZilla il 46,8%; nelle foto direttamente dalla fotocamera, invece, quella ridondanza era del tutto intatta e ImgZilla è riuscita a toglierne il 76,8% in un'unica passata.
3. Perché le foto originali della fotocamera si comprimono così tanto
Quando fotocamere e smartphone esportano JPEG, la priorità è “non perdere dettagli”, non “rendere il file il più piccolo possibile”. Di conseguenza, i JPEG appena esportati contengono una grande quantità di dati che non contribuiscono alla qualità visiva:
- Parametri di qualità prudenti: i JPEG appena esportati usano di solito tabelle di quantizzazione con quality 90–98; l'occhio umano non distingue più la differenza con una qualità più alta, ma i byte aumentano parecchio.
- Codifica entropica generica e non ottimale: la codifica diretta utilizza una tabella di Huffman standard fissa, non calcola la codifica ottimale per ogni singola immagine e non applica né la quantizzazione trellis né l'ottimizzazione della scansione progressiva.
- Un sacco di metadati: EXIF, GPS, campi privati del produttore, miniatura di anteprima completa incorporata, profili colore: insieme raggiungono spesso decine o centinaia di kilobyte.
Ciò che ImgZilla fa sui JPEG è una ricodifica visivamente lossless: riorganizza la codifica entropica con una strategia migliore, porta i parametri di quantizzazione in un intervallo impercettibile all'occhio ed elimina i metadati ridondanti. A livello di pixel c'è effettivamente qualche modifica, ma i parametri sono scelti in un punto in cui la differenza è quasi invisibile. Per questo, su file come questi “originali” pieni di ridondanza, in una sola passata si riesce a eliminare i tre quarti del peso.
Va chiarito un termine che viene spesso confuso: “visivamente lossless” non è “lossless”. Il lossless (pixel completamente invariati) esiste solo per PNG (oxipng) e SVG; JPEG, WebP, AVIF, HEIC e GIF sono, per loro natura, ricodifiche lossy, solo che i parametri di compressione sono scelti in un intervallo visivamente lossless. Se non vuoi crederci sulla parola, ImgZilla ha una finestra di confronto integrata, con vista affiancata prima/dopo e zoom al 100% per controllare pixel per pixel: guarda con i tuoi occhi.
4. Analisi nel dettaglio: rapporto di compressione per file, dimensioni in pixel e casi estremi
Il 76,8% precedente è il confronto sul volume totale dei 32188 file. Scendendo al livello dei singoli file emergono altre cose più concrete.
La stragrande maggioranza delle foto risparmia il 70%–90%
Le 32188 foto sono state abbinate una a una come “byte prima → byte dopo” e classificate in base alla percentuale di risparmio:
| Percentuale risparmiata | Numero foto | Percentuale |
|---|---|---|
| 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% |
| Sotto il 50% | 956 | 3,0% |
L'82,7% delle foto ha risparmiato tra il 70% e il 90%. La media aritmetica del rapporto di compressione per singolo file è un risparmio del 76,6%, quasi identico al 76,8% calcolato sul totale dei byte: significa che, in questo lotto, foto molto compresse e foto poco compresse sono distribuite in modo abbastanza uniforme in termini di peso, senza che pochi file enormi distorcano il risultato.
Guardando ai percentili: più della metà delle foto ha risparmiato oltre il 77%; anche il 10% con il recupero peggiore ha risparmiato circa il 68%; solo circa l'1% delle foto (p99) è sceso sotto il 40% di risparmio.
Dimensioni in pixel: non un pixel è cambiato
Il calcolo sulle variazioni di risoluzione di tutte le 32188 immagini: dimensions_changed è false per tutte — il 100% mantiene la risoluzione originale. ImgZilla non ridimensiona e non ritaglia: i 76,7 GB risparmiati provengono interamente dalla ricodifica, non da una riduzione dei pixel. È la metà della definizione di “compressione in place” che spesso viene dimenticata: non restano uguali solo i nomi dei file e i percorsi, ma anche la risoluzione.
Alcuni casi estremi
| Tipo | Originale | Dopo compressione | Risparmio |
|---|---|---|---|
| Rapporto di compressione più alto | 3,55 MB (4000×3000) | 100 KB | 97,2% |
| Maggior risparmio su una singola foto | 17,90 MB (4000×3000) | 1,13 MB | 16,8 MB |
| Recupero peggiore | 70 KB (1242×1242) | 68,8 KB | 2,1% |
Il gruppo con il maggior rapporto di compressione (oltre il 95% di risparmio) è di solito composto da foto scattate con parametri di qualità molto alti e piene di metadati; quelli con il recupero peggiore sono immagini già piccole e processate in precedenza. In media, ogni foto ha risparmiato 2,38 MB.
5. Convertito in bolletta mensile: quanto vale questo 76,8%
Quando il volume si riduce, lo si capisce davvero solo guardando la bolletta. Qui non citiamo statistiche del tipo “la compressione aumenta le conversioni”: facciamo solo una cosa, cioè prendiamo il 76,8% misurato e lo moltiplichiamo per le attuali tariffe pubbliche di alcuni provider cloud. Puro calcolo aritmetico.
Risparmio sui costi di archiviazione = volume risparmiato (GB) × prezzo unitario (yuan o dollari / GB / mese)
Risparmio sui costi di traffico in uscita = volume risparmiato (GB) × numero di download nel mese × prezzo unitario (yuan o dollari / GB)
Costi di archiviazione
| Dimensione originale della raccolta | Volume risparmiato | Alibaba Cloud OSS Standard ¥0,09/GB/mese |
AWS S3 Standard $0,023/GB/mese |
Google Cloud Storage $0,020/GB/mese |
Cloudflare R2 $0,015/GB/mese |
|---|---|---|---|---|---|
| 10 GB | 7,68 GB | ¥0,69/mese | $0,18/mese | $0,15/mese | $0,12/mese |
| 100 GB | 76,8 GB | ¥6,91/mese | $1,77/mese | $1,54/mese | $1,15/mese |
| 1 TB | 786 GB | ¥70,8/mese | $18,1/mese | $15,7/mese | $11,8/mese |
| Il lotto misurato in questo test (99,9 GB) | 76,7 GB | ¥6,90/mese | $1,76/mese | $1,53/mese | $1,15/mese |
È un costo che si ripete ogni mese: si comprime una volta e da quel momento ogni mese la fatturazione si basa sul nuovo volume. Un investimento una tantum che produce benefici a lungo termine.
Traffico: la voce davvero pesante
Il costo del traffico è il prodotto di volume × numero di download: più le immagini vengono visitate, maggiore è il beneficio della compressione. Esempio: una raccolta di 100 GB genera in un mese 500 GB di traffico in downstream via CDN (l'equivalente di circa 5 download completi dell'intera raccolta). Con il volume ridotto dello stesso -76,8%, il traffico si riduce in proporzione:
| Tariffe traffico in uscita CDN (primo scaglione) | Costo mensile traffico prima | Dopo | Risparmio mensile | Risparmio annuo |
|---|---|---|---|---|
| Alibaba Cloud CDN Cina (¥0,15/GB) | ¥75,0 | ¥17,4 | ¥57,6 | ¥691 |
| AWS CloudFront Asia Pacifico ($0,12/GB) | $60,0 | $13,9 | $46,1 | $553 |
| Google Cloud CDN Nord America/Europa ($0,08/GB) | $40,0 | $9,3 | $30,7 | $369 |
Sono tutte tariffe del primo scaglione, le più basse offerte da ogni provider; nella pratica i prezzi degli scaglioni successivi sono spesso più alti, e più è alta la bolletta, più il risparmio assoluto è significativo. Fa eccezione Cloudflare R2: il traffico in uscita costa $0, quindi il beneficio si concentra quasi tutto sull'archiviazione.
I prezzi sopra riportati sono una sintesi delle tariffe pubbliche del 2026. I prezzi effettivi variano in base ad area geografica, sconti sull'account e scaglioni di utilizzo: fai sempre riferimento ai prezzi correnti sul sito ufficiale. Il numero di download è un'ipotesi di esempio: sostituiscilo con i dati reali della tua bolletta.
6. Scenario locale: quanto tempo di attesa si risparmia spostando questi dati
Riducendo il volume del 76,8%, i tempi di trasferimento si accorciano più o meno nella stessa proporzione. Questo vale anche senza una bolletta del cloud e si nota direttamente nell'attesa di copie e backup.
- Disco rigido mobile USB3: throughput sostenuto 120 MB/s.
- SSD mobile USB3: 450 MB/s.
- Rete cablata gigabit: tolto il protocollo, 105 MB/s.
| Scenario | Volume risparmiato | HDD USB3 | SSD USB3 | Rete gigabit |
|---|---|---|---|---|
| Questo lotto di prova | 76,7 GB | ≈11 min | ≈2,9 min | ≈12,5 min |
| Raccolta da 10 GB | 7,68 GB | ≈66 sec | ≈17 sec | ≈75 sec |
| Raccolta da 100 GB | 76,8 GB | ≈11 min | ≈2,9 min | ≈12,5 min |
| Raccolta da 1 TB | 786 GB | ≈112 min | ≈30 min | ≈128 min |
Come per l'archiviazione, si tratta di un investimento una tantum che produce benefici continui: copiare avanti e indietro un hard disk, sincronizzare un NAS, eseguire Time Machine, migrare su un nuovo computer, inviare file a un collega: ogni volta che sposti questi dati, risparmi tempo in questa proporzione.
7. Se la compressione avviene prima dell'upload dell'utente
Finora abbiamo calcolato il bilancio “dopo che le immagini sono state salvate”. C'è un altro tratto che merita ancora più attenzione: il tempo che passa da quando l'utente preme “Carica” a quando la barra di avanzamento finisce, un tempo che viaggia sulla banda di upload dell'utente — quasi sempre l'anello più lento dell'intera catena. Le foto originali fuori dalla fotocamera pesano diversi MB l'una, un ordine di grandezza in più rispetto alle immagini finali “già compresse dal sito, in media 299 KB” dell'articolo precedente, quindi la differenza su questo tratto è molto più evidente.
Usando la dimensione media per foto rilevata in questo lotto: le foto originali pesano in media 2,96 MB, dopo ImgZilla scendono a 0,69 MB in media, con un risparmio di circa 2,27 MB per foto.
| Banda di upload (intervallo tipico dei test di velocità pubblici, solo riferimento) | Singola foto 2,96MB→0,69MB |
Upload di un album da 50 foto ≈148MB→34MB |
Upload di tutte le 32188 foto di questo lotto 99,9GB→23,1GB |
|---|---|---|---|
| Rete mobile (combinazione 4G/5G, 30 Mbps) | risparmio ≈0,6 sec | risparmio ≈30 sec | risparmio ≈5,7 ore |
| Linea domestica comune in upload (25 Mbps) | risparmio ≈0,7 sec | risparmio ≈36 sec | risparmio ≈6,8 ore |
| Fibra simmetrica gigabit in upload (1000 Mbps) | risparmio ≈0,02 sec | risparmio ≈0,9 sec | risparmio ≈10 min |
0,6 secondi per una singola foto non sono ancora percepibili, ma quando carichi un intero album in una volta, o importi in batch centinaia di foto originali dalla fotocamera, i minuti risparmiati si sentono in modo chiaro — soprattutto per gli utenti con connessioni mobili che hanno già upload lenti.
I valori indicativi provengono da statistiche pubbliche sui test di velocità; le velocità effettive variano molto in base a operatore, area geografica, dispositivi e congestione della rete. Da considerare solo come ordine di grandezza.
8. Dati e note sul test
- Ambito del campione: I dati di questo articolo provengono dalla misurazione reale di questo lotto di 32188 JPEG esportati da fotocamera/smartphone e riflettono il risultato di questo specifico campione, non significano che “ImgZilla comprime in media del 76,8%”. Fotocamere diverse, modelli diversi: i risultati cambiano; su immagini già ottimizzate con cura, lo spazio recuperabile è chiaramente minore.
- Selezione del campione: L'intero lotto non è stato filtrato o ripulito in alcun modo: è stato compresso integralmente mantenendo le 16 sottodirectory originali. Non c'è stata alcuna selezione di campioni favorevoli.
- Confrontabilità con l'articolo precedente: Il 46,8% dell'articolo precedente e il 76,8% di questo dipendono quasi interamente dal fatto che il materiale fosse già stato compresso o no. La maggior parte delle librerie di immagini si colloca tra questi due valori: quelle già compresse all'archiviazione si avvicinano al 46,8%, le foto originali al primo upload dell'utente sono più vicine al 76,8%.
- Criterio statistico: Il 76,8% citato nel testo è “byte totali risparmiati ÷ byte totali originali”; la media aritmetica dei rapporti di compressione per singolo file è 76,6%, con mediana di 77,3%. Entrambi i criteri sono indicati nel testo. Le unità di volume sono convertite secondo 1 GB = 10⁹ byte.
- Parametri di compressione: I parametri sono fissi; nell'interfaccia non c'è alcuno slider della qualità. È una scelta progettuale: per ogni formato i parametri sono calibrati sul punto di equilibrio all'interno dell'intervallo visivamente lossless. Gli utenti abituati a regolare tutto manualmente devono tenerne conto.
- Ambiente di esecuzione: Tutto è stato eseguito in locale sulla macchina; le immagini non lasciano questo Mac e non è richiesta alcuna connessione di rete (a parte la verifica dell'acquisto su App Store).
Fonti dei prezzi di riferimento (tariffe pubbliche 2026, fare sempre riferimento ai prezzi in tempo reale sui siti ufficiali): AWS S3 Pricing, Prezzi di Alibaba Cloud OSS, Google Cloud Storage Pricing, Cloudflare R2 Pricing, Prezzi di Alibaba Cloud CDN, AWS CloudFront Pricing, Google Cloud CDN Pricing.
Vuoi verificare di persona? Scarica ImgZilla direttamente dal Mac App Store e prova su alcune immagini già elaborate del tuo sito, poi decidi se comprimere anche le altre.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Per saperne di più: https://imagetool.app/ImgZilla
Requisiti di sistema: macOS 12.3 o versioni successive.