Wpisy

Opublikowane w

Guetzli – lepsza kompresja JPEG

Przedwczoraj Google ogłosiło na blogu nowe narzędzie do kompresji JPEG o nazwie Guetzli, wydawane na wolnej licencji (Apache License). Ma dawać lepsze optycznie rezultaty przy mniejszym rozmiarze wynikowym (mowa nawet o 35% mniejszych plikach). Cena? Oczywiście czas kompresji.

Postanowiłem przetestować na szybko, co mogło by się zmienić, gdybym wykorzystał grafiki skompresowane przy pomocy Guetzli na blogu. W tym celu sięgnąłem po obrazki z backupu bloga i uruchomiłem program (domyślne opcje kompilacji, domyślne ustawienia jakości, czyli 90%) na moim laptopie (CPU: Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz). Zdziwiło mnie to, że aż przy 12 plikach nie udało się ukończyć działania – program zgłosił błąd:

Invalid input JPEG fileGuetzli processing failed

Udało się przetworzyć 66 plików, całość trwała prawie 17 minut (sic!). Czyli jest bardzo wolno. Kompresor wykorzystywał tylko jeden rdzeń CPU. Efekty są obiecujące, zarówno wizualne, jaki i objętościowe. Mimo, że algorytm jest zaprojektowany z myślą o działaniu na możliwie nieprzetworzonych obrazach wejściowych, a te na blogu raczej są już zoptymalizowane, to łączny rozmiar udało się zmniejszyć o 14% (z ok. 3,3 MB do ok. 2,8 MB).

Jeśli wezmą się za wykorzystanie i optymalizację duże firmy, a jest na to szansa po uwolnieniu programu, może to oznaczać mniej przesyłanych danych po sieci, czyli szybsze ładowanie się stron, widoczne zwłaszcza na komórkach. Chwilowo główną barierą jest czas działania, który wygląda na zależny bezpośrednio od wielkości pliku wejściowego.

Zrobiłem jeszcze jeden test – plik JPG bezpośrednio z aparatu, rozmiar 2560×1440, rozmiar wejściowy 1,2 MB. Po kompresji (trwającej kilka minut) brak zauważalnych zmian jakości, natomiast rozmiar zmniejszony aż o 50% (614 kB).

Opublikowane w

Międzyczas

Zacząłem od opisu założeń i tym podobnych rzeczy nie związanych bezpośrednio z programowaniem, ale ciągnie wilka do lasu i chciałem się w międzyczasie na boku pobawić fragmentami kodu i modułami. Ponieważ już w komentarzach w poprzednim wpisie pojawiły się wzmianki o tym co będzie, nie będzie wielkiej szkody czy niespodzianki, jeśli nieco wybiegnę naprzód.

Na pierwszy ogień poszło pingowanie, bo właśnie w ten sposób chcę mierzyć jakość łącza. Jak można się spodziewać, do korzystania z ICMP wymagane są uprawnienia użytkownika root. Nie jest to dla mnie niespodzianką, bo spotkałem się z tym przy perlowym skrypcie do powiadamiania o konieczności wpisania CAPTCHA dla Aero2. Tym razem postanowiłem nie odpuścić, tym bardziej że w sumie dopuszczam – przynajmniej w pierwszej wersji – uruchamianie skryptu z użytkownika root. W końcu i tak będzie trzeba dotykać routingu, a do tego potrzebne są wyższe uprawnienia niż posiadają zwykli użytkownicy.

Żeby poznać najlepszy i zalecany sposób pingowania, wrzuciłem zapytanie do wyszukiwarki i… włos mi się zjeżył na głowie. Rozwiązań jest wiele, modułów jest wiele, a prostego i działającego jakoś nie widać. Zacząłem od prostego modułu ping, który ma funkcję quiet_ping robiącą to, co potrzebuję, ale o ile dał się bez problemu zainstalować z Python 2, o tyle z Python 3 ma problem:

virtualenv --python=python3 test
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /tmp/abcc3/test/bin/python3
Also creating executable in /tmp/abcc3/test/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.
source test/bin/activate
pip3 install ping
Collecting ping
  Using cached ping-0.2.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "", line 1, in 
      File "/tmp/pip-build-qqotvnqc/ping/setup.py", line 23, in 
        from ping import __version__
      File "/tmp/pip-build-qqotvnqc/ping/ping.py", line 196
        except socket.error, (errno, msg):
                           ^
    SyntaxError: invalid syntax
    
    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-qqotvnqc/ping/

Z kolei próba użycia modułu python3-ping wygląda tak:

pip3 install python3-ping
Collecting python3-ping
  Could not find a version that satisfies the requirement python3-ping (from versions: 2014.05.01.022aa83, 2014.05.02.805ee25, 2014.05.02.16245f0)
No matching distribution found for python3-ping

Wgląda więc, że prawdopodobnie w pierwszym etapie, by nie tracić czasu, pozostanę przy Python 2, zachowując zgodność z Python 3, a najwyżej później dostosuję całość. Nie powinno być to trudne – wystarczy wymienić moduł i jego wywołanie, funkcje u mnie i argumenty raczej się nie zmienią. Będę wdzięczny za sugestię działającego modułu do pingowania. Oczywiście zawsze zostaje użycie systemowego polecenia ping i parsowanie wyjścia, ale tego wolałbym uniknąć…

Z innych newsów okołoprojektowych: zakupiłem modem GSM, żeby mieć na czym testować. Jest wbudowana karta w lapka, mam jakieś wifi na USB, dorzucę modem i wygląda, że nawet do pięciu łącz jestem w stanie w środowisku testowym mieć. Pewnie zostanę przy dwóch-trzech, ale dobrze jest mieć perspektywy. 😉

Opublikowane w

Założenia i opis projektu abcc

Projekt abcc składa się z demona, napisanego w Pythonie, który czyta plik konfiguracyjny, a następnie na podstawie jego zawartości dokonuje cyklicznej kontroli jakości dostępnych łącz względem określonych w konfiguracji IP docelowych. Przeprowadzane operacje zapisywane są do logu (syslog?), podobnie jak oceny poszczególnych łącz.

Zakładam wykorzystanie Pythona w wersji 3, przestrzeganie PEP8 i programowanie funkcyjne. Całość ma być możliwie prosta koncepcyjnie i możliwie konfigurowalna przy pomocy pliku konfiguracyjnego za pomocą wag poszczególnych wskaźników, wag IP. Rozwiązanie ma też zapewniać użytkownikowi pełną przejrzystość działania, wybór poziomu logowania i możliwość uruchomienia w wersji „na sucho”, w celu przetestowania, jak uruchomienie z daną konfiguracją wpłynęłoby na zmiany routingu.

Aby to osiągnąć, zmienia na czas pomiaru routing do docelowych IP na dane łącze, dokonuje pomiaru jakości łącza, a następnie, po zebraniu danych dla wszystkich łącz, określa, które z nich jest najlepsze i – jeśli zachodzi taka potrzeba, dokonuje zmiany routingu.

Do zmiany routingu wykorzystywane są zewnętrzne skrypty bashowe – pozwala to na dostosowanie działania demona do różnych platform i potrzeb – np. dodanie zmiany NATowanaia, wywołanie zmian na zdalnym systemie (router sprzętowy) – bez zmian w samym silniku.

Teoretycznie można by to napisać w czystym Bashu i wywoływać z crona, ale po pierwsze, chcę potrenować Pythona, po drugie tak będzie łatwiej, bardziej elegancko i będzie otwarta droga np. do zwiększenia częstotliwości próbkowania przez zrównoleglenie pomiarów.

Z racji wymogów konkursowych dotyczących ilości postów, tworzenie projektu będzie trochę przegadane, i spowolnione, przynajmniej na początku. Zaleta jest taka, że będzie lepiej widać sposób rozumowania, gdyby ktoś chciał coś skomentować lub się przyłączyć. Commity kodu i dokumentacji będą się pojawiały w miarę równolegle z wpisami na blogu, pierwszy właśnie poszedł.