Vlákno názorů k článku JPEG 2000 smývá rozdíl mezi ztrátovou a bezeztrátovou kompresí od judovana - Tusite jak je na tom ted jpeg2000 s...
-
Michal ŠmucrBronzový podporovatelJako obecný formát třeba na webu moc ne. Co si vybavuju, tak ten formát byl v době vzniku opravdu napřed, byl relativně komplexní na implementaci a pomalý při kódování i dekódování (bez paralelizace, v době kdy multi-core CPU byla relativní vzácnost nebo vcelku drahý špás). Zároveň byl naprosto odlišný od předchozího JPEGu a nebyla tam žádná kompatibilita (což třeba řeší mnohem novější JPEG-XL, který umí bezztrátově překódovat původní JPEGy).
Další problém pro široké užití byly licenční poplatky.
V mezičase se vyvinuly alternativy jako WebP, AVIF, co vychází z otevřených video kodeků a mají širokou podporu v prohlížečích.Nicméně se nedá říct, že se to vůbec nechytlo nebo že ten vývoj nebyl důležitý. JPEG2K se používá pro archivaci, lékařská obr. data, satelitní snímky. Tam se benefituje z některých jeho vlastností (např. škálovatelnosti komprese, ROI, hierarchického/progresivního dekódování).
Další důležité použití je kódování videa (standardizovaný DCI formát pro použití v kině má video stopu v JPEG2K, resp. MJ2 kodeku).
Zároveň podle mě JPEG2K ovlivnil i ostatní video kodeky s praktickým použitím vlnkové (Wavelet) transformace. Úplně nemyslím ty distribuční kodeky pro koncové použití, ale ty pro ukládání a zpracování videa během výroby (říká se jim intermediate, mezanine) - jako například Apple ProRes, Canopus HQX, Cineform, REDCode. Tam si můžete dovolit relativně vysoké datové toky, které jsou ale výrazně nižší než ukládání bez komprese, ale zároveň potřebujete relativně rychlé kódování i dekódování při zachování vysoké kvality, která se nesníží ani když provedete několik generaci. Hodí se zas i to heirarchické kódování, kdy vám pro náhledy stačí dekódovat video rychleji např. v osminovém rozlišení.Jinak si samozřejmě zkoušejte, ať žije OpenJPEG :)
18. 12. 2024, 09:13 editováno autorem komentáře
-
S temi video kodeky opatrne.
ProRes = je JPEG v blede modrem, jen namisto 8bit to umi 10/12bit, DCT
DNX, HQX, znova 8x8 DCTCineForm / CineForm RAW je uz wavelet (integer based, aby to slo dobre delat na mmx/sse), stejne tak jako Dirac/DiracPro.
Puvodni REDCode je 1:1 JPEG2000, jen do YUV se tam cpe bayer RAW, samotna RED1 kamera vyuziva JPEG2000 hw enkoder od Analog Devices (AD212), sest kousku, ktere zpracovavaji regiony obrazu paralelne. Pozdejsi verze firmwaru pak modifikuji bitstream, at to neni tak easy dekodovat. A nejnovejsi iterace v REDcode je DCT based a kopiruje pristup z ProResRAW.
Pak dalsi kodeky, ktere se pouzivaji v kamerach - jsou taky waveletove, jmenovite Canon CRX/CRW/CR3, pak Sony LLVC (XOCN), pripadne Tico/TicoRAW/NRAW. U nekterych variant je vertikalni rozliseni regionu snizeno na 16 az 32 pixelu, takze to je pametove (a vypocetne) mene narocne behem enkodovani, a dovoluje masivni paralelni dekodovani napr na GPU. Ta vlastnost progresivniho dekodovani je fajn, kdyz mate treba 8K/4K zdroj, a potrebujete dekodovat jen 2K pro rychly nahled, zbytek dat a vypoctu se proste nezpracuje.
Co se tyce progresivniho dekodovani a prenosu MSB nejdrive - tak to bylo zajimave v dobe, kdy rychlost pripojeni byla drasticky mensi, nez vypocetni schopnosti - tj. mohli jste vyrenderovat aktualni castecny stav - to platilo i pro klasicky progressive-jpeg. Nebo pak na ty satelitni obrazky, kde je bitrate taky malej.
-
Michal ŠmucrBronzový podporovatel
Máš samozřejmě pravdu, ten ProRes mi tam do toho výčtu příkladu vletěl omylem, pardon. Jasně je to taky DCT, stejně jako třeba DNxHD od AVIDu z podobné kategorie kodeků.
S tím RECCode jsem měl na mysli tu původní waveletovou verzi. Pamatuji si jak to byl velký problém dekódovat a de-bayerizovat v rozumném čase na tehdejším běžném PC. Pak přišly RED ROCKET (X) akcelerační karty za bratru 7000 USD a nekonečným čekáním na dodávku. Nakonec se všem ulevilo, když se to dalo offloadovat přes CUDU na grafické karty. Hlavně těm co se nedočkali té ROCKET karty :)
Novější DCT based profily, co zmiňuješ, jsem popravdě ani moc nezkoumal.Jinak v návaznosti na JPEG2000 a video bych ještě možná zmínil i streamovanou podobu. Z které později vznikl JPEG-XS, což je variace se zjednodušenou komplexitou pro rychlejší kódování i dekódování a je součástí SMPTE standardu ST 2110-22. Při vyšších kompresních poměrech to logicky vychází hůř než původní JPEG2000, nicméně např. do 5:1 nebo 10:1 je to pořád zkousnutelné i pro následné zpracování. Prakticky se dostáváš třeba pod 200Mbit s 1080p50 a enkodér i dekodér má každý 1 frame latenci (+ IP roundtrip samozřejmě).
-
JPEG-XS je prave TICO, ktera je iniciativou nejakych francouzu a nechali si to zaplatit od EU na dotacich a cekove kazi trh, protoze to licencuji za dalsi poplatky. Vytvorili si nejakou alianci, ale me tam nikdy nevzali, protoze jsem se jim nehodil do kramu :D
To rychlejsi dekodovani je hlavne dusledek snizeni vertikalni velikosti prouzku, ktere neni unikatni zde, a pak pouzitim integer math.
V podstate vykradli DiracPro a udelali z toho proprietarni reseni. Zaslouzili by si pres hubu :D
Jinak cely ten kodekovy vesmir by sel krasne ilustrovat Vennovym diagramem, jak se napady a pristupy recykluji dokola jen s malymi variacemi.
-
Michal ŠmucrBronzový podporovatel
Zajímavé téma ;) S tím TICO (RDD35) kodekem jsem se prakticky nesetkal, už jen pak s odvozeným JPEG-XS. Nicméně jak jsem zmiňoval spíš se s tím setkám ve formě nějakého "blackboxu", kdy je to třeba celé pronajaté jako služba na přenos videa včetně konektivity a dodavatel poskytuje a nastaví svá koncová zařízení, já tím posílám SDI, tuneluju GPIO atp. Vím, že předtím používali JPEG2000 a někteří teď přechází na JPEG-XS kodeky pro linky, kde je kritická latence.
Jinak o těch EU dotacích jsem nevěděl, to je zajímavé pozadí. I když na druhou stranu asi i logické, pokud to generuje nějaké kvalifikované joby, prodávají IP po celém světě a daní v Belgii. Je mi to upřímně milejší, že to směřuje do tohohle segmentu než třeba do linky na toustový chleba, případně do rozhledny u vesnice na rovině :)
Ale je škoda, že tě nepřibrali do party, měl bys pak ještě víc insider informací.. :) možná se jim nezdálo, že sis o nich myslel, že jsou to Francouzi :DI k těm lic. poplatkům jsem asi milosrdnější a u těchhle "niche" věcí pro profi použití mě to štve míň než třeba u distribučních kodeků, co reálně používají miliardy lidí, případně ty všemožné Dolby záležitosti, nebo třeba HDMI konsorcium. JPEG-XS je relativně dostupný ISO, SMPTE standard a poplatky budou třeba deset, patnáct dolarů na zařízení, co stejně stojí tisíce EUR.
... -
Michal ŠmucrBronzový podporovatel
A dík za připomenutí toho Diracu.. nedovedu teď úplně posoudit jak moc je TICO/XS obšlehnutý od Diracu Pro (VC2), nebo jestli tam byl prostě jen podobný proces při úpravě plnotučného kodeku ke snížení latence a komplexity, u kterého dojdeš logicky k podobným krokům, resp. omezením. V prvním případě z JPEG-2K s tím, že se nemuseli nutně vyhýbat patentovaným věcem, a v druhém zas redukcí plného Diracu, který byl zas od začátku vyvíjen tak, aby naopak nic patentovaného z JPEG-2000 nepoužíval (chápu, že to může být tak trochu tanec mezi střepy :)).
Dirac měl podle mě trochu smůlu a přišel tak nějak v mezičase. Chápu ten základní impuls, kdy chtěli mít patentově čistou implementaci waveletového kodeku. Když to bylo hotové (téměř dekádu po JPEG2K), tak popravdě nikdo moc netušil prakticky co s tím. Pro normální uživatele a distribuci to nemohlo moc konkurovat AVC. Jako intermediate kodek s intra-kompresí to bylo oproti DCT kodekům příliš heavy-handed (v té době Core2Quad jsem hrál tak možná SD a to ještě s odřenýma ušima, i na rychlejších stanicích by to jakýkoliv střih s multikamerou poslal do kolen). Ty archivační a hi-end věci už byly řešeny JPEG2K na který byly dostupné akcelerátory a postupně i CUDA implementace. Standardní akviziční formát zas vyzdily intraframe varianty DCT kodeků jako AVC-Intra nebo XDCam HD.Ten krok s uvedením verze VC-2 s nízkou latencí byl vcelku logický, budoucí trend s přechodem na IP se dal tušit. Akorát neměli moc podchycené HW vendory a produkty. Co vím, tak existovala po pár letech jedna FPGA implementace s Xilinxy od britské firmy, na které spolupracovala sama BBC, pak kdysi nějaká diplomka na akceleraci Diracu přes CUDU. Ale jinak nic, žádný hotový komerční produkt (SDI HW kodek, akcelerovanou knihovnu) jsem nikdy neviděl, vím jen že BBC měla své řetězce a rakouská ORF dělala taky nějaké testy.
Oproti tomu ten intoPIX na to šel od hardware (už předtím měl JPEG2K řešení), pak to dal dohromady s Fraunhoferem, který pomohl se standardizací a nabízí komerční SDK (s akcelerovanými knihovnami, co se dají integrovat do dalších produktů). Pomohlo jim i to, že s tím přišli v době kdy po tom začla být daleko větší komerční poptávka (souvisí to s cenou konektivity na WAN spojení, zásadně se to rozjelo až po Covidu. Deset let zpátky jelo skoro všechno s long-GOP kodeky, byť s brutální latencí.). Plus se teprve utvářely SMPTE 2110 standardy, řešilo se jak přistupovat k UHD atp. To je teď víceméně hotovo a JPEG-XS je součástí.
Pro levnější použití (řekněme semi-profi technika) to zas válcuje NDI od Newteku/Vizrtu, který je také proprietární ale má tak široké rozšíření napříč výrobci v tomhle segmentu, že je de-facto standardem.Takže dnes mám obavu, že Dirac/VC-2 je bohužel mrtvá záležitost. Schválně jsem si ještě dával menší refresh a díval se jak teď vypadá jeho sw podpora v nějakých volně dostupných nástrojích (např. pro nějaký DIY stream s nízkou latencí po lokální síti). Binding na libschreodinger vypadl z ffmpegu ve verzi 3.3. Vestavěný VC-2 kodek v ffmpegu mi nepřijde úplně dobrý. Ve srovnání s SVT-JPEG-XS ( https://github.com/MartinEesmaa/SVT-JPEG-XS/tree/fix-multiple-definitions ) má asi 7x pomalejší kódování (ok může být chybějící vektorizace), ale hlavně je daleko míň efektivní, pro 1080p50 video bez viditelných artefaktů jsem musel jít na 350 Mbit. Nad rámec toho jsem VC-2 nedokázal dekódovat jinak než zas jen ffmpegem (třeba VLC s libschroedinger pluginem si ani neškrtlo, ale nedebugoval jsem to dál).
