2008-04-13 23:07:19
Desizer

"Potrzeba jest matką wynalazków" - nie inaczej jest tym razem. Potrzebowałem programiku który w łatwy i szybki sposób dokona dość żmudnej operacji na obrazkach, jaką jest korekta rozmiaru. Czasami dostaje się obrazki powiększone bez wygładzania o współczynnik nie będący liczbą całkowitą, co poważnie obniża ich jakość. Zastanawiałem się, czy może nie dałoby się zatrudnić do tego komputera? Tak mi się nudziło, że nawet nie sprawdzałem, czy coś takiego jest w jakimś innym programie - uznałem to za dobry pretekst do podszlifowania swoich umiejętności i przy okazji zabicia czasu. Efekt - ten program. :)

Założenie jest proste - przy powiększaniu bez wygładzania, część wierszy i/lub kolumn jest powielana. Należy wykryć powielone kolumny i je zlikwidować. Do tego wykorzystałem dwa algorytmy rozpoznające - binarny, jak nazwa wskazuje, rozróżnia dwa wiersze/dwie kolumny, jeśli różnią się którymkolwiek bitem. Jest to metoda błyskawiczna, ale nie daje rezultatów jeśli ktoś zapisał źle powiększony obrazek w pliku ze stratną kompresją (jpeg czy jpeg2000). Algorytm progowy bada po dwa równoległe piksele z każdego wiersza lub kolumny i kwalifikuje je jako różne dopiero wtedy, gdy różnica ich jasności wynosi więcej niż ustalony próg. Wartość należy dobrać "na wyczucie", ale w większości przypadków próg równy 32 daje sensowne rezultaty. Za niski lub za wysoki próg da całkiem ciekawe rezultaty... ;)

Update 14 IV 2008, 3:40: dwa screeny (kliknij by powiększyć) z działającego programu. W lewym-górnym rogu oryginalny obrazek, w prawym-górnym - po przetworzeniu, poniżej oryginalny po powiększeniu 3x.

Przykład 1 Przykład 2


A tutaj przykładowe obrazki (w oryginalnym rozmiarze, po powiększeniu i po potraktowaniu programem) - 2,93MB.

Program nie jest idealny i ma jeden zasadniczy błąd konstrukcyjny - przy powiększaniu o współczynnik nie będący liczbą całkowitą, na jeden wiersz/kolumnę oryginalnego obrazka przypada n *oraz* n+1 wierszy/kolumn oryginalnego obrazka wg np. takiego wzoru:

n n n n+1 n n n n+1 n n n n+1 n n n n+1

Jeżeli obrazek posiada identyczne wiersze lub kolumny występujące obok siebie, program błędnie je rozpoznaje jako wiersze/kolumny należące do wcześniejszej kolumny, np.:

n+64 n+16 n n+1 n n n n+1 n n n n+1 n n n n+1

Jak widać, po przetworzeniu program wytnie pierwszych 80 kolumn lub wierszy. Należałoby tu zastosować jakąś medianę czy inny post-processing, ale to sobie zostawiłem na wersję 1.1. Myślę, że razem z tym poprawiłaby się jakość korekty obrazków potraktowanych stratnymi kompresorami.
Program obsługuje tylko obrazki .bmp.

Do pobrania (bez źródeł) z witryny Branchware

2008-04-12 20:54:50
Jestem księżniczką!

Było na wykopie, ale ja z trochę innej beczki - ile sekund oglądania tego po raz pierwszy wytrzymacie lub wytrzymaliście? Oczywiście - głośniki włączone, filmik na pierwszym planie, pełne skupienie na oglądaniu, etc. - żadnego oszukiwania! ;-)

Ja - koło 20 sekund...

2008-04-06 19:29:45
Uwaga na PeerGuardiana!

Chwilowo przestrzegam przed dokonywaniem update'u bazy blokowanych przez program PeerGuardian 2 adresów IP. Przed chwilą sam to zrobiłem i skończyło się wyczyszczeniem listy blokowanych IP. Wpływ MPAA/RIAA? Czy komuś paluszek się "omsknął"? Mam nadzieję, że to drugie.

Jeżeli ktoś już tego dokonał i ma puste listy, niech natychmiast potraktuje partycję z listami programem do odzyskiwania skasowanych plików - pomaga.

2008-04-05 01:37:55
TPixelTransformer

This article is also available in english language.

Do kilku operacji na bitmapach (np. lustrzane odbicie, resampling czy inny filtr) czasami trzeba skonwertować format pikseli w źródłowej bitmapie. Przeważnie, mając na względzie wydajność i wygodę, pisze się jeden kod obsługujący bitmapy 24-ro lub 32-bitowe. Czasami autorzy są "szczwani" i konwertują (niejawnie) bitmapę na 24 czy 32 bity. Ale to powoduje spore zużycie pamięci jeśli bitmapa jest duża. Jeszcze gorzej, jeśli źródłowej bitmapy nie chcemy modyfikować - wtedy kopiuje się bitmapę od razu do docelowego formatu - ale marnuje się czas na skopiowanie bitmapy, i następującą potem konwersję - dopiero po tych dwóch operacjach można dokonać właściwej obróbki czy analizy. Jeżeli bitmapa jest "poważna", to nie mieszczenie się w pamięciach Cache (czy w skrajnym przypadku RAMie) powoduje jeszcze większe opóźnienia. Inny problem pojawia się, gdy chcemy obrobić/przeanalizować fragment bitmapy. Wtedy przy konwersji/kopiowaniu tracimy czas na przygotowanie tych fragmentow bitmap, których nie tkniemy. Pewnym rozwiązaniem jest utworzenie pomocniczej bitmapy zawierającej kopię tylko obrabianego fragmentu.

Dla swoich potrzeb opracowałem rozwiązanie trochę inne - mianowicie klasę TPixelTransformer. Służy ona do konwersji "on fly", tj. przy tworzeniu obiektu podajemy jej źródłową bitmapę, a następnie wołamy metodę Convert, która zwraca wskaźnik na dane wskazanej linii (wiersza) źródłowej bitmapy skonwertowanej do trybu 24bpp. Jest to rozwiązanie - moim zdaniem - bardzo wygodne, gdyż można to zastosować jako bezpośredni zamiennik tablicy Scanline, a narzut pamięciowy wynosi wtedy ledwie 3*szerokość_w_pikselach. Wiadomo że takie podejście wprowadza do maszynerii pewne opóźnienie, kod nie jest szczególnie inteligentny i wywołanie kilka razy pod rząd metody Convert z tym samym argumentem spowoduje tyle samo konwersji. W gruncie rzeczy można by to zmienić i oprócz tego jeszcze dodać możliwość określenie GDZIE mają wylądować skonwertowane dane bitmapy (domyślnie idą do wewnętrznego bufora, chyba że źródłowa bitmapa JUŻ jest bitmapą 24bit), ale tego nie chciało mi się nigdy zrobić.

Jeśli komuś się to przyda, to może sobie zassać ze strony BranchWare. Kod był tworzony i testowany pod Delphi 3, ale pod nowszymi też powinien kompilować się i działać. Polecam lekturę readme.

2008-04-02 23:41:36
register_globals

Co robi programista PHP, gdy przez lata korzystał z dobrodziejstw WŁĄCZONEJ opcji register_globals i w wyniku nagłej "zmiany warty" zmienia się również stan aktywności tej opcji? Oczywiście ma dwa wyjścia. Poprawić swój kod i żyć dalej, lub... próbować obejść. Możliwych sposobów jest wiele, ale to, co zobaczyłem, to chyba już kwalifikuje się na The Daily WTF:

login as: [user]
[user]@[server]'s password:
Linux [server] 2.6.18-6-686 #1 SMP Sun Feb 10 22:11:31 UTC 2008 i686

The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law.
Last login: Tue Mar 4 18:01:03 2008 from [..]
[user]@[server]:~$ ls
www
[user]@[server]:~$ cd www
[user]@[server]:~/www$ ls
andrespol favicon.ico jajko.html php.ini tuszyn
[..]
[user]@[server]:~/www$ cat php.ini
register_globals = 1[user]@[server]:~/www$

Dobrze widzicie. Tutaj ktoś utworzył plik "php.ini" (plik o tej nazwie - aczkolwiek znajdujący się w innym katalogu - zawiera konfigurację PHP) i wpisał do niego "register_globals = 1", nawet nie kończąc enterem. Pomijam brak nazwy sekcji. Nie muszę dodawać, że nic to nie dało?

Powered by:
Hellcore Mailer - polski program pocztowyOpera Web BrowserFreeBSD - The Power to Serve!Slackware
RSSy:
Sidekick:
Projekty:
O autorze:
Zobacz:
Kategorie:
Archiwum:
Szukaj: