Facebook maakt software voor verkleinen bestandsgrootte foto-uploads open source

Facebook heeft de software die het in zijn apps gebruikt om de bestandsgrootte van foto's voor het uploaden te verkleinen, open source gemaakt. Andere ontwikkelaars mogen Spectrum ook gebruiken, als zij dat willen.

De software heeft de naam Spectrum en staat op GitHub. De software maakt bestanden voor het uploaden kleiner om zo het uploaden betrouwbaarder te maken en het datagebruik van de app te verminderen, meldt Facebook. De software is nu meer nodig dan voorheen, omdat de bestandsgrootte van foto's van smartphones steeds meer toeneemt, met de komst van camera's met hoge resoluties.

Facebook heeft de software ontwikkeld in C++, met een klein laagje Java voor Android-apps en Objective-C voor iOS. Daardoor moet het makkelijk zijn om aanpassingen in de code naar beide besturingssystemen te pushen zonder al te veel moeite. Afbeeldingen zouden 15 procent kleiner worden met de encoding van Spectrum, claimt het bedrijf. Het is niet de eerste keer dat Facebook code van een project op GitHub zet. Het heeft afgelopen jaren tientallen projecten open source beschikbaar gemaakt.

Reacties (28)

Iedereen die ooit iets met rood tegen een donkere achtergrond geupload heeft op FB. Weet dat de 'optimalisatie' die ze doen echt een drama is. Nou begrijp ik met de enorme berg data die ze bij Facebook verwerken, ieder procentje een groot verschil maakt in kosten. Maar ze hadden wat mij betreft dan beter een JPEG 2000 of h265 still conversie schil kunnen doen.

Zelfde verhaal met donkere tinten, die worden ontzettend 'gecrushed', vind ik. Als hobbyfotograaf upload ik weleens wat zwart-witfoto's, maar het verschil met de jpegs die Photoshop produceert is zo groot dat belangrijke donkere details op Facebook verloren gaan. Ik kan me voorstellen dat mensen donkere tinten speciaal voor FB wat opkrikken.

Detail: de broncode is niet alleen vrijgegeven, maar het heeft ook de MIT licentie gekregen.

Dit is niet een detail, dit is zelfs cruciaal.

Wanneer iemand anders eenzelfde code schrijft om een doel te bereiken, dan kan onder het MIT license die persoon daar niet mee in de problemen komen. (ongeacht of daarbij alleen inspiratie uit deze code wordt opgedaan, of deze code gedeeltelijk of geheel wordt benut)

Het is, zoals je hint, ook mogelijk om code open source te maken maar wel met een zeer restrictieve licentie. Alle rechten liggen dan bij de oorspronkelijke auteur, en ook een derivatief werk is dan mogelijk inbreukmakend. (Iemand die daarna iets doet wat er te veel op lijkt, kan dan ook in de problemen komen, juridisch.)

De MIT license is met name handig voor programmeurs en bedrijven die niet te moeilijk willen doen en gewoon de code willen gebruiken zonder na te hoeven denken over mogelijk consequenties. In tegenstelling tot bijvoorbeeld de GPL licenties mag je vrijelijk deze code aanpassen en gebruiken binnen niet-open source code. De enige voorwaarde is doorgaans dat de oorspronkelijke bibliotheek/code en auteurs daarvan worden geciteerd in (uit mijn hoofd) in ieder geval de broncode.

Als je het mij vraagt hint dit op een bepaalde manier ook naar het feit dat de bibliotheek zelf grotendeels een wrapper is, zoals anderen melden. (Als een werk namelijk echt een doorbraak is, dan wil je graag dat nieuwe ontwikkelingen erop ook beschikbaar komen voor de community. Anders is het mogelijk dat een bibliotheek uiteindelijk wordt vervangen door een 'verbeterde' maar wel closed-source en proprietare versie.)

Kortom: MIT is een makkelijke licentie voor andere gebruikers (programmeurs en bedrijven) en in dit geval is er weinig risico dat een derivatief werk in de toekomst, tenzij Facebook hier weer zelf op verder wil gaan borderen in een closed-source derivatief; ook dat is namelijk heel goed mogelijk met deze licentie.

[Reactie gewijzigd door Alienus op 17 januari 2019 20:23]

Grappig om te zien. Spectrum gebruikt MozJPG (https://github.com/mozilla/mozjpeg/) die zelf ook weer gebaseerd is op LibJpeg-Turbo (https://github.com/libjpeg-turbo/libjpeg-turbo). M.a.w, is dit dan weer nieuw of puur een sausje erom heen?

Volgens Spectrum's github:

The Spectrum APIs incorporate declarative traits. This simplifies the usage for the developer by focusing on the desired outcome. At the same time it enables Spectrum to transparently choose the best execution sequence. Additionally, Spectrum makes common image operations simple by surfacing many difficult operations that are not typically exposed by platform frameworks. For example, some JPEG-to-JPEG operations like cropping are executed lossless, and disabling chroma sub-sampling when saving graphical JPEGs will lead to better quality final products.

M.a.w het versimpeld de API van de libs die het wrapped en gebruikt meer sane defaults. Met als doel om betere kwaliteit jpegs te produceren.

Ik vraag me met dit soort dingen af wat dan werkelijk de meerwaarde is. Het feit dat er een Android/iOS interface omheen zit? Waarom niet een PR aanbieden bij mozjpeg? (misschien hebben ze dat gedaan).

Weet iemand daar meer van?

mozjpeg is een library die bepaalde aspecten van libjpeg-turbo optimaliseert voor web-gebruik. Zoals ik het begrijp hebben ze een aantal compressie heuristics toegevoegd, en een aantal defaults veranderd, waardoor de afbeeldingen die gegenereerd worden gemiddeld kleiner zijn, sneller laden en hun kwaliteit behouden.

De library wordt dus gewoon gebruikt om jpegs te genereren.

Spectrum is een stuk software dat, gegeven bepaalde eisen van de programmeur, een afbeelding zo conprimeert dat het aan deze eisen voldoet. Ik kan me voorstellen dat een programmeur zegt: "Ik wil een afbeelding van max. 5MB, max 2000x2000 pixels en ik vermoed dat het een foto is (geen digitale afbeelding)".

Spectrum zal dan de juiste conversies uitvoeren met de onderliggende libraries, zonder dat de programmeur de details of parameters van deze libraries hoeft te kennen.

Het is in weze dus een abstractie van afbeelding conversie libraries. Abstracties kunnen heel nuttig zijn om applicaties overzichtelijk en onderhoudsvriendelijk te houden (al gaat er soms wat performance aan verloren). Nu is een afbeelding uploaden niet iets dat je 20x per seconde, 10 uur per dag aan het doen bent, dus waarschijnlijk is die performance penalty het in dit geval waard. Helemaal als je daarmee 5-15% server opslag en bandbreedte kunt besparen.

[Reactie gewijzigd door Laloeka op 18 januari 2019 11:38]

Ik ben wel benieuwd hoe die 15% bestands reductie de kwaliteit beïnvloed(?)

- update -
Als ik deze link moet geloven passen ze ook hogere compressies toe, al is dit artikel wel van januari 2017: https://www.quora.com/How...compression-quality-value

[Reactie gewijzigd door GVeen op 17 januari 2019 14:18]

Ik ben wel benieuwd hoe die 15% bestands reductie de kwaliteit beïnvloed(?)

- update -
Als ik deze link moet geloven passen ze ook hogere compressies toe, al is dit artikel wel van januari 2017: https://www.quora.com/How...compression-quality-value

Dit algoritme is toevallig voor compressie, maar Facebook doet niet alleen aan compressie op de fotos die ze laten zien; ze verkleinen ook (eerst?) de resolutie... en best flink ook.

Dit betekend niet dat ze de foto niet in hoge resolutie opslaan (misschien doen ze dat wel, dat weet ik niet) maar in elk geval is de foto die je als gebruiker krijgt te zien van een relatief lage resolutie. Er is geen optie om de originele te downloaden (al heeft Facebook die dus misschien wel).

Hetzelfde geldt voor de andere Facebook: Instagram.

[Reactie gewijzigd door GeoBeo op 17 januari 2019 14:29]

Als de functie van deze tool is om de bestandsgrootte van de foto te verkleinen vóór het uploaden, met als doel om zodoende het dataverbruik te verminderen (zoals in de tekst staat), dan betekent dat dus eigenlijk per definitie dat ze zelf de foto niet in de hogere resolutie opslaan op hun servers.. Die hebben ze dan immers niet ter beschikking, omdat deze nooit geupload is op deze manier.

Overigens zijn de meeste fotos die op facebook online gezet worden toch vaak uitsluitend bedoeld om te bekijken op een display. Dan heeft het natuurlijk geen nadelige effecten op de weergave als die 12-24Mpixel uit de telefoon even geresized wordt naar een wat vriendelijkere resolutie voor upload en weergave... Je kunt zo'n resolutie tenslotte nog flink wat verkleinen voordat dat op een bovengemiddeld 1440p scherm (bijvoorbeeld) pas zichtbaar wordt op full-screen weergave.. (met de 3.7Mpix op een dergelijk scherm).

Vind dat je dat al goed kan zien als je bijvoorbeeld een raw-foto omzet naar JPG waar je zelf de 100% kan instellen. 80% kwaliteit (20% compressie) vind ik persoonlijk nog acceptabel maar 60% kwaliteit (40% compressie) vind ik echt niet meer kunnen.

Voor alle duidelijkheid, JPEG gebruikt altijd "lossy" compressie, en ook als je 100% kiest is er dus verlies. Kiezen voor 100% betekent dus niet "0% verlies". Bovendien lijkt de de kwaliteit tussen verschillende programma's sterk te verschillen (bij een gelijk percentage-instellingen).

Een groot nadeel aan dit soort systemen is dat de input al JPEG is, en je dus een extra generatie verlies krijgt. Min of meer vergelijkbaar met het kopiëren van casettebandjes vroeger. Elke generatie voegt extra verlies toe.

Het (JPEG-compressie) was meer als voorbeeld op hoeveel verlies er bij compressie er uit kan komen te zien. Dat 15% hoeft dus "op zicht" niet veel te schelen.

[Reactie gewijzigd door GenomDalar1983 op 17 januari 2019 16:39]

Kijk op facebook zou ik zeggen.

15% kleiner vind ik zo fenomenaal. Waarom zou het kleiner maken ook het uploaden betrouwbaarder maken? Op welke manier word dat bedoelt? Daar hebben we TCP toch voor.

Als je slecht bereik hebt is elke bit minder mooi meegenomen en vergroot de kans op een succesvolle upload.

Mobiele verbindingen vallen regelmatig weg, dus mogelijk is het doel simpelweg een kortere uploadtijd waardoor de kans op wegvallen binnen de uploadtijd verkleint. Het lijkt me sterk dat ze bitwise een robuuster signaal kunnen genereren voor alle mogelijke mobiele verbindingen waarmee FB te maken krijgt.

Afbeeldingen zouden 15 procent kleiner worden met de encoding van Spectrum, claimt het bedrijf.

Dit zou toch afhankelijk moeten zijn van de grootte van de afbeelding? Als ik een 60MP afbeelding upload is 15% niet veel.

Iemand uitleg?

Uit het bron artikel van facebook:

The default integration with Mozilla JPEG allows a reduction of up to 15 percent in upload file size compared with a baseline encoder

dus het is niet 15% van de bestandsgrootte maar 15% meer reductie dan het standaard android/iOS compressie mechanisme

Door niet op het standaard compressie mechanisme van het OS te leunen kan de app bepalen werke compressie techniek gebruikt wordt (onafhankelijk van OS en OS versie) en met een app-update de nieuwste compressie technieken binnen halen.

Wat betreft 60MP afbeeldingen.. Daarvoor kan ook gekozen worden deze te resizen om het bestandsformaat kleiner te krijgen.. https://libspectrum.io/docs/resizing_images

Ik heb liever dat ze ook een optie aanbieden "geen compressie". Ik heb daar met bv een advertentie last van, de afbeelding heeft dan na uploaden overal artifacts - alsof het een compressie uit 1990 is Reuze irritant.

Ik vind 15% echt magertjes. Als ik mijn foto's door TinyPNG trek verliezen ze vaak de helft zonder zichtbaar kwaliteitsverlies.

Hallo! Ik ben op zoek naar een sekspartner. Mijn nick migiri95. Vind mij hier http://sexbadoo.gq

Dat is toch juist mooi? Het is niet enkel facebook die er baat bij heeft dat de efficiëntie omhoog gaat van dit soort componenten.

De tech afdeling van facebook doet dat al jaren. Ze hebben heel veel van hun technologieën uiteindelijk open source gemaakt..

opensource.facebook.com

Facebook heeft bakken met opensource producten, welke zelfs banen en opleidingen hebben aangewakkerd (zoals ReactJS en React Native).

Facebook doet veel aan open source waar HHVM en React denk ik wel de meest bekende zijn.

Zie ook:
https://opensource.facebook.com/

Open source "Monitoring" van je Windows/Linux omgeving dankzij Facebook:

https://osquery.io/