En titt inn på Instagrams komprimeringskvalitet

Instagram-applikasjonen for Android har blitt en av de mest populære plattformene for sosiale medier i verden i dag. Med over 300 millioner månedlige brukere på alle plattformer, og over 100 millioner individuelle nedlastinger på Google Playstore, kan du forvente at Facebooks øyeblikksbilde-delingsapplikasjon kan skryte av kvalitet både i design og funksjonalitet. For en stor del av sin brukerbase - det vil si Android-instagrammere - kommer Instagram dessverre til kort i å gjøre en god jobb på det eneste det er ment å gjøre - å dele pene bilder.

Selv om iOS-brukere kan dele sine kreasjoner og øyeblikk med høy tro, har Android-brukere rapportert ekstremt kvalitetstap på bildene sine i mange år nå. En av de eldste trådene som klaget over en slik hodepine ble funnet her i september 2012, og tråden har kjørt opp til nå, og gir leserne uortodokse måter å prøve å komme seg rundt på Instagrams latterlige ødeleggelse av bilder. Du skulle tro at etter over to år med klager, teknologiske forbedringer i både programvare og maskinvare, og økonomisk vekst og markedsvekst, ville Instagram ha adressert disse problemene. Er det noe de har skylden for? Eller løper den underliggende årsaken til problemet dypere enn det ser ut?

Et direkte blikk

Opprinnelig

1: 1 Avling

Her er et bilde jeg tok selv. Det originale skuddet veier 4, 34 MB og ble skutt på 9, 6 MP . For ikke å redegjøre for “Instacrop” -nedsampling som forståelig nok ville ødelegge detaljene i en slik høyoppløsningsfil ved senere å nedskalere den til Instagrams opprinnelige 640 × 640 pikslers utdata, beskjærte jeg den til en JPG i forholdet 1: 1 på Instagram opplastinger for å se de direkte effektene av etterbehandlingsalgoritmen og dens komprimering på denne filen.

Jeg tok rett og slett tak i den kvadratiske JPG-beskjeden og la den ut på Instagramen min uten noen ekstra filter, effekter eller justering av verdier. Du kan forvente at bildet skulle komme ut som ganske likt det som opprinnelig ble sett, men resultatet var underveisende. Kompresjonsartikkene rundt grenser og fargegradienter er imponerende merkbart for selv det utrente øyet. Mens den opprinnelige beskjæringsfilens størrelse på 1, 6 MB var 1, 6 MB, er det nye størrelsen på det komprimerte og komprimerte bildet 125 KB . Dette betyr at komprimeringen reduserte filstørrelsen på originalen med en faktor på nesten 13 - noe som ikke nødvendigvis er dårlig i noen sammenhenger.

Interessant nok tilbyr Instagram en “High Quality Image Processing” som er slått av som standard, men når den er slått på, ser det ikke ut til at resultatene virkelig forbedres, og den komprimerte filen ligger på 129KB . Her gir jeg deg den samme beskjeden, og du kan se at kompresjonen som er til stede fortsatt er ganske intens og at bildets troskap fortsatt har et grovt og pikslert tap.

Komprimert m / behandling av høy kvalitet av

Komprimert m / behandling av høy kvalitet PÅ

kompresjon

Datamaskinalgoritmer tilbyr forskjellige måter å redusere størrelsen på et bilde med forskjellige teknikker som optimaliserer

data som trengs for senere å bli tolket og vise riktig bilde på riktig måte. Mange filtyper for bilder er tett forbundet med disse komprimeringsteknikkene som de støtter eller ikke støtter - og det er derfor vi vanligvis ser bedre kvalitet på noen typer bilder enn andre. PNG- filer (Portable Network Graphics) brukes vanligvis til å dele medier uten å miste troskap og bildekvalitet, på bekostning av en større filstørrelse enn bilder som gjennomgår tapet komprimering. GIF er et veldig gammelt bildeformat som også komprimeres tapløst.

Teknikker for å redusere eller optimalisere filstørrelse læres av mange programmerere i sine akademiske aktiviteter, uavhengig av hvilket felt de vil utvikle seg i. Navn som deflasjon (brukt for PNG ) eller Lempel-Ziv-Welch- algoritmen (vanligvis brukt for GIF ) kjører gjennom mange datavitenskapelige klasserom i dag, ringer i mange programmerers ører, og med den videre utviklingen og dokumentasjonen av stadig mer effektive komprimeringsteknikker, kan du forvente at milliardærplattformen vil inkorporere rimelig effektive algoritmer for å gi et veldig fint bilde mens de tekniske for beskatte på serverne og maskinvaren til brukeren.

Men dette er rett og slett ikke tilfelle. Bildene som millioner av Instagrammers, og jeg, tar og laster opp hver dag, motsier direkte fortellingen om ingeniørferdighetene til disse supermaktene i tech-verdenen, som er ment å pumpe en stor brøkdel av inntektene sine på å investere tilbake i programvaren for å gi den beste brukeropplevelsen. Men det er fortsatt et spørsmål ubesvart her: Hvorfor Android og ikke iOS?

VSCO og Android-minne

Mens populære internettfora som Reddit prøvde å finne ut årsaken til deres daglige forargelse, syntes urettferdigheten ikke å ha noe annet logisk grunnlag enn den mulige forklaringen på at Android-maskinvare var iboende under datakraftavdelingen, eller det faktum at gitt det et stort utvalg av Android-enheter med lavere ende, disse tiltakene måtte tas for å sikre en jevn brukeropplevelse på hele plattformen - uavhengig av hvor mye du betalte for telefonen. Etter hvert som månedene gikk, rapporterte rapportene etter hver Instagram-oppdatering det samme problemet, til det punktet hvor dette problemet ble en løpende knebling blant forumbrukere som kort tid fulgte hver iterasjon av applikasjonen.

Brukere la også merke til en lignende forekomst med det populære kamera- og bilderedigeringsprogrammet VSCO Cam. Noen prøvde “den nye standarden for Android Photography”, og noen var raske til å merke at applikasjonen kom til kort på disse påstandene. Kvalitetstapet og typen gjenstander som ble lagt merke til, var lik den på Instagram, så noen var raske til å tro at det var en linje som forene prikkene. Frem til nå hadde vi bare spekulasjoner om hva årsaken til dette problemet kan være. Noen ga skylden for problemet direkte på Androids innebygde bitmap-downsampling-algoritmer. Det som imidlertid syntes å være den mest overbevisende årsaken som dukket opp var det enkle faktum at Instagram, og muligens VSCO, hadde en dårlig implementering av en downsampling-algoritme, nærmere bestemt den nærmeste naboen som ny sampling. Men uten det offisielle ordet fra utviklere, kunne ikke spekulasjonene bekreftes fullt ut.

Det var da vi lærte gjennom VSCOs tekniske støtte at grunnen til deres tap av oppløsning og troskap ikke var en dårlig programvareimplementering, men snarere en minnebegrensning i Android-enheter:

"De fleste Android-enheter er ganske begrenset i minnet til tross for at noen har oppover med noen få gigabyte minne, men applikasjoner har ikke lov til å bruke alt det tilgjengelige minnet, og vi må derfor gjøre rede for det som er gitt oss fra Android."

“Store bilder kan reduseres til 50% når du importerer, avhengig av enheten du er på og tilgjengelig minne.

De hevder også at det er bildebehandlingsteknikkene deres som beskatter både minne og SoC, og dette, sammen med Android-minnebegrensninger, er grunnen til at vi ser den flaskehalsen vi ikke finner på iOS.

I følge Android's utviklingsopplæringsartikler er det satt en hard grense for haugestørrelsen for hver app for å opprettholde et funksjonelt multitasking-miljø. Dette avhenger av hvor mye RAM enheten har tilgjengelig, og hvis appen nærmer seg haugekapasitet, risikerer den å gå tom for RAM.

Så ved første øyekast ser det ut til at VSCOs historie er overbevisende, men dette forklarer ikke noen av tingene som menneskene som tar en skeptiker tilnærming ikke kan se ut til å riste av seg.

begrensning

På et veldig overfladisk blikk kan vi stille dette spørsmålet: Hvis en smarttelefon som vanligvis har mellom 1 GB og 2 GB RAM og det siste innen bærbare prosessorer ikke kan behandle et bilde i full oppløsning, hvorfor er 32 MB RAM DSLR-kameraer i stand til det?

Vi kontaktet en av våre anerkjente eldre utviklere for å samle en sterkere mening om dette problemet. OmniROM-utvikler XpLoDWilD kommenterte:

"Begrensningen her er snarere måten bildet blir beregnet eller behandlet på. GPU er raskere for det, og den raskeste måten å gjøre det på er ved å 'laste opp' bildet til GPU som en tekstur og behandle det - problemet med det er at du er begrenset av GPU maksimale teksturstørrelse, som vanligvis er 4096 × 4096 “.

Generelt er 8MP-bilder 3264 × 2448, små nok til å passe inn i grensene for opptil 12MP på 4000 × 3000. Nyere flaggskip- og kamera-telefonsensorer kan gå oppover 13MP og har bildestørrelser større enn den maksimale GPU maksimale teksturstørrelse, noe som nødvendigvis vil måtte nedskalere bildet innenfor begrensningen og miste generelle detaljer.

"Problemet er ikke at apper laster opp en nedskalert versjon, men det er snarere at apper behandler en nedskalert versjon av bildet, og laster opp den behandlede filen", la han til. "Sannsynligvis for å redusere behandlingstiden ytterligere, setter de også oppløsningen enda lavere".

XpLoDWilD antyder at den fine balansen mellom behandlingstid og GPU-begrensning, i stedet for å vise brukeren en fullstendig behandlet forhåndsvisning av bildet de jobber med, har det visuelle hjelpemiddelet for redigeringsprosessen en nedskalert miniatyrbilde som kan passe på skjermen (noe mindre enn 2048 × 2048). Denne miniatyrbildet kan generelt behandles pålitelig raskt, samtidig som den gir brukeren et godt estimat av hvordan bildet vil se ut. Når brukeren bekrefter valgene han gjorde på verdijusteringene og filtervalget, ville bildet i full oppløsning bli transformert i bakgrunnen - ved å dele opp bildet i et rutenett med miniatyroppløsningsstørrelse og deretter behandle hver blokk separat. Det siste trinnet vil innebære å sammensette det endelige bildet på CPU-en ved å montere hvert område tilbake i ett stort fulloppløselig bitmap.

Det er en måte å behandle bildet i den opprinnelige oppløsningen på. Dette ser ikke ut til at Instagram ikke gjør, gitt at forhåndsvisningen du ser helt opp til det øyeblikket du behandler bildet, ikke har den samme forferdelige kvaliteten og gjenstandene til den som er klar til å laste opp. bilde. Forhåndsvisningsbildet ser ikke ut til å gjennomgå den brutale komprimeringen, så komprimeringen foregår i det øyeblikket behandlingen av det endelige bildet - som gir bildet av lav kvalitet.

Android-plattformen har egentlig ingen problemer med å behandle et bilde i høy full oppløsning og mye mindre å laste det opp. På maskinvaresiden har de nyeste iPhonene en størrelse på 2048 til 4096. Så det er sannsynligvis ikke en maskinvarebegrensning, og det er ikke en plattformbegrensning - som den kan, og har blitt, jobbet rundt av andre utviklere.

Men det var en hette til høyden, skjønt!

Ja, men ikke helt. Det er en rimelig grense for Java-haugen, på grunn av tilleggsminnet som trengs for bilder med høy tetthet. Etter litt undersøkelser fant jeg dette diskussjonsutdraget om en Google-gruppe som diskuterte Android NDK, eller Native Development Kit, som lar utviklere gjenbruke koden skrevet i C / C ++ ved å introdusere den i applikasjoner gjennom Java Native Interface, og gjøre utførelsen av appen noe raskere ettersom den direkte tolkes på prosessoren i stedet for en virtuell maskin.

I samtalen, som kan bli funnet her, fjerner Google-ingeniøren og Android Framework-utvikleren Dianne Hackborn noen misoppfatninger om Android minnes begrensninger. Hun bemerker at "gitt at dette er NDK-listen, er grensen faktisk ikke pålagt deg, fordi den bare er på Java-haugen. Det er ingen begrensning på tildelinger i den naturlige haugen ... “ . Når det gjelder bruken av RAM, kommenterer hun: “Hvis det er nok RAM, blir dataene lagret i RAM. Hvis ikke… vel, du løper fortsatt ”.

Hun sier også at det ikke bare er noen grense for den naturlige haugen, men at det heller ikke er en for GPU-dyngen. Så det ser ut til at det egentlig ikke er noen begrensninger “pålagt” av Android som helhet for hvor mye minne, generell behandling eller GPU du kan bruke, på grunn av NDKs eksistens.

Men selv da, Java-haugen skal være stor nok til ett bilde

. Et 13MP-bilde som en ukomprimert bitmap (ARGB 8888) vil ta omtrent 50 MB . Standard maksimal høystørrelse varierer opp til 256 MB eller 512 MB, avhengig av Android-enheten og Android-versjonen den kjører. Instagram tar omtrent 62 MB når den går på tomgang, og som jeg vurderer ut fra System Monitor-grafen, øker bruken av RAM-bruk under henting og behandlingen av et 13MP-bilde å være ubetydelig, og absolutt ingen steder i nærheten av grensen angivelig “pålagt av Android”, som kan jobbes rundt uansett, og det kan også unngås eller dempes ved å bruke visse algoritmer fremfor andre.

Konklusjon

Som tidligere nevnt, kanskje vi aldri kjenner hele historien om hva som skjer bak kulissene i disse appene. Men begrunnelsen fra produsentens svar eller fra apologene deres virker rett og slett ikke så sannsynlig ved nøye inspeksjon. Problemet her ser ut til å være forårsaket av middelmådig programvareimplementering i stedet for hvilken begrensning Android-maskinvare eller -programvare tilsynelatende kan gi.

At det finnes applikasjoner der ute som jobber rundt komprimering, pluss eksistensen og innholdet av dokumentasjon på Android's indre virkemåte, potensialet til nåværende Android-maskinvare og mening fra eksperter, ser ut til å peke mot den urettferdigheten Android-brukere står overfor bevisst eller i det minste anerkjent løselig.

Jeg tror det er på tide at Android-brukere ikke bare får sannheten, men også behandlingen de fortjener. Selv om det kan være slik at Android-enheter, som en gjennomsnitt og median, er under iPhones når det kommer til maskinvare, er det ingen grunn til å senke standardene og ødelegge alles brukeropplevelser over det. Og med hver utvikler som gir plattformen andrehåndsrester, fokuserer brukere i økende grad sin frustrasjon på utviklerne i stedet for systemet - som det skal være.

Kreditt til PixelPulse for kjennetegnet bilde