GPRS - kompresja wyświetlanych zdjęć [Archiwum]

tantal

16-07-2009, 15:36

Witam,
jak to jest z wyświetlaniem zdjęć na stronach, mam galerię coppermine i patrzeć na nią nie mogę, domyślana kompresja wyswietlanych zdjęć jest obrzydliwa, picowanie i resamplowanie zdjęć mija się z celem:( żadne zaklęcia ctlr+R, shift+A nie działają
Wniosek jest taki, że jeśli ja nie mogę patrzeć na te fotki to odwiedzający tym bardziej :???: chamówą byłoby zmuszać wszystkich do pobierania trochę większych plików ale strony z fotografiami są dla oka więc jakąś możliwość poprawy wyglądu powinienem oferować. Być może u mnie w systemie coś nie tak ? Bo mam wrażenie że to od nie dawna na moim kompie tak się wyświetla. Przykład
1.oryginalny obrazek

https://canon-board.info//brak.gif
źródło (http://img142.imageshack.us/img142/5301/crw7686.jpg)2.link do zdjęcia na coppermine
http://jarex.freehostia.com/displayimage.php?album=lastup&cat=0&pos=0
A może to wina coppermine że skróty nie działają ? jak dać szansę odwiedzającym na zobaczenie zdjęcia w normalnej krasie ? Dodam że z Internet Explorerem mam podobnie i też od niedawna , ale pal licho mnie , gorzej że oglądający widzą takie g...bez możliwości poprawy widoku :(
No dobra, w Firefoxie coś działa ale tylko dla zdjęcia otwartego w nowym oknie, przy normalnym przeglądaniu nic nie działa...

Kolaj

16-07-2009, 15:40

tantal

16-07-2009, 15:44

Nie widzę różnicy pomiędzy oryginałem i tym, co jest pd linkiem. FF nie "obrabia" w żaden sposób zdjęć.
Sorki, edytowałem posta.
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
Mocno dziwi mnie że do tej pory nie miałem takiego wyglądu ani w w Ie ani w Ff a wersji coppermine ani przegladarek nie zmieniałem
:shock:

Kolaj

16-07-2009, 15:47

u mnie ma 101,5k. Może używasz jakiegoś proxy z kompresją. Albo korzystasz z dostępu przez sieć GSM i tam w zależności od wybranego APN-a może też następować kompresja.

dgcracker

16-07-2009, 15:52

U mnie jak u kolegi powyzej - roznic brak, wielkosc 101,5 kB.
Pozdrowienia,
D.C.

tantal

16-07-2009, 16:45

Dzięki, panowie.
To już coś dla odwiedzających... Fakt - korzystam z GPRS, ale traffic compressora wyłączyłem chwilowo (zresztą jpg i tak nie kompresował). APN pewnie ma znaczenie, tyle że skróty shift+A, shift+R dla canon-board działają, dla galerii - nie. Działają dopiero po otwarciu zdjęcia w nowym oknie. Coppermine mam ustawione na 100% jakości wyświetlanych plików, zakaz tworzenia zdjęć skalowanych (pośrednich), więc to co się wyświetla po kliknięciu w podany przeze mnie link powinno mi ważyć ok 100Kb - tyle ile uploadowałem, a mam 15 z paskudnymi artefaktami na jednorodnych przestrzeniach i obwódkami na krawędziach. Dzięki za uwagi, poszperam jeszcze w dokumentacji coppermine.

Kolaj

16-07-2009, 16:53

Dzięki za uwagi, poszperam jeszcze w dokumentacji coppermine.Ale w coppermine jest wszystko ok. Obrazek wyświetlany w galerii ma 101,5kB.

tplewa

16-07-2009, 17:12

Nie widzę różnicy pomiędzy oryginałem i tym, co jest pd linkiem. FF nie "obrabia" w żaden sposób zdjęć. Coppermine może przeskalowywać obraz i wtedy robi to swoimi algorytmami, co może powodować utratę jakości.

Dokłądnie używa do tego biblioteki GD lub ImageMagick... i perzeskalowuje jedynie do miniaturek. W oryginalnym rozmiarze sa wyświetlane bez ingerencji.

tantal

16-07-2009, 17:44

Ale w coppermine jest wszystko ok. Obrazek wyświetlany w galerii ma 101,5kB.
Rozumiem, dzięki.
Czyli chodzi o mój net. Jak wspominałem, problem pojawił się dopiero "na dniach", więc pewnie "coś" się zmieniło. Korzystam z Bleueconnect Ery, w tej chwili pre-paid. Hm, tylko nie rozumiem czemu shift+R, shift+A nie działają mi w galerii na standardowym podglądzie zdjęć, a np. na canon-board działają.

tantal

16-07-2009, 19:48

Może używasz jakiegoś proxy z kompresją. Albo korzystasz z dostępu przez sieć GSM i tam w zależności od wybranego APN-a może też następować kompresja.
Dzięki Kolaj. Nic trafniejszego już chyba nie wygooglam, tak to wygląda jak napisałeś. Dostawca prasuje mi dane, tyle że od krótkiego czasu prasuje jeszcze mocniej. Gdzieś wyczytałem potwierdzenie Twojej diagnozy:

ISP modifying the web pages on the fly with javascript and providing lower res images via a transparent proxy in order to reduce download bandwidth (it was over a GPRS/3G link), and there was no way to disable it (it was setting at the ISP end with no option to allow customers to override it).

Kolaj

16-07-2009, 21:22

Dzięki Kolaj. Nic trafniejszego już chyba nie wygooglam, Myślę, że masz szansę wygooglać, jak ustawić blueconnect, żeby tej kompresji nie było.

tiroy

16-07-2009, 21:56

Fakt - korzystam z GPRS, ale traffic compressora wyłączyłem chwilowo (zresztą jpg i tak nie kompresował). APN pewnie ma znaczenie...
Operatorzy często robią takie numery z kompresją danych, które da się upakować w "mniejszą ilość radia". Szybciej strona się ładuje, klient zadowolony, więcej pasma dla innych, etc. Same plusy, chociaż bywają wyjątki, jak w Twoim przypadku.

tantal

16-07-2009, 22:40

Szybciej strona się ładuje, klient zadowolony, więcej pasma dla innych, etc. Same plusy, chociaż bywają wyjątki, jak w Twoim przypadku.
W zasadzie to nie będzie dramat, ja mam fotki na swoim kompie lepszej jakości niż na coppermine. Wkurza mnie już tylko to, co już wspominałem: gdy przeglądam foty na canon-board skrót Shift+R wczytujący zdjęcia w oryginalnej jakości działa, a na mojej galerii za Chiny nie chce, działa dopiero po otwarciu zdjęcia w nowym oknie. No ale pocieszam się że nie cały świat łączy się przez sieci komórkowe, więc nie muszę póki co zmieniać skryptu galerii.:mrgreen:

tplewa

17-07-2009, 00:49

Generalnie jeśli chodzi o takie zmniejszanie to się trochę dziwię, jeśli już to robią to zapewne nie w javascript - bo javascript jest wykonywana po stronie przeglądarki. Czyli lokalnie na komputerze klienta...

Zresztą takie skalowanie okropnie by zamulało przeglądarkę, a i tak trzeba przesłać do klienta cały obrazek. Więc jest to bez sensu.

Kolejna sprawa to robiąc to na jakimś serwerku u providera też było by to mało opłacalne - wyspecjalizowany soft szukający fotek i je zmniejszający. Zapewne nieźle by orało taką maszynę. Więc duże koszty dla operatora.

Do tego taki operator nie ma w tym zbytniego celu, wiadomo że są limity i po przekroczeniu transfer mocno spada (można sobie dokupić). Więc finansowo jest to opłacalne dla operatora.

Owszem istnieją sposoby kompresji np. gzip - tyczy się to jednak już konkretnego serwera WWW. Poprostu serwer wysyła całośc skompresowane i przeglądarka automatycznie dekompresuje. Jednak używa się tutaj kompresji bez stratnej i człowiek nawet o tym nie wie że pobiera stronę kompresowaną, to jest dość często stosowane...

tantal

17-07-2009, 02:29

Generalnie jeśli chodzi o takie zmniejszanie to się trochę dziwię, jeśli już to robią to zapewne nie w javascript - bo javascript jest wykonywana po stronie przeglądarki. Czyli lokalnie na komputerze klienta... No tak, użyszkodnicy przeglądarek o javascript server side wiedzieć nie muszą, co niestety nie przeczy jej istnieniu i jej wykorzystywaniu :mrgreen:

Kolejna sprawa to robiąc to na jakimś serwerku u providera też było by to mało opłacalne - wyspecjalizowany soft szukający fotek i je zmniejszający. Zapewne nieźle by orało taką maszynę. Więc duże koszty dla operatora.

Do tego taki operator nie ma w tym zbytniego celu, wiadomo że są limity i po przekroczeniu transfer mocno spada (można sobie dokupić). Więc finansowo jest to opłacalne dla operatora.

Owszem istnieją sposoby kompresji np. gzip - tyczy się to jednak już konkretnego serwera WWW. Poprostu serwer wysyła całośc skompresowane i przeglądarka automatycznie dekompresuje. Jednak używa się tutaj kompresji bez stratnej i człowiek nawet o tym nie wie że pobiera stronę kompresowaną, to jest dość często stosowane...Wydaje mi się że po trosze teoretyzujesz a po trosze próbujesz nagiąć protokoły internetowe do swojego o nich wyobrażenia. Bez urazy- to są procesy proste do granic możliwości... ale nie bardziej :mrgreen:
"Serwerek u providera" ...dość protekcjonalnie piszesz o operatorach komórkowych :-D
Ale OT się robi, blueconnect compressor obrazki prasuje, traffic compressor już nie ale ich wspólną cechą jest to, że ja decyduję czy i co kompresować. Natomiast pominąć proxy, którego nie widzę w swoich ustawieniach to już dla mnie kłopot :(

tplewa

17-07-2009, 03:19

tantal wiem i to dobrze że istnieje SSJS... tylko to i tak się nie nadaje.
SSJS można bardziej przyrównać do PHP, ASP itp.

Stosuje się to np. do komunikcji z SQL-em itp. po stronie serwera.
Jednak do analizy i kompresji przesylanych danych z innego serwera to juz raczej malo ciekawe rozwiazanie.

Jesli chodzi o "serwerek u providera" to pisze to w uproszczeniu.... nie bede pisal ze maja jakis cluster, mainframe itp. Co do Ery to nie wiem możemy porozmawiać co ma T-Mobile na Słowacji :)

Napewno nie zrealizujesz tego na jakims Cisco czy Juniper - wiec rozwiazanie raczej dedykowane.

Tak samo nie mam zamiaru tutaj rozwodzic sie do poszczegolnych protokolow, bo zaraz dojdziemy do flag w ramce i zaczniemy mowic co to jest RST, ACK itp.

Inna sprawa jak mowimy o kompresji to musiala by byc wybiorcza, bo pakowanie jpeg-a itp. raczej mija sie z celem - no mozna sobie pakowac bitmapy bo najwyzej maja kiepska kompresje RLE4. Do tego wiecej niz obrazki zabiera transfer plikow - ktore w wiekszosci sa umieszczane w necie juz spakowane.

Dlatego takie rozwiazania wydaja mi sie troche bez sensu. Moim zdaniem spokojnie wystarczy odpalenie np. w Apache i PHP kompresji gzip (duze serwisow WWW tego uzywa - mozna sprawdzic tcpdumpem lun pod win Ethereal-em)... wiecej sie nie wydusi. A jak ci leci juz z serwera www w gzip to pakowanie tego dodatkowo to kolejne wariactwo...

Natomiast resize jpeg-ow to juz zakrawa mi na olanie takiego lacza - bo moze zepsuc polowe stron, wiec po co mi uposledzony internet.

Proxy robi sobie tylko cache wiec nie jest jeszcze tak zle, a ominac sobie mozesz robiac tunel przez jakis serwerek jak masz dostep... inaczej raczej trudno bo zapewne uzyte jest WCCP...

muflon

17-07-2009, 12:33

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

17-07-2009, 16:53

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 :mrgreen: ale fakt algorytmy w takich wypadkach działają szybciej...

Kolaj

17-07-2009, 16:55

no w sumie tak tylko wychodzi najczęściej większy niż oryginał po kompresji, bo trudno tam już coś skompresować znanymi algorytmami :mrgreen: 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

17-07-2009, 17:07

Ź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

17-07-2009, 17:26

no w sumie tak tylko wychodzi najczęściej większy niż oryginał po kompresji, bo trudno tam już coś skompresować znanymi algorytmami :mrgreen: 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

17-07-2009, 17:34

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

17-07-2009, 17:36

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

17-07-2009, 17:49

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 :mrgreen:

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

17-07-2009, 18:03

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/Carrier/MobileInternet/MobileInternetOptimizationAcceleration_features.as px, piąty akapit.

zresztą nie wiem ile by się statystycznie zyskało przy takiej kompresji JPEG-a
Tyle na ile pozwala bezczelność operatora :)

tplewa

17-07-2009, 18:11

google:"mobile jpg traffic recompression solution", pierwszy strzał: http://www.radware.com/Solutions/Carrier/MobileInternet/MobileInternetOptimizationAcceleration_features.as px, piąty akapit.

Tyle na ile pozwala bezczelność operatora :)

no dokładnie jeśli chodzi o bezczelność to chyba jedyny wyznacznik.

Co do różnych rozwiązań to owszem istnieją. Ja się spotkałem z rozwiązaniami Ellacoya :) z tym że to działa inaczej :)

Kupiło to trochę firm za ogromną kasę i z tego co wiem niezbyt trafiona inwestycja bo nikt się z tym sprzętem jeszcze nie dogadał tak aby normalnie to działało :mrgreen:

Kolaj

17-07-2009, 18:51

no dokładnie jeśli chodzi o bezczelność to chyba jedyny wyznacznik.Nie jedyny. Wiele osób korzysta z internetu mobilnego na zasadach pre-paid, płacąc za każde przesłane 100kb. Dla nich możliwość 4-krotnego ograniczenia pasma to wymierny czynnik działający na korzyść takiego rozwiązania, za które są gotowi poświęcić jakość wyświetlanych grafik. Jest taniej i szybciej a, że trochę brzydziej... cóż. Korzystają z internetu bo potrzebują dostępu do informacji a nie wrażeń estetycznych.

I cały czas wydaje mi się, że operatorzy dają możliwość wyboru, czy chce się z tego rozwiązania korzystać czy nie.

krzysztofr

17-07-2009, 20:32

Opera Mobile wykorzystuje kompresję strony www przed załadowaniem. Koszty transmisji maleją, ale wyświetlane jpg są kompletnie nie czytelne.

Kolaj

17-07-2009, 21:01

Opera Mobile wykorzystuje kompresję strony www przed załadowaniem. Koszty transmisji maleją, ale wyświetlane jpg są kompletnie nie czytelne.Tak samo jest w nowej Operze 10 z włączoną opcją Turbo, ale sformułowanie, że są kompletnie nieczytelne jest mocno na wyrost. Ilustracja do artykułu o pożarze fabryki, przedstawiająca tenże pożar, będzie wystarczającej jakości, żeby można się było zorientować, co jest na zdjęciu. Artefakty na niebie doprawdy nie są w takim przypadku istotne. Widać ogień, dym i fabrykę. Wystarczy.

Na wyjazdach, kiedy korzystam z prepaidowego internetu, chętnie z tej funkcji korzystam. Do onetu wystarcza. Wyłączam to tylko na czas oglądania galerii, kiedy faktycznie zależy mi na dobrej jakości.

krzysztofr

17-07-2009, 21:25

Tylko, że Opera 10 kompresuje w znacznie mniejszym stopniu. Wersja Mobile kompresuje dużo bardziej i do tego dochodzi znaczny resize obrazka.

tantal

19-07-2009, 22:48

Nie jedyny. Wiele osób korzysta z internetu mobilnego na zasadach pre-paid, płacąc za każde przesłane 100kb. Dla nich możliwość 4-krotnego ograniczenia pasma to wymierny czynnik działający na korzyść takiego rozwiązania, za które są gotowi poświęcić jakość wyświetlanych grafik. Jest taniej i szybciej a, że trochę brzydziej... cóż. Korzystają z internetu bo potrzebują dostępu do informacji a nie wrażeń estetycznych.

I cały czas wydaje mi się, że operatorzy dają możliwość wyboru, czy chce się z tego rozwiązania korzystać czy nie.
Z ostatniej chwili :mrgreen:: sytuacja wróciła do normy, obrazki wyświetlają się w normalnej jakości, bez jakiejkolwiek ingerencji z mojej strony w parametry połączenia. Czyli dochodzi prawdopodobnie kolejny wyznacznik- obciążenie łączy. Piszę "prawdopodobnie" bo jednak przypomniałem sobie, że podobne krótkotrwałe sytuacje miały jednak miejsce w przeszłości. Czyżby więc "zawór bezpieczeństwa", sprzężenie zwrotne zwiększające skokowo kompresję w zależności od obciążenia łączy ?
A co do elastyczności, to nie korzystam z żadnej aplikacji blueconnect ( o ile taka istnieje) dołączonej do modemu. Zwykła Nokia PC Suite,kabelek, 6020 i jazda:-D Tak jak wspomniałem, żadnego proxy nie mam w ustawieniu połączenia z poziomu pc, jak i w preferencjach FF więc nie bardzo wiem co ode mnie zależy w tej kwestii.Byłoby wygodnie na bieżąco ustalać jak kompresowana jest wyświetlana grafika na www, bo to jednak bardziej elastyczne roziązanie od włączania/wyłączania obrazków. Dobrze wiedzieć że Opera 10 coś takiego oferuje.