Nieuwe jpeg-bibliotheek belooft betere lossless-compressie

De Independent Jpeg Group heeft een nieuwe versie van de libjpeg library uitgebracht. Aan deze veelgebruikte bibliotheek is een verbeterde lossless compressiemethode toegevoegd die afbeeldingen verder zou kunnen verkleinen dan met png-compressie mogelijk is.

De nieuwe compressiemethode is ondergebracht in versie 9 van de libjpeg library. Bij het comprimeren treedt geen verlies aan data op, ook bekend als 'lossless compressie'. Volgens de Independent Jpeg Group, de organisatie achter de jpeg-standaard, is de nieuwe compressiemethode in staat om bitmapafbeeldingen met rgb-indeling beter te comprimeren - met een kleinere bestandsomvang tot gevolg - dan afbeeldingen die met de png-standaard zijn verkleind.

Ondanks dat versie 9 van libjpeg afbeeldingen lossless beter zou kunnen comprimeren dankzij het toepassen van een reversible color transform-algoritme, is de gekozen compressiemethode niet compatibel met eerdere versies van de jpeg-library. Hierdoor is het voorlopig de vraag of de nieuwe compressiemethode breed zal worden omarmd.

Reacties (36)

Aangezien nog "niemand" JPEG2000 gebruikt, ondanks het feit dat dit formaat duidelijk superieur is aan z'n voorganger, vermoed ik dat ook dit nieuwe formaat het komende decennium niet veel gebruikt zal worden. JPEG2000 kende ook al een losless codering; blijkbaar is daar niet zoveel behoefte aan (misschien ook omdat PNG die niche al aardig vult).

grappig dat je 'niemand' aan haalt. blijkbaar is niemand de complete film delevery industie. Alle DCP's (digital cinema packages) die je te zien krijgt in elke willekeurige bioscoop gebruikt de jpeg2000 compressie om de 12 bit beelden op het scherm te vertonen. inderdaad er is niet zo veel behoefte aan zo een standaard. jammer dat de JPEG group net als de MPEG group de patenten graag heel strict in handen houdt.

Misschien omdat JPEG2000 niet vrij te gebruiken is.

De Independent Jpeg Group heeft een nieuwe versie van de libjpeg library uitgebracht.

Deze 'groep' bestaat uit een persoon en niet iedereen is het er over eens wat nou het officiële JPEG formaat is.

Erg verwarrend inderdaad, oorspronkelijk was libjpeg (door de Independent JPEG Group) enkel een implementatie van de specificatie door de Joint Photographic Experts Group.
Deze nieuwe versie van de bibliotheek lijkt echter een nieuwe compressie toe te voegen die geen onderdeel van de standaard is.

Dat terwijl er ondertussen al een tijdje een opvolger voor JPEG als standaard bestaat, namelijk JPEG XR

Het word er ook allemaal niet duidelijker op vermits de website van de Joint Photographic Experts Group hopeloos verouderd is. (en het nog steeds heeft over de JPEG 2000 standaard die voor zover ik weet nooit echt gebruikt is)

De wikipedia pagina van de JPEG groep is iets recenter, en geeft wel duidelijker aan welke specificaties wel tot de standaard behoren.

Jpeg2000 werd enkele jaren terug veel door de verschillende aanbieders van fotoboeken gebruikt voor het verzenden van de foto's naar de servers van de aanbieders.

Maargoed: stel dat ik voor mijn website van deze functionaliteit gebruik wil maken; moeten bezoekers dan deze nieuwe library ook hebben?

Ja; want deze nieuwe compressiemethode is niet backward compatible. En as usual is 't een beetje een kip-ei probleem: waarom ondersteuning inbouwen voor iets dat toch niet gebruikt wordt of waarom iets gebruiken dat toch niet ondersteund wordt.

Ik verwacht dat, als 't een kwestie is van de browser(s) compileren met een nieuwe versie van deze library, ondersteuning hiervoor niet heel lang zal uitblijven. Of 't daadwerkelijk gebruikt gaat worden is een tweede.

[Reactie gewijzigd door RobIII op 14 januari 2013 19:32]

Niet echt een kip-ei probleem naar mijn idee. Er is wel duidelijk een begin en dat begin ligt bij de grote browsers. Het is gewoon de vraag ofzij het gaan omarmen of niet. Ze hebben er overigens alle reden toe als de compressie daadwerkelijk erg goed is. Als zij het wel doen, volgen de ontwikkelaars vanzelf.

Of de grote sites? Denk dat er genoeg, bijvoorbeeld, foto-sites zijn die, mits deze nieuwe compressie goed genoeg is, het nodige aan bandbreedte en opslagruimte kunnen besparen.

Voor de grote sites kost het enkel extra. Je kan niet van standaard jpeg afstappen (vanwege geen bc) dus dit zou enkel maar extra zijn.

fotosites gebruiken helemaal geen lossless compressie. Die gebruiken gewoon de oude vertrouwde lossy compressie, die 10 keer meer bespaard in bestandgrootte.

Lossless compressie is goed als vervanging van gebruik van gif's voor niet-foto's, bijvoorbeeld voor logo's.

Maar niet alle browsers gebruiken per se libjpeg? Ze zullen dus hun eigen implementatie voor het decoderen deze nieuwe compressiemethode moeten maken. Hebben ze daar genoeg mensen voor? Misschien lijdt het tot nieuwe security bugs? Het is dan maar de vraag of het het waard is.

Als ik de laatste alinea lees kan ik afleiden van wel...

Het antwoord staat min of meer in het artikel... Ja, oudere versies kunnen er niet mee overweg

Ik denk het wel, anders heb je ook niets aan backwards compatability. Je moet weten hoe een afbeelding is gecomprimeerd voor je dat kunt omkeren.

Dus de reden dat ze geen snelle adoptie verwachten zal daar ook mee te maken hebben.

Technisch gezien zou het kunnen dat de browser bij het request gewoon meestuurt dat ie het nieuwe formaat ondersteunt. Daar zou je webserver op kunnen reageren door het plaatje in het nieuwe formaat terug te sturen. Vereist natuurlijk wel dat je beide versies hebt opgeslagen, realtime conversion wil je niet.

is de gekozen compressiemethode niet compatibel met eerdere versies van de jpeg-library

Dus miljoenen gebruikers krijgen straks te maken met verschillende .jpg-bestanden waarvan hun software aghw alleen aan de header (dus na het openen) kan zien of het de oude lossy of de nieuwe lossless variant betreft. Nee daar gaan mensen blij van worden. Png heeft dan tenminste het voordeel dat je aan de extensie kan zien wat het is.

Wat is er overigens van .mng geworden, de lossless variant van de animated gif? Er zit nog steeds een kloof tussen een plaatje en een filmpje. Laat een independent gif group zich daar eens op richten. Of ook leuk: gifs waarvan je individuele frames kunt aanspreken.

De gebruikers zijn niet het grote probleem. Digitale duurzaamheid is het wel! Heel veel materiaal is opgeslagen in jpeg "omdat het niet veranderd".

Als je geanimeerde lossless afbeeldingen wil kan je gewoon APNG (animated PNG) gebruiken.

Png heeft dan tenminste het voordeel dat je aan de extensie kan zien wat het is.

Daar ben ik heel benieuwd naar. Wat kun jij zien aan 1000 files allemaal met de extensie 'png' ?

[Reactie gewijzigd door Anoniem: 166774 op 14 januari 2013 20:48]

Waar ik meer toekomst zie is één codec voor video en afbeeldingen, zoals HEVC (de opvolger van H264/AVC). Erg efficiënt en ook geschikt voor afbeeldingen. Afbeeldingen in HEVC zijn gemiddeld 43% kleiner dan JPEG (en 22% kleiner dan JPEG2000) voor vergelijkbare kwaliteit.

Lees http://imgs.xkcd.com/comics/standards.png dan eerst eens. Eén standaard die alles omvat zal er nooit komen. Het wordt gewoon een extra standaard.

Ja, alleen die is vast niet lossless, en daar ging het bij deze variant juist om.

Opzich natuurlijk wel mooi dat ook lossy compressie steeds beter wordt.

Nu nog een formaat dat gebruikt kan worden voor Responsive Design please.

Dit gaat deel uitmaken van een nieuwe HTML5-spec die in ontwerp is, niet van de JPEG-standaard. Voor icoontjes e.d. kan je trouwens stilaan gebruik beginnen maken van SVG, mits fallback naar PNG voor IE<9 en Android 2.x.

Wellicht van een HTML 6 of 7 spec, maar 5 zie ik echt niet zo erg omgegooid worden dat er even een nieuwe non-bc jpeg-standaard inkomt.

Iemand enig idee of JPEG 9 ook transparency toestaat? Ik kan het zelf niet zo snel vinden. JPEG 2000 had al wel support voor transparency, dus ik neem aan dat dit ook het geval is bij JPEG 9.

Voor zover ik kan vinden niet. Het wordt in ieder geval niet vermeld in de changelog op de site (directe download van versie 9 als zip).

CHANGE LOG for Independent JPEG Group's JPEG software


Version 9 13-Jan-2013
----------------------

Add cjpeg -rgb1 option to create an RGB JPEG file, and insert
a simple reversible color transform into the processing which
significantly improves the compression.
The recommended command for lossless coding of RGB images is now
cjpeg -rgb1 -block 1 -arithmetic.
As said, this option improves the compression significantly, but
the files are not compatible with JPEG decoders prior to IJG v9
due to the included color transform.
The used color transform and marker signaling is compatible with
other JPEG standards (e.g., JPEG-LS part 2).

Remove the automatic de-ANSI-fication support (Automake 1.12).
Thank also to Nitin A Kamble for suggestion.

Add remark for jpeg_mem_dest() in jdatadst.c.
Thank to Elie-Gregoire Khoury for the hint.

Support files with invalid component identifiers (created
by Adobe PDF). Thank to Robin Watts for the suggestion.

Adapt full buffer case in jcmainct.c for use with scaled DCT.
Thank to Sergii Biloshytskyi for the suggestion.

Add type identifier for declaration of noreturn functions.
Thank to Brett L. Moore for the suggestion.

Correct argument type in format string, avoid compiler warnings.
Thank to Vincent Torri for hint.

Add missing #include directives in configuration checks, avoid
configuration errors. Thank to John Spencer for the hint.

edit:
Foutje in opmaak.

[Reactie gewijzigd door Sthomkop op 14 januari 2013 22:18]

Tja, imho is het tegenwoordig onbegonnen werk om jpeg-libraries te veranderen. Had dan een nieuw formaat uitgebracht, of had het op de een of andere manier bc gemaakt.

Deze nieuwe versie van jpeg zal met geluk in iOS 7 / Android 5 / windows 8.5 smarttv versies x/y/z zitten, daarvoor zal het op het web niets kunnen doen imho want niemand kan er iets op verzinnen qua filtering oid.

Door het aan jpeg op te hangen kan het niet meer een simpele add-on zijn, maar moeten systeem-library's geupdate worden. Weinig kans imho.

Niet alleen dat, maar steeds meer projecten en websites gebruiken libjpeg-turbo, een geoptimaliseerde libjpeg-compatible implementatie die dankzij MMX en SIMD instructies gewoon tig keer sneller is in het verwerken van jpegs dan libjpeg. Zolang die lib niet libjpeg9-compatible wordt zie ik weinig fotosites overstappen naar het nieuwe formaat.

Acceptatie hangt natuurlijk mede af hoeveel procent efficienter dit algoritme is.

Oh, nooit geweten dat PNG lossless was. Weer wat geleerd! Mooi formaat.

En tsja, dit gebeuren. Denk niet dat t veel kans heeft.