GPRS - kompresja wyświetlanych zdjęć

[muflon]

Inna sprawa jak mowimy o kompresji to musiala by byc wybiorcza, bo pakowanie jpeg-a itp. raczej mija sie z celem

Wręcz przeciwnie, właśnie JPEG jest idealnym kandydatem do takiej rekompresji "w locie", praktycznie bezczasowo.

[tplewa]

Wręcz przeciwnie, właśnie JPEG jest idealnym kandydatem do takiej rekompresji "w locie", praktycznie bezczasowo.

no w sumie tak tylko wychodzi najczęściej większy niż oryginał po kompresji, bo trudno tam już coś skompresować znanymi algorytmami ale fakt algorytmy w takich wypadkach działają szybciej...

[Kolaj]

no w sumie tak tylko wychodzi najczęściej większy niż oryginał po kompresji, bo trudno tam już coś skompresować znanymi algorytmami ale fakt algorytmy w takich wypadkach działają szybciej...

Źle kombinujesz. To jest kompresja stratna. Mocno stratna. Właśnie dlatego autor wątku widzi obrazek mający 15kb, chociaż na serwerze leży >100kb.

Ale u mnie wszystkie fotki do momentu otwarcia ich w nowym oknie są z paskudnymi artefaktami a ten powyższy plik waży 15 kB zamiast 100

[tplewa]

Źle kombinujesz. To jest kompresja stratna. Mocno stratna. Właśnie dlatego autor wątku widzi obrazek mający 15kb, chociaż na serwerze leży >100kb.

He he to sobie spakuj na dysku jpeg-a zipem, rarem itp. to zobaczysz... tu nie ma znaczenia czy to kompresja stratna czy bez stratna. W jpeg-u jest bardzo mała ilość powtarzających się sekwencji (to tak w uproszczeniu) z których mogą skorzystać algorytmy kompresji. A przesyłany jest plik więc liczy się jego rozmiar... algorytm wyświetlający lokalnie dopiero dekompresuje np. jpeg-a

[muflon]

no w sumie tak tylko wychodzi najczęściej większy niż oryginał po kompresji, bo trudno tam już coś skompresować znanymi algorytmami ale fakt algorytmy w takich wypadkach działają szybciej...

He he to sobie spakuj na dysku jpeg-a zipem, rarem itp. to zobaczysz... tu nie ma znaczenia czy to kompresja stratna czy bez stratna. W jpeg-u jest bardzo mała ilość powtarzających się sekwencji (to tak w uproszczeniu) z których mogą skorzystać algorytmy kompresji. A przesyłany jest plik więc liczy się jego rozmiar... algorytm wyświetlający lokalnie dopiero dekompresuje np. jpeg-a

Nie, tu nie chodzi o żadne "znane algorytmy", tylko o manipulacje na danych zapisanych w JPEGu, bez jego rekompresji.

Konkretnie i technicznie (zakładając, że masz jakieś pojęcie o plikach JPG i kompresji opartej o transformaty): wycięcie pewnej ilości składowych IDCT, które są "dalej" w kolejności zigzag. Trochę tak, jak np. LAME potrafi "bezstratnie" - w sensie: bez rozpakowywania do PCM i ponownej kompresji - zmniejszyć bitrate MP3. Jedno i drugie sprowadza się do relatywnie prostych operacji na danych w pliku, nie ma tu żadnych "algorytmów".

[tplewa]

Nie, tu nie chodzi o żadne "znane algorytmy", tylko o manipulacje na danych zapisanych w JPEGu, bez jego rekompresji.

Konkretnie i technicznie (zakładając, że masz jakieś pojęcie o plikach JPG i kompresji opartej o transformaty): wycięcie pewnej ilości składowych IDCT, które są "dalej" w kolejności zigzag. Trochę tak, jak np. LAME potrafi "bezstratnie" - w sensie: bez rozpakowywania do PCM i ponownej kompresji - zmniejszyć bitrate MP3. Jedno i drugie sprowadza się do relatywnie prostych operacji na danych w pliku, nie ma tu żadnych "algorytmów".

No mam pojęcie o transformacie kosinusowej ale o wycinaniu odwrotnej transformaty nie myślałem. Ciekawe jak wygląda taki plik po wyświetleniu...
...aż sobie chyba to sprawdzę...

[muflon]

Ciekawe jak wygląda taki plik po wyświetleniu...

Od odpowiedzi na to pytanie zaczął się ten wątek Proste: wygląda tak, jak JPEG zapisany z większą kompresją...

[tplewa]

Od odpowiedzi na to pytanie zaczął się ten wątek Proste: wygląda tak, jak JPEG zapisany z większą kompresją...

albo już wcale nie wygląda

i prawdę mówiąc w mojej karierze jako admin u kilku providerów się z czymś takim nie spotkałem... zresztą nie wiem ile by się statystycznie zyskało przy takiej kompresji JPEG-a zważywszy że trzeba analizować cały ruch... (tzn. ile % zajmuje w paśmie transfer jpeg-ow).

Zresztą i tak na BTS-e jest ruch priorytetowany i data nie ma najwyższego priorytetu. Dlatego między innymi obiecanki typu 7.2Mbps są to marketingowe bzdury bo tyle to można uzyskać będąc na sektorze samemu...

Więc dalej nie wiem czy taka wybiorcza kompresja ma sensowne podstawy finansowe dla sieci GSM, na pewno T-Mobile na słowacji w Flarionie tego nie używa - tą sieć akurat znam. Może inne sieci hmm

Zwłaszcza że zmorą najczęściej nie są obrazki itp. tylko torrenty itp. to potrafi każde łącze wysycić...

[muflon]

i prawdę mówiąc w mojej karierze jako admin u kilku providerów się z czymś takim nie spotkałem...

google:"mobile jpg traffic recompression solution", pierwszy strzał: http://www.radware.com/Solutions/Car..._features.aspx, piąty akapit.

zresztą nie wiem ile by się statystycznie zyskało przy takiej kompresji JPEG-a

Tyle na ile pozwala bezczelność operatora