Forrige artikel testede de færdige billeder, som et website allerede havde komprimeret én gang – og ImgZilla sparede alligevel yderligere 46,8 %. Denne artikel bevæger sig til den modsatte yderlighed: originalbilleder, der kommer direkte fra kamera og mobil, og som aldrig er blevet behandlet af noget værktøj. Vi citerer heller ikke nogen branchestatistik, men viser bare resultatet af én ægte test, med metoden beskrevet til sammenligning.
1. Testobjektet denne gang: de ægte »originaler«
Prøverne i forrige artikel havde en forudsætning – billederne var blevet komprimeret én gang, da de blev lagt ind på websitet, og var derfor ikke længere rå. Denne gang fjerner vi den forudsætning og tester JPEG’er, der er eksporteret direkte fra kamera/mobil, uden at de har været igennem noget komprimeringsværktøj, uden at være gemt igen og uden en anden kodning.
Stikprøvens størrelse: 32.188 JPEG’er, arkiveret i 16 bucket-underbiblioteker, uden at være udvalgt eller ryddet op til testen.
Den samlede størrelse for filerne er: 99,9 GB (ca. 93 GiB).
Billedspecifikationerne er også typiske – alle er i standardopløsning fra kamera/mobil:
| Opløsning | Antal | Andel |
|---|---|---|
| 4000×3000 (12 MP) | 19.867 | 61,7 % |
| 4032×3024 (12 MP, iPhone) | 3.529 | 11,0 % |
| 3456×4608 (16 MP, stående) | 2.631 | 8,2 % |
| Andre (3120×4208, 4608×3456, 2448×3264 …) | 6.161 | 19,1 % |
Gennemsnitligt 11,5 megapixel og 2,96 MB pr. billede, og den største enkeltfil er på 18,3 MB og 30 megapixel. Det er de billeder, din mobil eller dit kamera tager, og som du aldrig har rørt.
Spørgsmålet er: hvor meget kan et specialiseret komprimeringsværktøj presse ud af den slags originalbilleder, som ingen har rørt?
2. Resultat: 76,8 % sparet – 99,9 GB bliver til 23,1 GB
32.188 billeder bliver komprimeret ét for ét på stedet, mens filnavne, mappestruktur og opløsning forbliver præcis som de var:
| Volumen | I forhold til original | |
|---|---|---|
| Originalbilleder direkte fra kamera | 99,9 GB | — |
| Efter komprimering med ImgZilla | 23,1 GB | -76,8 % |
Én komprimering sparer ca. 76,7 GB, og efter komprimeringen er der kun under en fjerdedel tilbage. De relative stier, filnavne og mapper for alle 32.188 filer er helt identiske før og efter – det kan direkte ses ved at sammenligne de faktiske data.
Sammenlignet med forrige artikel:
| Testrunde | Billedkilde | ImgZillas komprimering |
|---|---|---|
| Forrige artikel (4.624 billeder) | Billeder, som websitet allerede havde komprimeret én gang | -46,8 % |
| Denne artikel (32.188 billeder) | Originalbilleder direkte fra kamera/mobil | -76,8 % |
Konklusionen er ligetil: Jo mindre et originalbillede er blevet rørt, desto mere er der at hente. Den komprimering, der sker ved upload til websitet, har allerede fjernet en del af redundansen, så der er 46,8 % tilbage til ImgZilla. Men på de direkte kamerabilleder er denne redundans slet ikke rørt, og ImgZilla kan fjerne 76,8 % på én gang.
3. Hvorfor kan originalbilleder fra kamera spare så meget?
Når kameraer og mobiltelefoner eksporterer JPEG, er prioriteten »helst ingen detaljetab«, ikke »mindst mulig fil«. Derfor er der i de direkte JPEG’er en hel del volumen, der ikke bidrager til billedkvaliteten:
- Konservative kvalitetsparametre: Direkte JPEG’er bruger typisk kvantiseringstabeller på quality 90–98, hvor øjet for længst ikke kan skelne forskellen fra endnu højere kvalitet – men antallet af bytes er meget forskelligt.
- Generel og ikke-optimal entropikodning: Den direkte kodning bruger faste, standard Huffman-tabeller; den beregner ikke en optimal kodning for hvert enkelt billede og anvender hverken trellis-kvantisering eller progressiv scan-optimering.
- En bunke ekstra data: EXIF, GPS, producentspecifikke felter, et indlejret præview i fuld størrelse og farveprofiler – tilsammen ofte flere ti- eller hundredvis af KB.
ImgZilla laver en visuelt tabsfri omkodning af JPEG: det omarrangerer entropikodningen med en bedre kodningsstrategi, lægger kvantiseringsparametrene i et interval, hvor øjet ikke kan se forskel, og fjerner overflødige metadata. Der sker faktisk ændringer på pixelplan, men parametrene er valgt, så forskellen er praktisk taget usynlig. Derfor kan den på materiale som »originalbilleder« – med rigelig redundans – fjerne tre fjerdedele i én omgang.
Det er vigtigt at få styr på en term, der ofte blandes sammen: »visuelt tabsfri« er ikke det samme som »tabsfri«. Tabsfri (hvor pixelene er 100 % uændret) findes kun for PNG (oxipng) og SVG; JPEG, WebP, AVIF, HEIC og GIF er i princippet tabsgivende omkodninger, men med parametre valgt i det visuelt tabsfri område. Hvis du ikke vil tage ordet for det: ImgZilla har et indbygget sammenligningsvindue, hvor du kan se før/efter side om side, zoome til faktisk størrelse og sammenligne pixel for pixel – se selv.
4. Detaljer: komprimeringsgrad pr. fil, pixelstørrelse og ekstreme tilfælde
De første 76,8 % er en sammenligning af den samlede mængde for hele partiet på 32.188 billeder. Når man bryder det ned på enkeltfilniveau, dukker der et par mere konkrete ting op.
De fleste billeder sparer 70 %–90 %
Alle 32.188 billeder parres én for én efter »bytes før komprimering → bytes efter komprimering« og inddeles efter, hvor stor en andel der er sparet:
| Besparelse | Antal | Andel |
|---|---|---|
| 90 %–100 % | 866 | 2,7 % |
| 80 %–90 % | 11.375 | 35,3 % |
| 70 %–80 % | 15.244 | 47,4 % |
| 60 %–70 % | 3.349 | 10,4 % |
| 50 %–60 % | 398 | 1,2 % |
| Under 50 % | 956 | 3,0 % |
82,7 % af billederne sparede 70 %–90 %. Det gennemsnitlige komprimeringsforhold pr. fil er 76,6 % regnet som aritmetisk gennemsnit, hvilket næsten er sammenfaldende med de 76,8 %, der beregnes ud fra det samlede antal bytes – det viser, at billeder med stor og lille besparelse er ret jævnt fordelt vægtmæssigt, og at resultatet ikke er skævvredet af nogle få meget store filer.
Ser man på percentiler: mere end halvdelen af billederne sparede 77 % eller mere; selv de 10 % dårligste sparede omkring 68 %; kun ca. 1 % af billederne (p99) sparede under 40 %.
Pixelstørrelse: ikke en eneste pixel ændret
Ved at gennemgå opløsningen på alle 32.188 billeder er dimensions_changed false over hele linjen – 100 % bevarer den oprindelige opløsning. ImgZilla skalerer ikke og beskærer ikke. De sparede 76,7 GB kommer udelukkende fra omkodning – ikke fra at fjerne pixels. Det er den del af definitionen på »in-place-komprimering«, man let overser: Ikke kun filnavn og stier forbliver uændret, opløsningen er også fuldstændig urørt.
Et par ekstreme tilfælde
| Type | Original | Efter komprimering | Besparelse |
|---|---|---|---|
| Højeste komprimeringsgrad | 3,55 MB (4000×3000) | 100 KB | 97,2 % |
| Mest sparet på ét enkelt billede | 17,90 MB (4000×3000) | 1,13 MB | 16,8 MB |
| Mindst at hente | 70 KB (1242×1242) | 68,8 KB | 2,1 % |
Den gruppe med højest komprimering (sparer mere end 95 %) er typisk billeder, hvor kameraet har brugt meget høje kvalitetsparametre og er fyldt med metadata; dem med mindst udbytte er billeder, der i forvejen er meget små og har været behandlet tidligere. I gennemsnit bliver der sparet 2,38 MB pr. billede.
5. Regnet om til den månedlige regning: hvad er de 76,8 % værd?
Når størrelsen er sparet, bliver det først rigtig håndgribeligt, når det rammer regningen. Nedenfor citerer vi ingen statistikker om f.eks. »komprimering forbedrer konverteringsraten«. Vi gør kun én ting: tager den målte 76,8 % og ganger den med nogle af de aktuelle offentlige priser fra cloududbyderne – et rent regnestykke.
Besparelse på lageromkostninger = sparet volumen (GB) × enhedspris (¥ eller $ / GB / måned)
Besparelse på udgående trafik = sparet volumen (GB) × antal downloads i måneden × enhedspris (¥ eller $ / GB)
Lageromkostninger
| Billedbibliotek, original størrelse | Sparet volumen | Alibaba Cloud OSS Standard ¥0,09 / GB / måned |
AWS S3 Standard $0,023 / GB / måned |
Google Cloud Storage $0,020 / GB / måned |
Cloudflare R2 $0,015 / GB / måned |
|---|---|---|---|---|---|
| 10 GB | 7,68 GB | ¥0,69 / måned | $0,18 / måned | $0,15 / måned | $0,12 / måned |
| 100 GB | 76,8 GB | ¥6,91 / måned | $1,77 / måned | $1,54 / måned | $1,15 / måned |
| 1 TB | 786 GB | ¥70,8 / måned | $18,1 / måned | $15,7 / måned | $11,8 / måned |
| Faktisk test i denne artikel (99,9 GB) | 76,7 GB | ¥6,90 / måned | $1,76 / måned | $1,53 / måned | $1,15 / måned |
Det er en udgift, der gentages måned for måned: Komprimér én gang, og derefter faktureres der hver måned efter den nye størrelse – en engangsinvestering, der betaler sig løbende.
Trafikafgifter: den store post
Trafikafgiften er produktet af volumen × antal downloads. Jo oftere billederne hentes, desto større er komprimeringsbesparelsen. Eksempel: Et 100 GB billedbibliotek, der i en måned genererer 500 GB udgående trafik via CDN (svarende til, at hele biblioteket hentes ca. 5 gange), får med den tilsvarende volumenreduktion på -76,8 % også trafikken reduceret:
| CDN-pris for udgående trafik (første pristrin) | Månedlig trafikudgift før komprimering | Efter komprimering | Spar pr. måned | Spar pr. år |
|---|---|---|---|---|
| Alibaba Cloud CDN, Kina (¥0,15 / GB) | ¥75,0 | ¥17,4 | ¥57,6 | ¥691 |
| AWS CloudFront, Asien/Stillehavet ($0,12 / GB) | $60,0 | $13,9 | $46,1 | $553 |
| Google Cloud CDN, Nordamerika/Europa ($0,08 / GB) | $40,0 | $9,3 | $30,7 | $369 |
Der er brugt de laveste pristrin hos hver udbyder; de faktiske priser er som regel højere, og jo større regningen er, desto mere markant er den absolutte besparelse. Cloudflare R2 er en undtagelse: udgående trafik koster i sig selv $0, så hele besparelsen ligger reelt på lagersiden.
Ovenstående priser er en sammenstilling af platformenes offentlige priser fra 2026. De faktiske priser varierer alt efter region, kontorabat og pristrin; tjek altid den aktuelle pris på udbyderens hjemmeside. Antallet af downloads er et antaget eksempel – erstat det med de reelle tal fra din egen regning.
6. Lokale scenarier: hvor meget ventetid sparer man ved at flytte dataene?
Når volumen ryger ned med 76,8 %, forkortes overførselstiden stort set i samme forhold – det gælder også uden nogen cloud-regning, og det kan mærkes direkte, når man kopierer eller tager backup.
- USB3 ekstern mekanisk harddisk: vedvarende gennemstrømning på 120 MB/s
- USB3 ekstern SSD: 450 MB/s
- Gigabit kablet netværk: når protokoloverhead er trukket fra, 105 MB/s
| Scenarie | Sparet volumen | USB3 mekanisk harddisk | USB3 SSD | Gigabit-netværk |
|---|---|---|---|---|
| Den faktiske test i denne artikel | 76,7 GB | ≈ 11 min | ≈ 2,9 min | ≈ 12,5 min |
| 10 GB billedbibliotek | 7,68 GB | ≈ 66 sek | ≈ 17 sek | ≈ 75 sek |
| 100 GB billedbibliotek | 76,8 GB | ≈ 11 min | ≈ 2,9 min | ≈ 12,5 min |
| 1 TB billedbibliotek | 786 GB | ≈ 112 min | ≈ 30 min | ≈ 128 min |
Ligesom med lageromkostningerne er det en engangsinvestering, der giver udbytte hver gang: kopiere til/fra en ekstern harddisk, synkronisere en NAS, køre Time Machine, migrere til en ny computer, sende til en kollega – så længe dataene flyttes, sparer man tid i samme forhold.
7. Hvis komprimeringen sker, før brugeren uploader
Indtil nu har vi regnet på billeder, der allerede ligger gemt. Der er endnu et sted, som er mere værd at regne på: tiden fra brugeren klikker på »Upload«, til statuslinjen er færdig. Her bruges brugerens egen upload-båndbredde – og upload er næsten altid det langsomste led i hele kæden. Et originalt kamerabillede er på flere MB, hvilket er en størrelsesorden større end de allerede komprimerede billeder fra forrige artikel (gennemsnit 299 KB), så forskellen i tid er også langt mere tydelig.
Regner man med gennemsnitsstørrelsen pr. billede i denne test: kamerabillederne er i gennemsnit 2,96 MB, efter ImgZilla-komprimering 0,69 MB – en besparelse på ca. 2,27 MB pr. billede.
| Upload-båndbredde (typisk interval fra offentlige hastighedstests, kun som reference) | Enkelt billede 2,96 MB → 0,69 MB |
Upload af 50 billeder i et album ≈ 148 MB → 34 MB |
Upload af alle 32.188 billeder 99,9 GB → 23,1 GB |
|---|---|---|---|
| Mobilt netværk (4G/5G kombineret – antag 30 Mbps) | sparer ca. 0,6 sek | sparer ca. 30 sek | sparer ca. 5,7 timer |
| Typisk bredbåndsopload (antag 25 Mbps) | sparer ca. 0,7 sek | sparer ca. 36 sek | sparer ca. 6,8 timer |
| Gigabit symmetrisk bredbånd (1000 Mbps) | sparer ca. 0,02 sek | sparer ca. 0,9 sek | sparer ca. 10 min |
0,6 sekunders besparelse pr. billede føles måske ikke af meget, men når man uploader et helt album på én gang eller importerer flere hundrede kamerabilleder i én omgang, er de sparede minutter tydeligt mærkbare – især for mobile brugere, hvis upload i forvejen er langsom.
Tallene i intervallet kommer fra offentlige hastighedsmålinger i Kina. Den faktiske hastighed afhænger meget af udbyder, region, enhed og netværksbelastning, og tallene bør kun bruges til at vurdere størrelsesordenen.
8. Data og testbetingelser
- Stikprøve: Tallene i artiklen stammer fra en faktisk test af 32.188 JPEG’er direkte fra kamera/mobil. Resultatet beskriver netop denne stikprøve og betyder ikke, at »ImgZilla i gennemsnit kan spare 76,8 %«. Forskellige kameraer og modeller giver forskellige resultater; billeder, der allerede er blevet omhyggeligt optimeret, har markant mindre at hente.
- Udvælgelse: Hele partiet er komprimeret uden nogen form for filtrering eller oprydning, i de oprindelige 16 undermapper. Der er ikke plukket fordelagtige billeder ud.
- Sammenligning med forrige artikel: Forskellen mellem forrige artikels 46,8 % og denne artikels 76,8 % skyldes næsten udelukkende om materialet allerede har været komprimeret. De fleste billedbiblioteker vil ligge et sted imellem – biblioteker, der er blevet komprimeret ved upload, ligger tættere på 46,8 %, og brugergenererede originaler ved første upload ligger tættere på 76,8 %.
- Opgørelsesmetode: De 76,8 % i artiklen er »samlet antal sparede bytes ÷ samlet antal oprindelige bytes«. Det aritmetiske gennemsnit af komprimeringsgraden pr. fil er 76,6 %, og medianen er 77,3 % – begge opgørelser er angivet i teksten. Volumen er regnet med 1 GB = 10⁹ bytes.
- Komprimeringsparametre: Parametrene er faste – der er ingen kvalitetsglider i brugergrænsefladen. Det er et bevidst designvalg; parametrene for hvert format er afstemt til en balance i det visuelt tabsfri område. Brugere, der er vant til at justere parametre manuelt, skal være opmærksomme på dette.
- Kørselsmiljø: Hele processen kører lokalt på denne Mac; billederne forlader ikke maskinen, og der kræves ingen internetforbindelse (undtagen App Store-købsvalidering).
Prisreferencer (offentlige priser fra 2026; de gældende priser på udbydernes hjemmesider er altid de autoritative): AWS S3 Pricing, Alibaba Cloud OSS-priser, Google Cloud Storage-priser, Cloudflare R2-priser, Alibaba Cloud CDN-priser, AWS CloudFront-priser, Google Cloud CDN-priser.
Vil du afprøve det selv? Download ImgZilla direkte fra Mac App Store, kør den på et par allerede behandlede billeder fra dit eget website, og beslut derefter, om du vil komprimere resten.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Lær mere: https://imagetool.app/ImgZilla
Systemkrav: macOS 12.3 eller nyere.