Als je een foto maakt op wat voor apparaat dan ook, wordt deze meestal opgeslagen als jpeg-bestand. Dat is de standaard die we al sinds 1992 gebruiken op camera's, smartphones en andere apparaten. In de jaren negentig was jpeg een kleine revolutie en luidde het mede de transformatie van analoog naar digitaal in. Het werd immers het standaardformaat voor foto's en ander beeldmateriaal, en dat is het anno 2018 nog steeds. Wat minder fijn is, is dat er sindsdien nauwelijks iets is veranderd. In feite werken je smartphone en hypermoderne camera dus nog steeds met een gedateerd en technisch inferieur bestandsformaat van begin jaren negentig, en dat terwijl er juist heel veel ontwikkeling is geweest op het gebied van kwaliteit, compressie en opslagmogelijkheden. Zie het voorbeeld hieronder.
Het effect van zware compressie met jpeg (links) versus een modern hevc-compressiealgoritme: bpg
Wat is het probleem?
Er zijn nogal wat ontwikkelingen geweest op het vlak van digitale formaten. Enkele praktijkvoorbeelden zien we in de audio- en videowereld, waar de klassieke mp3's en mpeg2-bestanden niet langer alleen heersen, maar waar betere alternatieven bestaan en daadwerkelijk worden gebruikt. Denk bijvoorbeeld aan aac, ogg vorbis en flac voor audio, en mpeg4 en hevc voor video. Het jpeg-formaat heeft die ontwikkeling niet doorgemaakt en dat ligt niet aan een gebrek aan alternatieven.
Net als bij audio en video zijn er verschillende knelpunten: lossless versus lossy compressie, sterk verouderde compressiealgoritmen en een lage, 8bit-kleurdiepte. Door het eerste en laatste is de kwaliteit veel lager dan mogelijk is en door het tweede punt neemt het bestandsformaat zestig procent meer ruimte in beslag dan feitelijk nodig is. Voor het maken van foto's heb je daardoor slechts één alternatief: fotograferen in het rawformaat. Dat is echter weer onnodig groot en niet compatibel met veel apparaten en apps, waardoor je verplicht wordt de bestanden via software te bewerken en om te zetten. Voor veel mensen is dat een drempel.
Het probleem beperkt zich niet tot foto's. Ook 'animated gifs' met slechts 256 kleuren worden nog steeds op het web gebruikt, terwijl het png-formaat online veel gebruikt wordt voor transparantie, maar onnodig veel ruimte in beslag neemt door lossless compressie.
Een nieuwere jpeg-versie, die nu al bestaat, zou het beste van beide werelden zijn; een modern bestandsformaat dat weinig ruimte in beslag neemt en maximale kwaliteit biedt, ook voor beeldbewerking. Verderop in dit artikel leggen we uit wat dit nieuwe jpeg-formaat zoal kan en welke alternatieven er nog meer zijn, maar eerst gaan we iets dieper in op de manco's van het huidige jpeg-formaat.
Compressie en kleurdiepte
Aan de huidige jpeg-standaard kleven twee grote nadelen. Het bestandsformaat dat in camera's en smartphones wordt toegepast, gebruikt een zwaar verouderde compressievorm. Iedere keer dat je een jpeg-bestand opnieuw opslaat, wordt opnieuw compressie toegepast en gaat er beeldinformatie, lees: beeldkwaliteit, verloren.
Compressie
Er bestaan twee soorten compressie: lossless en lossy. Beide hebben als doel om de bits en bytes zo efficiënt mogelijk op te slaan, zonder dat onnodig veel ruimte wordt gebruikt. Lossless werkt als een zipbestand; data wordt op een slimme manier efficiënt opgeslagen. Stel je hebt de volgende tekst: aaaaabbbccccccccccccccc. Dit kun je letterlijk zo opschrijven, maar ook als a5b3c15. Dat laatste neemt veel minder ruimte in beslag. Bij lossless compressie is wel sprake van compressie, oftewel het kleiner maken van het bestand, maar blijft alle data intact. Je kunt een bestand dus kleiner maken zonder kwaliteitsverlies, omdat je altijd het origineel kunt reconstrueren. Dit is hoe raw, met dng als voorbeeld, over het algemeen werkt; alle beeldinformatie blijft behouden.
Een concreet voorbeeld van de gevolgen van compressie. De linkerfoto is het origineel en bevat weinig compressie. De rechterfoto bevat veel compressie, wat duidelijk is terug te zien aan de kleurgradaties in de lucht en de blokcompressie in de muur.
Lossy compressie, die voor het jpeg-, maar ook voor het mp3-formaat wordt gebruikt, is een vorm van destructieve compressie, want hierbij wordt 'overtollige' informatie weggegooid. Een blauwe lucht ziet er voor onze ogen egaal uit, wat je kunt opvatten als oneindig veel tinten blauw. Er kan best een aantal tinten blauw verdwijnen zonder dat we verschil merken. Als de lucht tot één tint blauw wordt gereduceerd, zullen we dat zien, maar niet als het een paar duizend tinten minder zijn of de compressie slim wordt ingezet. Bij jpeg wordt de compressie in blokken van 8x8 pixels toegepast, wat ook zichtbaar is in de afbeelding hierboven.
Lossy compressie scheelt enorm in de omvang van een beeldbestand. Waar een ongecomprimeerde foto 60MB groot kan zijn en lossless gecomprimeerd 40MB, kan dat bij jpeg worden gereduceerd tot slechts 6MB of minder. Dat scheelt dus een factor tien, waardoor meer foto's in het geheugen of op een sd-kaartje passen. Vroeger was dat pure noodzaak, want de geheugenopslag was beperkt. Tegenwoordig is dit minder belangrijk, want geheugen is goedkoop geworden. Hoewel je vaak de mate van compressie kunt instellen, gebruiken smartphones en camera's nog steeds de jpeg-standaard uit 1992, terwijl er tegenwoordig betere alternatieven zijn, met slimmere compressie en een grotere kleurdiepte. Bovendien, telkens als je het bestand opnieuw opslaat, wordt opnieuw compressie toegepast en gaat dus weer beeldinformatie verloren. Met lossy compressie neemt de beeldkwaliteit dus altijd af.
Bits, kleurdiepte en dynamisch bereik
Los van kleurverlies door compressie gebruikt jpeg slechts 8bit-kleurinformatie, tegenover 12bit tot 16bit in tiff en raw. Dat verschil is enorm. Zoals je weet, worden gegevens bewaard als enen en nullen. Een foto met een bitdiepte van 1 zou bestaan uit 0 en 1, oftewel van iedere pixel zou simpelweg vastgelegd kunnen worden of hij zwart of wit is. Reken dat door en dan besef je dat je met 8bit alle combinaties krijgt met een numerieke schaal van 0 tot en met 255, oftewel 256 helderheidsgradaties per kleurkanaal. Met drie kleurkanalen, rgb, betekent dat dus een weergave van in totaal 16,8 miljoen verschillende kleurtinten: r256xg256xb256.
Dat lijkt heel wat en het is voor normaal gebruik ook prima, maar voor beeldbewerking is het niet optimaal, omdat niet alle kleurgradaties worden vastgelegd, nog los van eventuele schadelijke compressie. Een 8bit-bestand, zoals jpeg, kan maximaal circa acht stops aan dynamisch bereik vastleggen. Een moderne camerasensor is in staat om 10bit tot 14bit aan dynamisch bereik vast te leggen, dus is het zonde dat een groot deel daarvan simpelweg wordt weggegooid, vaak met colour banding als ongewenst resultaat. Een rawbestand kan tien à zestien stops bevatten, mede afhankelijk van de analoog-naar-digitaalconverter, die meestal 12bit tot 14bit is. Simpel samengevat: hoe meer bits, hoe groter het belichtingsbereik zonder dat colour banding optreedt.
Witbalans en ruis
Als je een foto maakt met een smartphone of fotocamera, wordt deze eerst rekenkundig onder handen genomen. Allereerst om het resultaat te optimaliseren door de kleurverzadiging en het contrast op te schroeven, het beeld te verscherpen, ruis kunstmatig te verminderen en de details in lichte en donkere delen te verbeteren. Vooral smartphones peppen foto's flink op zodat ze er beter uitzien. Bij camera's met verwisselbare lenzen is dat veel minder het geval. Hoe dan ook, het resultaat wordt uiteindelijk opgeslagen als jpeg-bestand.
Op dat moment komen de nadelen van het jpeg-bestand aan het licht, nog los van de eerder genoemde gevolgen van de lossy compressie en beperkte kleurdiepte. Het eerste nadeel is dat de witbalans vast komt te liggen. Dat kan leiden tot kleurzwemen, bijvoorbeeld te oranje of te blauw, die bij een jpeg-foto lastig te corrigeren zijn. Het tweede nadeel is dat de camera softwarematige ruisreductie toepast als een foto in een donkere omgeving is genomen. Dat filtert lelijke ruis weg, maar maakt een foto ook minder scherp. Vooral camera's met een kleine sensor, zoals een smartphone, zijn daar erg gevoelig voor en dat leidt dan tot minder mooie resultaten. Als je je foto's niet in jpeg, maar in raw opslaat, kun je zowel de witbalans als de ruisreductie zelf optimaliseren, bijvoorbeeld met gespecialiseerde software zoals Lightroom of Noise Ninja. Met een nieuw jpeg-formaat zou dat ook kunnen.
De eerste foto is een onbewerkte jpeg waarbij ruisreductie is toegepast. De tweede foto toont de onbewerkte rawfoto zonder ruisreductie, maar met kleurruis. De laatste is een door ons bewerkte rawfoto.
Witbalans
Dankzij extra kleurgradaties en niet-gecomprimeerde beeldinformatie van het rawformaat kun je zonder kwaliteitsverlies achteraf de witbalans aanpassen. Een verkeerde witbalans is een van de meest voorkomende 'fouten' van digitale camera's. Dit wordt veroorzaakt doordat de camera de witbalans verkeerd inschat, met name door kunstlicht. Zonlicht heeft gedurende de dag steeds een andere kleurtemperatuur en ook kunstlicht is per type lichtbron, van gloeilamp, via tl-buis tot kaars, verschillend. Een stuk wit papier ziet er daardoor steeds een beetje anders uit. Het menselijke gezichtsvermogen corrigeert dit kleurverschil automatisch, waardoor een kleurafwijking ons niet of nauwelijks opvalt. Een camera is minder goed in staat om kleurafwijkingen te constateren en herstellen, al wordt de automatische witbalans wel steeds beter.
Kleurzwemen komen vooral voor in een omgeving met verschillende lichtbronnen, zoals een stad in het donker waarbij verschillende soorten kunstlicht door elkaar worden gebruikt: wit, blauw en geel. Dat soort beelden wordt meestal erg warm, oftewel oranje. Dat is te voorkomen door vooraf de juiste witbalans in te stellen, wat op de meeste smartphones standaard kan in de camera-app, al dan niet in de 'pro'-stand. Als je echter in raw hebt gefotografeerd, kan het ook achteraf, bijvoorbeeld in Lightroom (Mobile). Je kunt dus achteraf nog kiezen voor een voorgeprogrammeerde witbalans of deze zelf heel nauwkeurig instellen met een bepaalde kleurtemperatuur, uitgedrukt in kelvin.
Hieronder zie je een praktijkvoorbeeld. De eerste foto toont de originele, onbewerkte foto, waarbij de witbalans duidelijk te warm is. Bovendien bevat de foto overbelichte delen door felle lampen. De jpeg-versie van deze foto is gedeeltelijk te verbeteren, maar door de correctie van de oranje kleurzweem worden bepaalde delen juist iets te blauw. De hooglichten laten zich redelijk corrigeren, maar overbelichte delen kunnen hooguit grijs worden. In de rawversie zijn de witbalans en de overbelichte delen gecorrigeerd.
De originele foto is veel te oranje geworden doordat de witbalans zich liet beïnvloeden door het kunstlicht. Tegelijk zijn bepaalde delen van de foto overbelicht door felle lampen. Dit hebben we geprobeerd te corrigeren met zowel een jpeg- als een rawbestand.
Dynamisch bereik jpeg versus raw
De compressie en de beperkte kleurdiepte hebben ook grote gevolgen voor beeldbewerking. Een rawbestand bevat dus het maximale dynamische bereik, waardoor je veel meer bewerkingsmogelijkheden hebt. Zo kun je vrijwel zonder kwaliteitsverlies de belichting twee stops bijstellen of de schaduwen en hooglichten aanpassen, waardoor meer details in donkere en lichte gebieden zichtbaar worden. Bij jpeg-foto's is die beeldinformatie simpelweg niet aanwezig. Een ander voordeel van raw is dat je ongestraft achteraf de witbalans van een foto kunt aanpassen en dus heel eenvoudig kleurafwijkingen kunt neutraliseren.
Een concreet voorbeeld? Stel je wilt details van een overbelichte lucht redden. Dan heeft dat bij jpeg maar een beperkt effect. Bepaalde kleurgradaties zijn immers verloren gegaan door de compressie en die krijg je niet terug. Simpel gesteld: als witte lucht honderd procent wit is, wat bij overbelichting het geval is, dan kun je hier niets meer uithalen. De lucht kan alleen egaal grijs worden, maar dat ziet er niet uit. Als je foto opgeslagen is in raw, is de succeskans een stuk hoger. Dat zit hem dus in een combinatie van compressie en bitdiepte. De ruwe beeldinformatie die in het rawbestand is opgeslagen, bevat meer bruikbare beeldinformatie, die bij dergelijke beeldbewerking goud waard is. Dat is in de foto's hieronder ook goed te zien.
Een lastige lichtsituatie, in deze volgorde: het origineel, de bewerkte jpeg en de bewerkte raw (Samsung Galaxy S7)
De bovenstaande foto's tonen een lastige lichtsituatie in klassieke vorm. Er is sprake van een donkere voorgrond, met op de achtergrond donkere bewolking waar de zon doorheen schijnt, met een reflectie daarvan op het water. Dat is voor een camera een vrijwel onmogelijke situatie om goed te belichten. Als je de belichting afstemt op de voorgrond, wordt de lucht overbelicht; stem je af op de lucht, dan blijft de voorgrond onderbelicht. Hdr is een optie, maar omdat dan drie losse foto's worden samengevoegd, kan dat leiden tot ghosting en bovendien oogt tone mappingsoms wat kunstmatig.
Fotograferen in raw is een betere oplossing, omdat je dan achteraf gebruik kunt maken van het grotere dynamisch bereik en de extra kleurdiepte, zonder schadelijke compressie. Zoals je aan de tweede foto in de bovenstaande reeks kunt zien, laat de overbelichte lucht van de jpeg-versie zich niet corrigeren. Er zijn pixels die honderd procent wit zijn en deze bevatten dus onvoldoende kleurinformatie om overbelichte details zichtbaar te maken. Dat zie je in sommige beeldbewerkingsapps, Photoshop en Lightroom ook terug. Het rode deel in het screenshot hieronder bevat honderd procent witte pixels, die dus niet te corrigeren zijn.
De rode kleur toont overbelichte pixels, die honderd procent wit zijn (Lightroom)
De derde foto toont de gecorrigeerde versie op basis van het rawbestand. De lucht laat zich hier prima corrigeren en de voorgrond kan ook goed worden opgelicht. Deze foto toont veel meer details in de lucht. Fotograferen in raw biedt je dus veel meer speelruimte om over- en onderbelichte delen in een foto te corrigeren, zonder zichtbare schade.
Raw of dng
Fotograferen in raw heeft dus grote voordelen, maar toch is het niet alleen halleluja. Naast het kwaliteitsvoordeel kleven er ook nadelen aan het gebruik van raw. Het belangrijkste is dat rawfoto's drie tot tien keer zoveel ruimte in beslag nemen als jpegs. Hoewel opslag tegenwoordig niet duur meer is, is het voor huis-tuin-en-keukenkiekjes niet praktisch om standaard in dit formaat te fotograferen. Voor smartphones met een beperkte geheugencapaciteit en zonder uitbreidingsmogelijkheden is dat helemaal een potentieel struikelblok. Voor reguliere camera's met geheugenkaartjes met ruime capaciteit is dat minder een probleem, maar als je alleen in raw schiet, zul je de bestanden moeten omzetten voordat je ze bijvoorbeeld kunt delen op sociale media. Dat komt doordat er verschillende rawvarianten in omloop zijn; iedere camerafabrikant gebruikt een eigen rawformaat. Apps en softwarepakketten ondersteunen lang niet altijd al die verschillende formaten, dus is omzetten noodzakelijk.
Idealiter zou je dus altijd in jpeg én raw willen fotograferen. De jpeg-bestanden gebruik je dan voor het snel kunnen delen van foto's, en de rawbestanden voor het optimaal bewerken van foto's en het corrigeren van lastige lichtomstandigheden of kleurzwemen. Het overgrote nadeel daarvan is natuurlijk dat dit nóg meer ruimte in beslag neemt, terwijl je in de praktijk waarschijnlijk slechts incidenteel de rawbestanden nodig zult hebben. Zou het niet ideaal zijn als dat slechts met één modern fotoformaat zou kunnen?
Dng
Sony Xperia smartphones bieden geen ondersteuning voor raw.
Het goede nieuws is dat dit formaat er min of meer is: dng - oftewel Digital NeGative. Dit is een standaard van Adobe, bedoeld voor rawfoto's, opgeslagen met lossless compressie. Een dng-bestand doet geen preprocessing, oftewel het demozaïeken van de ruwe sensordata, maar converteert wel de metadata waardoor bepaalde fabrikantspecifieke informatie wordt gestandaardiseerd, oftewel weggegooid.
Een beperkt aantal fotocamera's, waaronder die van Pentax, Ricoh, Leica en in het verleden ook Samsung, ondersteunt dng. In de smartphonewereld wordt dng al langer geaccepteerd. Veel smartphonemakers bieden in hun native app de mogelijkheid om foto's in het dng-formaat op te slaan en anders zijn er nog altijd alternatieve camera-apps waarmee dat kan.
Hoewel veel programma's en besturingssystemen overweg kunnen met dng-bestanden, moet je toch nog meestal de beelden eerst omzetten in jpeg. Bijvoorbeeld als je ze op Instagram of Facebook wilt plaatsen. De meeste apps kunnen er niet direct mee overweg. Ook in dat geval zou een nieuw bestandsformaat dat zowel lossy als lossless compressie ondersteunt, dit probleem kunnen oplossen. Mits het massaal door app- en softwaremakers wordt opgepikt.
Hoewel je bij smartphones het there's an app for that-voordeel hebt, is dit niet altijd een garantie voor succes. Android en iOS bieden tegenwoordig standaard ondersteuning voor rawbestanden, maar toch kan niet ieder toestel het. Soms zijn er hardwarematige beperkingen. Zo werkt het alleen met Apples twaalfmegapixel-sensoren die sinds de iPhone 6s worden gebruikt. Met oudere iPhones en iPads werkt het dus niet. En bij Android moet ook de smartphonemaker zelf rawondersteuning bieden, ook al kan het besturingssysteem het aan. Verschillende smartphonefabrikanten, waaronder Sony, weigeren dit al jaren. Het gevolg is dus dat raw geen optie is, ook niet met thirdparty-apps, en je overgeleverd bent aan jpeg.
Geen echt alternatief
Overigens is dng ook geen volledig alternatief voor jpeg, alleen al om het simpele feit dat het formaat lossless compressie gebruikt, waardoor bestanden vrij groot worden. De dng-standaard kan sinds enkele jaren wel overweg met lossy compressie, maar in de praktijk alleen door rawbestanden te converteren naar een dng met lossy compressie, en dus niet rechtstreeks in camera's.
Het omgekeerde geldt ook; zelfs als er in de toekomst een nieuw en modern bestandsformaat is, met bijvoorbeeld lossless compressie en grotere bitdiepte, zal dit formaat nog steeds geen echt alternatief zijn voor raw. Een rawbestand slaat de ruwe sensorinformatie op. Pas bij het openen in software wordt het ruwe sensorbeeld gedemozaïekt, waarna het kan worden opgeslagen met ofwel lossless of lossy compressie.
Een nieuw fotoformaat?
Is er een noodzaak voor een nieuw fotoformaat? Die vraag kun je zowel met ja als met nee beantwoorden.
Nee
Ook al is de jpeg-standaard maar liefst 26 jaar oud en technisch gezien zwaar gedateerd, hij wordt door honderden miljoenen mensen en een veelvoud aan apparaten gebruikt zonder dat dit als probleem wordt ervaren. Opslagruimte is goedkoop, dus al neemt de oude standaard zestig procent meer ruimte in beslag dan nodig is, het is niet echt een groot probleem voor de consument. Recente smartphones hebben meestal ruim voldoende opslagcapaciteit en zijn vaak ook nog eens uitbreidbaar. Daarnaast zijn er talloze clouddiensten waar foto's gratis of tegen een kleine vergoeding worden opgeslagen.
Jpeg is kwalitatief verre van perfect vanwege de beperkte 8bit-kleurdiepte en lossy compressie, maar veel mensen interesseert dat helemaal niet; voor hen is het goed genoeg. De serieuzere fotografen fotograferen in raw, dus deze groep interesseert dit evenmin.
Ja
Aan de andere kant… Waarom zou je een 26 jaar oude standaard blijven gebruiken terwijl er inmiddels veel betere technieken voorhanden zijn? Betere beeldkwaliteit, een groter kleurbereik en minder schadelijke compressie, terwijl daarvoor slechts veertig procent van de opslagcapaciteit nodig is. Dat klinkt als een no-brainer, toch? Voor audio zijn er inmiddels ook betere alternatieven dan mp3 en voor video geldt hetzelfde, dus waarom voor jpeg niet?
Je zou zeggen dat iedereen wel openstaat voor betere beeldkwaliteit terwijl de beeldbestanden tegelijk nog maar een fractie van de ruimte in beslag nemen. Dat betekent dat je minder snel door je 4g-bundel bent als je foto's heen en weer stuurt, wat vooral met vakantie buiten Europa fijn is. Ook zit het geheugen van je telefoon minder snel vol, evenals de harde schijf of ssd van je computer, en back-ups maken neemt minder tijd in beslag.
Consumenten maken zich misschien niet zo snel druk over de onnodig grote omvang van jpeg-bestanden, bedrijven doen dit wel. Het gaat immers om veel grotere hoeveelheden bestanden, dus veel data. Iedere kleine bezuiniging is dan meegenomen, want dat betekent dat er minder opslagruimte nodig is, ook voor back-ups. Denk bijvoorbeeld aan Google, dat vele exabytes aan data van gebruikers in zijn datacenters opslaat. Als die data met zestig procent kan worden verminderd, dan scheelt dat miljoenen dollars aan kosten. Dat is exact wat Google doet met bijvoorbeeld WebP.
Jpeg (links) en WebP
Technische en praktische voordelen
We kunnen de voordelen van een nieuw fotoformaat dus onderverdelen in twee segmenten: beeldkwaliteit en opslagruimte. Beeldkwaliteit zou wat ons betreft het belangrijkste voordeel zijn, want een nieuw universeel beeldformaat zou een alternatief vormen voor de vele verschillende bestandsformaten die we nu gebruiken: jpeg's voor foto's, raw voor foto's met maximale kwaliteit, tiff voor opslag met lossless compressie, gif voor animaties en png voor transparantie.
Tijdens het fotograferen zou je de kwaliteit kunnen veranderen zonder om te schakelen van het ene naar het andere bestandsformaat. Voor huis-tuin-en-fotokiekjes gebruik je dan bijvoorbeeld vergelijkbare instellingen als bij de huidige jpeg-standaard: 8bit-kleurdiepte en lossy compressie. Eenmaal op een mooie locatie of in de studio schakel je over naar een hogere kleurdiepte, lossless compressie en hdr. Je bent niet meer afhankelijk van het specifieke rawformaat van de fabrikant en de bijbehorende software, maar kunt de foto's met iedere app of ieder softwarepakket openen of direct publiceren op sociale media.
Desgewenst kan gekozen worden voor een combinatie van lossless en een beetje lossy compressie, die voor het doel goede resultaten produceert. Het zou ook minder ervaren gebruikers de mogelijkheden van het rawformaat geven, terwijl de compatibiliteit behouden blijft en conversie dus niet nodig is. Daardoor worden foto's met de best mogelijke beeldkwaliteit opgeslagen, terwijl je ze bovendien kunt aanpassen zonder kwaliteitsverlies. Denk bijvoorbeeld aan het achteraf corrigeren van de belichting. Ook hdr zou ondersteund kunnen worden. Ditzelfde formaat zou bovendien alphakanalen met een transparante achtergrond kunnen ondersteunen. Daarvoor wordt momenteel png veel gebruikt, maar vanwege lossless compressie zijn de beelden dan vrij groot en daardoor minder geschikt voor het gebruik op websites. Voor kleine logo's is het nog wel oké, maar foto's worden reusachtig groot.
Zo komen we bij het tweede grote voordeel: opslagcapaciteit. Voor semitransparante bestanden zou dan ook lossy compressie kunnen worden gebruikt voor online gebruik, als alternatief voor png en gif. En indien gewenst kan hetzelfde bestand ook lossless worden opgeslagen, bijvoorbeeld voor opmakers en reclamebureaus. De slimmere lossy compressie leidt tot een betere kwaliteit met een grotere kleurdiepte, terwijl de bestanden minder ruimte in beslag nemen. Dat laatste is ook fijn voor smartphones, tablets, 4g-netwerken en datacenters.
Jpeg XL, WebP en heic
Het is niet zo dat er in het verleden geen initiatieven zijn geweest om de oude jpeg-standaard te vervangen. Sterker nog, rond de eeuwwisseling, toen jpeg nog een relatief nieuw bestandsformaat was, kwamen de oorspronkelijke makers, de Joint Photographic Experts Group, al met een beter alternatief: jpeg 2000. Dit formaat bood een beter compressiealgoritme met minder kwaliteitsverlies en had ook minder last van bit errors dankzij een betere coderingsstructuur. Bovendien konden bestanden desgewenst lossless worden opgeslagen, dus in feite in raw. Tot slot bood het nieuwe formaat een hogere kleurdiepte en dus meer dynamisch bereik.
Dat klinkt fantastisch, maar toch werd het geen groot succes. Er is niet één oorzaak te noemen, maar er waren wel twee belangrijke bottlenecks. De eerste was technisch van aard. Jpeg 2000 gebruikte compleet nieuwe code en had redelijk wat computerkracht nodig. In die tijd werkten we nog op kloksnelheden van 400MHz tot 1GHz, met een Intel Celeron, Pentium III of AMD Athlon, en het geheugen was doorgaans zo'n 64MB. Minder snelle machines met weinig geheugen hadden het zwaar met het nieuwe formaat.
De tweede bottleneck was meer organisatorisch. Ondanks de naam jpeg was het een compleet nieuw bestandsformaat, dat ook niet compatibel was met de oude standaard. Software moest het formaat, met de extensie .jpf, dus expliciet ondersteunen. Adobe voegde aanvankelijk ondersteuning toe, maar sinds CS2 wordt de jpeg 2000-plug-in niet meer standaard geïnstalleerd. Het was natuurlijk ook noodzakelijk dat cameramakers én webbrowsers het nieuwe formaat gingen ondersteunen, maar dat bleef uit en dus had het weinig nut om het bestandsformaat in gebruik te nemen.
Toch wordt jpeg 2000 vandaag de dag nog wel gebruikt, zij het in specifieke bedrijfstakken. Bijvoorbeeld voor de pasfoto's van id-kaarten, voor videosurveillance en in de filmindustrie. Als fotoformaat is het echter in geen enkele camera terug te vinden.
Een vergelijking van jpeg, jpeg 2000 en jpeg xr
Jpeg XL, XT, LS, XS, XR
Wie op de site van de jpeg-organisatie, voluit Joint Photographic Experts Group, kijkt, ziet een veelvoud aan verschillende standaarden. De organisatie ontwikkelt nieuwe beeldformaten om in te spelen op trends en werkt samen met verschillende bedrijven om deze op de markt te brengen. Een recent voorbeeld is jpeg 360, een beeldformaat voor 360-gradencamera's. De bestandsformaten zijn soms royaltyvrij, oftewel gratis te gebruiken, maar soms ook alleen met een licentie, waar dus kosten voor verschuldigd zijn. Dat laatste leidt vaak tot specifiek gebruik binnen bedrijven of in een bepaalde branche, maar niet tot een brede adoptie.
In de periode 2007 tot 2009 leek er met jpeg XR even sprake van een kleine doorbraak. Dat was te danken aan ondersteuning door Microsoft in verschillende Windows-versies én Internet Explorer. Heel gek was dat niet, want Microsoft had het formaat oorspronkelijk bedacht; het begon onder de naam HD Photo. Het biedt ondersteuning voor zowel lossy als lossless compressie en had een geavanceerder compressiealgoritme dan jpeg en jpeg 2000. Desondanks is het nooit doorgebroken als universeel fotoformaat, mede doordat andere browsers, software en producten het niet gingen ondersteunen. Er is overigens wel een plug-in beschikbaar voor Photoshop.
Een andere variant is jpeg XT. Dit is meer een uitbreiding van het bestaande jpeg-formaat uit 1992, met toevoegingen als hdr, ondersteuning voor alphalagen en near-lossless compressie. Doordat de codec backwards compatible is met het oude jpeg-formaat, is het gebruik ervan laagdrempelig. Compatibiliteit blijft bovendien behouden. Wanneer een apparaat geen jpeg XT-decoder heeft, worden de extra features simpelweg niet benut. Op een apparaat met hardwarematige ondersteuning kan het formaat wel gebruikt worden, bijvoorbeeld om high dynamic range-informatie weer te geven. Dankzij de compatibiliteit is het mogelijk dat jpeg XT onbewust veel vaker wordt gebruikt dan gedacht, maar in de meeste consumententoepassingen is het niet te vinden.
Jpeg XS is een zakelijke standaard voor omgevingen met veel bandbreedte, zoals wifi-, kabel- en glasvezelnetwerken. De nadruk ligt op snelle, niet-complexe compressie. Dat is nuttig voor apparaten die bijvoorbeeld op accu's werken. Door de mate van compressie te beperken wordt energie bespaard.
Vervolgens is er jpeg LS. Heel simpel gezegd is dit een beeldformaat met lossless compressie, waarmee dus de maximale kwaliteit behouden blijft. Deze wordt vooral in de medische sector gebruikt, bijvoorbeeld voor het opslaan van röntgenfoto's. Jpeg 2000 kan dit ook, maar dat is een veel complexer algoritme.
Jpeg XL
Na alle eerder genoemde varianten is er nog een jpeg-formaat: jpeg XL. Dit bestandsformaat bestaat nog niet, maar is wat de Joint Photographic Experts Group betreft dé nieuwe standaard die alle andere bestanden moet vervangen. In april dit jaar zijn de eerste concrete voorstellen gedaan om de technische specificaties vast te leggen. Jpeg XL moet jpeg, jpeg XR en jpeg 2000 gaan vervangen en tussen de regels door ook andere formaten als gif en png. Jpeg XL belooft alle eigenschappen die eerder in dit artikel zijn genoemd, waaronder meer dan zestig procent minder opslagruimte dankzij slimme compressie, 12bit- tot 16bit-kleurdiepte, transparantie, animatie en ondersteuning voor zowel lossy als lossless compressie. Technisch gezien borduurt jpeg XL verder op hevc, met zogenaamde hm-encoder en scc-extensies.
De Jpeg-groep liet Tweakers in een reactie weten hoge verwachtingen te hebben van jpeg XL en stelt dat verschillende marktpartijen geïnteresseerd zijn in de adoptie ervan. Om de kans op succes te vergroten, komt er ook een variant waarvoor geen royalty's verschuldigd zijn, zodat iedereen het formaat kan ondersteunen en gebruiken. Dat laatste is niet onbelangrijk, want voor het gebruik van h264- en h265-gebaseerde codecs is vaak licentiegeld vereist.
Google WebP
Een alternatief beeldformaat dat al enige tijd wordt gebruikt, is WebP, wat uitgesproken wordt als 'weppie'. Het formaat is gebaseerd op VP8, een vrij te gebruiken opensourcecodec voor videobestanden. Google gebruikt WebM en WebP intensief in zijn datacenters., waar bestaande beeldformaten worden omgezet naar WebP om ruimte te besparen. Een jpeg-bestand wordt 39 procent kleiner, png-bestanden nemen 45 procent minder ruimte in beslag en gifbestanden worden zelfs 64 procent kleiner. WebP ondersteunt animatie, icc-profielen, xml-metadata en transparantie, en bevat een vernuftig compressiealgoritme. Lossless compressie is ook mogelijk.
WebM is een vergelijkbaar containerformaat, maar wordt gebruikt voor video en is gebaseerd op VP9. WebP wordt ondersteund door Chrome, Chromium, Opera en de Google-webbrowser van Android. Daarnaast wordt het gebruikt door Netflix en Facebook om dataverkeer te besparen en de snelheid te vergroten. WebP is afkomstig van het VP8-videoformaat en de broncode is beschikbaar met bsd-licentie. Ook is voor alle platforms software beschikbaar om bestanden om te zetten naar WebP, maar het wordt bijvoorbeeld nog niet standaard ondersteund door Photoshop.
Apple heic en heif
Net als Google gebruikt Apple intern en voor haar producten ook een afwijkende standaard. Sinds iOS 11 worden bestanden, zoals jpeg-foto's, omgezet in het heic-formaat. Dit formaat is weer gebaseerd op heif, wat staat voor high efficiency image format, en dat is gebaseerd op de hevc-videocompressie, oftewel h265. Het formaat, dat beschikbaar is in licentievorm, is ontwikkeld door de MPEG Group en wordt inmiddels ook ondersteund door Windows 10. Ook Android P zal het formaat gaan ondersteunen.
Net als WebP is heic een containerformaat. Apple gebruikt het ook voor video's en live foto's. Door slimmere compressie zouden beeldbestanden nog maar de helft van de ruimte in beslag nemen, op de iPhone en iPad, maar ook in iCloud. Verder biedt het formaat 16bit-kleurendiepte en dus meer potentieel dynamisch bereik. Als een foto of video wordt gedeeld via sociale media, wordt hij automatisch omgezet in jpeg of mov.
En verder
De genoemde formaten zijn niet de enige die strijden om het opvolgerschap van jpeg. Al in 2014 werd bpg aangekondigd, wat staat voor Better Portable Graphics. Het werd en wordt ontwikkeld door programmeur Fabrice Bellard, die in april dit jaar versie 0.9.8 vrijgaf. Ook bpg is gebaseerd op hevc, maar zou desondanks leiden tot kleinere bestanden dan jpeg, jpeg XR en WebP. Het ondersteunt ook animaties. Hoewel bpg tot op heden niet echt is opgepikt, kunnen browsers het ondersteunen via JavaScript, waarvoor Bellard de code gratis beschikbaar stelt.
En dan is er nog AV1 (AVIF), dat nauw verbonden is aan hevc, heif en VP9. Dit open formaat zag in 2015 het levenslicht en is royaltyvrij te gebruiken. Het is voornamelijk bedoeld voor video, maar er is ook een fotoformaat. Onder andere YouTube en Netflix zijn van plan dit te gaan gebruiken voor de opslag en streaming van video's. Het zou kunnen zijn dat het fotoformaat mee kan liften als AV1 de nieuwe videostandaard wordt.
Update: in de reacties werd ook nog FLIF genoemd, wat staat voor Free Lossless Image Format. Dit is een lossless-beeldformaat, dus sluit niet helemaal aan als vervanger van jpeg, maar het is wel interessant om te noemen. Het is ontwikkeld door Belgische ontwikkelaars, die de broncode ter beschikking hebben gesteld. Het formaat is dus geheel gratis te gebruiken, zonder licentiekosten. Naar verluidt zou de lossless compressie van FLIF betere resultaten bieden dan lossless BPG en lossless WebP, mede dankzij Meta-Adaptive Near-zero Integer Arithmetic Coding. Ook transparantie, zoals png, wordt ondersteund. Het is nog niet helemaal uitontwikkeld, want CMYK wordt bijvoorbeeld nog niet ondersteund. Onder andere XnView en ExifTool kunnen ermee overweg, maar brede adoptie is nog niet in zicht.
De obstakels
Er zijn dus verschillende alternatieven voor de huidige jpeg-standaard, maar toch is de kans klein dat we voor een grote doorbraak staan. Een nieuw bestandsformaat kan technisch gezien nog zo goed zijn, als het formaat niet massaal door grote partijen wordt ondersteund, gaan consumenten het uiteindelijk niet gebruiken. In plaats daarvan zien we het klassieke patroon bij nieuwe standaarden: het leidt niet tot één universeel, alles oplossend formaat, maar juist tot meer fragmentatie, waarbij verschillende partijen verschillende formaten gaan gebruiken die onderling niet compatibel zijn.
Er is dus geen technisch probleem voor een opvolger van jpeg, maar een menselijke bottleneck. Het is een gemengd organisatorisch, maatschappelijk en economisch vraagstuk. Net als bij andere standaarden is het lastig om mensen en bedrijven met de neus dezelfde kant op te krijgen. Eén universele standaard is praktisch, maar vaak zijn er tegengestelde belangen. Op economisch vlak bijvoorbeeld. Camerafabrikanten gebruiken het liefst hun eigen proprietary rawformaat, in plaats van bijvoorbeeld dng. Dan kunnen ze veel makkelijker kleine tweaks uitvoeren, bijvoorbeeld om lensfouten weg te werken.
En op organisatorisch vlak heeft niet iedere softwaremaker, app-maker en smartphonefabrikant een direct voordeel om een nieuwe standaard te gaan ondersteunen. Dit kost mankracht en het maakt de interface misschien minder duidelijk voor minder ervaren gebruikers, want weer een extra optie. Als er geen significant voordeel voor de fabrikant of ontwikkelaar is en dus een eigen belang, neemt de kans flink af dat een nieuw formaat wordt omarmd.
Dat is extra complex omdat er verschillende lagen en segmenten van ondersteuning nodig zijn. Smartphone- en cameramakers moeten het nieuwe formaat in hun producten gaan inbouwen, populaire apps en software moeten het gaan ondersteunen, en webbrowsers moeten er ook mee overweg kunnen, zonder dat de eindgebruiker bestanden moet converteren. De hele sector moet er dus achter staan. En dan volgt de laatste bottleneck: de consument moet het echt gaan gebruiken, anders was de hele implementatie voor niets. Zoiets zal vele jaren duren, als het al gebeurt…
Zelfs áls camerafabrikanten en smartphonemakers een nieuw bestandsformaat opnemen in hun producten, is het de vraag of consumenten dit gaan gebruiken. Allereerst is dat een psychologische drempel; je vertrouwt wat je kent en wantrouwt wat je niet kent. Zal iemand een foto in het nieuwe formaat wel kunnen openen? Kan die geüpload worden naar apps en op formulieren, en werkt het formaat op websites? Jpeg werkt in ieder geval; iedereen is ermee opgegroeid. Bovendien zullen veel mensen de eerder genoemde nadelen van het jpeg-formaat waarschijnlijk niet zwaar vinden wegen, als ze er al mee bekend zijn.
Standaard der standaarden
De wereld zit vol uiteenlopende standaarden. Dat is een probleem, maar het is niet onoverkomelijk. Als een standaard eenmaal in gebruik is, is het heel lastig om deze in te ruilen voor iets anders. Het beste voorbeeld is waarschijnlijk het metrieke stelsel, dat al in 1815, na de Franse revolutie, werd ingevoerd en intussen in vrijwel alle delen van de wereld de norm is. Toch zijn er nog steeds landen, zoals Engeland en de Verenigde Staten, die hun eigen, middeleeuwse systeem gebruiken, met inches, yards en miles.
En kijk naar stopcontacten en stekkers. De Eurostekker is hier de norm, maar zelfs binnen Europa zijn er uitzonderingen, laat staan in de rest van de wereld. Daardoor moeten fabrikanten verschillende stekkers bij hun producten leveren en dus verschillende producten voeren in lokale markten. Dat moeten ze toch al, want op stroomgebied is er evenmin één standaard, met 110V en 230V en vele variaties daarop.
De cartoon hierboven zegt eigenlijk alles. Het lijkt handig en logisch om met één nieuw, universeel bestandsformaat op de proppen te komen dat alle andere, oude en technisch achterhaalde standaarden moet vervangen. De praktijk is vaak anders. Als één schakel in de keten niet meewerkt, wordt het niets. En die kans is groot, alleen al vanwege de vele schakels. Allereerst moet het fotoformaat in smartphones en camera's worden opgenomen, en vervolgens moeten de makers van besturingssystemen, browsers, apps en bewerkingssoftware het allemaal gaan ondersteunen. De laatste schakel is de consument, die al zijn hele digitale leven met het jpeg-formaat werkt en misschien niet echt geïnteresseerd is in de beloofde vernieuwingen.
Dat is begrijpelijk, maar wel jammer. Zo'n nieuw formaat zou het mogelijk maken om foto's, illustraties en andere afbeeldingen met een veel hogere kwaliteit op te slaan dan nu gebruikelijk is, terwijl meer dan de helft van de opslagruimte kan worden uitgespaard. Dat geldt voor fotobestanden, maar ook voor animaties zoals 'animated gifs', en transparante bestanden, waarvoor nu lossless png wordt gebruikt.
Een nieuwe standaard op basis van hevc biedt een veel groter kleurenpalet, oftewel bitdiepte, waardoor een foto meer dynamisch bereik kan bevatten zonder colour banding en overweg zou kunnen met hdr. De gebruikte compressiealgoritmen zijn een stuk geavanceerder dan die in de jpeg-standaard van 1992, die vandaag de dag nog steeds wordt gebruikt. Dat betekent betere kwaliteit en minder opslagruimte. Bovendien kan desgewenst ook lossless compressie worden toegepast voor de best mogelijke beeldkwaliteit en de bijbehorende voordelen voor beeldbewerking in bijvoorbeeld Photoshop, Lightroom of Snapseed.
De voordelen van betere kwaliteit spreken voor zich, maar ook opslag is een groot voordeel. Als beeldbestanden nog maar veertig procent van de oorspronkelijke ruimte innemen, blijft er meer opslagcapaciteit over. Dat verlaagt bovendien de druk op 4g- en wifinetwerken en je bent minder snel door je 4g-bundel heen. Daarbij scheelt het kostbare back-upcapaciteit. Het is niet voor niets dat Google en Apple intussen al hun eigen op hevc gebaseerde bestandsformaten gebruiken.
Zal het mogelijk zijn dat zowel de volledige industrie als de consument een nieuw beeldformaat, zoals jpeg XL, omarmt? Onmogelijk is het niet, maar voor nu blijft het wishful thinking.
Het FLIF-format is nog niet helemaal uitontwikkeld. Het beloofd echter wel een mooi formaat te worden wat in één klap alle beeld formaten (raw, gecomprimeerd, bewegend, transparant) kan vervangen. Het heeft ook nog eens een goede progressieve beeldopbouw.
De progressieve kwaliteiten maken het in principe mogelijk om alleen beelden in hoge kwaliteit op te slaan en slechts een aantal procent van de data te versturen voor verkleinde weergaves, data beperking of aanpassing aan het formaat en kwaliteit van het scherm.
Flif is (wordt) een heel mooi formaat, maar is meer een vervanger voor png dan voor jpg. Het comprimeert losless. Door de goede progressieve opbouw van het plaatje kan je het ook lossy gebruiken door gewoon het laatste deel van het plaatje af te knippen. Maar dit geeft toch net een wat mindere kwaliteit dan een jpeg van vergelijkbare grootte (op het moment iig).
Wat in dit artikel ook niet mag ontbreken is lepton van dropbox https://github.com/dropbox/lepton .Lepton kan jpegs met ongeveer nog 20% meer comprimeren zonder (extra) loss. De lepton file is terug te converteren naar een (exact gelijke) jpeg file. Of in de toekomst wellicht meteen te openen.
Maar dit geeft toch net een wat mindere kwaliteit dan een jpeg van vergelijkbare grootte (op het moment iig).
Heb je de vergelijkende tests wel goed bekeken? Flif geeft in alle gevallen bij dezelfde bestandsgrootte een kwalitatite beter resultaat dan jpeg.
Flif is bij uitstek hét formaat om zowel lossless als lossy formaten te vervangen. Het biedt het beste van twee werelden, en presteert beter dan PNG en JPG.
Ook andere zaken zoals alpha channels die in JPG nooit lekker zijn doorontwikkeld zit er allemaal in.
Ik heb veel met flif gestoeid. En nee de JPEG is toch echt meestal kleiner. probeer het zelf maar. Flif is een prachtig formaat, maar nog wel wat 'rough around the edges'. De voorbeelden op de flif site zijn op het gebied van lossy vergelijken met jpeg niet helemaal objectief imho.
Maar wellicht dat ze er nog wel komen met nog een beetje tweaken, en het gemak van flif (knip gewoon het bestand kleiner en je hebt een lossy bestand) is natuurlijk ook wat waard.
Alleen is een proprietary standaard wel riskanter, wat als je het op een gegeven moment niet vrij mag gebruiken? Daarnaast is het fijn je het offline kan gebruiken. Geef mij maar de open standaard als het goed genoeg is.
Jij gaf aan dat een bepaalde proprietary standaard voordelen heeft, ik merkte daarom op dat het feit dat het proprietary is een groot nadeel is. Het gaat om meer dan enkel welke van de twee superieur is. Natuurlijk is er wel een minimumstandaard die je moet hanteren, ook voor open standaarden.
ik haal dit aan aangezien we momenteel aan troep van Windows en Adobe vastzitten doordat in het verleden proprietary standaarden werden gekozen, laten we die fout niet nog een keer maken en zo voorkomen dat we in de toekomst aan nog meer software-troep vast zitten.
De offtopic beoordeling van die ene persoon of 2 personen raakt kant noch wal, in de titel van dit artikel staat duidelijk vermeld dat het gaat om de standaard die JPEG gaat opvolgen. Mijn reactie was ontopic.
[Reactie gewijzigd door Anoniem: 444127 op 22 juli 2024 15:56]
JPEG? Niet helemaal een 'Open Standard' naar moderne maatstaven, maar eventueel geclaimed patenten erin zijn verjaard (en waren al onzin om mee te bginnen). Er zij legio open source implementaties. Geen black box toestanden zoals met word documenten.
Lepton? Dat is apache-licenced open source.
Zie ik iets over hoofd?
Of bedoel je dat je me met iemand anders verwisseld had, dat kan ook natuurlijk.
Jpg heeft ook de mogelijkheid om progressief in te laden. Dat is gewoon een vinkje in (bijvoorbeeld) photoshop.
Waar ik naartoe wil is een kleine update van het jpeg principe. Transparantie zou een gigantische weerwaarde zijn. Vooral in de web en app wereld. Een klein detail maar de voordelen zijn enorm.
Toch is er nog een grotere innovatien(waar niet over gesproken wordt) en dat zijn vectoren. Het web zit er vol van!
Een logo in jpg is not done in de web en appwereld, je gebruikt SVG code’s om uw logo of buton op te bouwen zodat het super scherp is op elk scherm. Net zoals tekst nooit blurry wordt.
Het verschil is dat JPEG wel progressief kan laden en het beeld in stappen kan opbouwen. In alle gevallen wordt het gehele bestand geladen. FLIF heeft de mogelijkheid om het tonen op elk moment te stoppen. In tegenstelling tot JPG kan je er dus voor kiezen om de opbouw van het beeld na bijvoorbeeld 25% al te stoppen.
Helaas zie ik nog niet de mogelijkheid om slechts een x percentage te downloaden. Als dat mogelijk zou zijn, dan kan je een app of website toch voor veel situaties (lage bandbreedte, klein scherm enz.) aan laten passen, terwijl je maar één plaatje in hoge resolutie hoeft op te slaan. Ik moet nu elke foto in 4 resoluties opslaan, soms ook nog eens in minimaal 2 resoluties als een soort thumbnail.
Vector en pixel formaten bestaan al sinds het begin van de computer-graphics naast elkaar. Vectoren zijn ideaal voor computer gegenereerde graphics. Geen enkele pixel gebaseerd formaat kan ooit de specifieke vector kwaliteiten (aast oneindig schalen) benaderen. Beeldsensors zijn echter pixel georiënteerd. Omrekenen naar vectoren geeft altijd artefacten. Daarom zijn de compessie algoritmes op andere technieken gebaseerd. Vaak zijn dat wavelet of fractal gebaseerde algoritme. Als je je daar meer in wilt verdiepen kan ik je het onderstaande artikel aanraden. http://homepages.vub.ac.be/~andooms/cursus2012.pdf
Omschalen van vector naar pixel geeft in de praktijk net veel minder artefacten in logo’s en knoppen. Daarom dat ik altijd voor svg-kies ipv van png of jpeg. (Voor digitale interfaces)
Vectoren omzetten naar pixels kan pixelprecies gebeuren op elke scherm dpi terwijk een jpg erg slecht schaalt op meerdere scherm formaten en dpi’s.
Het bestaat eingelijj al een beetje. PDF combineert bijvoorbeeld al vector + pixel en dat is super handig want zo kan je ren flyer maken in photoshop en voorzien van vectoriele logo’s, tekst en icons waardoor de flyer leesbaar blijft op elk afdrukformaat.
Als jpg ook vector zou ondersteunen of interactie kan bevatten kan je de tekst in meerdere talen aanleveren of copyright of een logo plaatsen op een foto.
Wat ook leuk zou zijn is dat bewegend beeld mogelijk is zodat je de zogenaamde cinemagraphs kan maken.
Een soort programmable jpg die in browser svg’s in overlay kan plaatsen, annimaties toevoegen etc.
[Reactie gewijzigd door Coolstart op 22 juli 2024 15:56]
Vector -> pixel gaat inderdaad goed. De vectorformaten zijn ook niet het probleem. Het probleem zit vooral in de pixelformaten. PDF heeft beide mogelijkheden, maar kan ze niet mengen (wel over elkaar heen plaatsen). De compressie is instelbaar en voor pixel formats is het erg afhankelijk van de gekozen eind resolutie. Als je daar 300 dpi kiest terwijl de afbeelding 600 dpi (of meer) was, dan verdwijnt er gewoon detail. Dat geldt ook voor bitmap-lettertypen. JPG is vooral bedoeld als container voor het aanleveren van complete eindproducten (flyer), of als archief bestand (pdf-a).
Het sleutelen aan JPG naar een nieuw formaat lijkt me een zinloze exercitie. Het algoritme is gewoon niet meer geschikt om de hoge kwaliteitsfoto's van nu te kunnen behappen. Het algoritme aanpassen is natuurlijk mogelijk, maar dan krijg je een gedrocht met meerdere compressie algoritmen (want backwards compatible). Eigenlijk gaat het dan meer lijken op een camper waar een caravan aan is gehangen omdat de camper te klein is om de kinderen in onder te brengen. Als er nog meer vriendjes, vriendinnetjes en kleinkinderen komen, dan voegt men nog een aantal tenten toe. De kamper wordt dan een kleine, verplaatsbare camping.
Zeer interessant, waarom zit dit nog niet in Gimp en andere programma's? Ik zie dat het al uit 2015 stamt, ze mogen dus wel wat opschieten om het meer bekendheid te geven.
Ik zie dat het al uit 2015 stamt, ze mogen dus wel wat opschieten om het meer bekendheid te geven.
Dit is bij meer Belgische projecten het geval. Men maakt er een studie van, maakt wat werkende voorbeelden en schrijft een paper in een wetenschappelijk blad. Daarna is de kous af. In dit geval is men nog een heel klein stapje verder gegaan door het gratis (inclusief broncode) beschikbaar te stellen.
Na dit "droppen" doet men geen inspanning om het formaat meer bekendheid te geven. Als men contact gezocht had met een aantal cameraproducenten en de grote grafische progrgramma's en zelf plugins voor bijv. Gimp en IrfanView had gemaakt, dan had FLIF mogelijk nu al in de camera hardware gezeten.
Als je dit artikel goed leest dan zie je dat het zeer moeilijk is om een nieuw formaat te adopteren. Dus lijkt me onwaarschijnlijk dat plots een alternatief in alle mainstream camera's komt. Je moet continu competen, reclame maken, support winnen van grote bedrijven (wat hoogst waarschijnlijk veel politiek inhoudt).
FLIF is niet aan een bekend ICT-bedrijf gelieerd, maar het resultaat van een wetenschappelijke studie. Er zitten geen rechten of kosten aan, dus implementeren is alleen maar een kwestie van doen.
Voor camera's is een (near) lossless formaat met goede compressie best een belangrijk dingetje. Het genereren van tumbnails gaat ook razend snel (je leest gewoon de eerste 15% van een bestand in). De dure camera's werken nu met RAW opslag. Die kijken niet naar de geheugengrootte.
De goedkope en middenklasse camera's en de middenklasse en high-end smartphones gebruiken meestal nog jpeg als opslag formaat. De kwaliteit van de camera (lens en beeldsensor) is vaak beter dan je ooit te zien kan krijgen. Het geheugen is vaak niet al te groot en moet ook nog eens gedeeld worden. Het wordt dus hoog tijd dat jpeg een keer aan de kant gezet wordt.
Het toevoegen van de ondersteuning van FLIF in een grafisch pakket is een fluitje van een cent en zodra een groter cameramerk FLIF gaat gebruiken kunnen de makers van grafische software dat in no-time in een patch verwerken.
Over de acceptatie bij het volk hoef je je niet druk te maken. Zodra een nieuw formaat in camera's gebruikt gaat worden, komt dat vanzelf.
FLIF is wel zeer processor intensief om te schrijven. Dat is voor camera's een probleem (zolang er geen gespecialiseerde hardware voor is, maar om dat voor elkaar te krijgen ben echt al een heel stuk verder).
Ik kan niet voor GIMP spreken, maar voor Krita gaat het zo: we beginnen aan het ondesteunen van een nieuw bestandsformaat als er echt veel vraag naar is, of als de auteurs van het nieuwe bestandsformaat helpen met het schrijven van code. Dat heeft Dirk Farin gedaan voor Krita voor Heif support. Dat zit er nu in, al zijn de onderliggende libraries nog heel erg in beweging, zodat we nu wel code hebben, maar het nog niet in de binary builds zit.
Er is nog geen vraag naar flif, en nog niemand heeft aangeboden het werk te doen... Dus is er nog geen flif plugin.
Het word steeds beter en ook op het video en foto gebied.Opslag capaciteit voor camera's, smartphones gsm,desktop computer word steeds meer.Men heeft meer ruimte tot hun beschikking.
Ik denk dat raw de beste kwaliteit heeft ondanks dat jpg of jpeg meer compressie gebruikt.
De vraag is nu weer wat het meeste ervan gebruikt gaat worden kortom wat word in de toekomst het gestandaardiseerd compressie formaat. Het zijn er best veel wat je in het wild op het internet tegenkomt.
De kwaliteit van de beeldschermen word steeds beter en alleen daarom al is de honger naar een betere en kwalitatief hoofwaardige formaat nodig, ook steeds meer smart tv ,en oled tv laten steeds een betere beeld kwaliteit zien waardoor jpg of jpeg het niet meer kan bijbenen of overbodig word.
Nu rijst de vraag en net als mp3 en jpeg,jpg, mp4,wat gaat men het meeste gebruiken,alhoewel ik png ook best een goede kwaliteit vind hebben.Wat voor een formaten gaan de mensen het meeste gebruiken?En wat word in de toekomst de standaard?
[Reactie gewijzigd door rjmno1 op 22 juli 2024 15:56]
Wat ik nog mis in dit verhaal is de invloed van patenten en vergoedingen op een bepaald formaat, net als dat een proprietary formaat bedoeld is de klant aan een bepaalde leverancier te binden, zijn betaalde standaards prijs opdrijven en jagen mogelijke kopers weg.
En patenten zorgen altijd voor marktbescherming, alleen grote spelers mogen in de zandbak.
MP3 is nu eindelijk afgelopen. Ik heb ooit contact opgenomen met Fraunhofer om die $2 per gebruiker gewoon netjes te betalen om MP3 encoder support in m'n shareware programma te hebben (gewoon via LAME library). Die lui vroegen dus doodleuk een minimum van $15k per jaar, iets dat ze niet op hun site vermeldden.
Mocht je je afvragen waarom er nauwelijks fatsoenlijke videobewerkingssoftware is, patenten zijn de reden. Als je iets leuks bouwt komt er een advocaatje al snel een stokje voor steken. En al wil je best betalen, het wordt je onmogelijk gemaakt.
Idem dito met DTS op vrijwel alles. Zelfs op TV's die claimen je hele entertainment te kunnen bedienen heeft geen DTS, waardoor je toch weer wat anders moet.
Ik mis eigenlijk iets veel belangrijker in dit artikel, er lijkt een aardig stukje kennis te ontbreken. Aangezien mijn achtergrond heb ik dat stukje wel.
Jpeg 2000 is al een heel oud formaat en niet een concurrent van Webp, Jpeg 2000 is niet doorgebroken omdat het in de praktijk niet beter bleek dan jpeg.
Er waren wel betere formaten dan Jpeg 2000 welke 'resolutie onafhankelijk' zijn (denk aan RAW formaat zoals in fotografie) en dan in combinatie met wavelet compressie. Het zijn de wavelet compressie formaten die de directe concurrenten waren voor Jpeg 2000.
Ik weet zo even niet uit mijn hoofd wat de name waren, maar zijn er een aantal.
En het waren de wavelet compressie formaten die nog te veel processor kracht gebruikten om succesvol door te breken als opvolgers van jpeg.
Ook hadden de Wavelet compressieformaten (te) hoge licentie kosten.
Wavelet is echter niet verdwenen en wordt gebruikt om on demand plaatjes op de juist resolutie te leveren, maar dan meestal in een meer standaard formaten als jpeg.
Wavelet wordt dus als resolutie onafhankelijk archiefmedium gebruikt, dit is vooral nodig voor grote archieven. Ik vermoed dat sites als IMDB wavelet compressie gebruiken.
Webp is eigenlijk gewoon weer een nieuwe poging van Google om DRM er weer in te krijgen en probeert het gat tussen gif, png en jpeg op te vullen.
Ook de dotcom bubble is een reden waarom de andere formaten uit de internet geschiedenis zijn geschreven, Jpeg 2000 was makkelijk te onthouden omdat iedereen jpeg al kende.
[Reactie gewijzigd door fevenhuis op 22 juli 2024 15:56]
Kleine correctie. Jpeg 2000 is wel degelijk een format met wavelet compressie.(1) De discrete cosinustransformatie (DCT) is bij JPEG 2000 ingeruild voor de Daubechieswavelet-transformatie (2) wat eigenlijk een overgang inhoudt van een lokale, blokgebaseerde transformatie naar een globale beeldtransformatie.
Er dook wel een ander artifact op als je het te gek maakte:ringing. Waardoor je vervaging (blur) en ringen kreeg langs de randen. Bij JPEG krijg je de typische blokartafacten door de 8 x 8 blokken.
Ook was het mogelijk om lossless op te slaan in JPEG2000.
Er waren wel betere formaten dan Jpeg 2000 welke 'resolutie onafhankelijk' zijn (denk aan RAW formaat zoals in fotografie) en dat is wavelet compressie, het zijn de wavelet compressie formaten die de directe concurrenten waren voor Jpeg 2000.
Over oude standaarden gesproken.. (de meeste) RAW is grotendeels "gewoon" TIFF met een fabrikant-specifieke header. En TIFF stamt uit 1986.. Niets tegen TIFF overigens, het is een stuk robuuster dan JPEG. Bij beiden gaat er niet snel iets veranderen, verwacht ik: TIFF-achtig RAW voldoet goed voor artiesten en consumenten klagen niet over JPEG.
Klopt ongeveer, ik haalde RAW aan als een formaat met meer image informatie dan wat er in de lossy jpegs zit. Echter werd/wordt er ook lossy compressie gebruikt met RAW formaten.
Je moet hierbij denken dat aan dat er twee strategieën zijn voor image compressie:
een die geoptimaliseerd is voor data compressie en een zo klein mogelijk bestand proberen te produceren
en een die geoptimaliseerd zijn om zo veel mogelijk informatie uit image data te preserveren.
Wavelet compressie probeert dan het beste uit die twee werelden te krijgen.
Iets waar Jpeg 2000 dus uiteindelijk niet zo goed in bleek te zijn, maar helaas is het toch de standaard die in de herinnering van mensen is blijven steken dankzij de naam.
Even wat pedant gedoe: 'raw' is niet echt een formaat. Het is namelijk afhankelijk van de fabrikant van de camera wat het formaat van een raw bestand is. Vaak is het een dump van de (grayscale) ruwe sensordata met wat metadata. Al dan niet in een Tiff formaat gestopt, of een of andere proprietary header van de fabrikant. De grayscale data moet je dan zelf nog als kleur interpreteren door het juiste kleurenraster erbij te weten (ook weer camera afhankelijk).
Tevens is Tiff niet bepaald 'robuuster' dan Jpeg. Tiff is een container formaat, waar een aantal formaten image data in opgeslagen kunnen worden. Onder andere in jpeg formaat. Als je dus een tiff extensie ziet, weet je eigenlijk nog niet wat je hebt. Het openen van een Tiff bestand is ook vreselijk omslachtig, omdat het zoveel verschillende types data kan bevatten. Voor lossless zou je eigenlijk liever .png gebruiken, behalve dat de metadata 'standaarden' om de een of andere reden beter doorontwikkeld zijn voor tiff.
In de GIS-wereld wordt vooral ECW gebruikt voor de uitwisseling van luchtfoto's en satellietbeelden in goede kwaliteit. Voor een gebied ter grootte van een gemiddelde Nederlandse provincie voor luchtfoto's met een grondresolutie van 10 cm komt dat neer op ongeveer 80 GB.
Ook MrSID is een bekend formaat, maar comprimeert minder dan ECW.
Ik deel deels je mening. Licentiekosten en encoding power waren destijds de bottleneck.
Jpeg2000 was echter veel kleiner zonder zichtbare detoriation. Destijds maakte ik posters altijd in pdf met jpeg2000, waar ik eerst op cd deed aanleveren omdat de posters snel 260 MB waren, werd het sinds jpeg2000 rond de 3 MB zonder dat je het verschil zag. Prima voor de mail dus.
Op hoge resoluties vergeleken met Jpeg heeft Jpeg 2000 dus niet zoveel voordelen, de zwaardere processorkracht woog niet af tegen de marginale kleinere bestand groottes, maar vergeleken met PDF natuurlijk wel.
De ander wavelet formaten die er destijds waren (20 jaar gelden) waren beter maar te duur en hadden niet goed nagedacht over markt acceptatie.
Waarom dan JPG waar als ik het goed heb rechten op zitten en niet PNG wat als ik het weer goed heb juist een beter en goedkopere (of gratis) alternatief van GIF/JPG is.
Begin deze eeuw heeft een bedrijf Forgent Networks geprobeerd een patent op Jpeg te claimen gebaseerd op rechten uit 1986. Uiteindelijk heeft dat bedrijf verloren en is het patent ongeldig verklaard. Ik ben niet bekent met andere vergoedingen voor gebruik van Jpeg op dit moment.
Er zat patent op de zgn. arithmetic coder, van die f*c*ers van IBM volgens mij (vanaf 1978). Deze is ca. 20-25% efficiënter dan Huffman omdat je geen 'hele' bits nodig hebt om entropie-waarden te coderen.
Dat patent kost tot op de dag van vandaag aan de hele wereld dus 25-30% extra opslagcapaciteit!
Jpeg is een *stuk* kleiner dan png, voor visueel vergelijkbare kwaliteit.
Normale JPG is visueel gezien altijd van inferieure kwaliteit t.o.v. PNG, als het origineel van voorliggende kwaliteit was. Simpelweg omdat JPG informatie wegflikkert.
Als ik iets inscan, bewaar ik de PNG-originelen. Als ik me dan later bedenk over de nabewerkingen, en opnieuw wil beginnen, is 't altijd beter om opnieuw met de originele PNG te beginnen i.p.v. met een 'origineel' initieel opgeslagen JPG van die scan.
Ja, JPG is kleiner en vooral veel sneller dan PNG. Toch geef ik de voorkeur; alleen zijn er geen fototoestellen die in PNG opslaan; en volgens mij zijn er ook geen compacts die in RAW opslaan (dus dan past het toestel niet in mijn heuptasje op vakantie).
[Reactie gewijzigd door kimborntobewild op 22 juli 2024 15:56]
Als je JPG niet gaat openen en bewerken en dan weer als jpg saven maak ik me sterk dat je het verschil met de source png op het oog niet gaat zien (met een beetje goeie settings natuurlijk).
Voor een source die je daarna nog gaat bewerken gebruik je natuurlijk geen JPG, dat spreekt voor zich.
Als je trouwens een compact wil die in raw kan schieten zou je kunnen zoeken naar een camera die custom firmware support zoals bijvoorbeeld CHDK voor (sommige) canon compacts. Die custom firmwar geeft je meestal wel de mogelijkheid om in raw te schieten.
Jammer genoeg is meestal het ruisniveau van een compactcamera , met zn keine sensortje, dusdanig hoog dat je meestal niet veel winst hebt uit de extra kleurdiepte.
Jammer genoeg is meestal het ruisniveau van een compactcamera , met zn keine sensortje, dusdanig hoog dat je meestal niet veel winst hebt uit de extra kleurdiepte.
Maar winst heb je toch; simpelweg omdat er niet in JPG wordt opgeslagen, die ongeveer 2/3e van de data weggooit (ruwe, eigen schatting).
Meh. Je hebt in sommige gevallen ietsjes winst inderdaad. Maar wel ten koste van een hoop meer gedoe. Die raw bestanden moet je eerst nog 'developen', dwz het bayer raster interpoleren voor rgb en de goeie whitebalance toepassen. Met die whitebalance kan je dan nog de meeste winst maken t.o.v. de door de camera geproduceerde jpeg. Maar de kwaliteit van de sensor maakt dat het verschil in kwaliteit m.i. de extra hassle meestal niet waard is. En ja, jpeg gooit data weg, maar als je jpegs op de hoogste quality die je camera kan opslaat (en je camera is niet uit het stenen tijdperk) dan is dat over het algemeen niet echt te zien. Behalve misschien door audiofielen en wijnproevers.
maar als je jpegs op de hoogste quality die je camera kan opslaat (en je camera is niet uit het stenen tijdperk) dan is dat over het algemeen niet echt te zien.
Als je inzoomt, wel. En als je 't verschil echt niet meer ziet: dan mag dat beetje extra (qua bytes) om lossless op te slaan ook wel. Ben je gelijk af van 't gezeik van re-coding bij elke bewerking.
Nee... ik vind lossy JPG nog steeds één van de slechtste uitvindingen ooit. Internet staat vol met slechte kwaliteits-foto's door JPG.
Het is maar heel, heel zelden dat ik een afbeelding heb waar de kwaliteit met JPG echt slechter is.
Het is dan een afbeelding met een lage resolutie en scherpe rand overgangen.
Als ik met Irfan foto's bewaar met 70-80% jpg compressie, moet ik ca 400% inzoomen voordat ik verschil KAN zien. Bij de huidige hoge resolutie foto's kan ik me geen situatie voorstellen waarin je daar last van hebt!
Als jij een scan maakt met 300 of 600dpi? en je scanner software staat niet te agressief afgesteld, dan kan dat prima met jpg.
Heb je het echt een keer naast elkaar gelegd?
Ik doe dat regelmatig met Irfan, save als jpg 70%, open die file, terwijl venster met origineel open staat.
Snel Alt-Tab om van venster te wisselen, kijken of verschil zie.
Dan beide inzoomen met + , en weer kijken.
Als je echte afwijkingen ziet, terug uitzoomen en kijken of je het terug kan vinden.
nb: Bij Irfan is een jpg met 80% groter en beter dan 60%.
Jpg gaat trouwens bij 50% en meer de compressie zeer agressief aanpakken door het aantal kleuren sterk te verminderen.
Het is maar heel, heel zelden dat ik een afbeelding heb waar de kwaliteit met JPG echt slechter is.
Een 'normale' (niet JPG2000 etc) JPG is altijd echt slechter dan het origineel. Er wordt data weggegooid. 'Alleen' om wat ruimte te besparen.
Bij de huidige hoge resolutie foto's kan ik me geen situatie voorstellen waarin je daar last van hebt!
Dat je het niet direct ziet, wil nog niet zeggen dat het niet zo is . De 'normale' JPG is en blijft een lossy bestand. Ik vind het zonde dat er data van een foto wordt weggegooid; zeker als 't een mooie foto is. En wellicht erger: hele volksstammen hebben niet door dat bij JPG de kwaliteit bij gebruik elke keer achteruit gaat.
Stel, je kan twee verschillende JPG-versies vinden van hetzelfde plaatje op internet. Dan kom je weer een nadeel tegen: welke is van de beste kwaliteit? Nu kan je natuurlijk zeggen: als je dat optisch gezien niet direct kan zien, dan neem je toch de kleinste? Maar dat optisch vergelijken kost tijd.
En bijna alle compact-fototoestellen gooien direct al veel beeldinformatie weg, louter omdat ze alleen JPG ondersteunen. Ik vind dat een slechte zaak. Al met al vind ik JPG één van de slechtste uitvindingen ooit.
Met de huidige opslagcapaciteiten heeft de lossy JPG wat mij betreft helemaal geen bestaansrecht meer.
[Reactie gewijzigd door kimborntobewild op 22 juli 2024 15:56]
Idd goed punt. Het debakel met GIF in de 'begintijd' van internet deed het formaat geen goed (link), en daarvoor was eigenlijk elke afbeelding jpeg of gif (afhankelijk van beeld ivm omvang en artefacts). Patentgedoe was destijds wel aanleiding voor ontwikkeling van PNG, dus het is niet alleen maar negatief
Dat niet, wel dat iedereen varianten van GIF ging gebruiken zonder compressie of andere varianten. Dat Henk en Ingrid zich er weinig van aantrokken is waar, maar voor commerciele bedrijven had het wel consequenties (met voornoemde workarounds)
WebP is niet bebaseerd op HEVC, maar op VP8. VP8 is een concurrent voor H.264.
Dat maakt WebP en HEIC/HEIF verschillende stromingen, al zijn ze beiden gebaseerd op een videocompressietechniek.
Waarom is dit belangrijk: aan de kant van H.264/H.265 zitten behoorlijke geldgraaiers, die proberen licentiegeld te vangen, en dan niet alleen per verkocht apparaat, maar ook bijvoorbeeld per gestreamde film.
Voor video heb ik alle hoop gevestigd op AV1. Dit heeft alle grote spelers achter zich, waar HEVC of WebM met de VP8 of 9 codec dat niet heeft. Beiden zullen dus waarschijnlijk kunnen fluiten naar marketwide adoption.
Daarbij belooft AV1 beter te worden, maar dat worden ze allemaal natuurlijk een keer
AV1 is alleen nog altijd in ontwikkeling. Het zal nog een tijd duren eer het uitontwikkeld is en DAN kan het pas echt uitgerold gaan worden. Veel browsers en software pakketten ondersteunen AV1 al als beta of alpha, maar dat zijn dus allemaal niet de final codecs. Ik hoop echt dat alle grote spelers nu eens doorpakken en er helemaal voor gaan.
Enige waar je dan nog tegenaan loopt, en altijd tegenaan zal blijven lopen, is bejaarden of mega trage instanties die nog altijd Internet Explorer 7 draaien.
Ik heb me gisteren nog pissig gemaakt om het feit dat wij als Dynamic Video bedrijf nog altijd alles moeten uitserveren in h.264 mp4. Eeuwig zonde...h.264 is ondertussen ook al 15 jaar oud.
Nou, ik zie juist eerder dat tegenwoordig electronica onderstuening voor .265 op een sticker hebben staan. Maar HEIC/HEIF WebP of VP 1/8/9 heb ik tot nu toe nog niet gezien.
End at gaat de doorslag geven, welke codec wordt ingebouwd in je volgende tv/camera/telefoon. Want wat al die fancy bestandsformaten gemeen hebben is dat ze best zwaar zijn in het in en uitpakken als er geen support voor zit in de hardware zelf.
Licencie gelden of niet, het formaat (net zoals .264) dat overal ingebouwd wordt zal winnen.
Mee eens, maar waarom jij nu h265 stickers ziet en geen AV1 stickers is omdat die eerste al helemaal uitontwikkeld is, en die andere nog in alpha is. Daarbij zullen meer mensen h264 'herkennen', en dus ook h265, waarbij AV1 voor niemand nog echt herkenbaar is. Dus qua marketing is een h265 sticker effectiever. Dat gezegd hebbende, ik weet eigenlijk niet of HEVC acceleration universeel is of niet. Het zou kunnen dat telefoons met h265 acceleration stiekem ook AV1, VP9 of wat dan ook hardware matig kunnen acceleraten. Waarschijnlijk niet, maar ik kan me voorstellen dat dit voor AV1 misschien nog in backwards compatible gemaakt zou kunnen worden.
Maar inderdaad, uiteindelijk is diegene die overal ingebouwd wordt de winnende.
Echter, H265 gaat dat hoogstwaarschijnlijk niet worden, omdat de ondersteuning te laag is, en de kosten te hoog. (de kans dat apple dit gaat ondersteunen is bijvoorbeeld bijzonder klein. Ik ga ervan uit dat zij liever de h265 generatie overslaan en direct voor AV1 gaan, waar zij trouwens ook hun steentje aan bijdragen).
Tja het wordt een beetje afwachten, maar asl je nu bijv kijkt in de pricewacht bij de media speler categorie (daar is een codec filter) kun je zien dat 265 op het moment het meest ondersteund wordt. VP9 heeft nog niet de helft van de apparaten die het ondersteunen. categorie: Mediaspelers
Ik vind het vergelijk met audio niet een vergelijk. Er wordt MP3 met flac vergeleken terwijl een flac file juist een stuk groter is dan een MP3 (en ik hoor het verschil van FLAC zo goed als niet met een 320kbit MP3).
Dit is een eeuwige discussie waarom FLAC beter zou zijn. Nou FLAC is niet beter. Een gemiddeld persoon hoort het verschil niet net zoals je het verschil niet ziet tussen JPG en RAW.
FLAC is simpel weg een ongecomprimeerd MP3 bestand waar RAW hetzelfde is van een JPG.
Om iets uit te printen volstaat een JPG perfect, en waar voor het dagelijks luisteren een mp3 320kbs volstaat.
Alleen als je de foto of muziek wilt editen of mixen dan heb je meer baat bij het ongecomprimeerde bestand en dan moet je dus RAW of FLAC gebruiken. Maar zodra je daar dus klaar mee bent is het beter om te exporteren naar een kleiner bestand.
Het verschil tussen een 320 kbit MP3 bestand en een FLAC-bestand van een CD-track is "lastig" te horen, maar wel te horen. Alles onder 320 kbit MP3 is zeker te horen.
Maar sterker nog, ik kan het je LATEN horen:
1) Laad een MP3 bestand en het FLAC bestand van een CD-track in een audio editor.
2) downmix beide tracks van stereo naar mono.
3) inverteer 1 van de 2 tracks
4) sla het geheel op als 1 nieuw bestand.
Wat je nu hebt is een audio track met het MP3 geluid "cancelled-out", dus wat resteert is in feite wat MP3 aan data heeft weggegooid.
Speel maar eens af... en prepare to be shocked...
N.b.: de autdiotracks dien je wel handmatig in de editor te synchroniseren.
[Reactie gewijzigd door dragoon2000 op 22 juli 2024 15:56]
Wat verder nog van belang is om enige vergelijking mogelijk te maken is dat het volume van dit residu op normaal volume wordt afgespeeld.
Ga je het volume opkrikken dan ga je inderdaad de artefacten meer horen, terwijl ze mischien erg zacht zijn in verhouding tot de muziek (die je weggerekend hebt).
Daarnaast kunnen codecs eventueel ook de fases schuiven of een delay veroorzaken waardoor er residu achterblijft dat niks met waarneembare verschillen te maken heeft.
En er is het belangrijke punt dat in het gecodeerde bestand de artefacten worden afgedekt door de muziek eromheen. Dit effect is er niet in het residu waardoor je de artefacten 'kaal' hoort en die dus veel meer waarneemt.
Er zitten dus nogal wat haken en ogen aan deze test en uiteindelijk zal het niet heel goed terug te vertalen zijn naar hoe goed het gecodeerde bestand klinkt.
Waar dit goed voor is is voor het bestuderen van de aard van de artefacten. Dus, hoe klinken die artefacten in isolatie.
Maar eigenlijk kun je ze niet los zien zonder het geluid eromheen. De artefacten zijn berekend om samen met de muziek te werken.
Iets wat ik in het begeleidende verhaal ook duidelijk aangeef. (1)
Nee, in je verhaal raad je mensen juist aan om het harder te zetten. Je maakt het punt niet dat de luide versie niet is wat je normaal hoort. Je suggereert het hooguit, maar dat zal alleen voor mensen die dit al enigzins snappen duidelijk zijn. De meeste mensen krikken het volume op en roepen 'Ooh wat erg!!'
Iets wat ik in het begeleidende verhaal ook duidelijk aangeef. (2)
Ook dit kon ik niet echt terugvinden in je verhaal. Je haalt het een soort van aan maar maakt neit duidelijuk dat de artefacten in dat residu luider overkomen dan waneer ze in de muziek zelf verwerkt zijn (vanwege psychoacoustiek).
Ik vind het (korte) stukje tekst zelfs een klein beetje suggestief. Het lijkt een beetje te zeggen "kijk eens wat die codec allemaal weggooit, man!". Lichtjes, en het zou mensen dus op de verkeerde been kunnen zetten wat betreft het realistisch inschatten van wat die artefacten in het echt (dus verwerkt in de muziek) nog uitmaken.
Dat is ook wat ik in de basis tegen dit soort testjes heb. Het brengt de zaken erg uit balans en als je niet uitkijkt kun je er als leek heel verkeerde conclusies uit trekken, denk ik.
Doet me erg denken aan de hele discussie rondom sampling en hoe mensen geneigd zijn het niet te snappen en dus allerlei fantasieen gaan toepassen op wat ergens gezien of gehoord hebben. Je kunt het maar beter voor zijn
[Reactie gewijzigd door koelpasta op 22 juli 2024 15:56]
Wat verder nog van belang is om enige vergelijking mogelijk te maken is dat het volume van dit residu op normaal volume wordt afgespeeld.
Ga je het volume opkrikken dan ga je inderdaad de artefacten meer horen, terwijl ze mischien erg zacht zijn in verhouding tot de muziek (die je weggerekend hebt).
Als je het volume hoger zet worden de artefacten idd harder, net als de rest van de muziek, de balans blijft dus gelijk en hoger volume betekend dus niet dat je de artefacten beter gaat horen.
Is niet helemaal eerlijk, ja dan vind je inderdaad precies wat mp3 'sloopt' aan de audio, maar het is zo goed als onmogelijk om in te schatten hoe je dat verschil aan informatie ervaart als je gewoon naar de muziek luistert.
[Reactie gewijzigd door MerijnB op 22 juli 2024 15:56]
Het begon mij duidelijk op te vallen bij het vergelijken van een nummer met een piano intro: na het afspelen van de MP3 de FLAC afgespeeld en tot mijn stomme verbazing hoorde je op het FLAC nummer ineens de hamertjes in de piano. Die waren in het MP3 bestand volledig weggegooid.
Het voegde echt wat diepte en realisme toe om die terug te hebben.
Ik geef je wel gelijk: het MP3 algoritme is uitermate behendig in het analyseren van op welk moment je informatie waarschijnlijk wel kunt weggooien zodat iemand dat waarschijnlijk toch niet doorheeft.
In tijden dat opslagruimte geen beperkende factor meer is, en de processorkracht benodigd voor compressie evenmin, ga ik liever voor "lossless" want why not?
FLAC met de "--best" switch, en PNG gecomprimeerd met PNGout of Optipng met de "-o7" switch.
1x (batch-)comprimeren, eeuwig plezier.
Dan moet je maar eens een blinde test gaan doen. Ik heb zelf al grote moeite om verschillen te horen bij een bitrate van 128kb, bij 168 hoor ik echt geen verschil meer. Ik heb een redelijke geluidset (duurste logitech 5.1 icm x-fi titanium). Echte audiofielen met betere geluidssystemen en betere oren komen in blinde tests niet verder dan 192kb. Beweren dat je het verschil kan horen is hetzelfde als beweren dat je een alien bent.
Bedenk dan ook nog dat je supergeconcentreerd aan het luisteren naar verschillen tussen de twee formaten die je exact (verschillende keren) na elkaar hoort. Er zit dus ook nog een verschil tussen het kunnen horen van een verschil en het daadwerkelijk een minder prettige ervaring krijgen.
In het verleden heb ik ook wel testjes gedaan met mp3 en de cd speler. 128kb Haal je er wel uit, webradio klinkt ook niet geweldig. Met 192kb moest ik al moeite doen om het verschil te horen, het origineel klinkt wat opener maar dat is als je omschakelt tussen de verschillende bronnen. Eind resultaat: ik rip mijn cd's naar 320kb of VBR voor gebruik in de auto.
Precies, 320kbps mp3 is zo goed als niet te onderscheiden van lossless, zeker met de LAME codec, wat volgens mij de meest doorontwikkelde encoder is. Echter, met de goedkope opslag is lager dan 320kbps gewoon zonde en moet je altijd voor de grootste mp3 size gaan.
Een vervanger/opvolger voor mp3 is ook zo goed als kansloos, aangezien bijna ieder apparaat zoals portables, autoradio's, telefoon, e.d. mp3 ondersteunen en sommige zoals autoradio's alleen CD en mp3.
[Reactie gewijzigd door Tranquility op 22 juli 2024 15:56]
Als aanvulling hierop, een interessante studie waarin men een aantal sound enigeneers en musici het verschil tussen MP3 en CD-kwaliteit heeft laten testen. Methodologisch één van de betere studies die ik op dit onderwerp heb gelezen:
Zo'n test is natuurlijk vrij beperkt qua muziekgenres en weergaveinstallatie.
MP3 is gemaakt voor normale muziek onder gemiddelde thuissituaties en voor gemiddelde oren.
Is de situatie anders dan wat iik beschrijf dan kan de perceptuele codering van MP3 best uit elkaar gaan vallen.
Op de website van de AES (de de facto organisatie als het gaat om audio en akoestiek) zijn meerdere artikelen en onderzoeken te vinden dat zelfs professionals de grootste moeite hebben met MP3 bitrates van 256kbps in een GECONTROLEERDE omgeving (dus weining background noise etc).
In de praktijk betekent dat je dus minstens een stapje omlaag kan, mits je de huiste instellingen gebruikt.
Wel is het zo dat een editor graag het origineel wil behouden vergelijkbaar met de zelfde nadelen met jpg.
Dat is een beetje onzinnig. Het basis idee van MP3 is het 'psycho-acoustic-model'. Dat wil zeggen dat bepaalde harde tonen in de muziek zachtere tonen maskeren, omdat de manier waarop het menselijk oor werkt het onmogelijk maakt beide tonen tegelijk te detecteren. Op die manier kan MP3 heel veel data die je in principe niet kan horen wegggooien. Als je vervolgens *alleen* de weggegooide geluiden gaat luisteren hoor je ze natuurlijk wel, allicht. Maar dat wil niet zeggen dat je ze ook kan horen in de oorspronkelijke audio.
Het Psycho-acoustic-model is natuurlijk een gemiddelde, waardoor sommige mensen gevoeliger zijn voor mp3 compressie artifacts dan anderen. En voor honden/katten/niet-mensen klinkt een MP3 waarschijnlijk heel anders dan de oosrponkelijke wav.
Leuk bedacht, maar 't zegt niks over "wat MP3 aan data heeft weggegooid".
Het gaat om perceptie. Voor bepaalde geluidsbewerkingen zijn onze oren ongevoelig. Bijvoorbeeld lineaire faseverschuivingen, en meer van dat soort dingen. Lossy compressie is gebaseerd op "weggooien wat je toch niet horen kunt".
Werkelijk verschil horen tussen origineel en gecomprimeerde versies doe je met dubbelblind testen. Dat kun je thuis met wat software doen, en je zult versteld staan van hoe slecht je gehoor eigenlijk is.
Je kunt overigens wel trainen om compressie artefacten beter te horen, tot zeker hoogte. Dat zijn de mensen met de "gouden oortjes". Je kunt niet trainen om bijvoorbeeld ultrasoon te horen (dus boven 21kHz), er zijn immers ook geen mensen die infrarood kunnen zien... en ook de gouden oortjes hebben al heel veel moeite met compressie boven de 160kbps.
Is niet eerlijk zo te vergelijken, aangezien het mesnelijk oor gevoelig is voor frequency masking en net dat wordt doir mp3 gebruikt bij het weggooien van informatie
Maar je vergeet ff dat de meeste mensen muziek niet afspelen via een super deluxe audio systeem. Maar gewoon via de meegeleverde oortje van hun telefoon. Of nog erger de telefoon speaker.
Dan kan je formaat nog zo superieur zijn, je zal het niet horen. En dan is een klein mp3'tje vaak net zo goed.
Dat is niet eerlijk.
MP3 is gebaseerd op het menselijk gehoor.
De truck is juist dat weglaat wat je in de muziek eigenlijk niet KAN horen, omdat andere het overstemmen.
Als jij vervolgens de muziek weglaat, is het logisch dat de eerst onhoorbare delen nu wel hoorbaar zijn!
Je redenatie klopt wel dat de meeste mensen met normale apperatuur het verschil niet horen tussen 320kbps en flac. Maar je zegt dat flac niet beter is. Flac is wel degelijk beter (waarom zou je het anders gebruiken bij editen zoals je zelf zegt). Dat kun je zeker horen met goede apperatuur en vooral bij klassieke muziek.
Maar bijna niemand heeft dat, en daarom heeft het voor de meesten geen zin om flac te gebruiken, anders dan een master te bewaren als je je bestanden ooit nog wil omzetten naar andere formaten.
En je hebt het fout dat flac een ongecomprimeert mp3 bestand is. Flac is een variant van ZIP en er is wel degelijk sprake van compressie, alleen losless, zonder informatie verlies. https://nl.wikipedia.org/wiki/FLAC
En RAW is geen ongecomprimeerde jpeg. RAW is er in veel verschillende varianten, afhankelijk van de producent van de camera/sensor. Jpeg is een standaard. Dus RAW is veel meer dan een ongecomprimeerde jpeg.
[Reactie gewijzigd door gjmi op 22 juli 2024 15:56]
Bij flac wordt er geen informatie uit gehaald maar wordt het hele bestand gecomprimeerd(gezipt). Bij mp3 wordt er daadwerkelijk informatie uit het muziekbestand gehaald wat onherroepelijk leidt tot dynamiek verlies en detail verlies.
Je hebt flac gebruikt in vergelijking met blu-ray versus dvd. Bij Blu-ray en dvd zijn beeld en geluid in lossy formaten opgeslagen. Flac is niet lossy, maar losless. Daarom klopt je vergelijking niet.
Het is me nu duidelijk dat je een paar zaken door elkaar haalt. En dat zijn compressie technieken, samplefrequentie/rate en de bitbreedte van de samples.
Die staan los van elkaar. Het zij dat bepaalde standaarden beperkingen leggen op de gebruikte samplerate en aantal bits.
Mp3 compressie zou je ook in de gigahertz samples kunnen doen. Alleen heeft dat weinig zin om dat in een standaard voor een audio formaat op te nemen.
Audio kan natuurlijk dynamisch gecompressed zijn maar dat is niet gerelateerd aan de drager (CD) en niet aan dit topic (enige overeenkomst met compressie a la mp3 is de naam).
Zie ook post koelpasta:
Op zich klopt dit op een algemeen nivo. De meeste muziek is ook heel erg van een productie 'saus' voorzien. Dat zijn over het algemeen hele batterijen aan equalizers, compressors, limiters, galmen, delays, etc, etc, etc.
A dedicated electronic hardware unit or audio software that applies compression is called a compressor. In the 2000s, compressors became available as software plugins that run in digital audio workstation software. In recorded and live music, compression parameters may be adjusted to change the way they affect sounds. Compression and limiting are identical in process but different in degree and perceived effect. A limiter is a compressor with a high ratio and, generally, a fast attack time.
Opname is dus zeker niet = cd.
Daarnaast wordt vaak op 24-32 bits opgenomen, cd is "maar" 16 bits...
Maar goed, is off topic.
De vergelijking ging over het proces van verbetering, niet zozeer over de vorm van compressie...
Is flac beter dan mp3? Ja. Is Blu-ray beter dan dvd? Ja. Is jpeg xl beter dan jpeg? Ja. Ongeacht de mate en manier van compressie. Zo duidelijk?
[Reactie gewijzigd door Tourmaline op 22 juli 2024 15:56]
Nee, je betoog wordt eigenlijk steeds waziger. Je lijkt dynamische compressie en data compressie met elkaar te verwarren wat niets met elkaar te maken heeft. Dan heb je het over het band gelimiteerde karakter cd's wat daar weer compleet los van staat.
Opname is dus zeker niet = cd.
Dit kan ik ook niet plaatsen.
Daarnaast wordt vaak op 24-32 bits opgenomen, cd is "maar" 16 bits...
Is hartstikke waar maar heeft niets met al het voorgaande te maken (data compressie, dynamische compressie, etc).
Vanwaar deze opmerking?
Dat heeft met samplerates te maken en dat staat in princiepe los van compressie technieken.
Maar het ligt aan het formaat van het orgineel of je iets weggooit. Als je audio opneemt met 44.1 kHz samplerate (CD, tot 22 kHz audio) dan gooi je niets weg. Is iets met een hogere samplerate opgenomen, word het eerst geresampled (daarmee gooi je info weg) voordat het gecomprimeerd word. De compressie zelf zorgt niet voor de beperking van 20 kHz.
[Reactie gewijzigd door gjmi op 22 juli 2024 15:56]
'beter' is natuurlijk subjectief en afhankelijk van de situatie.
Een 192kbps MP3 is beter geschikt als ringtone voor een telefoon dan een FLAC bestand.
Een FLAC bestand is beter geschikt als studio opname dan een 192kbps MP3.
Ze hebben elk hun toepassing, en daarom bestaan ze ook allebei.
Zelfde met beeld en video formaten.
Als je een foto-site hebt die een hele zwik aan thumbnails laat zien, dan zou je die typisch als flink gecomprimeerde JPEG kunnen hebben. Je wilt er immers zo snel mogelijk door heen kunnen bladeren.
Terwijl de daadwerkelijke foto zou je dan als PNG aan kunnen bieden. (Even snelle voorbeelden, zijn vast wel corner-cases te bedenken.)
FLAC is simpel weg een ongecomprimeerd MP3 bestand waar RAW hetzelfde is van een JPG.
Je kan het niet zomaar omdraaien. Flac is vergelijkbaar aan een zip-bestand, MP3 moet je meer zien als een jpeg met zware compressie. Je kan een lossy formaat nooit meer terugzetten naar de oorspronkelijke kwaliteit.
Het heeft mij altijd verbaast dat mp3 en mod niet samen tot een nieuw muziek formaat hebben geleid. Heel veel muziek heeft repeterende delen, een mod bestand is een instructie hoe die repeterende delen (elk instrument) te plaatsen in tijd, incl. volumes etc.
Als je de filters die in de studio worden toegevoegd er bij neemt, zou je hele mooie "raw" bestanden van je muziek krijgen. Waarna je ook heel slimme compressie kunt toepassen.
Met mp3 worden eigenlijk de resultante golfvormen geanalyseerd en de verandering t.o.v. het vorige "beeld" en zo verlies je compressie van herhaling als de BMP niet in sync loopt met je "beeld"-jes. Aangezien herhaling vaak ritmisch gebeurd in muziek.
Dit is een leuk idee, maar gaat in de praktijk niet werken, zo repeterend is het allemaal niet, zelfs als je dit op micro niveau doet (repeterende periodes beschrijven) ga je dit heel snel horen (ik spreek uit ervaring).
Het probleem met een mod is dat je enorm veel aan het proces van muziekmaken zou moeten standardizeren.
Na het mengen van verschillende stemmen van de muziek word bijvoorbeeld een compressor gebruikt om het resultaat meer als een geheel te laten klinken.
Dat zou betekenen dat een compressor in de standaard van zo'n formaat moet worden opgenomen.
Alleen zijn er in de muziekwereld momenteel duizenden verschillende compressors beschikbaar, in software en in hardware, van gratis tot duur, met allen hun eigen klank, algoritme en instellingsmogelijkheden.
Een encoder die verder terug kan kijken in de tijd en daardoor bij het encoderen van een stukje audio op 1 plaats kan refereren aan een zeer gelijkend stukje een tijdje verder terug (inderdaad 1 beat of maat bijvoorbeeld) zou misschien nog wat extra winst kunnen boeken, al zou dat wel de complexiteit en het geheugengebruik van zowel de encoder als decoder vermoedelijk serieus opdrijven.
Ah dus wellicht juist door die compressor/eindmix filters krijgen we een uniek klankbeeld per artiest/mixer en uniformer beeld op een album. Dus een belangrijke saus om van de muziek te genieten. En wellicht dus dat dit juist de compressie ook weer makkelijker maakt, doordat de muziek meer uniform wordt.
Wellicht inderdaad een goed idee om te kijken naar de huidige encoders en daar slimme tricks aan toevoegen die de bestaande compressie verbeteren, zonder dan er een nieuwe decoder nodig is.
Ah dus wellicht juist door die compressor/eindmix filters krijgen we een uniek klankbeeld per artiest/mixer en uniformer beeld op een album. Dus een belangrijke saus om van de muziek te genieten. En wellicht dus dat dit juist de compressie ook weer makkelijker maakt, doordat de muziek meer uniform wordt.
Op zich klopt dit op een algemeen nivo. De meeste muziek is ook heel erg van een productie 'saus' voorzien. Dat zijn over het algemeen hele batterijen aan equalizers, compressors, limiters, galmen, delays, etc, etc, etc.
Echter wordt de muziek door compressie van dynamiek (dus de musicale compressors) vaak juist lastiger te coderen.
Ten eerste maximaliseer je de bandbreedte van het medium. Je gebruikt dus uiteindelijk meer van de, zeg, 16 beschikbare bits.
De data compressor zal dus gemiddeld een grotere range moeten kunnen coderen.
Daarnaast voeg je allerlei harmonische details toe met de meeste muziekale compressors waardoor de muziek eigenlijk complexer wordt. En dit is ook weer lastiger om te coderen.
Maar je zou een codec denk ik wel kunnen 'tunen' om hier beter mee om te gaan en er eventueel voordeel uit te slaan. Maar dat gaat bijna altijd gepaard met slechtere performance bij muziek die niet erg gecompressed (muziekale variant) is.
Heel veel muziek heeft repeterende delen, een mod bestand is een instructie hoe die repeterende delen (elk instrument) te plaatsen in tijd, incl. volumes etc.
Het zou mischien voor een heel beperkte hoeveelheid muziek kunnen werken, maar de meeste muziek is helemaal niet zo repeterend als je doet voorkomen.
Daarnaast is tempo over het algemeen verre van constant, zlefs als het uit een computer komt.
Je kunt dus niet voorspellen hoe die (zoals jij dat zegt) 'beelden' uitkomen.
Is dus niet echt een goed algemeen plan voor het efficient coderen van muziek.
Als je dan toch voordeel van beide formaten wilt hebben kun je nog altijd gewoon MODs maken met MP3's als bron.
Maar goed, 99,99999% van alle muziek is niet makkelijk of nauwkeurig te vatten in een MOD.
FLAC is dus wel beter. Alleen op een gegeven moment is het niet meer waarneembaar voor de meeste mensen. En dat is natuurlijk het hele concept waarop lossy compressie berust. Het is minder goed dan het origineel maar als de verschillen met het origineel verwaarloosbaar zijn, zal niemand klagen en geniet men vooral van de voordelen.
Bij RAW versus JPG ligt het iets anders. Waar je FLACs en MP3s allebei kunt luisteren is RAW niet bedoeld om te bekijken. Het is je ruwe sensor data die nog bewerkt moet worden. Je schiet RAWs om uiteindelijk JPG of TIFF van de maken. Waarbij je (zeker in het geval van JPG) de extra data uit de RAW gebruikt om details, die je anders niet zou zien, tevoorschijn haalt. En als je met je camera direct JPGs schiet, dan doet je camera die stap voor je. Dus JPG is een gecomprimeerde versie van RAW maar dan wel met een smaakje/sausje erover heen.
Het is trouwens niet enkel verschillen klein maken, maar ook gebruik maken van psychoaccoustics, met name temporal masking en vooral frequency masking van het menselijk oor, maw je kan het verschil zelf niet horen als de bitrate niet te laag wordt , maar wel zien aan waveform/short term power spectrum
Nouja, afhankelijk van je definitie van 'beter'. Diskspace is ook wat waard. Als je audio nog moet bewerken is flac beter. Als je het op je telefoon wil zetten om het door die kleine speakertjes af te spelen dan is mp3 veel beter, want kleiner en je gaat het verschil toch nooit horen.
Trouwens is ogg voor dezelfde kwaliteit als mp3 nog iets kleiner, en bovendien rechtenvrij. Voor elke mp3 die je maakt moet je eigenlijk geld afdragen aan het fraunhofer instituut.
Serieus? Ik heb een nummer van Carrie Underwood welke op 320 mp3 niet om aan te horen is welke kraakt aan alle kanten. Maar op flac en de cd gewoon zuiver is. Ja, rippen heb ik uiteraard ook zelf gedaan. Zowel 320 mp3 als flac.
Ikzelf hoor het verschil tussen flac en 320 mp3 wel. Ben geen audiofiel en heb ook niet de beste spullen, maar heb wel in-ears twv 180 euro. En een goede draagbare muziekspeler.
Wat iemand al aan gaf, het ligt aan je gehoor, maar ook aan je apparatuur.
Het verschil tussen 192 kbit mp3 met de laatste lame encoder en de originele wav is nauwelijks te horen.
Op 128 kbit is het soms nog net te doen als je een goede koptelefoon hebt en speciale wave file maakt die gemaakt zijn juist om het verschil te laten horen.
Maar goed ik dacht vroeger ook zo. Al mijn eigen muziek moest 192Khz 32bit FLAC zijn want andere is mijn kwaliteit niet de hoogste mogelijke? Maar nu denk ik al lang niet meer zo. mp3 op 192 doet het prima. Soms 320. En meestal AAC of andere codecs die hogere kwaliteit leveren bij lager bitrate.
Voor mijn eigen muziek gebruik ik inter gewoon 44,1 Khz wav op 32 bit en soms 16 bit. Een hogere bitrate is handig dat je dan kunt up en downsamplen zonder aliaing.
Tracks die naar een andere studio moeten? Wave files of flac files in een zip bestandje.
Tracks voor soundcloud? Ik upload meestal in wav want anders word de wav twee keer omgezet in mp3, een keer door mij en een keer door soundcloud.
Maar soms als het niet de hoogste kwaliteit moet zijn omdat het niet een afgewerkt product is upload ik gewoon een mp3tje. Het leuke aan mp3 is dat het formaat zo gigantisch goed ondersteunt word. Het minder leuke is dat er andere codecs zijn die het beter doen en als die nu zo goed als mp3 ondersteunt zouden worden zou helemaal fantastisch zijn.
Ikzelf hoor het verschil tussen flac en 320 mp3 wel
Dan behoor je tot de top 5 van mensen met de allerbeste oren in de wereld en moet je in een muziek studio gaan werken. Maar ik wil heus wel een wedje maken met wat crypto dat als we een dubbleblinde test doen dat er dan van je claim absoluut niks overblijft.
Probeer eens ReplayGain-informatie te berekenen en dan af te spelen met een functie om clipping te voorkomen m.b.v. de peak-info uit de ReplayGain-tags. Kan bij MusicBee, foobar2000, etc. Dan weet je iig of 't gewoon aan clipping ligt of niet.
Euh, nee. Als iets geclipt is in een opname (of na een compressie slag) ga je dit niet meer ongedaan maken door het output volume aan te passen. Dat werkt alleen als het aan de uitgang clipt, maar dat heeft dan weer niets met mp3/flac/pcm te maken.
Euh, nee. Als iets geclipt is in een opname (of na een compressie slag) ga je dit niet meer ongedaan maken door het output volume aan te passen.
Dat is niet het probleem.
Door het coderen naar MP3 kunnen golfvormen soms hoger uitkomen dan in het origineel (zonder dat het bijdraagt aan het gemiddelde nivo).
Als je je origineel (volkomen onnodig) tegen de 0dBfs hebt genormalized dan kan de MP3 die je ervan maakt op sommige plekken boven de 0dBFS uitkomen en dan krijg je clipping bij het afspelen van die MP3.
Sterker nog, dit kan zelfs gebeuren met Wav. Dan heet het intersample peaks, zoek maar eens op.
Aan te raden is om een willekeurige perceptuele coder (bv MP3) wat meer headrtoom te geven en het dus bestanden te voeren die een paar dB onder 0dBFS zijn genormaliseerd.
En vanwege de intersample peaks is het ook niet echt aan te raden om je ongecomprimeerde audio naar 0dBFS te normaliseren.
Natuurlijk is het mogelijk dat bij de compressie je uitkomt op waardes die gaan clippen (zeker met muziek die tegenwoording plat gecomprimeerd word -let wel: dynamische compressie in dit geval), maar zoveel dat je het hoort kraken heb ik volgens mij nog nooit gezien.
Maar dit staat los van mijn comment, guillaume geeft aan de clipping weer 'terug te draaien' door op een lager volume uit te sturen, en dat kan natuurlijk niet.
Ja het komt regelmatig voor en sommige codecs staan erom bekend.
Na codering kan het dan zijn dat de gecodeerde file een groter dynamisch bereik heeft dan het uitgangsformaat bij decodering.
Je kunt dan clipping krijgen bij afspelen.
Dit is op zich (buiten het verlagen van nivo voor het coderen) op te lossen door in de decoder het dynamisch bereik om te rekenen. En als de decoder rendert naar 32 bit floats dan kun je het zelfs na de codec terugnemen.
Achteraf dus, maar dat geldt dus alleen voor dit probleem.
In veel gevallen valt het niet op maar soms is het ernstig hoorbaar. Het is erg materiaalgevoelig
Ja het komt regelmatig voor en sommige codecs staan erom bekend.
Interessant, ik ben het nog niet zoveel tegengekomen.
En als de decoder rendert naar 32 bit floats dan kun je het zelfs na de codec terugnemen.
Achteraf dus, maar dat geldt dus alleen voor dit probleem.
Clipping is clipping, of dit nu in 16 bit int of 32 bit float domein is; omrekenen tijdens het coderen zal geen zin hebben als je het volume niet aanpast voor coderen.
Clipping is clipping, of dit nu in 16 bit int of 32 bit float domein is; omrekenen tijdens het coderen zal geen zin hebben als je het volume niet aanpast voor coderen.
Ja, maar er is dus nog niks geclipped totdat het ergens bij het afspelen niet meer past.
Kijk, op zich zijn de meeste DACs Integer dingen. Die snappen niks van floats.
Wat er dan de afgelopen pakumbeet 20 jaar werd gedaan is het geluid coderen in de mantissa van een 32 bit floating point.
Deze mantissa is 24 bits en als je het hele getal onder de 1.0 houdt dan gedraagt dit zich als een 24 bit integer.
Hierdoor zijn veelvoorkomende audio streams op computers van het type 32 bit float die dan als het getal boven de 1.0 uitkomt zullen leiden tot clipping op de DACs.
O.a. Asio hanteert dit formaat, maar volgens mij is het bijna alomvertegenwoordigd.
En dat is dus ook wat het audiosubsysteem van je pc verwacht. Het hele signaal onder de 1.0f. En dat dus terwijl een float theoretisch in de 10^38 kan coderen (volgens wikipedia).
Dit is bijvoorbeeld ook hoe de meeste DAWs werken.
Je kunt rustig de boel 'oversturen' op de individuele kanalen en dan is er niks aan de hand, geen clipping zolang je het op de masterbus weer terugneemt.
Maar als het masterkanaall clipt dan clippen je converters ook en ben je de sjaak.
En het probleem is dus dat sommige decoders aan het eind soms samples overhouden die boven de 1.0 liggen. Voer het aan de driver en CliP!!
Er zijn overigens uitzonderingen hierop, maar dat zijn dus uitzonderingen.
Waar het precies aan ligt durf ik nu niet te zeggen. Kan door vanalles komen, slechte filtering, slechte kwantisering...
Nou ja, inherent bakt een lossy codec natuurlijk fouten in en als de samples dicht bij 0dBFS liggen en de fout is naar boven toe dan heb je snel al een clip te pakken.
Ah, op die fiets, hetzelfde idee als 16bit audio in 24bit opslaan zonder het om te rekenen naar 24bit domein. Zo had ik er nog niet naar gekeken.
Wel leuk idd als je een bus hebt waar nog meerdere kanalen bijkomen en je aan het eind nog een master hebt, in geval van één kanaal (links of rechts van een stereo signaal) heb je er idd niet zo veel aan. Niet echt een oplossing dus. Eigenlijk verwacht je gewoon van een encoder dat hij hier rekening mee houdt en zorgt dat het niet gebeurt. Dus terug bij de concert kraken of komt door een eigen fout, of door een slechte codec :-)
ASIO heeft trouwens niet één formaat, er zit in de driver een mechanisme waarmee hardware kan aangeven in welk formaat ze hardware willen hebben, daarbij kan de hardware kiezen uit een vooral gedefinieerde lijst.
Clipping kan prima, zeker als de invoer tegen de 0dBfs aanligt.
Ik zou bijna durven zeggen dat dit hetgeen is dat het meeste fout gaat bij het coderen van een MP3.
Dat heeft niks met clipping te maken. Als er clipping in het orginele wav bestand zit dan komt het ook in je mp3 natuurlijk. Je krijgt absoluut geen clipping door het omzetten van wav naar mp3.
Je krijgt absoluut geen clipping door het omzetten van wav naar mp3.
Dat heb ik ook nergens gezegd.
Wat er geclipt raakt is de uitgang van de decoder, of eigenlijk, meestal de driver van de audio interface.
Ik heb dit in een andere post uitgebreid uitgelegd.
Hangt uiteraard van de codec af die niet gestandaardiseerd is, enkel het decoderen is gestandaardiseerd, maar goed mp3 is al zo oud denk niet dat er veel slechte codeerders in omloop zijn
Dan is er ofwel iets fout gegaan bij het encoden van je MP3, of bij het afspelen. Als hij 'kraakt aan alle kanten' dan is er waarschijnlijk ergens clipping. Of het bestand is beschadigd.
Nou FLAC is niet beter. Een gemiddeld persoon hoort het verschil niet
Dat de gemiddelde gebruiker het verschil niet hoort op een 200 euro Android zegt dat niet veel over dat het 'beter' is he? Dezelfde gemiddelde persoon zal het verschil ZEKER horen op een high end audio systeem.
Het kan zijn dat jij dat niet hoort, niet iedereen heeft een gehoor dat kleinere nuances kan horen. Heeft niets te maken met het formaat maar met genen.
Ik raad iedereen altijd aan om dingen op te slaan met zo min mogelijk compressie. Ik heb 20 jaar oude video die ik destijds opgeslagen heb voor de destijds gangbare resoluties. Je wilt niet weten hoe dat eruit ziet op 4K.
Dat de gemiddelde gebruiker het verschil niet hoort op een 200 euro Android zegt dat niet veel over dat het 'beter' is he? Dezelfde gemiddelde persoon zal het verschil ZEKER horen op een high end audio systeem.
Waarschijnlijk is het eerder andersom, hoor
Een high end systeem laat het perceptuele deel van de MP3 codec juist beter werken.
Een slecht systeem kan de auditieve maskeringen die plaatsvinden in lossy codecs juist blootleggen.
Als je de bitrate hoog genoeg zet zal er niets verloren gaan. Ik heb zelf al een mp3 codec geschreven en al veel er mee gespeeld, als je de verschillende frequentiebanden voldoende bits geeft zal er uiteindelijk exact hetzelfde uitkomen, tenminste als je bij de short term power spectrum ook voldoende coëfficiënten gebruikt en daar geen afrondingsfouten gebeuren.
Trouwens het encoder gedeelte ligt helemaal niet vast (dus per definitie is onzin) , enkel het decoden is gestandaardiseerd
Dan zou je moeten weten dat je onzin praat. Het model van MP3 splitst je geluid op in banden en probeert elk van die banden met een minimaal aantal bits te encoden en minimaliseert het aantal bits met een psycho-akoestisch model wat probeert te voorspellen welke band op welk moment in welke mate hoorbaar is. Zelfs met maximale kwaliteit en minimale compressie luister je nog altijd naar een recreatie van geluid. Daar gaat op geen enkele manier een bit-voor-bit nauwkeurige kopie van het origineel uitkomen. En een bit-voor-bit nauwkeurige exacte kopie van het origineel is wat FLAC je belooft.
Je kan zelf kiezen hoeveel bits je toekent (de encoder mag bij de bittoewijzing doen wat hij wil, waarbij meestal masking to noise ratio als criterium genomen wordt maar je mag even goed zeggen 1000 bits per band wat zwaar overkill is), en als de entropie van de bits aantal groter is dan de entropie van alle info met wat marge omdat de informatie niet uniform per band verdeeld is, dan komt er hetzelfde uit, tenminste als het opsplitsen in banden reversibel is. Mathematisch is dit reversibel (met oneindig coëfficiënten) , dus als je ook daar voldoende coëfficiënten gebruikt in de FIR filters zal het lukken, wat ligt aan het feit dat bij klassieke PCM of DPCM bv. 8 bit kwantisatie gebruikt wordt en dus ook daar afgerond wordt. Is het nuttig? Nee... Maar onmogelijk zeker niet
Is het gegarandeerd bit-voor-bit identiek aan het origineel?
Inmiddels zit je met een veel hogere bitrate dan je originele FLAC en bijna oneindig veel coëfficiënten in je bijna oneindig complexe filters, maar kun je garanderen dat je lossy codec altijd exact dezelfde bits uitspuugt als FLAC? Want dat is de definitie van lossless.
Vanaf bepaalde thresholds wel... Maar die is uiteraard voor elke mp3 file anders... Dus zal de encoder iteratief te werk moeten gaan... Maar goed laten we deze discussie beeindigen wil je losless gaan gebruik FLAC en geen mp3... Want dat laatste is onnozel en uiteindelijk zeker niet kleiner dan de FLAC file
De golfvorm zal hoogstwaarschijnlijk niet bit voor bit gelijk zijn, maar de eventuele storingen in het analoge deel van je audio apparatuur zouden wel eens groter kunnen zijn, zelfs bij een high end systeem.
De golfvorm zal hoogstwaarschijnlijk niet bit voor bit gelijk zijn,
Jawel, wel als je genoeg bits gbruikt.
Alleen compress je dan eigenlijk niet meer, je ben alleen de manier waarop je de informatie opslaat aan het veranderen.
Let op, dit is dus vooral een theoretische oefening omdat je dan geen voordeel meer hebt van het omzetten. Je gooit dan eigenlijk geen informatie meer weg en dus wordt het niet kleiner. Nutteloos, zoals aldieaccounts al aangaf.
Dat is het bullshit. Jij beweert dat je dus een wav bestand kunt nemen er een mp3 van kunt maken van die mp3 terug wav en dan een bestand krijgt dat bit per bit gelijk is?
Ja... Maar enkel met een brave encoder (die niets wegsmijt, maw enkel wederkerige transformaties uitvoert) die veel te veel bij houdt om afrondingsfouten te vermijden (veel bits per band en veel coëfficiënten bij de filters met veel padding, ok weet niet meer zeker of er daar limieten zijn in de mp3 standaard desnoods moeten er trucen zoals overlap add en overlap subtract toegepast worden). Van compressie zal er helemaal geen sprake zijn in tegendeel...en of het in de praktijk mogelijk is zou ik eens moeten testen. Is een beetje vergelijkbaar met de fouriertransformatie die wederkerig is, maar ook slechts in de limiet naar oneindig... Maar door dat een pc toch naar bv. 8 bits afrond lijkt het me wel mogelijk. Maar met typische encoders die op de markt zijn moet je het niet proberen die zullen altijd noise to mask ratio en andere heuristieken gebruiken om bits weg te smijten, zelfs al zet je de bitrate heel hoog...
Een gemiddeld persoon hoort het verschil niet net zoals je het verschil niet ziet tussen JPG en RAW.
Iedereen met normale ogen ziet verschil tussen JPG en RAW (danwel een optimale afgeleide van die RAW. Wat bij die JPG niet mogelijk is; daar is het gros van je beelddata weggegooid. Je kunt daar niet meer iets visueel beters uit afleiden).
[Reactie gewijzigd door kimborntobewild op 22 juli 2024 15:56]
Dan is er iets goed mis met je oren
Tenzij je oordopjes, boxen of een headset van de action gebruikt.
Zelf produceer ik muziek met ableton live, en hoor echt een duidelijk verschil. Op het blote oog zie je alleen al een verschil (sound waves zijn veel gladder tov. Mp3 wat haast een trap lijkt), laat staan horen
Dat is nogal een uitspraak, met naar waves kijken is het erg lastig om iets te zeggen over audio, omdat je over het algemeen flink uitgezoomt kijkt, en de software dus aan alle kanten samples aan het middelen is, ik geloof best dat je verschil ziet, maar wat betekend dat? En kan je eens een voorbeeld van zo'n trap posten? Ben wel benieuwd.
Over verschil horen, als er ergens een goede (blinde) test opgezet wordt met 'professionele' oren blijkt vaak dat het verschil bijna nooit te duiden is. Hoe zorg jij ervoor dat je niet in de standaard vallen trapt? Hoe heb je dit blind getest?
Ik betwijfel enorm of er iemand verschil zou horen, daarbij geen antwoord op de vraag.
Het flauwe van (digitale) audio is dat de techniek erachter ingewikkelder is dan je zou denken zo wordt er bijvoorbeeld vaak een vergelijk gemaakt tussen digitale audio en digitale video ("bij een foto zie je het als het niet high red is, daarom hoor je het ook bij audio"); op deze manier wordt er zeer regelmatig flink foute conclusies getrokken.
Daarbij moet je zo enorm opletten bij het beoordelen van audio met je oren dat je niet beïnvloed wordt door van alles en nog wat, je oren staan zo ontzettend ver weg van absolute meetinstrumenten, als iemand iets met zijn gehoor vaststelt zonder hier aandacht aan te hebben besteed kan je hier eigenlijk niets mee, niet (dubbel)blind getest = niet getest.
Ik geef je gelijk, maar dat verschil komt omdat MP3 voor het gemak erg lage tonen weglaat (omdat a. de meeste (thuis) speakers en koptelefoons dat niet kunnen weergeven en b. de meeste muziek hier niet veel energie heeft).
Laat de bass genres daar een grote uitzondering op zijn
MP3 zal bij een deel van de nummers de bas enorm verzieken.
Daarnaast blaas je eventuele artefacten ook met hoge luidheid de zaal in, dat zal niet bevorderlijk zijn voor de ervaring.
Verder is het ook zo dat mensen anders gaan horen afhankelijk van de luidheid.
MP3 is gemaakt, gefinetuned, voor normaal thuisgebruik. Bij extreme luidheid kan het formaat een beetje uit elkaar gaan vallen.
MP3 neemt aan dat je bepaalde dingen niet hoort bij een normale luidheid omdat deze dingen worden 'afgedekt' door andere geluiden ervoor of erna. Het luid afspelen kan deze 'dekking' deels ongedaan maken.
Er zijn dus goede redenen om niet met lossy codecs voor een zaal te gaan staan, al wordt het wel gedaan.
Zelf vind ik het over het algemeen ruk klinken.
Deze vind ik wel interessant en wist ik niet, dus ik heb even een testje gedaan.
Stukje roze ruis op 44.1kHz gegenereerd, en deze gecomprimeerd als mp3 met 128, 160, 256 en 320 kbps.
Daarna dit weer terug naar PCM en dat dan met een FFT analyseren.
Je ziet heel mooi de low pass bij de verschillende bit rates (128 kbps 17k; 160 kbps 18k; 256kbps 20k en 320 kbps 20.5) en die had ik ook wel verwacht.
Aan de onderkant zie ik totaal geen verschil, de door jou genoemde high pass zie ik helemaal niet terug.
Waar komt jou info vandaan dat mp3 lage tonen weglaat?
Dat hangt maar helemaal af van de MP3 encoder die gebruikt is. Als je MP3s maakt speciaal voor afspelen op een telefoon, kan ik me voorstellen dat je de lage tonen er uit filtert om ruimte te besparen.
Ik kan het fout hebben hoor, maar ik meende dat veel coders de boel wat hoger afsnijden dan normaal om
bandbreedte te sparen. In ieder geval worden de bassen met minder bits gecodeerd dan andere gebieden maar dat is al bepaald in de kwantiseringsmatrix.
Maar zoals aldieaccounts hier ook al zegt, dat kan met de coder te maken hebben.
Verder kan ik niet zoveel zeggen over je meting. FFT kan erg onnauwkeurig zijn aan de onderkant. En er kan ook vanalles mis zijn met je ruissignaal.
Maar ik ga zelf ook wat testjes doen.
Uit nieuwsgierigheid, welke coder gebruikte je?
Heb een testje gedaan.
Sub frequenties blijven wonder boven wonder bestaan (was jou al opgevallen), zelfs onder de 10Hz. Lame filtert (iig. met de standaard instellingen) inderdaad geen laag weg.
Wat me wel opviel is dat er enorm veel ruis bijkwam in het laag.
De ruis in dat gebied (ik heb specifiek gekeken naar 0~60Hz) was na het coderen ergens rond de -50dBFS.
[Reactie gewijzigd door koelpasta op 22 juli 2024 15:56]
Heh, nee, nog niet.
Zal dat vandaag mischien nog even doen.
Wel jammer dat ik hier geen andere coders heb liggen om te testen.
Ben wel benieuwd waar ik dat verhaal van de highpass zal tegenkomen
Ben wel benieuwd waar ik dat verhaal van de highpass zal tegenkomen
Ik denk helemaal niet; ik heb er iig nog nooit van gehoord, misschien hele specifieke toepassingen, zoals encoden voor een telefoon oid, maar ik vraag me af of dat serieus bestaat / gedaan wordt.
Wat een uitspraak over de sound waves. Ik ben zelf al 20 jaar bezig met het produceren van muziek en die waveforms die zichtbaar zijn, zeggen compleet niks eigenlijk.
Wanneer ik hetzelfde bestand in drie verschillende DAW's open, zie ik drie keer verschillen in de waveforms
Op het blote oog zie je alleen al een verschil (sound waves zijn veel gladder tov. Mp3 wat haast een trap lijkt), laat staan horen
Dit is absoluut niet wat MP3 met golfvormen doet.
Sterker nog, de golvform van een MP3 zal juist gladder zijn omdat er details worden weggegooid!!
Je hebt denk ik ook niet goed genoeg gekeken. Alle samples zullen bij inzoomen 'stappen' laten zien, ook in ableton.
Deze stapjes horen bij het samplingproces en worden bij het analoogmaken van de audio gladgemaakt. Bij dat analoog maken word pas de echte golfvorm gereconstrueerd. Voor het analoogmaken zijn alle samples losse, niet continue waardes. Stapjes dus.
Wat je ook ziet, ik denk dat het weinig met MP3 zelf te maken heeft.
Op het blote oog zie je alleen al een verschil (sound waves zijn veel gladder tov. Mp3 wat haast een trap lijkt)
Wat een onzin; dat is helemaal niet hoe MP3 werkt; de sample resolutie is gewoon nog steeds het volledige bereik en niet (meer) quantized (dan anders). Ik denk dat dat tussen je oren zit Dat je het verschil hoort wil ik wel geloven maar het zien aan waveforms is nuts.
[Reactie gewijzigd door RobIII op 22 juli 2024 15:56]
Je moet je echt eens inlezen hoe je van een analog continue signaal naar een digitaal signal kan gaan zonder dat er informatie verloren gaat.
bemonsteringstheorema van Nyquist-Shannon is een fundamentele stelling in de informatietheorie.
Harry Nyquist bewees in 1928 dat, wanneer een analoog signaal naar een tijddiscreet signaal wordt geconverteerd, de bemonsteringsfrequentie minstens tweemaal zo hoog moet zijn als de hoogste in het signaal aanwezige frequentie om het origineel zonder fouten te kunnen reproduceren. De helft van de bemonsteringsfrequentie heet de nyquistfrequentie. Anders gezegd: voor een foutloze reproductie na bemonstering mag het analoge signaal geen frequenties bevatten hoger dan de nyquistfrequentie.
De tijd tussen de bemonsteringen wordt het nyquistinterval genoemd.
Als een signaal bemonsterd wordt en er komen frequenties in voor hoger dan de nyquistfrequentie, resulteert dit in een "teruggevouwen" signaal waarvan de frequentie beneden de nyquistfrequentie is. Deze fout, c.q. vervorming van het signaal, wordt aliasing genoemd. Om dit te voorkomen, moet het bemonsteringssysteem voorzien zijn van een anti-aliasing filter. Dit is een analoog laagdoorlaat-filter dat signalen met frequenties hoger dan de nyquistfrequentie uit het ingangssignaal verwijdert. Men kan ook bewust van dit vouweffect gebruikmaken om de frequentie van een signaal naar beneden te brengen: zo zal een signaal met een frequentie van 12 kHz dat op 20 kHz bemonsterd wordt, hetzelfde lijken als de bemonstering van een 8 kHz ingangssignaal (De 12 kHz vouwt om de 10 kHz nyquistfrequentie). Dit geeft een probleem als het ingangssignaal componenten met zowel 8 kHz als 12 kHz bevat; in dat geval is uit het bemonsterde signaal niet meer op te maken wat van de 8 kHz en 12 kHz afkomstig is.
Het door Nyquist opgestelde theorema houdt geen rekening met ruis na conversie naar het discrete domein. Claude Shannon breidde in 1949 de theorie uit door wel rekening te houden met de beperking veroorzaakt door ruis. Hij stelde de wet van Shannon-Hartley op voor de maximale informatiecapaciteit van een bandbreedtegelimiteerd kanaal met ruis.
Hoewel het bemonsteringstheorema van Nyquist-Shannon meestal in één adem met digitale informatie wordt genoemd, is het geldig in alle systemen waar bemonsterd wordt.
In technisch Nederlands wordt voor bemonstering ook wel het woord samplen (naar het Engelse sampling) gebruikt.
En het feit dat je niet met je oren luister maar met je hersenen. Daarom dat mp3 werkt. mp3 probeert de info weg te gooien die je brein toch sowieso al weggooit. Dat heet https://en.wikipedia.org/wiki/Psychoacoustics
Mee eens, ook ben ik van mening dat bij Audio formaten er eigenlijk ook helemaal niet zo'n ontzettende ontwikkeling is geweest. AAC, OGG en FLAC zijn nooit zo mainstream geworden als MP3, waarbij FLAC ook gewoon een andere doelgroep bediend. De grootste concurrent van MP3 waren/zijn streaming diensten zoals Spotify. (waarvan ik eerlijkheidshalve moet bekennen dat ik niet weet wat voor formaat zij gebruiken)
But please correct me if I'm wrong.
Spotify gebruikt Volgensmij een implementatie van OGG en Apple gebruikt een implementatie van AAC voor hun streamingdienst
Ps. Andere formats na mp3 werden niet populair omdat die allemaal goed uitgewerkt implementaties hebbben voor drm. Drm werkte niet goed in mp3 en was makkelijk te verwijderen, daarom is het perfect voor de thuispiraat. Ook zijn de ruimte besparingen minimaal vergeleken met mp3
[Reactie gewijzigd door mikesmit op 22 juli 2024 15:56]
Het verschil is wel dat mp3 al die jaren enorm is doorontwikkeld. Een 128 bps mp3’tje uit het Napstertijdperk en eentje die je vandaag met Lame codeert, klinken heel anders. Jpeg blijft om een of andere reden enorm brak.
Als Google en Apple het nou eens eens zouden worden over een opvolger, volgt de rest vanzelf. Samen hebben die zo veel macht. Maar zelfs Google, dat miljoenen zou kunnen besparen op bandbreedte als WebP gemeengoed werd, lijkt er niet echt druk achter te zetten. Anders zou je wel verwachten dat Google een paar ontwikkelaars inzet om WebP-ondersteuning in browsers zoals Firefox te krijgen.
Jpeg heeft geen problemen behalve een nogal oude geboortedatum.. Het voldoet aan de wensen dus een andere standaard is geen oplossing... om het feit dat er geen problemen zijn met Jpeg. Alles wat Jpeg niet kan, wordt ondervangen door Png en Gif in de gevallen van websites.
En het gemak waarmee foto's van een camera zonder enige vorm van conversie naar het internet kunnen gaan is gewoon geweldig. Ok misschien wat compressie maar dat wordt ook al heel vaak server side opgelost.
Het enige nadeel is in mijn eigen beleving dat alle informatie na compressie verloren gaat en dat er dus geen weg meer terug is naar de oorspronkelijke kwaliteit.. Ik weet het, dit is meer wisfull thinking en beslist niet realistisch..
Maar goed: Jpeg is een blijvertje. Over 50 jaar is het er nog net als bier: eeuwen oud en inmiddels ingehaald door veel lekkerdere drankjes qua smaak, maar nog altijd de standaard.. /twist over smaak
Het hele artikel gaat over de problemen die de jpeg - compressie heeft!
De geboortedatum is geen probleem, maar de compressie zelf is het probleem. De digitale camera's zijn technisch zo vooruitgegaan dat jpeg de bottleneck is gaan vormen voor de beeldkwaliteit. Steeds meer camera's kunnen ook in raw format opslaan. Waar dat voorheen voorbehouden was aan de duurste typen, zie je dat nu al in het middensegment. Zelfs in smartphones begint het raw-format al aan een opmars.
Jpeg, png en gif kunnen gewoon niet de kwaliteit benaderen die als wenselijk kan worden bestempeld. Nu bevat een foto (in raw) meer pixels en kleurdiepte dan een scherm kan weergeven. Voordat een foto zichtbaar werd kwam er dus altijd nog een verkleining aan te pas. De schermen krijgen echter een steeds hogere resolutie en kleurdiepte. De artefacten van de jpeg compressie op een foto genomen met een oude 5mp camera zijn daardoor nu goed zichtbaar op een moderne monitor.
Al die compressie technieken zijn natuurlijk ontstaan door de beperkingen van data opslag en bandbreedte uit het verleden.
Nu deze beperkingen steeds meer opgerekt worden ontstaat de behoefte om de kwaliteit omhoog te gooien. De noodzaak van zware compressie is gewoon niet meer zo aan de orde.
De camera's maken inderdaad die beweging naar lossles/raw en daar zal het bij blijven naar mijns inziens omdat het belangrijkste medium waar foto's nu worden bekeken nu het Internet is waar nog lang niet iedereen breedband heeft en we niet willen wachten op een telegraaf.nl pagina met allerlei RAW foto's op de voorpagina. En helemaal al niet op je data bundel..
Voordat Jpeg vervangen zal worden in een revolutie ipv evolutie zal er een wonderbaarlijk nieuw bestandsformaat bedacht moeten worden die in een keer alles oplost wat Jpeg nu minder goed doet..
Jpeg zal blijven bestaan net als 320kbps MP3 en bier!
[Reactie gewijzigd door Liberteque op 22 juli 2024 15:56]
Jpeg zal nog wel een tijdje blijven bestaan, net als mp3. Het zijn standaarden geworden waar we niet meer van af komen, maar dat betekend niet dat er behoefte is aan beter. Voor MP3 is FLAC als beter alternatief algemeen aanvaard (of je de verschillen hoort doet er hier niet toe). Voor jpeg is er ook een verbeterd alternatief nodig. Die standaarden kunnen best naast elkaar blijven bestaan.
De redactie heeft de ontwikkelingen in België niet goed gevolgd zoals @Dooievriendhttps://tweakers.net/revi...ction=11770383#r_11770383 al opmerkte.
Het FLIF-format lost in potentie eigenlijk alle problemen in een keer op. Dit verdient eigenlijk meer aandacht.
Dat er bestand op de loer ligt op Jpeg te vervangen geloof ik maar al te graag, maar of dat in de praktijk ook zal gebeuren? Dat zou nog eens heel lang kunnen duren.
Het internet speelt een centrale rol in deze. Het Internet staat vol met vele honderden miljarden plaatjes en foto's. Alleen al in 2014 werden er bijna 700 miljard foto's geüpload en dat wordt alleen maar veel en veel meer..
Ook webdesigners houden de cultuur van Jpeg in stand. Het is nog steeds belangrijk dat websites snel laden en dat doet Jpeg gewoon afdoende. En een hoge kwaliteit Jpeg ziet er gewoon goed uit ook op grote schermen.
Bij 4K of 8K weet ik dit niet, maar zoals die gemene minnares ooit zei: "Alles kan stuk".
Als ik een RAW foto opblaas naar 50x50 meter zie je ook artefacten..
Wat webdesigners ook doen is dat zij altijd heel veel afbeeldingen recyclen van het Internet zoals foto's, achtergronden, buttons en tiles. Er zijn er maar weinig die alle grafische content from scratch opbouwen. En als ze dat al doen slaan ze het vaak op als Jpeg, zetten het op de webserver en zo is die cirkel ook weer gesloten..
De toolbox van de webdesigner zit aardig gevuld met Jpeg, GIF en PNG. Meer heeft ie gewoon niet nodig en een eventueel nieuw bestandsformaat zal wel hele zwaarwegende voordelen moeten hebben wil hij/zij overstappen.. Kan dit overtuigend plaatsvinden dat kan het in een paar maanden doorbreken.. Maar alleen als alle politics en licenties soepel meewerken..
Jij zegt dat jpeg afdoende is, maar bij een tegenlicht-foto is dat nog de vraag. Meer kleurdiepte maakt echt een verschil in de donkere of lichte vlakken.
Het gaat erom dat alle grote browsers het ondersteunen, en de grote besturingssystemen, en dan nog Photoshop. Als vervolgens de camera's in de telefoons standaard in het nieuwe format gaan fotograferen, zullen ook Nikon en Canon volgen. Het publiek gaat vanzelf mee als dit voorgeconfigureerd is, en als het werkt. Daar gaat een paar jaar overheen, en je moet zo'n nieuw format niet meteen de standaard maken, maar eerst wachten totdat je zeker weet dat het ook veilig uitgewisseld kan worden via whatsapp etc.
Enige probleem is om Apple, MS, Google, Mozilla en Adobe bijelkaar te krijgen. Zij kunnen het verschil maken.
Bij 4K of 8K weet ik dit niet, maar zoals die gemene minnares ooit zei: "Alles kan stuk".
Als ik een RAW foto opblaas naar 50x50 meter zie je ook artefacten..
Als je een RAW opblaast naar 50x50 meter is je publiek kilometers verderop te zoeken. Niemand gaat van dichtbij naar een poster van een half voetbalveld groot kijken. Je komt dan prima weg met pixels ter grootte van een voetbal..
(Ooit, toen ik jong was en net van school kwam, drukte ik hele grote billboards. 12 x 6 meter. Pixels zo groot als (ik zei dat het lang geleden was..) kwartjes, maar langs de snelweg zie jij dat er niet aan af:https://goo.gl/maps/eVS5SN9i6mB2 )
FLAC is echt geen 'beter alternatief' voor MP3. Ogg is dat wel. Of wellicht Opus.
FLAC heeft een heel ander doel dan MP3. Flac is voor muziek wat png is voor een plaatje. Als jij al de audiodata van een game als The Witcher als flac gaat opslaan (en de image data als png), dan zijn de spelers niet bepaald blij met de grootte van de download. (Veel games gebruiken dan ook OGG).
Ik bedoel meer dat het doel van MP3 en FLAC niet gelijk is. FLAC is een (beter) alternatief voor WAV. Maar niet voor MP3, want het hoofddoel van MP3 is acceptabele geluidskwaliteit in een zo klein mogelijk bestand en flac is nou eenmaal altijd beduidend groter, want het doel van FLAC is zo klein mogelijk *lossless*. Opus richt zich daar wel op (en Ogg is nu al iets beter dan MP3 op datzelfde gebied).
Voordat Jpeg vervangen zal worden in een revolutie ipv evolutie zal er een wonderbaarlijk nieuw bestandsformaat bedacht moeten worden die in een keer alles oplost wat Jpeg nu minder goed doet..
Dat bestandsformaat is er, en heet Flif.
Dit lost in één keer alles beter op, ten opzichte van zowel Jpeg als PNG.
Het is hier al een paar keer genoemd in andere reacties, het Flif formaat verdient absoluut een plaats in het lijstje kandidaten voor bestandsformaten van de toekomst (en wat mij betreft zelfs de eerste plaats).
Dan heb je niet veel aan een TV met HDR en kleuren diepte. die houd gewoon op bij de 8bits van Jpeg.
Ook nieuwe processoren (op alle gebieden) maken het mogelijk om zwaardere berekeningen te laten doen.
Reden genoeg voor een verbetering
Jpeg, png en gif kunnen gewoon niet de kwaliteit benaderen die als wenselijk kan worden bestempeld.
Dat kan PNG wel degelijk, of is 16 bit per channel, praktisch ongelimiteerde pixel count, en lossless compressie (dus geen artefacts) niet goed genoeg?
Natuurlijk is PNG ongeschikt als camera-storage, vooral omdat de bestanden door de lossless compressie veel groter zijn dan nodig voor foto's, maar ook wel door de compressie-snelheid. Maar met de kwaliteit heeft het niks te maken.
Het zou toch mooi zijn dat je diezelfde ervaring hebt met een nieuw, en verbeterde bestandsextensie die ook overal supported is.
Je trekt een losless foto die xx% kleiner is, zwiert die op het internet zonder dat daar op een server nog een conversion nodig is om nog wat data uit te sparen (behalve als ze de foto's comprimeren voor nog minder dataopslag in ruil voor mindere kwaliteit) . 1 extensie voor al je transparantie,... benodigdheden.
[Reactie gewijzigd door SmokingCrop op 22 juli 2024 15:56]
"Jpeg heeft geen problemen behalve een nogal oude geboortedatum.. Het voldoet aan de wensen dus een andere standaard is geen oplossing."
Oneens want de wensen worden gevormd door de standaard en zijn beperkingen.
Met andere woorden: Indien de standard losless 14-bit color depth was en iedereen een gekalibreerde HDR OLED monitor had om dit te bekijken, dan was dat de nieuwe wens, en een fenomenaal probleem.
Maar dat is niet zo. Het voldoet niet aan onze wensen, we weten niet beter en een gemiddeld persoon zal de superieure alternatieven nooit ervaren, dus kun je niet weten wat de wensen zijn. Het is niet zo dat we massaal democratisch de alternatieven naast elkaar hebben gelegd en gestemd: "ja, dit vinden we nou goed genoeg".
Uit het artikel vind ik de zin "Wat minder fijn is, is dat de standaard sindsdien nauwelijks is veranderd." zo ongeveer de domste opmerking die ooit op Tweakers is neergeschreven, en het is tegelijk het grootste compliment voor JPEG: het is kennelijk de enige echteStandaard.
Men dient zich te realiseren dat er geen plak is voor 2 standaarden, dat is tegen de definitie van "standaard".
[Reactie gewijzigd door Bruin Poeper op 22 juli 2024 15:56]
Gisteren was er een discussie over het zogenaamde verouderde Jpeg formaat en binnen no time ging de discussie over MP3, Flac en bitrates.. Nou het regende gewoon +2
Zo vreselijk off topic was dat met een moderatie systeem dat niet meer te redden is en bij de laatste keer dat ik er over klaagde in de comments kreeg ik een mailtje thuis van Tweakers.net
Dan is het niet lekker ge-encode . Kleurverschillen zouden absoluut niet mogen .
De allereerste versies van x265 (populaire hevc encoder ) hadden wel moeite met kleine fijne details. Dus de look werd wat blurry vergeleken met _goede_ x264 encodes. Is ondertussen al geregeld
(en hevc blijft gewoon beter werken voor resoluties >1080p . De compressie winst van hevc neemt af met kleinere resoluties)
Veel mensen weten niet dat het coderen ook helemaal niet gestandaardiseerd is... Hevc bied zoveel mogelijkheden met variable blocksizes, intra coding met heel veel modes, allemaal verschillende inter coding hiërarchien, etc. De codec kan eender welke bitstream genereren die de decoder begrijpen kan (deze is gestandaardiseerd) , maar kan slechte keuzes gemaakt hebben waardoor het beeld minder is en daardoor wordt dan verkeerdelijk besloten dat de codec minder goed is... Je kan enkel iets zeggen over de gebruikte encoder met eventueel de gebruikte instellingen.
Het kan niet anders dan dat kleuren verschillen.
Het zijn lossy codecs die de kleurruimte ernstig kwantiseren (gelukkig zijn onze ogen niet erg gevoellig voor kleur). Hoeveel kleurverschil er in het resultaat terecht komt is afhankelijk van heel veel dingen.
En uiteindelijk is het enige doel bij dit soort consumentenformaten om de kleuren genoeg op het origineel te laten lijken zodat je het verschil niet merkt.
Das niet helemaal waar. Codecs gebruiken kleurreductie als deel van hun proces. Dat is dus zeker een eigenschap van een codec en verschillende codec gaan er anders mee om.
Maar met settings kun je daar weer controle over uitoefenen, afhankelijk van de codec. En dan zijn er andere dingen, zoals eisen aan de uiteindelijke bandbreedte, complexiteit van het beeld, etc, etc.
En al deze dingen zijn in meer of mindere maten vervlochten met elkaar. Je zult dus een balans moeten vinden die in dat specifieke geval tot het beste resultaat leidt.
Er komt dus ook heel veel menselijke interpretatie aan te pas.
Een bijkomend probleem is dat je bij het maken van die video's het origineel hebt om het mee te vergelijken.
Dan kun je vrij snel zien als een codec de kleuren aanpast om het makkelijker/beter te kunnen coderen.
Maar is dat wel zo'n probleem?
Iemand die enkel het gecodeerde filmpje ziet zal niet anders weten dan dat de kleur 'correct' is. Die valt het dus niet op dat de lucht een ander tintje blauw heeft, om een voorbeeld te noemen.
Dat terwijl als je het origineel er naast hebt het verschil vrij makkelijk te spotten is.
[Reactie gewijzigd door koelpasta op 22 juli 2024 15:56]
Veel hevc encodes zijn gedaan met gpu, en die loopt achter op de software variant...........veeeeeeeeeeel achter. Meestal uit tijdwinst. De gpu kant haalt 200fps tov van de software waar je ‘et beefy vomputer mss een 10de haalt of minder
Zo te lezen gebruiken Google en Apple al hun eigen standaard met meer compressie..? Dan vangen ze dus al het grootste deel van de markt af.. Dan zie ik eigenlijk weinig reden om als consument ook over te stappen want eigenlijk zijn ‘we’ al over dan toch?
[Reactie gewijzigd door D-Ed op 22 juli 2024 15:56]
Nee zo werkt het niet helemaal. Google en Apple bedienen alleen hun eigen ecosysteem momenteel met hun codecs en formats. Pas als zowel Google, Microsoft en Apple hetzelfde format/codec gebruiken kunnen we jpeg laten uitsterven.
De beslissing die Microsoft zal gaan maken in de toekomst over welke van de 2 codecs/formats het standaard zal gaan gebruiken zal bepalen welke de norm gaat worden. Dan zal Apple of Google uiteindelijk over stag gaan.
Yep, ik begrijp wat je zegt maar omdat zei samen zoveel bereik/massa hebben, ‘lijkt’ het alsof wij (consument) er geen keuze in hoeft te maken.. bv Apple zet zelf al de foto’s in JPEG om zodra je een foto wil plaatsen op bv Facebook oid.
Wij laten ook wel eens fotoboeken printen bij Albelli via de iPad en ook daar merken wij niet dat er een ander bestaan foto wordt gebruikt dus voor de eindgebruiker zal er naar mijn idee weinig veranderen..
Ik had begrepen dat die conversie in iOS op termijn weer zal verdwijnen waardoor apps de nieuwe formats en codecs native moeten ondersteunen. Dit zal het format/codec een enorme gebruiksboost geven buiten iOS/macOS.
Hoe Google webp wil gaan promoten weet ik momenteel niet. Maar het is duidelijk dat enkel het ontwikkelen van een nieuw format onvoldoende is om gebruikers te scharen.
Nope. Want nog geen enkele browser ondersteunt HEIF. Ook Safari niet, zowel op macOS als op iOS niet.
Dat is waar de bottleneck zit. Browsers moeten het eens worden en dat wordt lastig met HEIF/HEIC. Daar zit namelijk de MPEG groep achter, dezelfde groep achter HEVC en die willen graag centjes zien. De enige reden dat we tegenwoordig h264 ondersteuning hebben in alle browsers, is Cisco. Die hebben namelijk een gratis binary beschikbaar gesteld waarvoor zij alle royalties aan MPEG LA afdragen; zo kan Mozilla h264 ondersteuning in Firefox in bakken wanneer het OS dat niet ondersteunt (of die ondersteuning vrij geeft). Zij hebben veel goodwill verloren waardoor men op video gebied massaal achter AV1 is gaan staan. Tot een half jaar geleden zonder Apple, maar zelfs zij hebben zich daar nu bij aan gesloten.
Het zou me niets verbazen als men dat voor afbeeldingen ook doet, omdat AV1 toch al gebruikt wordt voor video.
Nee. Jpeg xl lijkt mij een goede vervanger voor de jpeg standaard wat standaard voor websites e.d. wordt gebruikt.
Het is noodzakelijk dat er een standaard formaat komt dat door alle webbrowsers e.d. wordt ondersteunt. Anders zit je zo weer met zoveel verschillende standaarden.
Ik had gehoopt op .svg als "the next big thing" op afbeeldingenformaat. Juist omdat het schaalbaar is, weinig ruimte inneemt als je het oorspronkelijke formaat klein houdt en de afbeelding niet vervormt bij schaling. Geen idee verder, maar blijkbaar kan dit niet bij camera's?
Laatst was ik op Windows 10 aan het werk met een map vol met duizenden Linux-iconen die ik wilde doorpluizen, op zoek naar een leuk vervangend icoon voor op mijn telefoon. Wat een drama was dat zeg! Zelfs programma's als XNview wilde .svg-afbeeldingen niet openen, ook niet na het wijzigen van wat instellingen die dat wel mogelijk zouden moeten maken. En de standaard afbeeldingenviewer in Windows weet er al helemaal geen raad mee. En om elke afbeelding te moeten openen in GIMP om er alleen maar naar te kijken is natuurlijk niet handig. Dat kost me tienduizenden handelingen. Snel dus Linux opgestart, en ik kon meteen de bestandsmap met duizenden iconen doorbladeren. Zoals het hoort.
Scalable Vector Graphics mag voor mij dé standaard worden vanwege alle voordelen die het heeft. Ik kan geen nadelen bedenken. Misschien kan iemand mij hierover bijpraten?
Maar kun je je voorstellen: een camera die .svg-bestanden gebruikt. Je kunt je foto dan schalen zo groot als jij dat wilt. Al wil je een foto zo groot als een voetbalveld: hij blijft scherp. Mits het kan hoor...
[Reactie gewijzigd door Qalo op 22 juli 2024 15:56]
Svg is een vector formaat en geen bitmap formaat. Het bestaat uit geometrische content (lijnen, vlakken, curven, enz) en geen pixels. Dat is totaal iets anders dan foto's en ook compleet ongeschikt om beelden van een digitale camera in op te slaan.
Bijna vergelijkbaar met het verschil tussen een boek opslaan in pdf (als tekst) versus mp3 (als audiobook). De aard van de content is fundamenteel anders. Zo ook tussen foto's en svg.
Tot zover begrijp ik het (en wist ik het ook al). Maar de output is een afbeelding. Het zou dan toch mogelijk moeten zijn om een camera op een dusdanige manier te ontwikkelen dat het vastgelegde beeld naar XML vertaald wordt en dan als .svg opgeslagen wordt? Het gaat 'm dan niet om de achterliggende technologie of methode, maar om de uiteindelijke output. En dat is dus een afbeelding.
Misschien is dit (foto's dus) voor het bestandsformaat nog teveel gevraagd (geen idee hoever men kan gaan met .svg), maar zeg nu zelf: het zou de meest ideale oplossing zijn die meteen alle afbeeldingsformaten overbodig maakt. Nooit meer artifacten, nooit meer gedonder met uitvergrotingen die steeds korreliger worden (vanwege de pixeltechniek). Gewoon een "esveegeetje" met zoveel dpi, en voilà... je kunt ermee doen wat je wilt. Fotootje van 10x15? Geen probleem? Oh, u wilt 'm afgedrukt hebben in een spandoekformaat? Geen punt. Zoiets?
Je kan in vectorprogramma 's zoals illustrator en inkscape een bitmap vertalen naar een vector tekening. Probeer dat eens. Serieus, je merkt dan heel goed waar vectoren goed voor zijn en waarvoor niet.
Vectoren gaan over vormen (polygonen enzo). Dit werkt over het algemeen het beste als je relatief simpele vormen hebt en met relatief weinig kleurgebruik.
Een camera sensor heeft een beperkt aantal pixels dat het waarneemt. Je zou (met pijn en moeite) dit op de camera kunnen vertalen naar een svg. Gezien de hoge mate van complexiteit van vorm en kleur in een typische foto, zou je een groot onhandig bestand krijgen. Verder inzoomen dan de raw/jpeg heeft geen zin, want de vector vertaling is gebasseerd op pixels en meer data heeft deze niet.
Een grotere foto krijg je door een grotere (of gevoeligere) sensor te gebruiken.
Waarschijnlijk kun je met een algoritme pixels verzinnen om een foto groter te maken, zonder dat deze pixelig wordt. Dat zal ook niet oneindig kunnen en waarschijnlijk zie je dan ook artefacten. SVG (of welke vector dan ook) gaat dat echter nooit voor je betekenen.
Ah, oké.... wel jammer in dat geval. Ik zag het al helemaal voor me. Misschien denk ik er te simpel over. Ik heb zelf trouwens nooit een foto in .svg gezien. Het zijn altijd redelijk "simpele" afbeeldingen. In dat perspectief zou je verhaal kunnen kloppen.
Het zou mooi zijn als er een afbeeldingsformaat zou komen die zich in ieder geval gedraagt als .svg. Dus bij een vergroting ook een factor aan pixels meegroeien, maar dan lossless. Die vertaling zal niet zomaar één-twee-drie ontwikkeld kunnen worden, maar wellicht is dat in de toekomst wèl mogelijk. Wie weet?
Wel, er is wel een verband. Als HDR 1000 schermen gemeengoed gaan worden, dan zullen mensen willen dat hun foto's daar ook gebruik van maken. Dat kan dan wel eens het moment zijn waarop jpeg wordt achtergelaten. Want een 16 bits (of zelfs 32 bits) per kanaal plaatje is leuk, maar als je er toch niets van kan zien, maakt die extra diepte ook niets uit. En als je het wel kan zien, dan wil je een bestandsformaat dat dat mogelijk maakt
Dan moet je het eerst over echte HDR camera’s hebben, want anders heb je aan zo’n monitor ook niets. Want weinig (of geen enkele) consumenten camera doet echt HDR. Als er al een HDR optie op zit, is dat een mix van opnames bij verschillende belichting gemapt op 8bit.
Maar ook dat zit er aan te komen. En ik heb net sponsorship binnengehaald om Krita op HDR schermen te laten werken, zodat je ook in HDR kan tekenen. Dat kan eigenlijk al, maar het resultaat wordt nu nog gemapt naar een 8 bits scherm.
/i/2002096887.jpeg?f=imagegallery)
:strip_exif()/i/2001260203.jpeg?f=imagegallery)
:strip_exif()/i/2001260205.jpeg?f=imagegallery)
/i/2001260215.jpeg?f=imagegallery)
:strip_exif()/i/2001264897.jpeg?f=imagegallery)
:strip_exif()/i/2001264899.jpeg?f=imagegallery)
:strip_exif()/i/2001264895.jpeg?f=imagegallery)
:strip_exif()/i/2001260379.jpeg?f=imagegallery)
:strip_exif()/i/2001260375.jpeg?f=imagegallery)
:strip_exif()/i/2001260377.jpeg?f=imagegallery)
:strip_exif()/i/2001261225.jpeg?f=imagegallery)
:strip_exif()/i/2001261223.jpeg?f=imagegallery)
:strip_exif()/i/2001261227.jpeg?f=imagegallery)
/i/2002097789.jpeg?f=imagegallery)
/i/2001264577.png?f=imagegallery)
/i/2002097199.jpeg?f=imagegallery)
/i/2002096971.jpeg?f=imagenormal)
/i/2004782266.png?f=fpa)
:strip_exif()/i/2002096969.jpeg?f=fpa)
/u/265477/forum_avatar_small.png?f=community){kind=avatar}
:strip_exif()/u/467778/crop5d7a5dd1f296a.gif?f=community){kind=small}
/u/947547/crop5baa4dbf26cca.png?f=community){kind=small}
:strip_icc():strip_exif()/u/543547/crop5f4eac1343ba1_cropped.jpeg?f=community){kind=small}
/u/357567/crop5dfcfaa04d0e8_cropped.png?f=community){kind=small}
/u/727812/crop5c893c9ed11f9.png?f=community){kind=small}
/u/583837/crop602abc4d4013c_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/16764/jh-avatar.jpg?f=community){kind=avatar}
/u/96903/cdwaveicon.png?f=community){kind=small}
/u/16450/icon06.png?f=community){kind=small}
:strip_exif()/u/88295/fevenhuisicon2.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/20383/crop57de62db41c81.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/98843/tmpgeel601.jpg?f=community){kind=small}
/u/13460/JUN982.GIF?f=community){kind=small}
:strip_icc():strip_exif()/u/20646/crop5db548de4a85c_cropped.jpeg?f=community){kind=small}
/u/4024/burne.png?f=community){kind=small}
:strip_exif()/u/325996/bomb3.gif?f=community){kind=small}
:strip_exif()/u/193139/tweakersIconSmall.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/52072/crop5de51ebf91960_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/13062/crop5e0cde80e7d91_cropped.jpeg?f=community){kind=small}
/u/105978/IMG_0188.png?f=community){kind=small}
:strip_exif()/u/27688/level42princess1.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/42559/crop6120373ab6800_cropped.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/234177/what-carrot.jpg?f=community){kind=small}
/u/12436/p1_normal.png?f=community){kind=small}
/u/98736/crop57f5f8979fbe3_cropped.png?f=community){kind=small}
/u/182977/crop65f9e5220f264_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/20205/IconMindGames.jpg?f=community){kind=small}
:strip_exif()/u/67404/C64.gif?f=community){kind=small}
/u/78932/Jewel3GoT.png?f=community){kind=small}
:strip_exif()/u/20843/RadioheadAvatar.gif?f=community){kind=avatar}
:strip_icc():strip_exif()/u/1085297/crop5b262ef103289_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/379078/crop58d8da5b23207_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/43400/avatar.jpeg?f=community){kind=avatar}
:strip_icc():strip_exif()/u/7851/b5fok.jpg?f=community){kind=small}
/twist over smaak
/u/26742/000000751.png?f=community){kind=small}
:strip_icc():strip_exif()/u/438947/crop575c94eea6d14.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/57655/SuperTeamLogo.jpg?f=community){kind=small}
/u/292867/crop5630e1f334453_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/358371/crop5ac7c4c8cd331.jpeg?f=community){kind=small}
:strip_exif()/u/464616/wvo-porsch-gif.gif?f=community){kind=small}
/u/226258/tweakersavatar.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/317599/crop5d18b37261809_cropped.jpeg?f=community){kind=small}
/u/584529/crop5af32c5cc1bce_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/1981/Image00001.jpg?f=community){kind=small}
