Myślę, że masz szansę wygooglać, jak ustawić blueconnect, żeby tej kompresji nie było.Cytat:
Zamieszczone przez tantal
Wersja do druku
Myślę, że masz szansę wygooglać, jak ustawić blueconnect, żeby tej kompresji nie było.Cytat:
Zamieszczone przez tantal
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.Cytat:
Zamieszczone przez tantal
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:Cytat:
Zamieszczone przez tiroy
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...
No tak, użyszkodnicy przeglądarek o javascript server side wiedzieć nie muszą, co niestety nie przeczy jej istnieniu i jej wykorzystywaniu :mrgreen:Cytat:
Zamieszczone przez tplewa
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:Cytat:
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...
"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 :(
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...
Wręcz przeciwnie, właśnie JPEG jest idealnym kandydatem do takiej rekompresji "w locie", praktycznie bezczasowo.Cytat:
Zamieszczone przez tplewa
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...Cytat:
Zamieszczone przez muflon
Ź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.Cytat:
Zamieszczone przez tplewa
Cytat:
Zamieszczone przez tantal
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-aCytat:
Zamieszczone przez Kolaj