En titt på Instagrams komprimeringskvalitet

Instagram-applikationen för Android har blivit en av de mest populära sociala medieplattformarna i världen idag. Med över 300 miljoner användare per månad på alla plattformar, och över 100 miljoner individuella nedladdningar på Google Playstore, förväntar du dig att Facebooks app för delning av ögonblicksbilder kommer att ståta med kvalitet i både design och funktionalitet. Tyvärr, för en stor del av sin användarbas - det vill säga Android-instagrammare - kommer Instagram till korta när det gäller att göra ett bra jobb med det enda som det är tänkt att göra - att dela vackra bilder.

Medan iOS-användare kan dela sina skapelser och ögonblick med hög trohet, har Android-användare rapporterat extrem kvalitetsförlust på sina bilder i flera år nu. En av de äldsta trådarna som klagar över sådan huvudvärk hittades här på XDA i september 2012, och tråden har pågått fram till nu, vilket ger läsarna oortodoxa sätt att försöka komma runt Instagrams löjliga förstörelse av foton. Man skulle kunna tro att efter över två år av klagomål, tekniska förbättringar av både mjukvara och hårdvara, och ekonomisk tillväxt och marknadstillväxt, skulle Instagram ha åtgärdat dessa problem. Är det något de är skyldiga till? Eller ligger den bakomliggande orsaken till problemet djupare än det verkar?

En direkt titt

Här är en bild jag tog själv. Originalskottet väger 4,34 MB och blev beskjuten 9,6 MP. Att inte ta hänsyn till "Instacrop"-nedsamplingen som förståeligt nog skulle förstöra detaljerna i en sådan högupplöst fil genom att senare nedskala den till Instagrams ursprungliga 640x640 pixelutgång, jag beskärde den till en JPG med bildförhållandet 1:1 för Instagram-uppladdningar för att se de direkta effekterna av efterbehandlingsalgoritmen och dess komprimering på detta fil.

Jag tog helt enkelt tag i den kvadratiska JPG-beskärningen och lade upp den på min Instagram utan några tillagda filter, effekter eller justeringar av några värden. Du förväntar dig att bilden kommer att se ganska lik ut som det som sågs ursprungligen, men resultatet var underväldigande. Kompressionsartefakterna runt kanter och färggradienter är förbluffande märkbara även för det otränade ögat. Medan den ursprungliga 1:1 beskärningsfilens storlek var 1,6 MB, är den nya storleksändrade och komprimerade bilden 125 kB. Det betyder att komprimeringen minskade filstorleken på originalet med nästan en faktor 13 - vilket inte nödvändigtvis är dåligt i vissa sammanhang.

Intressant nog erbjuder Instagram en "högkvalitativ bildbehandling" som är avstängd som standard, men när den är påslagen verkar resultaten inte riktigt förbättras, och den komprimerade filen sitter på 129 kB. Här ger jag dig samma beskärning och du kan se att komprimeringen fortfarande är ganska intensiv och att bildens trohet fortfarande har en grov och pixlad förlust.

Kompression

Datoralgoritmer erbjuder olika sätt att minska storleken på en bild med olika tekniker som optimerar

data som behövs för att senare tolkas och visa lämplig bild på lämpligt sätt. Många filtyper för bilder är nära förknippade med dessa komprimeringstekniker som de stöder eller inte stöder - och det är därför vi vanligtvis ser bättre kvalitet på vissa typer av bilder än andra. PNG (Portable Network Graphics)-filer används vanligtvis för att dela media utan att förlora kvalitet och bildkvalitet, på bekostnad av en större filstorlek än bilder som genomgår förlustkomprimering. GIF är ett mycket gammalt bildformat som också komprimeras förlustfritt.

Tekniker för att minska eller optimera filstorleken lär sig av många programmerare i sina akademiska sysselsättningar oavsett vilket område de kommer att utvecklas inom. Namn som t.ex deflation (används för PNG) eller den Lempel-Ziv-Welch algoritm (används vanligtvis för GIF) går igenom många datavetenskapsklassrum nuförtiden, ringer i många programmerares öron, och med vidareutveckling och dokumentation av allt mer effektiva kompressionstekniker, du förväntar dig att miljardärsplattformen kommer att införliva någorlunda effektiva algoritmer för att producera en mycket snygg bild samtidigt som de tekniska detaljerna inte belastar deras servrar och användarens hårdvara.

Men detta är helt enkelt inte fallet. Bilderna som miljontals Instagrammers, och jag, tar och laddar upp varje dag motsäger direkt berättelsen om ingenjörsskickligheten hos dessa supermakter i teknikvärlden, som är tänkta att pumpa en stor del av sina intäkter på att investera tillbaka i sin mjukvara för att ge den bästa användaren erfarenhet. Men det finns fortfarande en fråga obesvarad här: Varför Android och inte iOS?

VSCO och Android-minne

Medan populära internetforum som Reddit försökte ta reda på orsaken till deras dagliga upprördhet, verkade orättvisan inte ha någon annan logisk grund. än den möjliga förklaringen till att Android-hårdvara är i sig underlägsen inom datorkraftsavdelningen, eller det faktum att, med tanke på det stora utbudet av Android-enheter i lägre prisklass, måste dessa åtgärder vidtas för att säkerställa en konsekvent användarupplevelse över hela plattformen – oavsett hur mycket du betalat för din telefon. Allt eftersom månaderna gick fortsatte rapporterna efter varje Instagram-uppdatering att rapportera samma problem, till punkt och pricka där detta problem blev en pågående gag bland forumanvändare som snart följde varje iteration av Ansökan.

Användare märkte också en liknande händelse med den populära kamera- och bildredigeringsapplikationen VSCO Cam. Som "den nya standarden för Android-fotografering" utsågs till att vissa var snabba att märka att applikationen misslyckades med dessa påståenden. Kvalitetsförlusten och typen av artefakter som noterades liknade den på Instagram, så vissa var snabba att tro att det fanns en linje som förenade prickarna. Hittills har vi bara spekulerat i vad orsaken till detta problem kan vara. Vissa skyllde problemet direkt på Androids inbyggda bitmappsnedsamplingsalgoritmer. Det som dock verkade vara den mest övertygande orsaken som hade dykt upp var det enkla faktum att Instagram, och möjligen VSCO, hade en dålig implementering av en nedsamplingsalgoritm, särskilt Omsampling av närmaste granne. Men utan det officiella ordet från utvecklarna kunde spekulationerna inte bekräftas helt.

Det var då vi lärde oss igenom VSCO: s tekniska support att orsaken till deras förlust av upplösning och trohet inte var en dålig mjukvaruimplementering, utan snarare en minnesbegränsning i Android-enheter:

"De flesta Android-enheter är ganska begränsade i minnet trots att vissa har uppåt några gigabyte minne, men applikationer får inte använda allt som är tillgängligt minne och därför måste vi betala med det som ges till oss från Android."

"Stora bilder kan förminskas med upp till 50 % vid import beroende på vilken enhet du använder och tillgängligt minne.“

De hävdar också att det är deras bildbehandlingstekniker som är mycket belastande för både minne och SoC, och detta, tillsammans med Android-minnesbegränsningar, är anledningen till att vi ser kvalitetsflaskhalsen som vi inte hittar på iOS.

Enligt Androids artiklar om utvecklarutbildning, sätts en hård gräns på högstorlek för varje app att upprätthålla en fungerande multitasking-miljö. Detta beror på hur mycket RAM-minne enheten har tillgängligt, och om appen närmar sig heapkapacitet riskerar den att ta slut på RAM-minnet.

Så vid första anblicken, det verkar att VSCO: s berättelse är övertygande, men detta förklarar inte några av de saker som personer som tar en skeptikers inställning inte verkar kunna skaka av sig.

Begränsning

Vid en mycket ytlig blick kan vi ställa denna fråga: Om en smartphone som vanligtvis har mellan 1 GB och 2 GB RAM och det senaste inom bärbara processorer kan inte bearbeta en bild i full upplösning, varför kan DSLR-kameror med 32 MB RAM den där?

Vi kontaktade en av våra seniora erkända utvecklare för att samla in en starkare åsikt om denna fråga. OmniROM utvecklare XpLoDWilD kommenterade:

"Begränsningen här är snarare hur bilden beräknas eller bearbetas. GPU är snabbare för det, och det snabbaste sättet att göra det är genom att "ladda upp" bilden till GPU: n som en textur och bearbeta det - problemet med det är att du är begränsad av GPU: ns maximala texturstorlek, vilket generellt är 4096x4096."

I allmänhet är 8MP-bilder 3264x2448, tillräckligt små för att passa in i gränserna på upp till 12MP på 4000x3000. Nyare flaggskepps- och kamera-telefonsensorer kan gå uppåt på 13 MP och har bildstorlekar större än den maximala GPU maximal texturstorlek, som oundvikligen skulle behöva nedskala bilden inom begränsningen och förlora totalt detalj.

"Problemet är inte att appar är det ladda upp en nedskalad version, men det är snarare så att appar är det bearbeta en nedskalad version av bilden, och ladda upp den bearbetade filen”, tillade han. "Antagligen för att minska bearbetningstiden ytterligare satte de också upplösningen ännu lägre".

XpLoDWilD föreslår att den fina balansen mellan Behandlingstid och GPU-begränsning skulle vara, snarare än att visa användaren en fullständigt bearbetad förhandsvisning av bilden de arbetar med, ha det visuella hjälp för redigeringsprocessen är en nedskalad miniatyr som får plats på skärmen (något mindre än 2048x2048). Denna miniatyr kan i allmänhet bearbetas tillförlitligt snabbt, samtidigt som den fortfarande ger användaren en bra uppskattning av hur bilden kommer att se ut. När användaren bekräftar de val han gjort för värdejusteringar och filterval, blir bilden i full upplösning omvandlas i bakgrunden - genom att dela bilden i ett rutnät med miniatyrbildsupplösningsstorleken och sedan bearbeta varje block separat. Det sista steget skulle innebära att den slutliga bilden komponerades på CPU: n genom att anpassa varje region tillbaka till en stor bitmapp med full upplösning.

Det är ett sätt att bearbeta bilden i den ursprungliga upplösningen. Detta är något som Instagram inte verkar göra, med tanke på att förhandsvisningen du ser, ända fram till ögonblicket du bearbetar bilden, har inte samma fruktansvärda kvalitet och artefakter som den färdiga att ladda upp bild. Förhandsgranskningsbilden verkar inte genomgå den brutala komprimeringen, så komprimeringen sker i det ögonblick då den slutliga bilden bearbetas - vilket ger en bild av låg kvalitet.

Android-plattformen har verkligen inga problem med att bearbeta en bild i hög full upplösning och mycket mindre att ladda upp den. På hårdvarusidan har de senaste iPhones en texturstorleksgräns på 2048 till 4096. Så det är förmodligen inte en hårdvarubegränsning, och det är inte en plattformsbegränsning - eftersom det kan och har arbetats runt av andra utvecklare.

Men det fanns ett tak för högstorleken!

Ja, men inte riktigt. Det finns en rimlig gräns för Java-högen på grund av det extra minne som behövs för bilder med hög densitet. Efter lite forskning hittade jag det här utdraget av debatten i en Google-grupp som diskuterade Android NDK, eller Native Development Kit, som gör det möjligt för utvecklare att återanvända kod skriven i C/C++ genom att introducera den i applikationer via Java Native Interface, vilket gör exekveringen av appen något snabbare eftersom den tolkas direkt på processorn istället för en virtuell maskin.

I samtalet kan det vara hittas här, Google-ingenjör och Android Framework-utvecklare Dianne Hackborn rensar vissa missuppfattningar om Androids minnesbegränsningar. Hon konstaterar att "Med tanke på att detta är NDK-listan, är gränsen faktiskt inte påtvingad dig, eftersom den bara är på Java-högen. Det finns ingen gräns för tilldelningar i den inhemska högen... “. När det gäller RAM-användningen, kommenterar hon: "Om det finns tillräckligt med RAM-minne kommer data att lagras i RAM. Om inte... ja, du springer fortfarande”.

Hon säger också att det inte bara finns någon gräns för inhemsk hög, men det finns inte heller någon för GPU-hög. Så det verkar som att det verkligen inte finns några begränsningar "påtvingade" av Android som helhet för hur mycket minne, allmän bearbetning eller GPU du kan använda, på grund av NDK: s existens.

Men även då borde Java-högen vara tillräckligt stor för en bild. En 13 MP-bild som en okomprimerad bitmapp (ARGB 8888) skulle ta ungefär 50 MB. Standardinställningen för maximal högstorlek upp till 256mb eller512 mb beroende på Android-enhet och Android-version den körs. Instagram tar ungefär 62 MB när den är inaktiv, och att döma av min systemövervakningsgraf, tycks RAM-användningen öka under hämtning och bearbetning av en 13 MP-bild vara försumbar, och definitivt långt ifrån nära gränsen som påstås "påtvingas av Android", som kan kringgås oavsett, och den kan också undvikas eller mildras genom att använda vissa algoritmer över andra.

Slutsats

Som tidigare nämnts kanske vi aldrig vet hela historien om vad som händer bakom kulisserna för dessa appar. Men motiveringarna som görs av deras skapares svar eller deras apologeters svar verkar helt enkelt inte så rimliga vid noggrann inspektion. Problemet här verkar orsakas av medioker mjukvaruimplementering snarare än vilken begränsning Androids hårdvara eller mjukvara till synes kan ge.

Det faktum att det finns applikationer där ute som fungerar runt komprimeringen, plus existensen och innehållet i dokumentation om Androids inre funktioner, potentialen för nuvarande Android-hårdvara och experternas åsikter, alla verkar peka på att orättvisan som Android-användare möter är antingen avsiktlig eller åtminstone erkänd lösbar.

Jag tycker att det är dags för Android-användare att inte bara få sanningen, utan också den behandling de förtjänar. Även om det kan vara att Android-enheter, en masse, eftersom genomsnittet och medianen ligger under iPhones när det kommer till hårdvara, finns det ingen anledning att sänka standarderna och förstöra allas användarupplevelser över det. Och när varje utvecklare ger plattformen andrahandsrester, fokuserar användarna i allt högre grad sin frustration på utvecklarna snarare än systemet – som det borde vara.

Kredit till PixelPulse för utvald bild