"Ez a keresőóriásnak nyilván fontos szempont, hiszen a gyorsabb oldalbetöltés egységnyi idő alatt több oldalletöltést jelent"

A tömörítés a weblapokon hogyan érvényesül?
A weblap üzemeltetőjének konfigurálni kell valamit vagy automatikus lesz?

[ Szerkesztve ]

Szerintem a jpeg állományt kell a google tömörítőjével létrehozni, úgy lesz kisebb a szabványos libjpeg-et felhasználó programoknál.

És ez jobb, mint a BPG kiterjesztés?

[ Szerkesztve ]

Leteszteltem, mert kíváncsi voltam. Nálam az a 35% inkább csak 15%, és baromi lassú. Értsd: iszonyatosan lassú. Egy ~2500×2500 pixeles és 1005 KB-os termékfotót sikerült neki 8-10 PERC (!!!) alatt feldolgoznia, és 870 KB lett a vége. Mindezt úgy, hogy a 8 magos 3GHz-s procit folyamatosan 15-16%-on terhelte, és 1.3 GB (!) RAM-ot evett meg közben. Ez normális? Ilyen sebességgel nem fogom átméretezni a kb 80.000-es képállományt, mert jövő ilyenkorra se végezne. De legalább minőség romlást nem tapasztaltam.

Gondolom számít az is, hogy JPG-t akarsz átkonvertálni ezzel az új algoritmussal, vagy egy tömörítetlent.
(feltételezem, hogy az eredeti forrást átkonvertálva jobb eredmény érhető el, úgy lehet, hogy meglenne a ~30%.)
Bár a weboldalaknál kevés esetben van meg az eredeti tömörítetlen kép, így az átlag javulás sem lesz annyira látványos, mint "labor" körülmények között.

8mag 15-16%-on, az számomra azt jelenti, hogy 1 szál dolgozott. Ez valóban nem túl hatékony.

Az eredetihez képest nagyon kevés a 30%!

Kössünk egyezséget, megegyezős egyezséget... https://www.paypal.me/engiman/30

Grafikon szerint nem 1 szálat húzott, mind a 8 recegett. Inkább opimalizálási probléma lehet még benne. Illetve a memóriakezelése is gondot okozhat, mert hiába a 8 szál, ha ennyi memória kell neki, az meg lassú a 8 maghoz. De mindenképp van még mit fejleszteni rata. Amúgy mi számít "eredetinek"? bmp? Ahhoz valóban gyenge lenne a 30%. Nyilván a jpg-nek is ezer féle tömörítési beállítása lehet, már csak ha a minőség %-át állítgatod. Egyelőre nincs azon a szinten, hogy megérné használnom, pedig felcsillant a szemem a cikk ovasása közben

kipróbáltam és tényleg extrém lassú, illetve irdatlan erőforrást emészt fel a többihez képest

azt elhiszem hogy nehéz újítást hozni a JPG kódolásban úgy hogy visszafelé kompatibilis legyen, de ez így nem hiszem hogy megérné nagy mennyiségben használni - pl a google fotókban tárolt összes (összes) képet ezzel átkódolni

a BPG tudtommal egy új kép formátum, tehát hiába szuper és fantasztikus, ameddig nem támogatja a három nagy böngésző MIND addig nem sokat ér

nagyban kell gondolkodni. pl.: 30TB vs 21TB

Nem ahhoz viszonyítva értettem a 30%-ot, hanem a JPG-hez.
Viszont nem a JPG-t újratömörítve, hanem az eredeti forrást (pl. BMP).
Merem feltételezni, hogy ha nem a veszteséges JPG-t tömörítjük újra, hanem az eredetit, akkor jobb hatékonysággal tömörít, így elérhető a jpg-hez viszonyított jobb arány, nem az említett 15%, hanem picit jobb.

megnéztem a blogos szöveget, ott 35%-ot, a github-on 20-30%-ot írnak mint hatékonyság
a szövegből tényleg nem derül ki hogy mihez képest

eredeti optimalizálatlan, vagy a már optimalizált jpg-hez képest (na ez buli lenne ha itt lenne 20-30%)

meg kell hogy cáfoljam magam, ez a cucc tényleg nem semmi :-)

egyenlőre 2 db, már eleve optimalizált jpg-en próbáltam ki:
175 kb >> 99 kb - 65 sec - 1240x811 pixel - téma: világos kép, sok benne a fehér
187 kb >> 126 kb - 79 sec - 1240x840 pixel - téma: színekben és részletekben gazdag

az így "megrágott" képeket összehasonlítottam az eredetivel vizuális módon (link) és valóban nincs látható különbség!

( az "eredeti" ebben az esetben így készült: mogrify -strip -interlace Plane -resize 1240 -quality 95 )

A Guetzli-t mindenféle buherálás nélkül futott le. Tudom hogy ő is alapesetben 95-os minőséggel dolgozik, de ez szerencsére egyik esetben sem látszódik egyáltalán, tehát ha rontson rajta még egy kicsit ha úgy csinálja hogy nem látszik.

Az egyszerűség kedvéért számoljunk azzal hogy 1 perc alatt végez egy képpel.
24 óra alatt 1440 képet csinál meg, képenként 60 kb-ot megtakarítva, akkor ez azt jelenti hogy lesz egy saját "szabadhelygenerátor"-om, amivel naponta 86 megát tudok "csinálni", vagyis havonta 2,5 giga helyet csinál nekem
Persze tudom hogy ezt így nem lehet kiszámolni, de azért ad valami képet számomra hogy érdemes-e vele foglalkozni -> Igen!

(a fenti benchmarkot egy friss installos mini vps produkálta, 1 maggal és 1 giga rammal)

Technikailag és minőségileg tényleg jó cucc. De a mi cégünk képállományán kb 1 év alatt végezne 7/24-ben, amivel kb 5-8 GB-ot tudnánk spórolni Ja és évente frissülnek az állományok, így mehetne non-stop
Nem beszélve, hogy az eredeti felbontás mellett több méretben is tároljuk a webhez optimalizálva (90×90, 150×150, ...) Így már több százezres állományról beszélgetünk. Sajnos akármilyen jó minőségű 1-1 képre, számomra egyelőre nem aktuális. De hajrá a fejlesztőnek!

ez nemcsak a tarolas miatt erdekes a googlenek, hanem a netes forgalom miatt: ha egy 100kb-os kepet ossze tud nyomni 70kb-ra, akkor egymillio letoltesnel az 30G-val kevesebb forgalom. es a googlenel nem egy kep van, es nem egymillio letoltessel.

Persze, jogos, és értem is ezt, de a befektetett energia nem látszik megtérülni. Ha a feldolgozás sebességén szignifikánsan gyorsítanának, akkor lehetne hasznos. Így nettó energiapazarlás. A Google-nek persze van számítási kapacitása, de kép állománya is bőven, így az arány is kb megvan. De még náluk is kérdésesnek találom az alkalmazhatóságát ennek - a jelenlegi szinten.

Nálam csak 1 magot terhel 100%-ra, és 500-600MB között használ memóriát. Baromi lassú. Viszont nem minden esetben jó az alkalmazása. Vannak olyan PNG képeim, amik nagyobbak lesznek a normál JPG tömörítésű képeknél. A minőség mind a két esetben 95. Csak PNG képekkel próbáltam.

[ Szerkesztve ]

Ha csalódni akarsz, bízz az emberekben!

Nekem is vannak kis képek a nagyból, de azokkal természetesen sokkal gyorsabban végez, így azokat is megéri átfuttatni rajta, hiszen ott is lehet spórolni.

Nálam több mint 1.1 millió jpg kép van max. 1240 pixel szélességben (+ ugyanennyi kiskép (160x250)) közel 1TB helyet foglalva.

Az átkódolásra egy havi 300 Ft (+áfa) -os VPS-t fogok használni ([link]), így havi 381 Ft-ból lesz 2,5 giga helyem 1 hónap múlva. Illetve ha gyorsabban szeretnék több helyet akkor beállítok a csatasorba még egy ilyen miniVPS-t...

A veszteséges újrakódolás mindig minőség romlással jár.
381Ft 2.5gb = 152000Ft 1Tb Nem olcsóbb egy új Hdd?

4.7gb lemez 70Ft
25gb lemez 500Ft

Így nem éri meg...

szerveren levő képekről van szó, ott pedig számít
főleg annak fényében hogy havi 381 ft-ba kerül csak mindössze, hogy legyen egy kis helyem úgy hogy nincs belőle hátrányom, veszteséges igen, papíron, de valóságban nem veszed észre!

A webp-t és az apng-t se nagyon támogatja semmi, pedig pár éve megvan. Sőt, ha a böngésző támogatja, a legtöbb oldalon pl. az apng akkor is áll. Amúgy a példaképen el van színeződve... Az egy dolog, hogy a nagy egybe szín kicsit kevésbé zajos, de a jpeg legalább olyan színű.

ASRock Z370 Pro4+i3-8100+32GB Windows 22631.2361 Ubuntu 23.10 x64

Valóban lassú, és rettentő sok RAM-ot használ, ismert problémák.
Egy Xeon-on kb. 1 perc/MPixel, a lineárisnál kicsit gyorsabban növekszik a képméret függvényében. A memóriaszükséglet kb. 300 MB/MPixel. Nem nyomtatásra, hanem megjelenítésre szánt, max. 1-2 MPixeles képek optimalizálása a Google fő célja.

https://github.com/google/guetzli/issues/11
"Please note that Guetzli assumes that the image will be viewed at a reasonable DPI."

https://github.com/google/guetzli/issues/50
"It's true that Guetzli is really slow to compress. As a rough order of magnitude estimate, it takes ~ 1 minute / MPixel on a 2.6 GHz Xeon. The time consumed should increase a bit more quickly than linearly with image size."
"According to the readme Guetzli uses ~300MB per MPix"