GPRS - kompresja wyświetlanych zdjęć

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

2.link do zdjęcia na coppermine
http://jarex.freehostia.com/displayi...up&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...

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.

Cytat:

---

Zamieszczone przez Kolaj

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:

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.

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

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.

Cytat:

---

Zamieszczone przez tantal

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

---

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

Cytat:

---

Zamieszczone przez Kolaj

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.

Cytat:

---

Zamieszczone przez Kolaj

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

Cytat:

---

Zamieszczone przez Kolaj

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:

Cytat:

---

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

---

Cytat:

---

Zamieszczone przez tantal

Dzięki Kolaj. Nic trafniejszego już chyba nie wygooglam,

---

Myślę, że masz szansę wygooglać, jak ustawić blueconnect, żeby tej kompresji nie było.

Cytat:

---

Zamieszczone przez tantal

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.

Cytat:

---

Zamieszczone przez tiroy

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:

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

Cytat:

---

Zamieszczone przez 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...

---

No tak, użyszkodnicy przeglądarek o javascript server side wiedzieć nie muszą, co niestety nie przeczy jej istnieniu i jej wykorzystywaniu :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...

---

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

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

Cytat:

---

Zamieszczone przez tplewa

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.

Cytat:

---

Zamieszczone przez muflon

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

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

---

Ź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 tantal

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

---

Cytat:

---

Zamieszczone przez Kolaj

Ź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

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 tplewa

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

Cytat:

---

Zamieszczone przez muflon

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

Cytat:

---

Zamieszczone przez tplewa

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

Cytat:

---

Zamieszczone przez muflon

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

Cytat:

---

Zamieszczone przez tplewa

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.

Cytat:

---

Zamieszczone przez tplewa

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

---

Tyle na ile pozwala bezczelność operatora :)

Cytat:

---

Zamieszczone przez muflon

google:"mobile jpg traffic recompression solution", pierwszy strzał: http://www.radware.com/Solutions/Car..._features.aspx, 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:

Cytat:

---

Zamieszczone przez tplewa

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.

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

Cytat:

---

Zamieszczone przez krzysztofr

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.

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

Cytat:

---

Zamieszczone przez Kolaj

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.

Cytat:

---

Zamieszczone przez tantal

nie bardzo wiem co ode mnie zależy w tej kwestii.

---

Np wybór APN-a. Nie wiem, jak w Erze ale w iPlusie są do wyboru 2: "internet" i "optimizer". Ten drugi kompresuje w locie.

Cytat:

---

Dobrze wiedzieć że Opera 10 coś takiego oferuje

---

https://canon-board.info//brak.gif
źródło

Zmieniłem 'Firefox' na 'GPRS' w tytule bo winny się znalazł i nie ma sensu bezpodstawnie Firefoxa obwiniać :) .

Cytat:

---

Zamieszczone przez Vitez

Zmieniłem 'Firefox' na 'GPRS' w tytule bo winny się znalazł

---

Dokładnie :-D
A "winny" przez kilka dni raczył mnie widoczkami właśnie takiej jakości jak ten dolny w poście Kolaja powyżej :)