Een kijkje in de compressiekwaliteit van Instagram

De Instagram-applicatie voor Android is tegenwoordig een van de populairste sociale mediaplatforms ter wereld. Met meer dan 300 miljoen maandelijkse gebruikers op alle platforms en meer dan 100 miljoen individuele downloads op de Google Playstore, zou je verwachten dat Facebook's app voor het delen van snapshots opschept met kwaliteit in zowel ontwerp als functionaliteit. Helaas, voor een groot deel van zijn gebruikersbasis - dat wil zeggen de Android-instagrammers - schiet Instagram tekort in het goed doen van het enige wat het zou moeten doen - mooie foto's delen.

Hoewel iOS-gebruikers hun creaties en momenten met hoge betrouwbaarheid kunnen delen, melden Android-gebruikers al jaren extreem kwaliteitsverlies in hun foto's. Een van de oudste threads die klagen over zo'n hoofdpijn, werd hier in september 2012 gevonden en de thread loopt tot nu toe en biedt lezers onorthodoxe manieren om Instagram's belachelijke vernietiging van foto's te omzeilen. Je zou denken dat na meer dan twee jaar klachten, technologische verbeteringen in zowel software en hardware als economische en marktgroei, deze problemen zouden zijn opgelost. Is het iets waar zij de schuld van zijn? Of loopt de onderliggende oorzaak van het probleem dieper dan het lijkt?

Een directe blik

origineel

1: 1 bijsnijden

Hier is een foto die ik zelf heb genomen. Het oorspronkelijke schot weegt 4, 34 MB en werd neergeschoten met 9, 6 MP . Om geen rekening te houden met de "Instacrop" downsampling die begrijpelijkerwijs de details van zo'n bestand met hoge resolutie zou vernietigen door het later terug te schalen naar de native 640 x 640 pixeluitvoer van Instagram, heb ik het bijgesneden tot een JPG van de 1: 1 beeldverhouding van Instagram uploads om de directe effecten van het naverwerkingsalgoritme en de compressie op dit bestand te zien.

Ik pakte gewoon de vierkante JPG-uitsnede en plaatste deze op mijn Instagram zonder toegevoegde filters, effecten of aanpassingen aan waarden. Je zou verwachten dat het beeld er ongeveer hetzelfde uitziet als wat oorspronkelijk werd gezien, maar het resultaat was overweldigend. De compressie-artefacten rond randen en kleurovergangen zijn verbluffend merkbaar, zelfs voor het ongetrainde oog. Terwijl het oorspronkelijke bijsnijdbestand van 1: 1 1, 6 MB was, is het nieuwe formaat en de gecomprimeerde afbeelding 125 KB . Dit betekent dat de compressie de bestandsgrootte van het origineel met een factor van bijna 13 heeft verkleind - wat in sommige contexten niet noodzakelijk slecht is.

Interessant is dat Instagram een ​​"beeldverwerking van hoge kwaliteit" biedt die standaard is uitgeschakeld, maar wanneer ingeschakeld, lijken de resultaten niet echt te verbeteren en zit het gecomprimeerde bestand op 129 KB . Hier geef ik je dezelfde uitsnede en je kunt zien dat de aanwezige compressie nog steeds vrij intens is en de trouw van het beeld nog steeds een grof en korrelig verlies heeft.

Gecomprimeerd met verwerking van hoge kwaliteit uitgeschakeld

Gecomprimeerd met verwerking van hoge kwaliteit AAN

samendrukking

Computeralgoritmen bieden verschillende manieren om de grootte van een afbeelding te verkleinen met verschillende technieken die het optimaliseren

gegevens moesten later worden geïnterpreteerd en de juiste afbeelding op de juiste manier worden weergegeven. Veel bestandstypen voor afbeeldingen zijn nauw verbonden met deze compressietechnieken die ze ondersteunen of niet ondersteunen - en dit is de reden waarom we op sommige soorten foto's doorgaans betere kwaliteit zien dan op andere. PNG- bestanden (Portable Network Graphics) worden meestal gebruikt om media te delen zonder trouw en beeldkwaliteit te verliezen, ten koste van een groter bestandsformaat dan afbeeldingen die verliesgevende compressie ondergaan. GIF is een heel oud beeldformaat dat ook lossless wordt gecomprimeerd.

Veel programmeurs leren technieken om de bestandsgrootte te verkleinen of te optimaliseren, ongeacht het veld waarin ze zich ontwikkelen. Namen zoals deflatie (gebruikt voor PNG ) of het Lempel-Ziv-Welch- algoritme (meestal gebruikt voor GIF ) lopen door tegenwoordig veel informatica klaslokalen, klinkt het in de oren van veel programmeurs en met de verdere ontwikkeling en documentatie van steeds efficiëntere compressietechnieken, zou je verwachten dat het miljardairplatform redelijk efficiënte algoritmen zou bevatten om een ​​zeer mooi beeld te produceren, terwijl de technische details niet te belastend voor hun servers en de hardware van de gebruiker.

Maar dit is gewoon niet het geval. De foto's die miljoenen Instagrammers en ik elke dag maken en uploaden zijn in tegenspraak met het verhaal van de technische bekwaamheid van deze superkrachten van de techwereld, die een groot deel van hun inkomsten moeten pompen om terug te investeren in hun software om de beste gebruikerservaring. Maar er blijft hier nog een vraag onbeantwoord: waarom Android en niet iOS?

VSCO en Android-geheugen

Terwijl populaire internetfora zoals Reddit de oorzaak van hun dagelijkse verontwaardiging probeerden te achterhalen, leek het onrecht geen logische basis te hebben, behalve de mogelijke verklaring dat Android-hardware intrinsiek inferieur was op de computerafdeling, of het feit dat, gegeven de enorme reeks Android-apparaten van een lager niveau, deze maatregelen moesten worden genomen om een ​​consistente gebruikerservaring op het hele platform te garanderen - ongeacht hoeveel u voor uw telefoon hebt betaald. Naarmate de maanden voorbijgingen, rapporteerden de rapporten na elke Instagram-update steeds hetzelfde probleem, tot het punt dat dit probleem een ​​lopende grap werd onder forumgebruikers die kort elke iteratie van de applicatie volgden.

Gebruikers zagen ook een vergelijkbare gebeurtenis met de populaire camera- en fotobewerkingsapplicatie VSCO Cam. Aangeprezen als "de nieuwe standaard van Android-fotografie", merkten sommigen al snel op dat de toepassing niet aan deze eisen voldeed. Het kwaliteitsverlies en het soort waargenomen artefacten waren vergelijkbaar met dat van Instagram, dus sommigen dachten al snel dat er een lijn was die de punten verenigde. Tot nu toe hadden we alleen maar speculaties over de reden voor dit probleem. Sommigen gaven het probleem direct de schuld van de ingebouwde bitmap downsampling-algoritmen van Android. Wat echter de meest overtuigende oorzaak leek te zijn die naar boven was gekomen, was het simpele feit dat Instagram en mogelijk VSCO een slechte implementatie van een downsampling-algoritme hadden, met name de nabestelling van de dichtstbijzijnde buurman. Maar zonder het officiële woord van ontwikkelaars, kon de speculatie niet volledig worden bevestigd.

Het was toen dat we via VSCO's technische ondersteuning ontdekten dat de reden voor hun verlies van resolutie en trouw geen slechte software-implementatie was, maar eerder een geheugenbeperking op Android-apparaten:

"De meeste Android-apparaten zijn behoorlijk beperkt in het geheugen, hoewel sommige meer dan een paar gigabyte geheugen hebben, maar toepassingen mogen niet al dat beschikbare geheugen gebruiken en dus moeten we het nakomen met wat ons van Android wordt gegeven."

“Grote afbeeldingen kunnen tijdens het importeren tot 50% worden verkleind, afhankelijk van het apparaat dat u gebruikt en het beschikbare geheugen.

Ze beweren ook dat het hun beeldverwerkingstechnieken zijn die zowel op het geheugen als op SoC erg belastend zijn, en dit, in combinatie met Android-geheugenbeperkingen, is de reden waarom we het kwaliteitsprobleem zien dat we niet vinden op iOS.

Volgens Android-artikelen voor ontwikkelaars wordt er een harde limiet gesteld aan de heap-grootte voor elke app om een ​​functionele multitasking-omgeving te behouden. Dit is afhankelijk van hoeveel RAM het apparaat beschikbaar heeft en als de app heap-capaciteit nadert, loopt het risico dat de RAM opraakt.

Dus op het eerste gezicht lijkt het verhaal van VSCO meeslepend, maar dit verklaart niet enkele dingen die de mensen die een scepticus benaderen niet kunnen afschudden.

Beperking

Op een zeer oppervlakkige manier kunnen we deze vraag stellen: als een smartphone die meestal tussen 1 GB en 2 GB RAM heeft en de nieuwste draagbare processors een afbeelding niet in volledige resolutie kunnen verwerken, waarom zijn 32 MB RAM DSLR-camera's dan in staat?

We hebben contact opgenomen met een van onze Senior Erkende Ontwikkelaars om een ​​sterker oordeel over dit onderwerp te verzamelen. OmniROM-ontwikkelaar XpLoDWilD heeft gereageerd:

“De beperking hier is eerder de manier waarop de afbeelding wordt berekend of verwerkt. GPU is daarvoor sneller, en de snelste manier om dit te doen is door de afbeelding als textuur in de GPU te 'uploaden' en het te verwerken - het probleem is dat je wordt beperkt door de maximale textuurgrootte van de GPU, die over het algemeen 4096 is × 4096.”

Over het algemeen zijn 8MP-foto's 3264 × 2448, klein genoeg om binnen de limieten van maximaal 12MP van 4000 × 3000 te passen. Nieuwere vlaggenschip- en cameratelefoonsensoren kunnen meer dan 13 MP gaan en hebben beeldformaten die groter zijn dan de maximale GPU maximale textuurgrootte, die onvermijdelijk het beeld binnen de beperking zou moeten verkleinen en algehele details zou verliezen.

"Het probleem is niet dat apps een verkleinde versie uploaden, maar eerder dat apps een verkleinde versie van de afbeelding verwerken en dat verwerkte bestand uploaden", voegde hij eraan toe. "Hoogstwaarschijnlijk hebben ze de resolutie nog lager gezet om de verwerkingstijd verder te verkorten".

XpLoDWilD suggereert dat de fijne balans tussen verwerkingstijd en GPU-beperking zou zijn, in plaats van de gebruiker een volledig verwerkt voorbeeld te laten zien van de afbeelding waaraan hij werkt, het visuele hulpmiddel voor het bewerkingsproces een verkleinde miniatuur is die op het scherm past (iets kleiner dan 2048 × 2048). Deze miniatuur kan over het algemeen betrouwbaar snel worden verwerkt, terwijl de gebruiker toch een goede inschatting krijgt van hoe de foto eruit zal zien. Wanneer de gebruiker de keuzes bevestigt die hij heeft gemaakt bij de waarde-aanpassingen en filterselectie, zou de afbeelding met volledige resolutie op de achtergrond worden getransformeerd - door de afbeelding in een raster van de grootte van de miniatuurresolutie te splitsen en vervolgens elk blok afzonderlijk te verwerken. De laatste stap zou het samenstellen van de uiteindelijke afbeelding op de CPU omvatten door elke regio weer in een grote bitmap met volledige resolutie in te passen.

Dat is een manier om de afbeelding in de oorspronkelijke resolutie te verwerken. Dit is iets dat Instagram niet lijkt te doen, gezien het feit dat de preview die je ziet, helemaal tot het moment dat je de foto verwerkt, niet dezelfde verschrikkelijke kwaliteit en artefacten heeft als die van de ready-to-upload beeld. De voorbeeldafbeelding lijkt niet de brute compressie te ondergaan, dus de compressie vindt plaats op het moment van verwerking van de uiteindelijke afbeelding - die de afbeelding van lage kwaliteit uitvoert.

Het Android-platform heeft echt geen problemen met het verwerken van een afbeelding in hoge volledige resolutie en veel minder uploaden. Wat de hardware betreft, hebben de nieuwste iPhones een textuurgroottelimiet van 2048 tot 4096. Het is dus waarschijnlijk geen hardwarebeperking en het is geen platformbeperking - aangezien het kan en is gewerkt door andere ontwikkelaars.

Maar er was een dop op de grootte van de heap, hoewel!

Ja, maar niet helemaal. Er is een redelijke limiet op de Java-heap vanwege het extra geheugen dat nodig is voor afbeeldingen met een hoge dichtheid. Na enig onderzoek vond ik dit debatfragment over een Google-groep die de Android NDK of Native Development Kit besprak, waarmee ontwikkelaars code die in C / C ++ is geschreven opnieuw kunnen gebruiken door deze in toepassingen te introduceren via Java Native Interface, waardoor de uitvoering van de app iets sneller, omdat deze direct op de processor wordt geïnterpreteerd in plaats van op een virtuele machine.

In het gesprek, dat hier te vinden is, wist Google-ingenieur en Android Framework Developer Dianne Hackborn enkele misvattingen over de geheugenbeperkingen van Android. Ze merkt op dat, "aangezien dit de NDK-lijst is, de limiet eigenlijk niet aan jou wordt opgelegd, omdat het alleen op de Java-heap ligt. Er is geen limiet op toewijzingen in de native heap… “ . Wat het RAM-gebruik betreft, merkt ze op: “Als er voldoende RAM is, worden de gegevens in RAM bewaard. Zo niet ... nou, je rent nog steeds ”.

Ze zegt ook dat er niet alleen geen limiet is voor de native heap, maar dat er ook geen limiet is voor de GPU-heap. Dus het lijkt erop dat er door Android als geheel geen beperkingen zijn 'opgelegd' met betrekking tot hoeveel geheugen, algemene verwerking of GPU je kunt gebruiken vanwege het bestaan ​​van de NDK.

Maar zelfs dan moet de Java-heap groot genoeg zijn voor één foto

. Een 13MP-afbeelding als een ongecomprimeerde bitmap (ARGB 8888) zou ongeveer 50MB duren. De standaard maximale heap-grootte varieert van 256 MB of 512 MB, afhankelijk van het Android-apparaat en de Android-versie die wordt gebruikt. Instagram neemt ongeveer 62 MB in beslag wanneer inactief, en volgens mijn systeemmonitorgrafiek lijkt het RAM-gebruik tijdens het ophalen en verwerken van een 13MP-afbeelding te verwaarlozen, en zeker niet in de buurt van de limiet zogenaamd "opgelegd door Android", die kan zonder problemen worden omzeild en kan ook worden vermeden of beperkt door bepaalde algoritmen boven andere te gebruiken.

Gevolgtrekking

Zoals eerder vermeld, weten we misschien nooit het volledige verhaal over wat er achter de schermen van deze apps gebeurt. Maar de rechtvaardigingen van de antwoorden van hun makers of die van hun apologeten lijken simpelweg niet zo plausibel bij nadere inspectie. Het probleem hier lijkt te worden veroorzaakt door middelmatige implementatie van software in plaats van welke beperking Android-hardware of -software dan ook lijkt te kunnen bieden.

Het feit dat er applicaties zijn die werken rond de compressie, plus het bestaan ​​en de inhoud van documentatie over de interne werking van Android, het potentieel van de huidige Android-hardware en de mening van experts, lijken allemaal te wijzen op het onrecht dat Android-gebruikers worden geconfronteerd opzettelijk of op zijn minst erkend oplosbaar.

Ik denk dat het tijd is voor Android-gebruikers om niet alleen de waarheid te begrijpen, maar ook de behandeling die ze verdienen. Hoewel het kan zijn dat Android-apparaten, massaal, gemiddeld en mediaan onder iPhones liggen als het gaat om hardware, is er geen reden om de normen te verlagen en de gebruikerservaringen van iedereen te verpesten. En met elke ontwikkelaar die het platform tweedehands restjes geeft, richten gebruikers hun frustratie steeds meer op de ontwikkelaars in plaats van op het systeem - zoals het zou moeten zijn.

Met dank aan PixelPulse voor aanbevolen afbeelding