Ontdek of de slechte compressiekwaliteit van Instagram voor Android een gevolg is van platformbeperkingen of het opzettelijke handelen van de ontwikkelaars van Instagram.
De Instagram-applicatie voor Android is tegenwoordig een van de populairste sociale-mediaplatforms ter wereld geworden. Met meer dan 300 miljoen maandelijkse gebruikers op alle platforms, en meer dan 100 miljoen individuele downloads in de Google Playstore, zou je verwachten dat de Facebook-applicatie voor het delen van snapshots kan bogen op kwaliteit in zowel ontwerp als functionaliteit. Helaas schiet Instagram voor een groot deel van zijn gebruikersbestand, dat wil zeggen de Android-instagrammers, tekort in het goed doen van het enige dat het zou moeten doen: mooie foto's delen.
Terwijl 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 topics waarin wordt geklaagd over zo'n hoofdpijn vond ik hier op XDA
Een directe blik
Hier is een foto die ik zelf heb gemaakt. Het originele schot weegt 4,34 MB en werd beschoten 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 versie van Instagram 640x640 pixeluitvoer, ik heb het bijgesneden tot een JPG van de beeldverhouding 1:1 van Instagram-uploads om de directe effecten van het naverwerkingsalgoritme en de compressie hierop te zien bestand.
Ik pakte eenvoudigweg de vierkante JPG-uitsnede en plaatste deze op mijn Instagram zonder toegevoegde filters, effecten of het aanpassen van waarden. Je zou verwachten dat het beeld er ongeveer zo uit zou zien als het origineel, maar het resultaat was teleurstellend. De compressieartefacten rond randen en kleurovergangen zijn zelfs voor het ongetrainde oog verbluffend merkbaar. Terwijl de grootte van het oorspronkelijke 1:1-bijsnijdbestand 1,6 MB, de nieuwe verkleinde en gecomprimeerde afbeelding is 125 KB. Dit betekent dat de compressie de bestandsgrootte van het origineel met bijna een factor verkleinde 13 - wat in sommige contexten niet noodzakelijkerwijs slecht is.
Interessant is dat Instagram een “Hoge Kwaliteit Beeldverwerking” biedt die standaard is uitgeschakeld, maar als deze is ingeschakeld, lijken de resultaten niet echt te verbeteren en staat het gecomprimeerde bestand op 129 KB. Hier geef ik je dezelfde uitsnede en je kunt zien dat de aanwezige compressie nog steeds behoorlijk intens is en dat de getrouwheid van het beeld nog steeds een grof en korrelig verlies vertoont.
Compressie
Computeralgoritmen bieden verschillende manieren om de grootte van een afbeelding te verkleinen met verschillende technieken die de afbeelding optimaliseren
gegevens moesten later worden geïnterpreteerd en het juiste beeld op de juiste manier worden weergegeven. Veel bestandstypen voor afbeeldingen zijn nauw verbonden met de compressietechnieken die ze ondersteunen of ondersteunen deze niet - en dit is de reden waarom we bij sommige soorten afbeeldingen doorgaans een betere kwaliteit zien dan anderen. PNG (Portable Network Graphics)-bestanden worden meestal gebruikt om media te delen zonder verlies van betrouwbaarheid en beeldkwaliteit, ten koste van een grotere bestandsgrootte dan afbeeldingen die verliesgevende compressie ondergaan. GIF is een heel oud beeldformaat dat ook verliesvrij wordt gecomprimeerd.
Technieken om de bestandsgrootte te verkleinen of te optimaliseren worden door veel programmeurs geleerd in hun academische bezigheden, ongeacht het vakgebied waarin ze zich zullen ontwikkelen. Namen zoals deflatie (gebruikt voor PNG) of de Lempel-Ziv-Welch algoritme (meestal gebruikt voor GIF) die tegenwoordig door veel Computer Science-klaslokalen worden gebruikt, klinken in de oren van veel programmeurs, en met de verdere ontwikkeling en documentatie van steeds efficiëntere compressietechnieken, je zou verwachten dat het miljardairplatform redelijk efficiënte algoritmen bevat om een heel mooi beeld te geven, terwijl de technische details niet te belastend zijn voor hun servers en die van de gebruiker hardware.
Maar dit is gewoon niet het geval. De foto's die miljoenen Instagrammers, en ik, elke dag maken en uploaden, zijn in directe tegenspraak met het verhaal van de technische bekwaamheid van deze supermachten uit de technische wereld, die geacht worden een groot deel van hun inkomsten te investeren in hun software om de beste gebruikers te kunnen bieden. ervaring. Maar er blijft hier nog een vraag onbeantwoord: Waarom Android en niet iOS?
VSCO en Android-geheugen
Terwijl populaire internetfora als Reddit probeerden de oorzaak van hun dagelijkse verontwaardiging te achterhalen, leek het onrecht geen andere logische basis te hebben. dan de mogelijke verklaring dat Android-hardware intrinsiek inferieur is op het gebied van rekenkracht, of het feit dat, gezien het enorme aanbod ervan lagere Android-apparaten moesten deze maatregelen worden genomen om een consistente gebruikerservaring op het hele platform te garanderen, ongeacht hoeveel u ervoor betaalde jouw telefoon. Naarmate de maanden verstreken, bleven de rapporten na elke Instagram-update hetzelfde probleem melden, to the point waar dit probleem een running gag werd onder forumgebruikers die kort daarna elke iteratie van de sollicitatie.
Gebruikers merkten een soortgelijk voorval ook op bij de populaire camera- en beeldbewerkingsapplicatie VSCO Cam. Sommigen werden aangeprezen als “de nieuwe standaard voor Android-fotografie”, en sommigen merkten al snel dat de applicatie niet voldeed aan deze beweringen. Het kwaliteitsverlies en het type artefacten dat werd opgemerkt, waren vergelijkbaar met dat van Instagram, dus sommigen dachten al snel dat er een lijn was die de punten verbond. Tot nu toe hadden we alleen speculaties over wat de reden voor dit probleem zou kunnen zijn. Sommigen gaven het probleem rechtstreeks de schuld aan de ingebouwde bitmap-downsampling-algoritmen van Android. Wat echter de meest overtuigende oorzaak leek te zijn, was het simpele feit dat Instagram, en mogelijk VSCO, een slechte implementatie had van een downsampling-algoritme, met name het Herbemonstering van de dichtstbijzijnde buur. Maar zonder het officiële woord van de ontwikkelaars kon de speculatie niet volledig worden bevestigd.
Toen hebben we het geleerd VSCO's technische ondersteuning dat de reden voor hun verlies aan resolutie en betrouwbaarheid niet een slechte software-implementatie was, maar eerder een geheugenbeperking op Android-apparaten:
“De meeste Android-apparaten hebben een behoorlijk beperkt geheugen, ondanks dat sommige apparaten meer dan een paar gigabytes aan geheugen hebben. maar applicaties mogen niet al het beschikbare materiaal gebruiken geheugen en dus moeten we het doen met wat ons door Android wordt gegeven.
“Grote afbeeldingen kunnen bij het importeren tot 50% worden verkleind afhankelijk van het apparaat waarop u zich bevindt en het beschikbare geheugen.“
Ze beweren ook dat hun beeldverwerkingstechnieken erg belastend zijn voor zowel het geheugen als de SoC dit, in combinatie met Android-geheugenbeperkingen, is de reden waarom we het kwaliteitsknelpunt zien dat we niet tegenkomen iOS.
Volgens Trainingsartikelen voor Android-ontwikkelaars, wordt er een harde limiet gesteld aan de heapgrootte voor elke app om een functionele multitasking-omgeving te behouden. Dit hangt af van hoeveel RAM het apparaat beschikbaar heeft, en als de app de heapcapaciteit nadert, loopt hij het risico dat het RAM-geheugen opraakt.
Op het eerste gezicht dus wel lijkt dat het verhaal van VSCO overtuigend is, maar dit verklaart niet een aantal dingen die de mensen die de scepticus benaderen niet lijken te kunnen afschudden.
Beperking
Als we heel oppervlakkig kijken, kunnen we deze vraag stellen: als een smartphone die doorgaans tussen 1 GB en 2 GB RAM heeft en de nieuwste draagbare processors kunnen een afbeelding niet in volledige resolutie verwerken, waarom kunnen DSLR-camera's met 32 MB RAM dat wel? Dat?
We hebben contact opgenomen met een van onze Senior Recognized Developers om een sterkere mening over dit onderwerp te krijgen. OmniROM ontwikkelaar XpLoDWilD merkte op:
“De beperking hier is eerder de manier waarop het beeld wordt berekend of verwerkt. GPU is daarvoor sneller, en de snelste manier om dit te doen is door de afbeelding als textuur naar de GPU te 'uploaden' en verwerk het - het probleem is dat je wordt beperkt door de maximale textuurgrootte van de GPU, wat over het algemeen het geval is 4096x4096.”
Over het algemeen zijn 8 MP-foto's 3264 x 2448, klein genoeg om binnen de limieten van maximaal 12 MP van 4000 x 3000 te passen. Nieuwere vlaggenschip- en cameratelefoonsensoren kunnen meer dan 13 MP bereiken en hebben beeldformaten die groter zijn dan de maximale GPU maximale textuurgrootte, waardoor het beeld onvermijdelijk binnen de beperking moet worden verkleind en het geheel verloren gaat detail.
“Het probleem is niet dat apps dat zijn een verkleinde versie uploadenHet is echter eerder zo dat apps dat wel zijn het verwerken van een verkleinde versie van de afbeelding, en het uploaden van dat verwerkte bestand”, voegde hij eraan toe. “Ze hebben waarschijnlijk ook de resolutie nog lager gezet om de verwerkingstijd verder te verkorten.”
XpLoDWilD suggereert dat het fijne evenwicht 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, de visual te hebben hulpmiddel bij het bewerkingsproces is een verkleinde miniatuur die op het scherm past (iets kleiner dan 2048x2048). Deze thumbnail 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 met betrekking tot de waardeaanpassingen en filterselectie, zou het beeld met volledige resolutie zijn getransformeerd op de achtergrond - door de afbeelding te splitsen in een raster met de miniatuurresolutiegrootte en vervolgens elk blok te verwerken afzonderlijk. De laatste stap zou het samenstellen van het uiteindelijke beeld op de CPU inhouden door elke regio weer in één grote bitmap met volledige resolutie te plaatsen.
Dat is een manier om de afbeelding in de oorspronkelijke resolutie te verwerken. Dit is iets dat Instagram niet lijkt te doen, gezien het voorbeeld dat je ziet, helemaal tot op dit moment je verwerkt de foto, heeft niet dezelfde vreselijke kwaliteit en artefacten als die van de klaar-om-te-uploaden afbeelding. Het lijkt erop dat de voorbeeldafbeelding de brute compressie niet ondergaat, dus de compressie vindt plaats op het moment dat de uiteindelijke afbeelding wordt verwerkt, waardoor de afbeelding van lage kwaliteit ontstaat.
Het Android-platform heeft echt geen problemen met het verwerken van een afbeelding in hoge volledige resolutie en laat staan met het uploaden ervan. Wat de hardware betreft, hebben de nieuwste iPhones een textuurlimiet van 2048 tot 4096. Het is dus waarschijnlijk geen hardwarebeperking, en het is ook geen platformbeperking, zoals andere ontwikkelaars er wel omheen kunnen en hebben gewerkt.
Maar er zat wel een maximum aan de hoopgrootte!
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 wat onderzoek vond ik dit fragment van het debat in een Google-groep die de Android NDK besprak, of Native ontwikkelingskit, waarmee ontwikkelaars code die in C/C++ is geschreven opnieuw kunnen gebruiken door deze in applicaties te introduceren via Java-native interface, waardoor de uitvoering van de app iets sneller wordt omdat deze rechtstreeks op de processor wordt geïnterpreteerd in plaats van op een virtuele machine.
In het gesprek kan dat wel hier gevonden, Google-ingenieur en Android Framework-ontwikkelaar Dianne Hackborn neemt een aantal misvattingen weg over de geheugenbeperkingen van Android. Ze merkt op dat “aangezien dit de NDK-lijst is, wordt de limiet eigenlijk niet aan jou opgelegd, omdat deze alleen op de Java-heap staat. Er is geen limiet voor toewijzingen in de native heap... “. Wat het RAM-gebruik betreft, zegt ze: “Als er voldoende RAM is, worden de gegevens in RAM bewaard. Als niet... Nou ja, je rent nog steeds”.
Ze zegt ook dat er niet alleen geen limiet is op de inheemse hoop, maar er is er ook geen voor de GPU-hoop. Het lijkt er dus op dat er feitelijk geen beperkingen zijn ‘opgelegd’ door Android als geheel met betrekking tot de hoeveelheid geheugen, algemene verwerking of GPU die je kunt gebruiken, vanwege het bestaan van de NDK.
Maar zelfs dan zou de Java-heap groot genoeg moeten zijn voor één foto
. Een 13 MP-foto als ongecomprimeerde bitmap (ARGB 8888) zou ongeveer 50 MB. De standaard maximale heapgroottebereiken tot 256 MB of512mb afhankelijk van het Android-apparaat en de Android-versie waarop het wordt uitgevoerd. Instagram duurt ongeveer 62 MB bij inactiviteit, en zoals te oordelen naar mijn Systeemmonitor-grafiek, lijkt de toename van het RAM-gebruik tijdens het ophalen en verwerken van een 13 MP-afbeelding te verwaarlozen, en zeker bij lange na niet in de buurt van de limiet die zogenaamd “opgelegd door Android” is, waar hoe dan ook omheen kan worden gewerkt, en deze kan ook worden vermeden of verzacht door bepaalde algoritmen te gebruiken anderen.
Conclusie
Zoals eerder vermeld, zullen we misschien nooit het volledige verhaal weten over wat er achter de schermen van deze apps gebeurt. Maar de rechtvaardigingen die worden gegeven door de reacties van hun makers of die van hun verdedigers lijken bij nadere beschouwing eenvoudigweg niet zo plausibel. Het probleem lijkt hier te worden veroorzaakt door middelmatige software-implementatie en niet door de beperking die de hardware of software van Android schijnbaar kan bieden.
Het feit dat er applicaties bestaan die de compressie omzeilen, plus het bestaan en de inhoud van documentatie over de interne werking van Android, het potentieel van huidige Android-hardware en de mening van experts lijken allemaal te wijzen op het onrecht waarmee Android-gebruikers worden geconfronteerd, hetzij opzettelijk, hetzij op zijn minst erkend oplosbaar.
Ik denk dat het tijd is dat Android-gebruikers niet alleen de waarheid krijgen, maar ook de behandeling die ze verdienen. Hoewel het zou kunnen zijn dat Android-apparaten massaalAangezien het gemiddelde en de mediaan lager liggen dan die van iPhones als het om hardware gaat, is er geen reden om de normen te verlagen en daarmee ieders gebruikerservaring te verpesten. En omdat elke ontwikkelaar 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 uitgelichte afbeelding