Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 36 reacties

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)

Reactiefilter:-136036+134+22+30
Moderatie-faq Wijzig weergave
Kunnen we deze loss-less compressietechniek nu ook in de volgende versie Photoshop (bijvoorbeeld) verwachten?
De size was natuurlijk leuk aan png maar de reden waarom ik geen jpg meer gebruik is gebrek aan accurate kleuren en geen transparantie. Gaan ze dat fixen?
Minder accurate kleuren komt door de bitdepth die bij PNG hoger ligt (8 bij jpg en 24 bij png uit mijn hoofd) maar ondanks dat kun je wel een ICC profiel er in verwerken voor een zo goed mogelijke weergave.

Hoe dan ook, het ligt vaak aan het (brakke) beeldscherm van gebruikers ;)

Dus in dat opzicht vind ik JPG wel prima, zeker als er betere lossless compressie wordt toegepast, nu alleen nog transparantie! ... maar daarvoor moet de bitdepth weer omhoog en krijg je alsnog grotere bestanden enzo dus meh.
Oh, nooit geweten dat PNG lossless was. Weer wat geleerd! Mooi formaat.

En tsja, dit gebeuren. Denk niet dat t veel kans heeft.
Acceptatie hangt natuurlijk mede af hoeveel procent efficienter dit algoritme is.
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.
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]

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.
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.
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.
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.
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.
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 backspace219 op 14 januari 2013 20:48]

Als je geanimeerde lossless afbeeldingen wil kan je gewoon APNG (animated PNG) gebruiken.
De gebruikers zijn niet het grote probleem. Digitale duurzaamheid is het wel! Heel veel materiaal is opgeslagen in jpeg "omdat het niet veranderd".
Maargoed: stel dat ik voor mijn website van deze functionaliteit gebruik wil maken; moeten bezoekers dan deze nieuwe library ook 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.
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.
Het antwoord staat min of meer in het artikel... Ja, oudere versies kunnen er niet mee overweg
Als ik de laatste alinea lees kan ik afleiden van wel...
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.
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.
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.
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.
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.

Op dit item kan niet meer gereageerd worden.



Microsoft Windows 10 Home NL Apple iPhone 6s Star Wars: Battlefront (2015) Samsung Galaxy S6 Edge Apple Watch Project CARS Nest Learning Thermostat Besturingssystemen

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True