JPEG helyett WEBP vagy BPG vagy egyik se?

Multimédia

Kedves HUP.osok!

Az évek alatt több száz GB-ra hízott a saját fotóim albuma. Megfordult a fejemben, hogy a régi jó JPEG helyett valami jobbat használnék: átnyomnám az archívumot ebbe. A WEBP és BPG formátumokba futottam bele és láttam, hogy egyszer-kétszer a HUP-on is felmerültek ezek egyesekben, de senki se írta, hogy komoly archívumot áttett volna valamelyikbe.

Van-e valakinek erről tapasztalata? Volt gond több ezer kép konvertálásánál? Melyik vált be jobban?

Vagy maradjak a JPEG-nél?

( Nyosigomboc v | 2017. 09. 26., k – 15:40 )

A JPEG veszteseges. Ha mar ebben keszult el egy kep (pl. fenykepezo/telefon csinalta), akkor szerintem celszerubb ebben a formatumban archivalni.
Ha atrakod masba, vagy tovabb romlik a minosege, vagy ha megmarad, nagyobb lesz a filemeret.

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

Valóban nem optimális, de általában a fényképezők elég magas minőségi beállítással dolgoznak, így van értelme más formátumra konvertálni.

Az iOS11-től már default HEIF -ben tárolódnak a fotók. Szerintem ez eléggé meg fogja dobni az elterjedtségét, így én abba konvertálnám.

Összehasonlítás JPEG vs WEBP vs HEIF:
https://compare.rokka.io/_compare/#heif=60&jpeg=50&webp=60&width=1800&h…

Jelenleg a heif sem: http://caniuse.com/#search=heif
webp támogatottság: http://caniuse.com/#search=webp

ide feltöltöttem webp (196.0k) vs heif (192.2k) összeghasonlítást: http://screenshotcomparison.com/comparison/118558

különbségek heif javára:
- baloldali nő keze
- vonat lámpájának fénye
- vonat felett alagút tetejének mintája
- járda és hídpillér kövének mintázata részletdúsabb

webp javára:
- baloldali 4-es feletti kamera kevésbé homályos

Kicsit még felélesztem ezt a threadet, ha nem baj :)

HEIF-et mivel csináltad?
Én megpróbálkoztam ezzel https://github.com/nokiatech/heif, viszont azon túl, hogy ez a tool valahogy nem emberi fogyasztásra készült - mintha eleve h265-be tömörített képet várna inputnak és lényegében csak a konténer-formátummal foglalkozik. Van valami más eszköz?
---
Régóta vágyok én, az androidok mezonkincsére már!

Ha fele méretű, vagy kevesebb lenne a különbség a HEIF javára, elgondolkoznék rajta, de nem tűnik igazán nagy különbségnek, valamint alig tudná bárki is megnyitni. A ráfordított időt még nekem nem érné meg ezt használni. Továbbá ha rá szánnék időt, lehet én tudnék jobb JPG-t konvertálni, mint ami ott van az eredeti veszteségmentes képből. Sok elérhető JPG konvertáló nagyobb tömörítésnél elég gyenge, jobb szoftverekhez képest. Nyilván ha ugyanúgy nézne ki, azonos méretűen a JPG mint a HEIF, akkor nem lenne jó demó.

Sakk-matt,
KaTT :)

( gelei v | 2017. 09. 26., k – 16:04 )

Kimaradt az OP-ből, hogy mi az elvárt outcome :)
Kisebb méret? Jobb kezelhetőség? Stb.

( keccs | 2017. 09. 26., k – 17:19 )

A dropbox csinált egy tömörítőt jpeg képekre: https://github.com/dropbox/lepton.
Ettől ugyan kevesebb helyet fognak foglalni a képek, csak nézegetés előtt újra ki kell majd csomagolni, hacsak a képnéződ nem támogatja - de szerintem 99% hogy nem.

( KaTT | 2017. 09. 26., k – 18:16 )

Szerintem több a hátránya, mint az előnye az átkonvertálásnak.
Eleve rosszabb minőségű lesz, mint ami volt, ha a másik codec is veszteséges. EXIF infók átkerülnek majd? Nem biztos. Oda a fájl eredeti dátuma, ami maga is infó lehet.
Azt javasolnám, hogy szánj időt a duplikációk kiszűréséhez, például noclone alkalmazás, ami bit szinten vagy éppen a kép tartalmát hasonlítja össze, észreveszi az átméretezett képeket is. Második körben pedig manuálisan töröljed az értéktelen/életlen képeket, amiknek már nincs hasznuk.
Biztos vannak érvek a konvertálás mellett is.

Ott a tükörreflexes gép eredeti "digitális negatív" kép (Canon esetén CR2) átkonvertálása DNG-re. Én ezt sem teszem meg, mert nem félek attól, hogy nem lesz megnyitható. Az Adobe Camera Raw tökéletesen olvassa, konvertálja, és nem várható, hogy egyszer csak ez változna. A formátum nem változik, ez már kész megoldás.
Nekem nagy hely megtakarítás volt, hogy amikor egyszerre készült JPG és CR2, akkor letöröltem a JPG-t. Pár esetben pedig a CR2-t, amikor például egy jegyzetet fotóztam, amikor nem kell a negatív, mert nem hívom elő.

Sakk-matt,
KaTT :)

( XMI | 2017. 09. 27., sze – 00:25 )

Régebben tesztelgettem ezeket saját képeken. Aztán végül letettem arról, hogy a képarchívumomat átkonvertáljam. Sajnos a pontos eredmények nincsenek meg, ezért inkább csak szubjektív véleményt tudok mondani.

Először is meglepően lassú a betömörítés, főleg BPG-nél. Ez akkor kellemetlen, ha manuálisan játszogatni kell a minőséggel. A manuális próbálgatást eléggé nehezíti az is, hogy pl gimp-ben nincs olyan preview, mint a jpeg-nél + a már kész képeket sem tudtam az általam használt képnézegetőkben direkben megnézni. A bpgview ehhez elég béna, más nem nyitotta meg. (Vagyis bash-ből for ciklusban bpgenc, q érték a futóváltozó, aztán bpgdec vissza png-be és azt néztem meg)

A minőségere egyértelműen a sorrend: BPG (h265), Google AV1 (tavalyi snapshot build) végül VP9 és WEBP (VP8) ez utóbbi kettő kb egy szinten teljesített, kicsit más volt a kép, de nem volt egyértelmű sorrend közöttük.

DE...

Első körben "vizuálisan kvázi-veszteségmentes" minőségi szintet akartam belőni -> azt a pontot ahol oda-vissza ugrálva az eredeti és a tömörítésen átesett kép között szabad szemmel már nem látok részletekben sem változásokat, még a zaj is látszólag ugyanúgy áll. Ez egyébként számomra meglepő módon egy elég jóldefiniált pont, többszöri próbálkozásra is +/-1 minőségi értéken belül ugyanoda lőttem be. Nyilván függ a monitortól is, egy régebbi de viszonylag jó SPVA-paneles monitorral próbáltam, elég jó kontrasztja és színvisszaadása van, garantáltan 8 bites a panel, nincs dithering stb.

Erre a pontra kb minden codec-kel úgy adódott, hogy a kép mérete nagyságrendileg az eredeti jpeg méretével volt azonos, minimális mértékben lett csak kisebb. 4kx3k-es 8 bites fényképekről volt szó, amit a fényképező átlagos 6MB körüli JPEG-be tömörít. BPG-vel és WEBP-vel is 4-5MB-nál nem lettek kisebbek a képek. Ennyit majdhogynem a JPEG huffman-tábla újraoptimalizálással is lehet nyerni (pl mozjpeg ilyet csinál - igaz az még a BPG-nél is sokkal lassabban dolgozik, cserébe standard jpeg lesz a kimenet).

A jelentősebb nyereség akkor jön be, ha bevállal az ember valamennyi plusz minőségvesztést. Ha nem baj, hogy a zaj mintázata kissé "átrendeződik", akkor lehet lejjebb menni, és ilyenkor a BPG elkezd a többihez képest konzisztensen kisebb képet csinálni szemre kb hasonló minőség mellett.

A következő lépés, hogy bizonyos apróbb részleteknél a zaj eltűnik a képről, mintha itt-ott zajszűrőt kapott volna. A BPG-nél ez eleinte nem igazán zavaró jelenség, a WEBP-nél és a VP9-nél viszont a kevésbé kontrasztos képrészek elég nagy foltokban kezdenek egyszerre elmosódni, ami szemre észrevehető. Az AV1 emlékeim szerint ebből a szempontból előrelépés volt a WEBP-hez képest. Itt már elég jelentős méretkülönbségek vannak, egyértelműen a BPG javára de ez jó minőségben megtartásra szánt képeknél nekem már nem játszott.

---
Régóta vágyok én, az androidok mezonkincsére már!

( horvatha | 2017. 09. 27., sze – 13:37 )

Elolvastam minden hozzászólást és okosodtam. Kösz!

Amit leszűrtem:

a) Ha nem akarok látható minőségromlást, akkor csak max. 20% helytakarékosságra számíthatok. Jó kérdés, hogy ezért megéri-e bevállalni a konverziót meg a kényelmetlenséget, hogy BPG-t és másokat nem minden program támogat.

b) Más vonal a jpeg optimalizálás, mert az veszteségmenetesen elintézhető. Ezt még megnézem, mert egy gyors teszt után valamit még nem értek.
Volt olyan kép itt kéznél, amit a "mozjpeg -opt" nagyobbá tett, hacsak nem csináltam progresszív kimenetet. Amit nem értek, hogy ha a progresszív kisebb lesz, akkor miért nem tartalmazza azt is az optimalizáció. Vagy egyik kép progresszívben, másik nem abban lesz kisebb?

Csináltam pár összehasonlítást:
- HEIF (192k, q=60) vs Mozjpeg (369k, q=80): http://screenshotcomparison.com/comparison/118649
- HEIF (288k, q=66) vs Mozjpeg (369k, q=80): http://screenshotcomparison.com/comparison/118651
- HEIF (192k, q=66) vs Mozjpeg (190k, q=45): http://screenshotcomparison.com/comparison/118652

Konklúzió:
192k-s HEIF (h265) a feleakkora méret ellenére összehasonlítható eredményt nyújt. Nem "szőrösödik" a homogén felületeknél, de vesznek el részletek: a híd szegecselése, mozdonyvezető arca. A 288k-s HEIF-nél már visszatérnek ezek a részletek, de az így elért 25%-os megtakarítás miatt már valóban nem éri meg szerintem átállni.

A 190k-ban a jpeg értékelhetetlen minőséget nyújt. Ezek miatt szerintem főleg olyan felhasználásra alkalmas, ahol az alacsony méret fokozottan fontos (pl web), mert nem csak tárolni kell, hanem kiszolgálni is.

A jpeg esetén én is észrevettem ezt a jelenséget, gimp-ben a standard libjpeg-turbo library-vel linkelve is. Nem ritka hogy progresszivben kisebb a fájlméret, bár általában csak marginálisan. Nem jártam még utána a pontosabb okának, bár szerintem azon múlik, hogy ilyenkor a blokk DCT együtthatóit máshogyan rendezi el a streamben, és a veszteségmentes kódolási (RLE+Huffman) szakaszban szerencsésebben jön ki.

Az, hogy a mozjpeg tud-e veszteségmentesen optimalizálni erősen múlik azon, hogy az eredeti jpeg mennyire volt már eleve optimalizálva. Tapasztalatom szerint sok kamera energiatakarékosságból vagy gyorsaság miatt statikus huffman táblával vagy valami ehhez hasonló durva kompromisszummal dolgozik. Ezeken nagyot lehet optimalizálni, néha 20%-ot is, de 5-10% szinte mindig megvan. Ami jpeg már pl gimp-ből értelmes beállítással lett mentve, azokon alig tudsz fogni.
---
Régóta vágyok én, az androidok mezonkincsére már!