Dropbox přestavil bezeztrátový obrazový formát Lepton (diskuse)

[Jaroslav.K]

Lepton is a tool and file format for losslessly compressing JPEGs by an average of 22%.

Ja tomu rozumim tak, ze to umi bezeztratove komprimovat obrazky v jpegu, takovy vykonny zip. Nejsem si jist, ze by to umelo bezeztratove uchovat treba png.

[Ladislav Hagara]

Bezeztrátové PNG převést na bezeztrátový JPEG?
"Obrazový formát pro bezeztrátovou kompresi JPEG" je přesnější.

[Ladislav Hagara]

Zprávička aktualizována.

[Švanda Dudák]

Takovouhle technologii měl už dřív jeden archivátor pro Macy, tuším se to jemnovalo Stuffit. Ale ideálně by to chtělo, aby to fungovalo transparentně a ty obrázky se daly rovnou porhlížet, což s ním IIRC nešlo.

[Kvakor]

Pamatuju si, že před mnoha lety jeden kompresní program pro DOS (jeho jméno začínalo na U, ale víc si nevybavuju) uměl při kompresi rozpoznat typ dat a měl speciální profil i pro JPEGy. Tenkrát jsem se divil, že dokázal zkomprimovat i komprimovaný formát, i když to bylo (pokud si dobře pamatuju) špíš tak o deset než o dvacet procent.

[michi141]

UHARC?

[klingger]

Myslím že to bol Ultra Compressor II (UC2)

[user490]

Ako môže byť bezstrátový formát účinejší ako strátový?!

[ikar]

Co tak si přečíst původní článek, zkompilovat a vyzkoušet?

[Filip Jirsák]

Může^*), ale to není tento případ. Obrázek JPEG zkomprimován ztrátově a výsledná data se komprimují bezeztrátově (algoritmus podobný zipu). Kdyby byl ten bezeztrátový algoritmus ideální, tak by už bezeztrátově zkomprimovat nešel. Jenže ten algoritmus zas až tak dobrý není, víte, že dnes už existují lepší kompresní algoritmy než je starý zip. V Dropboxu tedy vymysleli kompresní algoritmus, který takhle bezeztrátově zkomprimovaná data dokáže zkomprimovat lépe. Takže ta původní ztrátová komprese je tam pořád, akorát se její výstup zkomprimuje lepší bezeztrátovou kompresí.

*) Zkuste si z textového souboru smazat poslední znak - to je příklad ztrátové komprimace, a pak ten původní nezkrácený soubor zkomprimujte zipem - bezeztrátové komprimace. Ten druhý soubor bude určitě menší - protože ta zvolená ztrátová komprese byla hodně neefektivní.

[Fluttershy, yay!]

To je nesmyslná otázka. Tady se totiž porovnávají různé zdroje dat – pro JPEG jsou to obecně obrazová data, pro Lepton data ve formátu JPEG – tj. zdroje s různými charakteristikami.

Je běžná praxe, že na data se během komprimace postupně aplikují různé kompresní algoritmy.

Samotný proces ukládání dat do formátu JPEG zahrnuje několik transformací následovaných kompresí variantou Huffmanova kódování IIRC. Lepton zřejmě přidává ještě další krok, a sice kompresi těch dat zakódovaných „Huffmanem“.

Je to analogické tomu, když BMP používá run-length encoding, na což můžeme dále poštvat běžný kompresní nástroj (*ZIP, RAR,…).

[Lol Phirae]

NSA dochází místo na disku?

[Grunt]

Spíš DropBoxu. Jestli jsem to správně pochopil, tak vypáčili z VP8 aritmetické kódování, šoupli před to nějaký prediktor, všechny obrázky co mají u sebe poukládané tím projeli, šoupli před linku nějakou mašinu co tohle schéma zase zpětně rozkóduje do Zigzagu, RLE a Huffmanová kódování a to pak šoupou po internetu jako klasické JPEGy klientům. Geniální. Ze zoufalství už neví co by.

[Kvakor]

Ono bylo aritmetické kódování součástí JPEG standardu už od začátku, ale téměř nikdy se nepoužívalo, protože bylo beznadějně zazděné všemožnými softwarovými patenty (takže ho nakonec nepoužíval nikdo, což je další důkaz praštěnosti amerického systému patentů v této oblasti). Sice už dnes všechny vypršely, ale kdyby ho někdo zkusil zavést zpět do JPEGu, okamžitě se stane nekompatibilní se zbytkem světa.

[Grunt]

Však to taky bylo stěžejním bodem kompresních programů toho tipu o kterém je řeč o něco výše. To samé se dneska týká BPG (alias HEVC Main Still Picture), který dělá úplně to samé a ještě lépe, ale vzhledem k oblepenosti patentama a z toho vyvozené 0% podopoře v prohlížečích se vymýšlejí takové střeva jako Lepton.

[fukfukfuk]

Tak pouzij misto BPG Daalu a mas po ptakach (po patentech)...

[Grunt]

Přílohy:

• bez_komprese.jpg (904135 bytů)
• Bpg.jpg (793159 bytů)
• daala.jpg (862135 bytů)

Tož zrovna včera jsem se s tím hrál a musím podotknout, že BPG se mi pro přenos stacionárních obrázků nelíbí ani trochu, protože z toho leze pomalu to samé co z toho Intra-Paint Algoritmu se kterým se hráli. Vhodné pro I-Framy které na tom budou budovat s MC a residuuama v podobě PB-framů? Určitě. Vhodné jako náhrada JPEGu či jiného stacionárního obrázkového formátu? Ani omylem. Jenže v tomhle ohledu se mi Daala líbí ještě míň. Takže asi tak.

[sk7]

Pre BPG používaš zlý quantizer ,treba dat napr. -q 10 defaultne je quantizer na 29
a encoder dat na x265 , pri novších verziách bpgenc je už defaultne x265 inak treba zadat -e x265

[Grunt]

To sem nedělal já. To jsou PNG z těch jejich demo stránek. Nevím co použili, ale musím dodat že já z toho nedostávám o nic lepší výsledek. Těžko říct jestli je to výdledek tak brutálního deblockingu nebo do x265 fakt nacpali nějaký Intra-Paint algoritmus.

a encoder dat na x265 , pri novších verziách bpgenc je už defaultne x265 inak treba zadat -e x265

?:

-lossless            enable lossless mode
-e encoder           select the HEVC encoder (x265, default = x265)
-m level             select the compression level (1=fast, 9=slow, default = 8)

Tam jde dat i něco jiného?

treba dat napr. -q 10 defaultne je quantizer na 29

Tak dva týdny zpět jsem zase pro změnu zkoušel sekvenci QP od 1 do těch 50 a musím říct že 29 je velmi racionálně nastavená hodnota. Na tom netřeba nic měnit ty desítko.

[Petr Tomášek]

Ocividne tam mas dost starou verzi Daaly (tipoval bych nejmin 1.5 let), ktera ma nektere uz davno opravene chyby (vypadky celych bloku)...

[Grunt]

Ale jinak libjpeg umí aritmetické kódování od verze 7 a jpegtran umí mezi nima šoupat bez nejmenších problémů.

[Lol Phirae]

Spíš DropBoxu.

To není jeden podnik?

Jinak to opravdu vypadá hodně zoufale, to snad nedává vůbec smysl, nepřidávají do těch obrázků nenápadně něco (žluté tečky)?

[Grunt]

To není jeden podnik?

Vim já? Já jim tam nic nezálohuju. Občas odtud dostanu data od klientů co to používají (ti spolehlivější mají vlastní NAS!).

Jinak to opravdu vypadá hodně zoufale, to snad nedává vůbec smysl, nepřidávají do těch obrázků nenápadně něco (žluté tečky)?

Však se taky v komentářích kdosi rozčiloval:

"We have used Lepton to encode 16 billion images saved to Dropbox, and .. saved Dropbox multiple petabytes of space."

Are you saying here you're willingly mutilating customer data just to save a few tens of thousands dollars in storage costs??? If I upload some images to dropbox I'm not going to get the exact same bits back out of it? Where is this even allowed in your ToS?

No vysmahl protože je to formát bitově exaktní, ale vsadil bych se že to nikdo nezkoušel a netestoval.

[Grunt]

Já spíš žeru jak si každý vymýšlí vlastní obrazový formát efektivnější než JPEG (dodám že samotný vývoj formátu začal v roce 1986, tak to ani není moc těžké) ale pravděpodobnost že bude masovou náhradou na internetu za JPEG samotný je tak daleko jako další nejbližší hvězda.

[Acci]

No právě proto nevymýšlí vlastní formát, ale jen jeho lepší bezztrátovou kompresi na jejich serverech. Nikde jsem nenašel, že by plánovali rozšíření tohoto formátu například do prohlížečů.

[Grunt]

No vždyť. A pak před to musíš šoupnout mašinu která to bude rozbalovat a přebalovat do JPEGu. Oni by docela rádi ušetřili lajny i ISPčka. Tohle řešení je to pověstné šťourání se v levé nosní dírce pravou rukou.

[Acci]

Tak to pak implementují do synchronizačního klienta a dekódovat to budou muset jen při zobrazení přes web.

[Grunt]

- *výtlem* -

Ale proč ne?

[Acci]

Tak prosadit vlastní formát místo JPEG se snaží jiní a větší (například Google s jejich WEBP, který podporuje Chrome a přes JavaScript i Firefox a další) a stejně se jim to nedaří. Tak Dropbox na to šel z jiného konce, kde to bude plnit jejich potřeby.