Waar blijft de opvolger van jpeg?

De 'strijd' om een nieuw beeldformaat

Conclusie

XKCD - Standards

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.

Reacties (360)

[Dooievriend]

Jullie zijn Free Lossless Image Format vergeten, een imagecompressieformaat beter dan BPG en WebP, open-source, en ontwikkeld door Belgen

[WillySis]

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.

[aldieaccounts]

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.

[Stromboli]

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.

[aldieaccounts]

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.

[Anoniem: 444127]

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.

[aldieaccounts]

? Pleit ik ergens voor een proprietary standaard dan?

Ik ben het helemaal met je eens hoor, alleen snap niet helemaal wat het met mijn post te maken heeft.

[Anoniem: 444127]

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]

[aldieaccounts]

> Jij gaf aan dat een bepaalde proprietary standaard voordelen heeft

???? waar dan? Ik denk dat je iets verkeerd begrepen hebt (of ik heb iets onduidelijk geschreven), want dat zou ik niet zo gauw zeggen :-D

[Anoniem: 444127]

Het maakt niet uit.

[aldieaccounts]

Ik ben gewoon wel benieuwd wat je bedoelt :-)

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.

[Josk79]

Beide zijn vrij te gebruiken, dus waar doel je op?

Resp. LGPL en Apache-2.0 licentie.

[Reactie gewijzigd door Josk79 op 22 juli 2024 15:56]

[Anoniem: 444127]

De verwarring zat in het feit dat hij naar Dropbox verwees. Dropbox is proprietary, ik dacht dat Lepton daarom ook proprietary zou zijn.

[Coolstart]

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.

[WillySis]

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

[Coolstart]

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]

[WillySis]

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.

[aldieaccounts]

De progressive variant van FLIF is *veel* beter dan die van jpeg. Veel sneller een goed resultaat.

[Mr777]

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.

[WillySis]

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.

[Katanatje]

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).

[WillySis]

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.

[aldieaccounts]

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).

[boudewijnrempt]

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.

Edit:

Ik zag juist dit: https://github.com/spillerrec/qt-flif-plugin -- met zelfs een (outdated) patch om het met Krita te laten werken.

[Reactie gewijzigd door boudewijnrempt op 22 juli 2024 15:56]

[Yero]

Beter laat dan nooit, maar ik heb nog een stukje over FLIF aan het artikel toegevoegd om nog een stukje completer te zijn.

[rjmno1]

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]

[swhnld]

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.

[cdwave]

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.

[iAR]

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.

[fevenhuis]

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]

[Fastfreddy666]

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.

(1) https://en.wikipedia.org/wiki/JPEG_2000
(2) https://en.wikipedia.org/...%E2%80%93Feauveau_wavelet

[Bacchus]

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.

[fevenhuis]

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.

[aldieaccounts]

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.

[kimborntobewild]

...en consumenten klagen niet over JPEG.

De gemiddelde consument niet, nee. (Dat komt mede omdat weinigen weten dat de kwaliteit achteruit gaat na elke bewerking.) Ik wel.

[gozoman]

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.

[PageFault]

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.

[fevenhuis]

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.

[PageFault]

Het ging om hele hoge resoluties, A1 bij 300 DPI. Er is wel degelijk een groot voordeel met jpeg2000

[memphis]

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.

[swhnld]

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.

[mawashigeri]

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!

[fevenhuis]

PNG is lossless compressie en Jpeg is lossy compressie.

PNG was gecreëerd omdat men licentiekosten voor het gebruikt van GIIF images ging vragen.

[aldieaccounts]

Jpeg is een *stuk* kleiner dan png, voor visueel vergelijkbare kwaliteit.

[PageFault]

Hangt af van de content. Screenshots zijn altijd beter en vooral kleinere files in png. Dus het is heel erg inhoudsafhankelijk.

[kimborntobewild]

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]

[aldieaccounts]

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.

[kimborntobewild]

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).

[aldieaccounts]

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.

[kimborntobewild]

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.

[SCS2]

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.

[kimborntobewild]

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]

[michelr]

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

[burne]

Ja, dat was even schrikken toen de hele wereld in 1995 opeens massaal GIF liet vallen en overstapte op PNG.

</sarcasm>

[michelr]

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)

[sympa]

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.

[Yero]

Thx, daar is inderdaad een foutje ingeslopen! Er stond hierover een topic in het Feedback-forum en op basis daarvan is het aangepast.

[Bombtrack]

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.

[MenN]

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.

[Bombtrack]

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).

[MenN]

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

[jongetje]

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).

[jhvanweerd]

Ben het met jee eens.

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.

[dragoon2000]

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]

[burne]

Maar sterker nog, ik kan het je LATEN horen:

Dan moet je het natuurlijk wel ook echt laten horen.. Hier, neem mijn voorbeeld maar:

http://www.nutz.nl/2008/11/24/a-b-error/

[koelpasta]

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.

[burne]

Wat verder nog van belang is om enige vergelijking mogelijk te maken is dat het volume van dit residu op normaal volume wordt afgespeeld.

Iets wat ik in het begeleidende verhaal ook duidelijk aangeef.

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.

[koelpasta]

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]

[MerijnB]

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.

[koelpasta]

Ja, dat is dus zo als je de muziek nog niet weggerekend hebt.

[Apollo 13]

Thx Burne. Heb me vaak afgevraagd wat het verschil zou zijn. Er wordt zoveel weggegooid dat dat deel zelfs goed herkenbaar is.

[MerijnB]

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]

[dragoon2000]

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.

[ADR3]

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.

[bouwfraude]

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.

[Tranquility]

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]

[rasnaap]

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:

http://www.music.mcgill.c...Pras_presentation2009.pdf

Conclusie: Er is een verschil te bemerken tussen CD kwaliteit en MP3, maar vanaf 256 kbit/s is het niet meer significant.

Wie zelf overtuigd is het verschil wel te horen zou ik aanraden eens een dubbel blind experiment te doen, het is een stuk lastiger dan je denkt!

[koelpasta]

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.

[B_FORCE]

Waar bazeer je dat " zeker te horen" op?

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.

edit: http://www.music.mcgill.c...Pras_presentation2009.pdf

[Reactie gewijzigd door B_FORCE op 22 juli 2024 15:56]

[aldieaccounts]

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.

[cdwave]

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.

[killerdemon]

Een muziek CD was maar iets van 174kbit toch?

Kan het me ook fout herinneren

[koelpasta]

Een CD heeft 44100 samples per seconde van 16 bits en dat 2x vanwege stereo.
Dat betekent dat een cd 141120 bits per seconde doet, oftewel 1.4Mbit/s

Als jouw verhaal waar was dan verbruikte een 256kbps MP3 meer data dan een CD.

[Clemens123]

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

[MenN]

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.

[SCS2]

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!

[gjmi]

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]

[Tourmaline]

Flac is wat Blu-Ray/4K is voor dvd.

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.

[gjmi]

Je eerste stelling is fout. Bij Blu-ray word ook lossy compressie gebruikt. Verschillende types zelfs vc-1 h.264 en h.265 voor UHD.

[gjmi]

Ik snap het juist heel goed!

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.

[Tourmaline]

Die van jou ook niet...cd kent ook compressie, als je het zo wilt doortrekken, prima.

[gjmi]

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.

[MerijnB]

Wat voor compressie bedoel je dan?

[Tourmaline]

Dynamic range compressie o.a.

[MerijnB]

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).

[MerijnB]

Dat heeft niets met compressie te maken.

[Tourmaline]

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]

[MerijnB]

Zo duidelijk?

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?

[Tourmaline]

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?

Dit ben je toch wel met mij eens, of niet. Daar ging het in eerste instantie om.

En ja, er kunnen verschillende manieren van "compressie" plaatsvinden voordat het op een cd staat.

[MerijnB]

Als je 'beter' versmald naar 'een meer transparante reproductie van het origineel' ben ik het daar best mee eens ja.

Maar deze stelling staat vrij ver af van "cd kent ook compressie" waar ik in eerste instantie op reageerde.

Conclusie is dan dat je compressie bedoelde die niets met dit topic, jpg, mp3, etc te maken heeft?

[Tourmaline]

Naja, compressie is compressie, in de ruimste zin van het woord.
maakt niet uit. we gaan of topic maar we verstaan elkaar wel.

Kan niet wachten op jpeg xl in ider geval. Eindelijk eens een formaat wat alles heeft, goede compressie, transparantie e.d.

[gjmi]

Niet 20 en 100 MHz, maar 20 en 100KHz.

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]

[Tourmaline]

klopt 20hz-20khz voor cd en 20hz -100khz voor sacd.

[Anoniem: 718943]

'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.)

[Ethirty]

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.

[djwice]

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.

Voor iedereen die zich afvraagt hoe dat nu gaat bestanden van 300kB voor een heel liedje:
https://mod.haxor.fi/Mad_Freak/mod.3ddemo en kik op "play"
https://mod.haxor.fi/Pattis/mod.nasty_priority
source: https://github.com/jhalme/webaudio-mod-player

https://modarchive.org/in...=view_player&query=183366 (150kb met stem)

[Reactie gewijzigd door djwice op 22 juli 2024 15:56]

[MerijnB]

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).

[djwice]

Dank voor de feedback! Als ik me goed herinner maak jij muziek en wordt je betaald met crypto toch? Gaaf

[MerijnB]

Nee, ben wel muzikant, maar niet professioneel :-)

Je verwart me denk ik met iemand anders.

[djwice]

Jammer

[FreshMaker]

Jij bedoelt @Kain_niaK ...

[djwice]

JEP! thanks!

[Kain_niaK]

Hoi hoi n_n

[Nazlive]

Lijkt meer een soort van samplepack en midi file als ik het zo beluister/zie. Soort van Renoise dawplayer

[Adion]

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.

[djwice]

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.

Eigenlijk dus wat men ook doet met JPEG

[koelpasta]

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.

[koelpasta]

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.

[maali]

hihi... zoals die Rebels amiga demo uit 1994 met een opgeknipte Prodigy track als modje, bedoel je? ;P
https://www.youtube.com/watch?v=dUhsKlIo2IE&t=4m45s

[sys64738]

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.

[Clemens123]

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

[aldieaccounts]

> Flac is dus wel beter

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.

[MerijnB]

Voor elke mp3 die je maakt moet je eigenlijk geld afdragen aan het fraunhofer instituut.

Sinds april 2017 niet meer, Fraunhofer heeft patent niet verlengt (of iets in die richting) en mp3 encoding is nu rechten vrij.

[aldieaccounts]

Ah, dat is mooi. Blijft dat Ogg (iets) kleiner is. Maar ja, dan weer geen hardware support voor afspelen meestal (en dus meer batterijverbruik).

[Arunia]

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.

[Kain_niaK]

Er is iets goed mis me je ripper dan hoor.

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.

Probeer het zelf maar eens http://www.mp3ornot.com/

Om statistisch relevant te zijn, moet je het vaak genoeg doen en minsten 80% scoren.

En iedereen zou deze video on Audio Myths moeten zien. https://www.youtube.com/watch?v=Zvireu2SGZM


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.

[guillaume]

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.

[MerijnB]

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.

[koelpasta]

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.

[MerijnB]

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.

[koelpasta]

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

[MerijnB]

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.

[koelpasta]

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.

[MerijnB]

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.

[guillaume]

Precies. Wel treurig dat dit blijkbaar geen gemeengoed is. Thx voor het aanvullen met deze heldere uitleg.

[MerijnB]

Mp3 compressie kraakt niet, zeker niet op 320kbps, dus als die opname kraakt is er waarschijnlijk ergens anders iets fout gegaan.

[Troetelbeer]

Mee eens, dan is er iets serieus mis gegaan met de instellingen van het rippen.

[guillaume]

Kan zeker wel door clipping.

[MerijnB]

Clipping door mp3 compressie? Lijkt me onwaarschijnlijk, zeker in de mate dat je het hoort kraken.

[koelpasta]

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.

[Kain_niaK]

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.

[koelpasta]

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.

[Clemens123]

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

[koelpasta]

Heb je al eens bedacht dat je MP3 coder mischien wel van inferieure kwaliteit is?

Echt goede coders zijn niet goedkoop.

[aldieaccounts]

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.

[Anoniem: 310408]

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.

[koelpasta]

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.

[burne]

een ongecomprimeerd MP3 bestand

Je praat onzin. MP3 is per definitie lossy compressed audio.

[Clemens123]

Het is variable bitrate, als die hoog genoeg is heb je na decompressie exact dezelfde golfvorm

[burne]

Je praat onzin. MP3 is per definitie lossy compressed audio. FLAC, Free Lossless Audio Codec, kan per definitie nooit een lossy formaat zijn.

[Clemens123]

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

[burne]

Ik heb zelf al een mp3 codec geschreven

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.

[Clemens123]

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

[burne]

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.

[Clemens123]

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

[aldieaccounts]

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.

[koelpasta]

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.

[Kain_niaK]

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?

[Clemens123]

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...

[kimborntobewild]

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]

[randomrepeat]

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

[MerijnB]

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?

[randomrepeat]

Ik treed op met een live set (DnB/Dub en techno), als ik dit zou doen met mp3 formaat loopt iedereen huilend weg.

[MerijnB]

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.

[Liberteque]

"Ik treed op met een live set (DnB/Dub en techno), als ik dit zou doen met mp3 formaat loopt iedereen huilend weg "

Dat komt door de techno

[Reactie gewijzigd door Liberteque op 22 juli 2024 15:56]

[koelpasta]

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.

[MerijnB]

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?

[aldieaccounts]

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.

[koelpasta]

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?

[MerijnB]

Lame

[koelpasta]

Thanks.,
geen puf meer vandaag maar het staat op mn lijstje van leerzame testjes

[koelpasta]

Lame

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]

[MerijnB]

getest met een sweep lijkt me dan?

[koelpasta]

Yup!

Sweep was ongeveer 2~50Hz.
Daar heb ik ook muziek van >100Hz bij gemixt om de codec beter te stressen.

Verschilbestand gemaakt en daar alles boven ~70Hz weer weggefilterd.

Bekeken met de spectrum analyzer van ableton live, die bij 16k bins redelijk wat resolutie had (meerdere banden onder 10Hz)

Bitrate was 130kbps, lame, gecodeert in foobar2000.

[MerijnB]

leuk, ook getest met hogere bitrates?

[koelpasta]

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

[MerijnB]

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.

[koelpasta]

zoals encoden voor een telefoon oid, maar ik vraag me af of dat serieus bestaat / gedaan wordt.

Ik denk dat het in dat soort toepassingen zeker wordt gedaan.

[MerijnB]

In ieder geval niet de use case die dit experiment startte.

[Troetelbeer]

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

[koelpasta]

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.

[RobIII]

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]

[Kain_niaK]

Wat is dat nou weer voor een onzin?

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

Zie ook dit. --> https://www.youtube.com/watch?v=Zvireu2SGZM

[STING]

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.

[mikesmit]

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]

[debroervanhenk]

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.

[guillaume]

Opus zou 'n goeie kunnen zijn, maar al is ondersteuning al vrij wijdverspreid, het komt qua nieuwe(re) standaard niet van de grond.

[Reactie gewijzigd door guillaume op 22 juli 2024 15:56]

[Liberteque]

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

[WillySis]

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.

[Liberteque]

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]

[WillySis]

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 @Dooievriend https://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.

[Liberteque]

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..

# bedankt voor je linkje over het FLIF formaat

[sumac]

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.

[Liberteque]

"Enige probleem is om Apple, MS, Google, Mozilla en Adobe bijelkaar te krijgen. Zij kunnen het verschil maken."

Die komen toch nooit op een lijn joh en al helemaal niet als de consument hier niet om vraagt.

[burne]

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 )

[deredding]

Inderdaad jammer dat FLIF niet genoemd wordt in het artikel, prachtig formaat.

[aldieaccounts]

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).

[WillySis]

Off topic:
FLAC is een beter alternatief, maar ik schrijf niet dat het gelijk de beste vervanger is.

[aldieaccounts]

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).

[Stromboli]

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).

[tinus73]

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

[Liberteque]

Mee eens, maar niet reden genoeg om breed geaccepteerd te worden door de industrie, internet en webdesigners. Tot die tijd blijft Jpeg waar het is..

[deadinspace]

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.

[SmokingCrop]

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]

[Liberteque]

Ja we mogen dromen toch haha klinkt goed in ieder geval..

[Anoniem: 457607]

"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".

Het is zo gegroeid, en we weten niet beter.

[Bruin Poeper]

Helemaal eens!

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 echte Standaard.

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]

[Bruin Poeper]

Dat had je beter niet kunnen zeggen, want je krijgt er een min voor...

Waar moet dat heen met Tweakers?

[Liberteque]

Ach in het begin maakte ik me er nog druk over..

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

[SuperDre]

Hvec comprimeert wel goed, maar wat mj vaak opvalt, is dat de hvec variant van een film vaak fuzzier is en onnatuurlijkere kleuren heeft.

[mjl]

Dan stond de compressie te hoog ingesteld. En als je gecomprimeerd her-comprimeerd verlies je altijd aan kwaliteit.

[dipje2]

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)

[Clemens123]

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.

[koelpasta]

Kleurverschillen zouden absoluut niet mogen .

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.

[dipje2]

Ok ok, ja natuurlijk zijn er verschillen .

Maar als de kleur zo anders is dat je denkt 'wow wat is er met de kleur gebeurd ' dan praat je over foute settings en niet een encoder-eigenschap

[koelpasta]

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]

[SadisticPanda]

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

[D-Ed]

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]

[mikesmit]

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.

[D-Ed]

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..

[mikesmit]

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.

[WoutervOorschot]

Windows ondersteunt gewoon heic/heif tegenwoordig dus die keuze is gemaakt.

[Werelds]

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.

[Tourmaline]

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.

[Qalo]

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]

[Stromboli]

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.

[Qalo]

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?

[Jantimon]

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.

[Qalo]

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?

[novasurp]

Als je een foto zou omzetten naar vectoren en hem dan gaat uit vergroten worden het denk ik gewoon driehoekjes in plaats van vierkantjes.

[MerijnB]

Svg is op vectoren gebaseerd (hence the name), het is eigenlijk niet mogelijk om een bitmap (camera plaatje) om te rekenen naar vectoren.

[WPNL]

Goed artikel, er wordt alleen 1 aspect / obstakel vergeten denk ik: het scherm waarop het bestand wordt bekeken. ;-)

[gjmi]

Nee, dit artikel gaat over de opslag van het bestand, niet over weergave. Dat is een heel ander onderwerp.

[boudewijnrempt]

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

[gjmi]

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.

[Universal Creations]

Veel premium compactcamera's (1" sensor) hebben al genoeg dynamisch bereik om iedere HDR monitor te overtreffen qua dynamisch bereik.

[boudewijnrempt]

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.