Różne formaty grafiki. Kiedy nie używać JPG

Pliki JPG stały się dominującym standardem zapisu grafiki wśród użytkowników domowych. Warto jednak wiedzieć, kiedy i dlaczego należy użyć na ich miejsce innych formatów.

Być może zauważyłeś, że grafiki zapisane jako BMP zajmują bardzo dużo miejsca na dysku. Wynika to z tego, że są one dosłownym zapisem obrazka na dysk, piksel po pikselu. Bardziej wyrafinowane formaty stosują kompresję – różne matematyczne sztuczki, które pozwalają zmieścić więcej informacji w takiej samej objętości pliku. To właśnie dzięki kompresji 5-megapikselowe zdjęcie w formacie JPG zajmuje tylko 2-3, a nie 14 megabajtów (nie wspominając już o zdjęciach 15-megapikselowych).

Istnieje wiele rodzajów kompresji. Dzielą się one na bezstratne i stratne. Kompresja bezstratna umożliwia odtworzenie obrazu identycznego jak oryginalny, natomiast po skompresowaniu stratnym obraz nie jest już zupełnie identyczny jak oryginał – może jednak być wystarczająco podobny, by bez wnikliwej analizy nie dało się zauważyć różnicy.

Skoro można kompresować bezstratnie, to czemu ktoś chciałby w ogóle korzystać ze stratnej kompresji? Dlatego, że często przynosi ona lepsze efekty: pliki są jeszcze mniejsze, a strat w obrazie nie widać. JPG jest właśnie algorytmem stratnym.

Porównanie zdjęcia JPG i bez kompresji.

Jednak JPG nie nadaje się do każdego obrazka. Algorytm kompresji używany w tych plikach został zaprojektowany do użytku na fotografiach – i faktycznie przynosi rewelacyjne efekty, co widać powyżej. Spróbujmy jednak zapisać w nim prosty rysunek, a zobaczymy jego niedoskonałości. Co gorsza, po wydrukowaniu stają się one jeszcze bardziej widoczne.

Niedoskonałości kompresji JPG.

Zwróć uwagę ma dziwne kropki przy krawędziach. Zauważysz też, że kolor nie jest jednolity, miejscami występują jaśniejsze i ciemniejsze plamy. To właśnie te „oszustwa”, dzięki którym kompresja stratna działa – na zdjęciach zupełnie ich nie widać, bo nie występują na nich jednolite kolory i ostre krawędzie. czytaj dalej

 

Sprawdź, czy jesteś geniuszem!

To takie proste! Pewna strona na Facebooku oferuje Ci test, dzięki któremu łatwo to zbadasz. Niestety, nie podaje poprawnego rozwiązania… Spróbujmy dojść do niego sami. Oto cudowny sposób na sprawdzenie, czy jesteś geniuszem:

Cudowny test z Facebooka

Teraz pomedytuj przez 5 minut nad prawidłową odpowiedzią. czytaj dalej

 

Jeszcze raz o L.in.oleum, jeszcze raz o quine

L.in.oleum to język programowania, o którym wspominałem już w poprzednim wpisie. Temat quine też już miałem okazję poruszyć, jednak wtedy prezentowałem go w wersji pascalowej, a problem rozwiązałem w zupełnie inny sposób.

Lino nie nadaje się zbyt dobrze do pisania quine w klasycznej postaci. Przyczyna jest prosta: język został zaprojektowany tak, by nie był zbyt oszczędny składniowo, za to bardzo czytelny. Poza tym jest asemblerem, co też nie ułatwia sprawy. Można jednak uciec się do pewnej sztuczki, która zupełnie rozwiązuje ten problem.

Program można wyposażyć w sekcję "stockfile", która umożliwia dołączenie dowolnego pliku do wyjściowej aplikacji. Dowolnego, a więc również samego pliku ze źródłem programu!

Obsługa tak dołączonego pliku nie różni się prawie niczym od wczytywania pliku z dysku, jednak spełnia warunek hermetycznego środowiska – taki program nie wymaga absolutnie żadnych danych z zewnątrz, wszystkie potrzebne informacje są już w pliku wykonywalnym. czytaj dalej

 

L.in.oleum – jeden poziom nad podłogą

Jeśli lubisz poznawać nowe, egzotyczne języki programowania i nie boisz się pracy bardzo blisko sprzętu, to L.in.oleum powinno Cię zainteresować.

Lino – bo tak brzmi popularny w środowisku fanów języka skrót nazwy – jest skutkiem ubocznym rozwijania piątej odsłony gry Noctis. Skutek uboczny to może nienajlepsze ujęcie sytuacji, bo Lino i Noctis rozwijają się równolegle, ale to właśnie od Noctis V zaczęła się historia języka.

Tworząc poprzednie wydania gry jej twórca, Alessandro Ghignola, doszedł do wniosku, że pisanie w asemblerze jest męczące i stosunkowo powolne – sam język nie grzeszy czytelnością, a debugowanie nie należy do najłatwiejszych. Kłopotliwy jest też zupełny brak przenośności, który skutecznie uniemożliwia proste przenoszenie aplikacji na inne platformy systemowe lub sprzętowe.

Będąc już doświadczonym programistą, Ghignola postanowił stworzyć własny niskopoziomowy język programowania, w którym chciał napisać piątą część serii. Tak narodziło się L.in.oleum. czytaj dalej