Organisatie achter jpeg komt met formaat voor streaming video en vr

De organisatie die verantwoordelijk is voor de ontwikkeling van jpeg, komt met een nieuw formaat: jpeg XS. Dit is voornamelijk geschikt voor streaming video, maar ook voor virtual reality-content.

Met het jpeg XS-formaat belooft de organisatie achter het bestandsformaat onder andere minder compressie; het nieuwe formaat zou bestanden met een factor zes verkleinen door de toegepaste compressie, maar de beelden zouden volgens de ontwikkelaars nauwelijks van het origineel te onderscheiden zijn. De 'gewone' jpeg-compressie zorgt voor een verkleining van bestanden met ongeveer een factor tien. Overigens is de XS-variant, net als de gewone jpeg-compressie, beschikbaar onder een opensourcelicentie.

Waar het originele jpeg-formaat voornamelijk bedoeld is om afbeeldingen op te slaan op dragers met een beperkte hoeveelheid geheugen, is het nieuwe XS-formaat juist bedoeld voor streaming. De organisatie achter het bestandsformaat stelt dat het lag bij streaming video en virtual reality kan verminderen door materiaal met jpeg XS te encoderen, doordat het nieuwe coderingsproces efficiënter is gemaakt. Wel zijn de uiteindelijke bestanden dus groter dan met de standaard jpeg-codering, maar dat hoeft bij streaming geen probleem te vormen, aldus de ontwikkelaars.

De Europese ruimtevaartorganisatie ESA zou al interesse hebben getoond in jpeg XS. De efficiëntere compressie zou een uitkomst kunnen bieden voor ruimtesondes, waarbij met relatief weinig energie foto's genomen moeten worden. Wel heeft dit natuurlijk als gevolg dat beeldmateriaal met een grotere omvang terug naar aarde gezonden moet worden.

Vorig jaar kwam Google met een nieuwe manier van compressie op jpeg-bestanden die afbeeldingen op het web tot een derde kleiner moet maken zonder zichtbaar verlies aan kwaliteit. Door de kleinere bestanden moeten websites sneller laden.

Reacties (44)

[cdwave]

Beetje marketingblabla allemaal. Gewoon JPEG zoals we dat al ruim twee decennia kennen heeft 8 beeldlijnen nodig om te kunnen starten met de compressie (werkt met 8x8 pixel blokjes). Dat is de enige latency die het formaat oplegt. Dedicated hardware encoders en decoders, GPUs en ook FPGAs kunnen dit formaat met gemak op hoge data rates verwerken. En klassiek JPEG comprimeert beter dan het XS formaat, dus da's allemaal winst.

Een MPEG video stream heeft data van beelden in zowel toekomst als verleden nodig om de "B" frames te maken (die de meeste compressie leveren). Een MPEG stroom (en dus ook h264 en alle andere familileden) heeft daardoor altijd enkele complete frames latency. Een MJPEG stream heeft dat probleem dus niet, die kan met 8 beeldlijnen toe.

Klassiek JPEG gebruikt wel YUV kleurenmodel, en dat helpt een flink deel van de kleurruimte om zeep. Daar zou je wel iets aan willen doen, want voor film en foto materiaal is dat niet zo erg, maar voor desktopbeeld valt dat heel erg op.

Een "licht" compressie formaat om te gebruiken voor beamers enzo is best praktisch, maar staat helemaal los van haalbaarheid. Overigens, een gewoon full-HD beeld van 1920x1080p60 heeft 1 Gbps bandbreedte nodig (1920x1080x60x8 bits/s zonder de "gutters" enzo waar de audio ook in zit).

De interesse van de ESA is wel te begrijpen, wat de ruimte in gaat is doorgaans minstens 15 jaar oude technologie en die heeft wel moeite met "live" JPEG compressie.

[Reactie gewijzigd door cdwave op 24 juli 2024 07:48]

[Anoniem: 714420]

Overigens, een gewoon full-HD beeld van 1920x1080p60 heeft 1 Gbps bandbreedte nodig (1920x1080x60x8 bits/s zonder de "gutters" enzo waar de audio ook in zit).

Per pixel heb je 24 bits nodig (3 kleurenkanalen a 8 bits), niet 8. Ongecomprimeerd full-HD@60fps is dus ongeveer 3 Gbps.

[TPar]

Video encoding gebeurt nooit in de RGB-representatie maar in YUV. YUV 4:4:4 heeft ook drie keer 8 bits nodig, maar meestal wordt YUV 4:2:0 gebruikt, wat slechts 12 bits per pixel nodig heeft (8 bits voor Y + 2*(8/4) bits voor U en V).

[Anoniem: 714420]

4:2:0 encoding is natuurlijk een vorm van compressie, en als ik @cdwave goed begreep ging het hier juist om de bandbreedte die nodig is voor een ongecomprimeerde video stream.

[cdwave]

Inderdaad, ik sta gecorrigeerd.

Overigens verwacht ik dat ruimte "beelden" in grijswaarden zijn, meestal wordt er maar in een golflengte gekeken. Een 12-bit Y-only stream is dus waarschijnlijker dan een YUV of RGB stroom.

[the_stickie]

De interesse van de ESA is wel te begrijpen, wat de ruimte in gaat is doorgaans minstens 15 jaar oude technologie en die heeft wel moeite met "live" JPEG compressie.

15 jaar geleden hadden we ook al hardware ondersteunde JPEG. En als ik dat argument volg, zouden ze zeker niet enthousiast zijn om mee te gaan in deze veel te nieuwe technologie.
Volgens mij zijn ze eerder geīnteresseerd omwille van het beperkter kwaliteitsverlies en toch nog relatief sterke compressie. Uiteindelijk is de kleine bandbreedte/datarate nu vaak een beperkende factor om beeldmateriaal weer op aarde te krijgen.

[JoannisO]

De eisen rondom hardware die de ruimte gaat is heel anders dan de eisen die op dat moment in de consumentenmarkt zijn. Hardware word vaak jarenlang getest i.v.m. ongefilterde radiatie die de stabiliteit van een systeem kan beinvloeden door random bits te toggelen.

Toch een +1 van mij voor de conclusie

[Reactie gewijzigd door JoannisO op 24 juli 2024 07:48]

[bbob]

Vraag me dus af hoe beperkt dat kwaliteitsverlies is. als je sommige beelden ziet van sterren dan praat je over paar pixels bij paar pixels. compressie kan dan een heel ander beeld geven.. Maar goed misschien zit ik er wel helemaal naast is is jpg van nu al voldoende

[the_stickie]

Waarschijnlijk kiest men de compressie ook adhv het scenario. Als pixels belangrijk zijn, is lossless compressie eigenlijk de enige optie. Voor een marslanschap oid is het beeld belangrijker dan de individuele pixel.

[Anoniem: 133816]

AV1 stream vs jpeg XS stream. Gewoon een gokje, dat AV1 het gaat winnen op meerdere vlakken.

[TPar]

AV1 is momenteel minstens een factor 1000 trager dan jpeg XS, en vergeten we dan voor het gemak nog even de memory footprint. Dit is dus niet de beste vervanger :-).

[Floris99]

AV1 komt net uit de ontwikkelingsfase. Ze zijn nog maar net begonnen met optimaliseren.

[TPar]

Correct, maar veel sneller dan een factor 100 zullen ze niet geraken (de code base is VP9 dus daar zitten al veel optimalisaties in). De technologie die gebruikt wordt is gewoon een heel stuk complexer (de arithmetische coder, de motion compensation, de set coding tools en zelfs de transformaties).

[Reactie gewijzigd door TPar op 24 juli 2024 07:48]

[Floris99]

Zelfs al is het softwarematig 10x trager dan Jpeg XS, zal hardwareversnelling dat oplossen. Bijna alle grote chipfabrikanten zullen dat implementeren aangezien het vrijwel zeker de mainstream codec wordt over enkele jaren.

[TPar]

Dan zal je nog steeds met dezelfde complexiteitsverhouding zitten en dus met dezelfde energie x keer zoveel jpeg xs beelden kunnen verwerken

[Ayporos]

De leeftijd van de technologie die de ruimte in gaat is minder interessant, wat meer interessant is dat het low-power moet zijn, robuust moet zijn en (praktisch) immuun moet zijn tegen allerlei vormen van bestraling waar wij hier op aarde met onze beschermende dampkring en magnetisch veld geen last van hebben.
Dit is waarom een 'RAM' module van bijvoorbeeld een flight computer 'grote' bits heeft en goede redundancy tegen bitflipping moet hebben omdat je niet wilt dat door een bestraalde index met bitflip als gevolg ineens je ruimtezonde een koers'correctie' uitvoert en regelrecht de zon in vliegt.

[The Chosen One]

Denk dat ze het helemaal niet erg vinden als iets de zon in vliegt, zolang ze de data maar krijgen. Duurt alleen ff om er te komen.

[TPar]

Toch even corrigeren.

B-frames zijn niet per definitie naar het verleden en de toekomst. Je kan naar verschillende beelden in het verleden wijzen. Maar dat is een detail. Je kan ze sowieso disablen.

Verder kan een MPEG-stroom evenveel latency hebben als JPEG. Ook bij MPEG kan je en/decoderen van het moment dat je de info hebt die nodig is om het eerste macroblok te encoderen/decoderen. En zelfs zonder deze hocus pocus (sub-frame processing) kan de latency extreem laag zijn.

Voor mijn onderzoek heb ik ooit een AVC encoder-decoder setup gemaakt (met standaard gstreamer software) die minder dan 16ms delay had tussen capture en display, inclusief netwerktransmissie (en ja de limitatie was eigenlijk dan nog de grafische kaart die aan 60fps renderde)

Added:
In verband met de verhouding geluid/video gisteren een heel coole demo gezien van een ex-collega die nu bij Netflix werkt. Hij toonde een AV1-versie van een trailer in 720p (1280x720) met een bitrate van 100 kbits/s. Ongelooflijk wat ze daar mee konden doen, zeker gezien het feit dat de trailer niet bepaald stilstaande landschappen warren. 10 jaar geleden kon je daar geen deftig stereo-signaal mee versturen...

[Reactie gewijzigd door TPar op 24 juli 2024 07:48]

[air2]

@cdwave Zegt ook niet dat B-Frames verplicht zijn, maar dat voor een goede compressie verleden en toekomst nodig zijn. Als je dat allemaal uitschakelt wordt de compressie ook minder. Net als bij jpeg-xs dus, minder latentie en minder compressie. De vraag is natuurlijk, levert jpeg-xs dan echt zoveel betere kwaliteit/minder latentie op dat het opweegt tegen de mindere compressie. Aldus de JPEG organisatie wel.

[Burgertrut]

MJPEG. Ik had nog een isa-bus video capture kaart van Pinnacle/Turtle beach (heette nog anders zelfs) met een AMD 486DX2 @ 100Mhz (DX4?) ,16Mb intern (met inruil 4Mb, nog 1400 gulden bijbetalen) en het werkte allemaal voor geen meter. Ben wel goed geworden in IRQ’s toewijzen. Wat een ellende allemaal.

Allemaal voor toelating creatieve studie in 1995. Was een stomme opleiding waar ik na 4 maanden mee gestopt ben. Net zolang als ik heb gedaan over een (toelatings)video van 1,5 minuut, waarvan de helft nog gerenderd met 3D studio onder MS-DOS (ver voor 3D studio Max, laat staan Maya of zo). Wel al met Adobe Première aan elkaar geplakt.

Goede herinneringen ook al was ik toen niet zo blij en erg gestresst van crashende computers als ze net 96 uur gerenderd hadden.

/edit: na een beetje zoeken weet ik het weer, het was de ‘Miro Video DC1’ later was dat pinnacle/turtlebeach.

[Reactie gewijzigd door Burgertrut op 23 juli 2024 08:12]

[Munters]

Waren dat geen Xionics kaarten? Die hadden we nodig om TIF te displayen en te capturen op een 386. Met de komst van de 486 had enkel het scanstation nog zo'n kaart nodig, de processor kon de plaatjes wel al in redelijke tijd tonen. fl 700,- kostte zo'n kaart kan ik me herinneren.

[Burgertrut]

Nee het was dus wat ik erbij ge-edit had, de Miro video DC1. Kon je echt video mee capturen (van een videorecorder of tv), en nog leuker, je kon met Adobe Première ook weer video outputten. Dus kon je toen al (1995) je 3D studio animaties op een (S)VHS terugzetten.

Was allemaal heel leuk, kostte alleen zeer veel geld en werkte maar af&toe.

Ongelooflijk, tegenwoordig kan mijn iPad het vloeiend.

[Anoniem: 221563]

het nieuwe formaat zou bestanden met een factor zes verkleinen door de toegepaste compressie

In vergelijking met? Wat is de bron? LosslessUncompressed video zal het niet zijn, want dan is een factor 6 niets vergeleken met de alternatieven.

Hoor steeds vaker over ‘dé nieuwe codec’ maar het valt vaak tegen zodra je dr echte Specs bekijkt danwel gaat testen.

[Reactie gewijzigd door Anoniem: 221563 op 24 juli 2024 07:48]

[the_stickie]

In vergelijking met ongecomprimeerde video.

Definieer je "lossless" dan wel correct? Het is niet omdat je normaliter geen verschil ziet dat er geen data verloren gaat. Simpel gesteld is lossless video-encoding het toepassen van datacompressie (denk ZIP en afgeleiden), eventueel gecombineerd met progressieve opslag (delta encoding) waarbij enkel verschillen tov vorige frames wordt opgeslagen. Dat laatste levert minder op dan je misschien verwacht omdat individuele pixels frame per frame zelden exact gelijk zijn, het eerste levert afhankelijk van het bronmateriaal "slechts" een factor 1/2 op. Ik heb geen weet van lossles compressie die boven 1/4 komt (zelfs in geīdealiseerde scenarios met statische achtergrond). Meestal is 1/2 tot 1/3 realistischer. Als jij iets kent dat beter doet, hoor ik het graag (echt).

Videocompressie is meestal lossy, net omdat lossless compressie zo weinig oplevert. De kunst is net het dataverlies zo weinig mogelijk te laten opvallen en toch zoveel mogelijk data te groeperen en gelijk te stellen.

[Reactie gewijzigd door the_stickie op 24 juli 2024 07:48]

[Mazda Man]

Ik vraag me af of de bitrate hier niet onder lijdt, net als op YouTube met videocompressie gebeurd

[Flamesz]

Bitrate is een indicator van bestandsgrootte per tijdseenheid. Wat het artikel dus zegt is dat ze video materiaal met Jpeg XS kunnen encoderen een daarbij de bitrate met 5/6 kunnen verminderen terwijl er bijna geen beeldkwaliteit verloren gaat.

Als de bitrate er dus onder te lijden heeft is het alleen maar een goed iets, verlies van beeldkwaliteit is wat je bij compressie juist wilt beperken.

[t link]

Ik snap de verwarring wel, bitrate gaat ruw geschetst hand in hand met kwaliteitsverschil als je op de niet zo legale websites content zoekt. des te groter het bestand des te beter de kwaliteit is daar de vuistregel.

[Mazda Man]

ik heb inderdaad te weinig kennis over dit onderwerp.... ik dacht dat bijvoorbeeld bij sites zoals YouTube de wazige bewegende beelden kwam door lage bitrates, bedankt voor de extra informatie jongens

[Asteryz]

Dat komt ook wel door lage bitrates, maar kort door de bocht mag je die bitrate vermenigvuldigen met hoe goed je compressie is.

slechte compressie * lage bitrate = wazige dia show onzin
slechte compressie * hoge bitrate = matig filmpje die je databundel opstookt
goede compressie * lage bitrate = matig filmpje <-- Dit is waar youtube op mikt, want zij verbruiken nogal wat data
goede compressie * hoge bitrate =

[Reactie gewijzigd door Asteryz op 24 juli 2024 07:48]

[Tourmaline]

Geen compressie* maximum bitrate = UHD
Alhoewel daar ook nog wel compressie opzit.

[Reactie gewijzigd door Tourmaline op 24 juli 2024 07:48]

[spNk]

Wat heeft een aanduiding voor een indicatie van de resolutie te maken met beeldkwaliteit?

[Ventieldopje]

Dus zonder compressie en maximale bitrate (wat dat ook moge zijn) is je beeld ineens ongeacht de originele resolutie 4K / 8K? Grapjas.

[devil-strike]

uncompressed uhd 4 of 8k zal niet door gbit lijn passen iedergeval.

[Nox]

Nee, de compressie is een factor zes tov tien van de vorige standaard. De bitrate gaat omhoog tegen efficientere encoding. Maar juist streaming drukt enorm op de belasting van netwerken van ISP's. Dus die stelling dat het niet zou boeien snap ik niet. Misschien vergeten ze dat ISP's overboeken?

[dunpealhunter]

Dit doet mij een beetje denken aan die xkcd webcomic, of zit ik hier nu helemaal mis?

[Adion]

Ik vermoed dat het in dit geval minder belangrijk is dat het een standaard is. Voor de genoemde doeleinden zoals VR zal de zender en ontvanger normaalgezien door dezelfde ontwikkelaar gemaakt zijn.
Het lijkt voornamelijk een systeem ter vervanging van uncompressed video streams.

Voor de meeste web-streaming toepassingen zal je toch liever een codec gebruiken die veel efficienter is door ook gelijkenissen tussen opeenvolgende frames te benutten. Een paar frames extra latencies is voor die toepassingen niet zo'n probleem.

[Tourmaline]

Als het een standaard wordt zoals jpeg gaat iedereen het gebruiken en heb je er zeker wel wat aan.

[Frituurbaas]

Een veelvoorkomend probleem kun je prima met een standaardoplossing verhelpen, de vraag is m.i. of jpeg XS een veelvoorkomend probleem oplost.

[TheRealProcyon]

Er is een relevante xkcd voor alles: ook als hij niet door Randall Munroe is gemaakt

[Anoniem: 968549]

Voor degene die gewoon een jpeg willen kleiner maken:

www.tinyjpg.com :-)

of via een programma: RIOT

[Reactie gewijzigd door Anoniem: 968549 op 24 juli 2024 07:48]

[his.dudeness]

AV1 is toch ook nieuw (en royalty vrij)?
Kan iemand mij het verschil uitleggen? Waarom zou men JpegX gebruiken ipv AV1 of andersom?

[sugarlee89]

Vorig jaar kwam Google met een nieuwe manier van compressie op jpeg-bestanden die afbeeldingen op het web tot een derde kleiner moet maken zonder zichtbaar verlies aan kwaliteit. Door de kleinere bestanden moeten websites sneller laden.

Wow denken dat websites alleen maar trager worden door afbeeldingen. Pak de oude google maps er eens bij, wat was die vlot en prettig in gebruik. En moet je de nieuwe zien traag en irritant. Zelfs op een uber computer. Nee jongens het ligt niet alleen maar aaan plaatjes.

[Nighter3D]

"onder andere minder compressie"

Ik denk dat je bedoeld MEER compressie. Minder compressie suggereert een grotere bestand.

[TPar]

En toch is het juist. Draait om minder complexiteit