GPRS - kompresja wyświetlanych zdjęć

[tantal]

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]

Dzięki za uwagi, poszperam jeszcze w dokumentacji coppermine.

Ale w coppermine jest wszystko ok. Obrazek wyświetlany w galerii ma 101,5kB.

[tantal]

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

[tiroy]

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]

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.

[tplewa]

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]

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

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

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]

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.