Do tego doświadczenia posłużyłem się napisanym specjalnym programem który kolejno, aż do znudzenia, otwierał i zapisywał do JPG’a ten sam obraz. I tak 100 000 razy. Nie wchodziłem zbytnio w optymalizację na ten jeden raz, stąd też nieco to trwało.

Pewnie myślicie że po kilkunastu takich operacjach z pierwotnego zdjęcia została sieczka? Prawdę mówiąc też tak myślałem. Jakież było moje zdziwienia gdy się okazało że praktycznie nic się nie zmienia! Ale gdyby to był końcowy wniosek, wpis ten był by nudny, poszedłem zatem o krok dalej .

Początkowo po prostu prowadziłem rekompresje obrazu zapisując go za każdym razem w tej samej jakości. I tak jak wyżej wspomniałem, jakość zdjęcia nie pogarszała się wraz z kolejnymi iteracjami – cały czas pozostawała na określonym poziomie wynikającym ze obranego stopnia kompresji.

Dlaczego tak się dzieje? Wynika to wprost z algorytmu JPEG. W dużym uproszczeniu, polega on na zmianie obrazu w drobne gradienty które najlepiej oddają dany fragment rysunku – w zależności od stopnia kompresji są one mniej lub bardziej widoczne. Więcej na ten temat można przeczytać na stronach Wikipedii.

Poziom jakości 1%, widoczne artefakty

I tak, po pierwszym zapisaniu z formatu źródłowego algorytm JPEG stosuje stratną kompresję zamieniając nasze zdjęcie w owe gradienty. Jeśli powtórzymy tą operację na skompresowanym już JPG’u, to sytuacja powtarza się, z tą tylko różnicą że nie ma już co zmieniać gdyż obraz poddawany kompresji wpasowuje się idealnie w to co zrobił by algorytm JPEG (a co uczynił przy poprzednim zapisie).

Dlatego właśnie, wraz z kolejnymi zapisaniami nie tracimy nic na jakości. Oczywiście pod warunkiem że nic nie zmieniamy na obrazku, oraz za każdym razem stosujemy ten sam stopień kompresji! Jednakże jest to sztuka dla sztuki, po co zapisywać jak nic się nie zmienia?

Nie do końca tak jest. Jeśli wykonamy operację które nie naruszają w sposób stratny zawartości rysunku (np.: zamalowanie twarzy) to możliwe jest ponowne zapisanie bez straty jakości. Do operacji takich zaliczyć możemy obrót o 90 stopni, bądź odbicie w pionie/poziomie. Stąd też właśnie, wbudowana w system Windows przeglądarka obrazów potrafi dokonywać rotacji bez uszczerbku na jakości zdjęcia.

Pamiętaj chemiku młody…

Tak jak mówiłem, powyższy wniosek jest nudny . Idąc krok dalej, postanowiłem przeprowadzić cały eksperyment jeszcze raz ale tym razem zmieniając poziom jakości kompresji losowo między 95% a 100% – zmieniając tym samym warunki pracy algorytmu JPEG.

I w tym momencie zaczyna robić się ciekawie. Tutaj faktycznie zaobserwujemy już destrukcję obrazu, zobaczcie sami.

Obraz źródłowy i po pierwszych 50 iteracjach

100 i 200 iteracji

300 i 400 iteracji

500 i 750 iteracji

1 000 i 1 500 iteracji

5 000 i 10 000 iteracji

25 000 i 50 000 iteracji

Jak widać, początkowo proces przebiega bardzo szybko. Im dalej, tym więcej powtórzeń potrzeba aby dostrzec jakie zachodzą zmiany w obrazie.

Wszystko wskazuje na to jakoby sytuacji stabilizowała się, jednak w okolicach 50 000 iteracji obserwujemy coś co można nazwać załamaniem się trendu.

50 500 i 51 000 iteracji

55 000 i 100 000 iteracji

Pomiędzy 60 000 iteracją a dalszymi, aż do 100 000 obserwowane są oscylacje obrazu, tzn. nie zmienia się on w sposób jak na początku, tylko zachowuje się jak szum, coś się przemieszcza delikatnie ale nic już się nie zmienia. Mówiąc w programistycznym slangu, wygląda to jakby obraz wpadł w nieskończoną pętlę.

Na koniec jeszcze raz to samo, ale zaprezentowane na filmie w przyspieszonym tempie, który bardzo dobrze oddaje tempo zachodzenia zmian.

Podsumowanie

I to w zasadzie już wszystko. Może nie jest to zbyt wiele wnoszący do życia eksperyment, jednak na pewno ciekawy . Od strony praktycznej, jeśli bałeś się korzystać z systemowej funkcji rotacji zdjęć w trosce o jakoś obrazu, teraz możesz robić to bez najmniejszych oporów.

function nazwa($argument)
{
  if (warunek)
  {
    return FALSE;
  }
  ... ciało funkcji
}

…czy też:

function nazwa($argument)
{
  if (warunek)
  {
    return FALSE;
  }
  else
  {
    ... ciało funkcji
  }
}

Intuicyjnie może się wydawać że pierwszy metoda będzie działać szybciej, gdyż po spełnieniu warunku wychodzimy od razu z funkcji – parser nie musi przetwarzać reszty kodu. Z kolei w drugiej, mimo iż to co znajduje się w bloku else się nie wykona i tak musi zostać przeczytane przez PHP. Jak jest w rzeczywistości? Sprawdźmy to!

Pierwsza konstrukcja, w której po spełnieniu warunku wykluczającego dalsze przetwarzanie, od razu zwracamy wartość jest na pewno bardziej przejrzysta. Nie musimy ciągnąć za sobą nawiasu kończącego blok else przez całą resztę instrukcji. Drugi fragment kodu z kolei charakteryzuje się bardziej logiczniejszą strukturą – gdyż wyraźnie widzimy co się stanie w przypadku spełnienia warunku jak i jego odrzucenia.

Przejdźmy zatem do testów. Przygotowałem na tą okazję dwie, identyczne pod względem działania, funkcje korzystające z dwóch w/w konstrukcji zapisu:

function test_return($arg)
{
  if ($arg % 2 == 0)
  {
    return 0;
  }
  $arg = $arg*7+2;
  $a = $arg+3;
  $b = 1024;
  $arg = $a - $b*$arg;
  $arg =- 500;
  $arg *= 2;
  return $arg+256;
}

…oraz:

function test_else($arg)
{
  if ($arg % 2 == 0)
  {
    return 0;
  }
  else
  {
    $arg = $arg*7+2;
    $a = $arg+3;
    $b = 1024;
    $arg = $a - $b*$arg;
    $arg =- 500;
    $arg *= 2;
    return $arg+256;
  }
}

Jak można zauważyć, funkcje te nie mają zbytniego sensu, nie mniej ich głównym celem jest odrzucanie liczb parzystych a przetwarzanie jedynie nieparzystych.

Procedura testowa polegała na wykonaniu jednego miliona iteracji każdej z funkcji, podając kolejne liczby całkowite jako argument poczynając od 0.

for ($i = 0; $i < 1000000; $i++)
{
  test_return($i);
}

Wyniki jakie otrzymałem prezentują się następująco:

Jak widać, wyniki są identyczne. W praktyce występowały pewne wahania w zależności od wywołania skryptu, nie mniej średnio, obie funkcje wykonują się w tym samym czasie. Nie ma więc znaczenia jakiego typu konstrukcji użyjemy – najlepiej tej która bardziej nam w danej chwili odpowiada.

Dlaczego tak się dzieje? Przyczyny braku różnicy w czasie wykonania można dopatrywać się tym, iż parser PHP bądź co bądź musi przeczytać całą zawartość skryptu przed jego kompilacją i uruchomieniem. Skompilowany kod jednej i drugiej funkcji nie różni się zatem niczym, co mogło by w istotny sposób wpłynąć na czas jego wykonania.

Pokusiłem się o mały test przy pomocy benchmark’a SunSpider nowej wersji Firefox’a, tego jak wypada w porównaniu do poprzedniej 3.5.7, oraz na tle innych popularnych przeglądarek. Co z tego wyszło? Zobaczcie sami.

Wyniki przedstawione na poniższym wykresie są rezultatami testów SunSpider’a, podanymi w milisekundach. Ogólnie rzecz ujmując, im mniej, tym lepiej.

Stawkę otwiera Internet Explorer 8 z oszałamiającym wynikiem na poziomie prawie 5 sekund. Najlepiej wypada przeglądarka firmy Google, deklasując pozostałych rywali. Nowy Firefox 3.6 stara się zbliżyć do lidera poprawiając swój dotychczasowy wynik o 25%. Jak widzimy, słowa Mozilli są jednak coś warte jeśli chodzi o deklaracje wydajności.

Oczywiście bezwzględne wartości liczbowe zależą od konfiguracji sprzętowej na jakiej wykonywany był pomiar. Nie mniej, względne różnice między wersjami czy też przeglądarkami mówią nam o wydajności ich silnika JavaScript.

Jak przekłada się to na realne odczucia? W dobie popularyzacji technik takich jakich jak AJAX, oraz dominacji framework’ów pokroju jQuery, bardzo! Może nowa wersja produktu Mozilli, w porównaniu ze starszą, nie wgniecie nas w fotel, to jednak dobrze że producenci starają się implementować coraz to lepsze rozwiązania w tym zakresie.

Czy rzeczywiście tak jest? Już logicznie rzecz biorąc, jeśli nic nie ładujemy, a nasza ładowarka nie wydziela ciepła, to nie może pobierać prądu z sieci, nic w przyrodzie nie ginie a zasada zachowania energii wciąż obowiązuje. Ale nie opierajmy się na założeniach i domniemaniach, weźmy miernik do ręki i sprawdźmy to!

Co nam będzie potrzebne? Najlepiej watomierz. Jako że wartość napięcia w gniazdu jest w miarę stała, a moc pobierana równa jest iloczynowi napięcia i przepływającemu prądowi, posłużę się amperomierzem cęgowym. Cóż to takiego? Zwyczajowy amperomierz musi zostać wpięty w obwód aby móc coś zmierzyć. Wie o tym każdy komu eksplodował miernik po wetknięciu sond pomiarowych do gniazda . W tej sytuacji musiał bym rozciąć przewód i włączyć do niego amperomierz. Nie jest to zbyt przyjemna metoda.

Amperomierz, czy też w ogóle miernik cęgowy, bazuje na pomiarze pola elektromagnetycznego, wytwarzanego przez przepływający przez przewodnik prąd. Zapina się go na docelowym przewodzie z prądem, który chcemy zmierzyć. Do tego celu wykonałem jedynie niewielki przedłużacz z rozdzielonymi żyłami, gdyż jeśli mierzył bym na wszystkich jednocześnie, nie otrzymał bym nic. Nie chciałbym tutaj wchodzić w dalszą teorię nt. metodologii pomiaru, zatem przystąpmy do rzeczy.

Pomiaru dokonałem na 5 ładowarkach do telefonów firm Nokia, Samsung oraz Sagem, w trzech stanach pracy: bez podłączonego telefonu, z podłączonym telefonem oraz po naładowaniu baterii telefonu. Co otrzymałem? Zobaczcie sami.

Od razu chciałbym zaznaczyć, iż wynik pomiaru bez podłączonego telefonu, oscylował już w granicach błędu pomiarowego i możliwości miernika cęgowego. Zatem rzeczywista wartość płynącego prądu, dla tego przypadku, była zapewne niższa.

Nie mniej, biorąc pod uwagę nawet zawyżoną wartość, mnożąc razy wartość napięcia sieciowego i przeliczając na kilowaty otrzymujemy:

0,001A * 235V = 0,235W = 0,000235kW

Mając już wyrażony w kW pobór mocy, możemy przemnożyć go przez stawkę za kWh naszego lokalnego dostawcy energii elektrycznej. Tym samym uzyskamy koszt, jaki generuje niepodłączona (do telefonu) ładowarka do gniazdka. W moim przypadku wynosi on 0,3176 zł / kWh (Vattenfall), zatem:

0,000235kW * 0,3176 zł / kWh = 0,000074636 zł / h

Jak widzimy, nie jest to oszołamiający koszt. Jeśli miałbym włączoną ładowarkę w trybie 24/7, w skali roku będzie to zaledwie 65gr.

Czy zatem warto odłączać nieużywaną ładowarkę do telefonu z sieci? W pierwszej kolejności trzeba się upewnić czy nasza ładowarka faktycznie w stanie jałowym nie pobiera tyle energii, co podczas zwyczajnej pracy – niewykluczone że starsze egzemplarze mogą się tak zachowywać (np.: Sagem myX-1 odbiega nieco od normy). Po drugie, odłączenie ładowarki na pewno wpłynie pozytywnie na jej żywotność, aczkolwiek sądzę iż w marginalnym stopniu. Tak czy inaczej, argument o kolosalnym zużyciu energii elektrycznej przez nieużywaną ładowarkę, możemy włożyć między bajki.

Aktualizacja

Zamieszczone zdjęcie miernika cęgowego jest poglądowe. Miernik pokazany na zdjęciu nie dysponuje odpowiednim zakresem pomiarowym, w przeciwieństwie do modelu użytego w pomiarach: UNI-T UT202.