Hirdetés

2017. november 18., szombat

Gyorskeresés

Hozzászólások

(#1) Sanyi.mTs


Sanyi.mTs
(őstag)
LOGOUT blog

"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 ]

|| PSN: geneMTS || Lenovo X200 || Moto X play || ASUS MeMo Pad 7 (ME572C) ||

(#2) Zigur válasza Sanyi.mTs (#1) üzenetére


Zigur
(senior tag)

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.

(#3) mtibee2


mtibee2
(kvázi-tag)

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

[ Szerkesztve ]

(#4) Taybore


Taybore
(senior tag)

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.

[ Samsung Galaxy S8 + Gear S3 ][ Waze.hu ]

(#5) BiP válasza Taybore (#4) üzenetére


BiP
(PH! kedvence)

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.

(#6) bacus válasza BiP (#5) üzenetére


bacus
(senior tag)

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

"Nagyon rossz lány voltam. Meg kell büntess !" nyögte a fülembe, így aztán telepítettem a windows 10-t a laptopjára... https://www.paypal.me/engiman/15

(#7) Taybore válasza BiP (#5) üzenetére


Taybore
(senior tag)

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? :D 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 :K

[ Samsung Galaxy S8 + Gear S3 ][ Waze.hu ]

(#8) szunyika


szunyika
(tag)

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

(#9) Sanyi.mTs válasza bacus (#6) üzenetére


Sanyi.mTs
(őstag)
LOGOUT blog

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

|| PSN: geneMTS || Lenovo X200 || Moto X play || ASUS MeMo Pad 7 (ME572C) ||

(#10) BiP válasza bacus (#6) üzenetére


BiP
(PH! kedvence)

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.

(#11) szunyika


szunyika
(tag)

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%)

(#12) szunyika


szunyika
(tag)

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)

(#13) Taybore válasza szunyika (#12) üzenetére


Taybore
(senior tag)

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 :D 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! :C

[ Samsung Galaxy S8 + Gear S3 ][ Waze.hu ]

(#14) Elbandi válasza Taybore (#13) üzenetére


Elbandi
(fanatikus tag)

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.

(#15) Taybore válasza Elbandi (#14) üzenetére


Taybore
(senior tag)

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. :R

[ Samsung Galaxy S8 + Gear S3 ][ Waze.hu ]

(#16) Sonja


Sonja
(PH! kedvence)

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 ]

Huawei P9 Lite (Android 7.0, EMUI 5.0), Apple iPad Mini (iOS 7.1.2), Kobo Glo HD (FW 3.19.5761), Nook Simple Touch (FW 1.2.1) - Linux User #586716

(#17) szunyika válasza Taybore (#13) üzenetére


szunyika
(tag)

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...

(#18) borg25 válasza szunyika (#17) üzenetére


borg25
(fanatikus tag)

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...

(#19) szunyika válasza borg25 (#18) üzenetére


szunyika
(tag)

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!

(#20) gyulank


gyulank
(őstag)

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ű.

GA-G31M-ES2C(1.x)+E8400+4GB Windows 10 x64 /Mégmindigszar/ Ubuntu Stúdió 17.10 x64

(#21) Kofa válasza Taybore (#4) üzenetére


Kofa
(újonc)

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"

Copyright © 2000-2017 PROHARDVER Informatikai Kft.