Wektoryzacja prostych schematów układów

Transkrypt

Politechnika Warszawska
Rok akademicki 2011/2012
Wydział Elektroniki i Technik Informacyjnych
Instytut Informatyki
PRACA DYPLOMOWA INŻYNIERSKA
Piotr Krzysztof Jastrze˛ bski
Wektoryzacja prostych schematów
układów cyfrowych
Opiekun pracy:
prof. dr hab. inż. Jan Zabrodzki
Ocena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.........................................
Podpis Przewodniczacego
˛
Komisji Egzaminu Dyplomowego
Specjalność:
Inżynieria systemów
informatycznych
Data urodzenia:
18 maja 1989 r.
Data rozpoczecia
˛
studiów:
23 lutego 2009 r.
Życiorys
Nazywam sie˛ Piotr Jastrzebski.
˛
Urodziłem sie˛ 18 maja 1989 r. w Radomiu.
W roku 2002 ukończyłem Szkołe˛ Podstawowa˛ nr 3. im. Jana Długosza w Radomiu i rozpoczałem
˛
nauke˛ w Publicznym Gimnazjum nr 23. im. Jana Kochanowskiego w Radomiu.
W roku 2005 zaczałem
˛
uczeszczać
˛
do klasy o profilu
matematyczno-fizycznym w VI Liceum Ogólnokształcacym
˛
im. J.Kochanowskiego
w Radomiu. W roku 2008 zdałem mature,
˛ a w lutym 2009 r. rozpoczałem
˛
studia
dzienne na wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej. W ramach wymiany miedzynarodowej
˛
studiowałem także na uczelni University of Ulsan w Korei Południowej oraz w Katholieke Universiteit Leuven w Belgii.
.....................................
podpis studenta
Egzamin dyplomowy
Złożył egzamin dyplomowy w dn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Z wynikiem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ogólny wynik studiów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dodatkowe wnioski i uwagi Komisji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
..........................................................................................
Streszczenie
Praca ta prezentuje aplikacje˛ pozwalajac
˛ a˛ na wektoryzacje˛ schematów układów
cyfrowych zapisanych w formacie grafiki rastrowej.
Została ona przygotowana
z myśla˛ o działaniu pod kontrola˛ systemu Android i na podstawie graficznych plików
wejściowych różnego rodzaju generuje wyjściowa˛ wersje˛ zapisana˛ w wektorowym
formacie SVG. Korzysta ona z algorytmów przetwarzania obrazu z biblioteki OpenCV.
Słowa kluczowe: grafika wektorowa, układ cyfrowy, wektoryzacja, trasowanie,
SVG, OpenCV, Android
Abstract
Title: Simple digital circuit diagrams vectorization
This thesis describes the application which vectorizes digital circuit diagrams
saved as a raster graphics. Created application runs on Android operating system
and being given different type graphics files processes it into vector-based SVG file.
It uses image processing algorithms from OpenCV library.
Key words:
vector graphics, digital circuit, vectorization, image tracing, SVG,
OpenCV, Android
Spis treści
1. Wstep
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2. Istniejace
˛ rozwiazania
˛
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3. Specyfikacja wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.1. Wymagania funkcjonalne
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.2. Wymagania niefunkcjonalne . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
4. Koncepcja rozwiazania
˛
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
5. Technologie i narzedzia
˛
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
5.1. Platforma systemu Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
5.2. Biblioteka OpenCV
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
5.3. Format Scalable Vector Graphics . . . . . . . . . . . . . . . . . . . . . . . . . .
15
6. Proces wektoryzacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
6.1. Korekta obróconego obrazu wejściowego . . . . . . . . . . . . . . . . . . . . . .
19
6.2. Detektor krawedzi
˛
Canny’ego . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
6.2.1. Redukcja szumu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
6.2.2. Wyszukiwanie nate˛ żenia gradientu . . . . . . . . . . . . . . . . . . . . .
22
6.2.3. Usuwanie niemaksymalnych pikseli . . . . . . . . . . . . . . . . . . . .
22
6.2.4. Progowanie z histereza˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
6.3. Wykorzystanie transformaty Hougha przy wykrywaniu odcinków . . . . . . .
23
6.4. Detektor wierzchołków Harrisa . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
6.5. Przetwarzanie zebranych danych . . . . . . . . . . . . . . . . . . . . . . . . . .
30
6.5.1. Odnajdywanie wierzchołków prostokatów
˛
. . . . . . . . . . . . . . . . .
32
6.5.2. Odnajdywanie obramowania prostokatów
˛
. . . . . . . . . . . . . . . . .
32
6.5.3. Odnajdywanie punktów wewnetrznych
˛
. . . . . . . . . . . . . . . . . . .
33
6.5.4. Wykrywanie punktów i wielokatów
˛
połacze
˛ ń . . . . . . . . . . . . . . .
33
6.5.5. Odnajdywanie symboli . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
6.5.6. Łaczenie
˛
pozostałych wierzchołków wolnych . . . . . . . . . . . . . . .
34
6.6. Rysowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
Spis treści
ii
7. Interfejs użytkownika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
8. Testowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
8.1. Sprawdzanie działania aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
8.2. Strojenie parametrów aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
9. Dokumentacja projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
10.Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
10.1.Spełnienie założeń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
10.2.Porównanie wyników . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
10.3.Perspektywy rozwoju aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
A. Jezyk
˛
skryptowy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
1. Wstep
˛
Jednym z podstawowych rodzajów grafiki komputerowej jest grafika wektorowa.
Do tworzenia obrazów wektorowych wykorzystuje sie˛ prymitywy graficzne takie
jak: punkty, odcinki, krzywe oraz różnego rodzaju figury geometryczne. Każdy
z obiektów tworzacych
˛
obraz jest matematycznie zdefiniowany i umiejscowiony
w układzie współrze˛ dnych.
Ze wzgle˛ du na swój matematyczny charakter, obraz wektorowy posiada wiele
zalet. Do głównych z nich można zaliczyć bardzo dobra˛ skalowalność oraz prostote˛
opisu wynikajac
˛ a˛ z wewne˛ trznej, hierarchicznie zdefiniowanej struktury pliku. Dodatkowo obraz wektorowy dla zastosowań niefotorealistycznych charakteryzuje sie˛
znacznie mniejszymi plikami wynikowymi. W zastosowaniach profesjonalnych, reprezentacja wektorowa grafiki znalazła szerokie zastosowanie ze wzgledu
˛
na forme˛
plików wejściowych wielu urzadze
˛
ń druku wielkoformatowego np. ploterów. Jest
to prawdopodobnie jedno z niewielu zastosowań bezpośredniej formy wektorowej.
Urzadzenia
˛
cyfrowe jak monitor czy drukarka bazuja˛ na reprezentacji opisanej
skończona˛ liczba˛ pikseli i dla każdej grafiki wektorowej przed wyświetleniem konieczna staje sie˛ operacja rasteryzacji, czyli obliczenia jaka˛ wartość (kolor) bedzie
˛
miał odpowiedni piksel. Jest to jednak, w przeciwieństwie do procesu wektoryzacji,
proces bezstratny i jednoznacznie określony.
Najwie˛ ksza˛ wada˛ obrazów wektorowych jest ogromna złożoność pamieciowa
˛
dla
zastosowań fotorealistycznych i tym samym nieopłacalność obliczeniowa konwersji
do formy wektorowej skomplikowanych obrazów rastrowych. Tym samym stosuje
si˛e je najcz˛eściej do wykonywania schematów naukowych i technicznych, map
i planów, różnych form grafiki użytkowej jak logo, herby, flagi lub piktogramy
oraz znaki, np.
drogowe.
Takie formy graficzne cechuja˛ sie˛ małym stopniem
skomplikowania, prostymi kształtami i dużymi obszarami jednokolorowymi. Dla
takich zastosowań grafika wektorowa sprawdza sie˛ najlepiej.
Obrazy wektorowe zapisywane sa˛ w różnych formatach plików. Wiele z nich
powstało jako odpowiedź na konieczność stworzenia zapisu danych dla konkretnej
aplikacji, np. CorelDRAW udostepnia
˛
format CDR, Adobe Illustrator format AI,
a AutoCAD format DXF. Istnieja˛ także rozwiazania
˛
wyspecjalizowane jak format
2
1. Wstep
˛
Gerber (RS-274X) be˛ dacy
˛ w praktyce standardem używanym przy produkcji obwodów drukowanych. Jednym z najbardziej popularnych formatów zapisu grafiki
wektorowej jest format SVG1 , który co do formy zapisu jest po prostu plikiem XML2 .
Jego popularność wynika z szerokiego zastosowania w Internecie, a wsparcie wyświetlania plików w formacie SVG zapewniaja˛ popularne przegladarki
˛
internetowe
jak np. Mozilla Firefox, Internet Explorer 9, Google Chrome, Opera i Safari. W najnowszej wersji standardu, SVG 1.1, zapewnia wszelkie potrzebne do realizacji projektu funkcje, takie jak: tworzenie ścieżek z prostych lub krzywych, podstawowe
kształty, wypełnianie ich kolorem z różnym stopniem przezroczystości. Pozwala
także na przechowywanie metadanych i zapewnia wbudowana˛ obsługe˛ fontów.
Do identyfikacji poszczególnych elementów na schematach układów cyfrowych
stosuje sie˛ różnego rodzaju symbole. W powszechnym użyciu sa˛ dwa zestawy,
oba zdefiniowane w dokumencie [8] przygotowanym przez ANSI3 i IEEE4 . Symbole
o zróżnicowanych kształtach (norma ANSI) bazuja˛ na tradycyjnych oznaczeniach
i używane sa˛ do prostych rysunków. Wywodza˛ sie˛ z amerykańskiego standardu
wojskowego z lat 50 i 60. Symbole prostokatne,
˛
bazujace
˛ na standardzie IEC5 maja˛
stały kształt i dzie˛ ki temu moga˛ reprezentować znacznie wieksz
˛
a˛ liczbe˛ elementów
i urzadze
˛
ń.
Zalecane jest stosowanie symboli IEC, ale na mocy porozumienia
zawartego mie˛ dzy IEEE a IEC oba standardy sa˛ równoważne i moga˛ być stosowane
wymiennie.
Istnieje jeszcze norma niemiecka zdefiniowana przez DIN6 , ale nie
znajduje ona powszechniejszego zastosowania poza granicami Niemiec.
Podczas wybierania tematu mojej pracy, chciałem aby efekt końcowy miał wartość nie tylko w postaci dobrze udokumentowanego procesu inżynierskiego, ale
przede wszystkim, aby przyczyniła sie˛ ona do rozwoju moich umiejetności
˛
w zakresie programowania i projektowania aplikacji mobilnych.
Celem pracy inżynierskiej jest stworzenie aplikacji wektoryzujacej
˛
obrazy bitmapowe, działajacej
˛
pod kontrola˛ systemu operacyjnego Android. Program ma za
zadanie uzyskanie możliwie wiernie wektorowej reprezentacji obrazu wejściowego
stosujac
˛ w tym procesie różne algorytmy przetwarzania obrazu. Końcowy wynik
zapisywany powinien być w formacie grafiki wektorowej SVG. Wykonana aplikacja
powinna w sposób możliwie prosty pozwalać na wybranie użytkownikowi zadanego
1
2
3
4
5
6
ang. Scalable Vector Graphics
ang. Extensible Markup Language
ang. American National Standards Institute
ang. Institute of Electrical and Electronics Engineers
ang. International Electrotechnical Commission
niem. Deutschen Institut für Normung
3
1. Wstep
˛
pliku do wektoryzacji, wykonać ja˛ i zaprezentować otrzymane rezultaty, zarówno
w zestawieniu z oryginałem, jak i sam efekt końcowy.
Moja˛ prace˛ dyplomowa˛ podzieliłem na 10 rozdziałów. Pierwszy, to niniejszy
wst˛ep. W drugim charakteryzuje˛ istniejace
˛ na rynku rozwiazania
˛
i przedstawiam
porównanie wyników ich zastosowania na potrzeby wektoryzacji. W rozdziale trzecim wyszczególniłem wymagania zarówno funkcjonalne jak i niefunkcjonalne stawiane aplikacji. Rozdział czwarty przedstawia koncepcje˛ rozwiazania
˛
problemu
wektoryzacji obrazów bitmapowych.
Nastepny
˛
rozdział - piaty
˛ - to krótki opis
technologi i narze˛ dzi wykorzystanych przy tworzeniu projektu. Rozdział szósty,
najobszerniejszy, przedstawia elementy składowe algorytmu przetwarzania obrazu
oraz tłumaczy sam proces wektoryzacji. Staram sie˛ w nim opisać „Jak to dokładnie
działa?”. Rozdział siódmy przedstawia interfejs użytkownika. W rozdziale ósmym
przedstawiłem proces testowania aplikacji. Rozdział dziewiaty
˛ to dokumentacja
projektu wraz z diagramamem klas i przypadków użycia. Rozdział dziesiaty
˛ to
podsumowanie, określenie, jakie cele spośród założonych udało sie˛ osiagn
˛ ać
˛ oraz
możliwe kierunki rozwoju. Uzupełnienie dokumentu stanowi bibliografia oraz dodatek zawierajacy
˛ je˛ zyk skryptowy przygotowany na potrzeby projektu.
Podczas przygotowywania pracy starałem sie˛ odpowiedzieć jednocześnie na dwa
pytania: „Jak wykonać dany element projektu?” i „Dlaczego, właśnie w ten sposób?”. Pokładam duża˛ nadzieje˛ w tym, że praca spełni oczekiwania odbiorców studentów Wydziału Elektroniki i Technik Informacyjnych Politechniki Warszawskiej oraz innych osób zainteresowanych zarówno tematem przetwarzania obrazu
jak i programowania aplikacji mobilnych.
2. Istniejace
˛ rozwiazania
˛
Procesem uzyskiwania obrazów wektorowych z wejściowych plików rastrowych
jest wektoryzacja (ang. vectorization) lub inaczej trasowania (ang. image tracing).
Samo wektoryzowanie może odbywać sie˛ w dwojaki sposób: recznie,
˛
gdzie osoba
odrysowuje na bitmapie krawedzie
˛
i kształty, które nastepnie
˛
zostaja˛ zamienione
na matematycznie opisane proste, krzywe i obsługiwane wielokaty
˛ lub automatycznie, gdzie odpowiednie algorytmy same analizuja˛ i przekształcaja˛ obraz rastrowy
na wektorowy, jak przedstawiano np. w [9, 22]. W przeszłości stosowano także
wektoryzacje˛ ekranowa,
˛ polegajac
˛ a˛ na „obrysowywaniu” rysunku rastrowego na
ekranie monitora. Rzadziej stosuje sie˛ metode˛ wektoryzacji za pomoca˛ tzw. digitizera (myszki z celownikiem poruszajacej
˛
sie˛ po swego rodzaju tablecie).
Najcze˛ stszym podejściem do rozwiazania
˛
problemu wektoryzacji jest zgrupowanie w wie˛ ksze obiekty wektorowe na zasadzie podobieństwa koloru rastrów opisujacych
˛
dana˛ bitmape˛ . Etapy takiego łaczenia
˛
i efekty końcowe algorytmów grupujacych
˛
przedstawiono w [18]. Efektem procesu wektoryzacji dla wielu skomplikowanych obrazów bitmapowych jest zniekształcony i pozbawiony szczegółów obraz
wektorowy. Tylko bitmapa składajaca
˛ sie˛ z elementów bed
˛ acych
˛
prostymi kształtami ma szanse być poprawnie przekształcona.
Wielu producentów oprogramowania graficznego zdaje sobie sprawe˛ z zapotrzebowania na aplikacje posiadajace
˛ funkcje wektoryzacji. Profesjonalnymi programami graficznymi obsługujacymi
˛
wektoryzacje˛ sa˛ m.in. CorelTrace (składnik pakietu CorelDRAW), Adobe Flash, Adobe Illustrator, Adobe FreeHand lub Inkscape
(przez wykorzystanie zintegrowanego programu Potrace). Istnieja˛ również rozwia˛
zania działajace
˛ po stronie serwera jak np. dostepny
˛
online Vector Magic [7] lub
AutoTrace [3]. Brak jest jednak rozwiazania
˛
na platformy mobilne jak np. urza˛
dzenia działajace
˛ pod kontrola˛ systemu Android. W zwiazku
˛
z faktem, że sam
proces wektoryzacji jest słabo zdefiniowany, a końcowe wyniki silnie zależne sa˛ od
przeznaczenia narze˛ dzia, konstruuje sie˛ różne algorytmy wektoryzacji: inne dla rysunku technicznego i schematów, inne dla postaci z kreskówek [15, 16], a inne dla
przetwarzania i ewidencji zdjeć
˛ naturalnych, satelitarnych czy lotniczych. Wyniki
2. Istniejace
˛ rozwiazania
˛
5
otrzymywane podczas wykorzystania uniwersalnych programów bardzo czesto
˛
albo
prezentuja˛ niska˛ jakość odwzorowania albo cechuja˛ sie˛ dużym rozmiarem plików.
3. Specyfikacja wymagań
1. Zbiór elementów przetwarzanych – program powinien umożliwiać rozpoznawanie i przetwarzanie obrazów rastrowych bed
˛ acych
˛
poprawnymi schematami
układów cyfrowych zapisanych zgodnie ze standardem IEC, złożonych z ograniczonego zbioru elementów: bramek logicznych (opisanych w dokumencie [8])
oraz przerzutnika typu D ( [14] s. 375). Porównanie standardów zapisu przedstawiono w tablicy 3.1)
2. Postać wejściowa – obraz wejściowy powinien być schematem dwubarwnym o
dość dobrej jakości i dokładnym wykonaniu. Dozwolone jest, aby schemat został
obrócony np. podczas skanowania.
3. Możliwość zmiany rozmiaru obrazu wyjściowego – aplikacja musi umożliwiać
skalowanie obrazu wyjściowego bazujac
˛ na wymiarach podanych przez użytkownika. Podane wymiary, wyrażone w pikselach, nie musza˛ zachowywać wzgled˛
nych proporcji obrazu oryginalnego. Zarówno szerokość jak i wysokość obrazu
moga˛ być zwie˛ kszane lub zmniejszane niezależnie od siebie.
4. Funkcja obrotu obrazu o zadany kat
˛ – obraz wyjściowy może zostać obrócony
o zadany kat.
˛ Wartościa˛ określajaca
˛ go w stopniach, jest dodatnia˛ liczba˛ całkowita,
˛ dla której wartości równe i wieksze
˛
360◦ oznaczaja˛ wynik funkcji kata
˛
modulo 360. Operacja obrotu powinna być wykonywana po ewentualnej operacji skalowania.
5. Opcja zmiany zestawu kolorów obrazu – aplikacja powinna pozwalać na niezależny wybór kolorów rysowania dla trzech elementów: tła obrazu, zestawu
czcionek użytych do oznaczania symboli oraz dla linii, za pomoca˛ których rysowane sa˛ układy cyfrowe. Wybór koloru powinien nastepować
˛
np. poprzez
wybranie odpowiedniej wartości z graficznej palety barw.
6. Obsługiwane formaty plików – program powinien zapewniać możliwość wektoryzacji rastrowych plików graficznych zapisanych w wielu popularnych formatach:
— Windows Bitmap (BMP): *.bmp, *.dib
7
— Portable Network Graphics (PNG): *.png
— Joint Photographic Experts Group (JPEG): *.jpeg, *.jpg, *.jpe
— JPEG 2000: *.jp2
— Tagged Image File Format (TIFF): *.tiff, *.tif
— Portable anymap: *.pbm, *.pgm, *.ppm
— Rastrowe pliki systemu Sun: *.sr, *.ras
7. Swobodny dostep
˛ do systemu plików – użytkownik powinien mieć możliwość
wyboru piku do przetworzenia poprzez podanie bezwzglednej
˛
ścieżki. Osiagalne
˛
musza˛ być wszystkie pozycje dostepne
˛
w systemie plików systemu Android.
Tablica 3.1. Porównanie sposobów zapisu symboli bramek logicznych.
US ANSI 91-1984
Standard
IEC 60617-12
&
AND
≥1
OR
&
NAND
≥1
NOR
1
XOR
1
XNOR
1
NOT
Przerzutnik typu D
DIN 40700
3.2. Wymagania niefunkcjonalne
8
3.2. Wymagania niefunkcjonalne
1. Interaktywna praca aplikacji – proces wektoryzacji może być czasochłonny
i wymagajacy
˛ obliczeniowo szczególnie dla dużych i skomplikowanych obrazów
wejściowych. Aplikacja nie powinna w żadnym momencie „zawieszać” sie˛ i nie
odpowiadać na akcje użytkownika. Program powinien w widocznej warstwie interfejsu użytkownika informować go o trwajacych
˛
w tle procesach i ewentualnie
wyświetlać poste˛ p prac.
2. Przyjazny interfejs – program powinien informować użytkownika o problemach
lub wydarzeniach wymagajacych
˛
podjecia
˛
jakiejś akcji. W przypadku podania
niepoprawnej ścieżki pliku wejściowego, zakończenia procesu wektoryzacji itp.
wyświetlany powinien być odpowiedni komunikat. Obsługa fizycznych przycisków standardowych: menu, powrotu i głównego ekranu powinna być zgodna
z zaleceniami tworzenia aplikacji pod systemem Android wersji 2.*. Układ i rozmiar elementów interfejsu użytkownika powinien być przystosowany do obsługi
poprzez ekran dotykowy.
3. Zgodność ze standardem SVG – wynikowy plik grafiki wektorowej powinien
być tworzony zgodnie z zaleceniami W3C1 , tak, aby niezależnie od urzadzenia
˛
czy aplikacji w której be˛ dzie wyświetlany, odbywało sie˛ to poprawnie i zawsze
dawało takie same wyniki.
4. Rozmiar pliku wynikowego – plik wektorowy uzyskany w procesie wektoryzacji powinien cechować sie˛ jak najmniejszym rozmiarem. Najlepiej, gdyby niezależnie od stopnia skomplikowania obrazu dla wzorcowej rozdzielczości pliku
wejściowego rze˛ du 1024x768 punktów, uzyskany obraz wektorowy miał rozmiar
mniejszy niż odpowiadajacy
˛ mu plik rastrowy.
5. Internacjonalizacja – ewentualne umiedzynarodowienie
˛
oprogramowania powinno odbywać sie˛ bez konieczności ingerencji w warstwe˛ algorytmów i wygladu
˛
aplikacji. Dla każdego je˛ zyka, w celu łatwiejszej modyfikacji, zalecane jest stworzenie oddzielnego pliku XML przechowujacego
˛
wszystkie teksty i napisy użyte
w programie.
1
ang. World Wide Web Consortium
˛
Wste˛ pnym zagadnieniem mojej pracy inżynierskiej była „Wektoryzacja obrazów
bitmapowych”. W przeciagu
˛
roku, w toku przygotowania do pisania pracy, pojawiało sie˛ wiele pomysłów, jak ten temat zagospodarować. Były to pomysły zarówno
dotyczace
˛ wyboru zastosowania aplikacji wektoryzujacej
˛
obrazy bitmapowe jak i
podejścia do rozwiazania
˛
samego problemu.
Poczatkowy
˛
etap polegał na zbieraniu informacji na temat dostepnych
˛
na rynku
narz˛edzi, które już posiadały funkcjonalność trasowania obrazu, jak również na zapoznaniu sie˛ z publikacjami naukowymi. W obu przypadkach taka analiza nie była
łatwa. Firmy nieche˛ tnie dziela˛ sie˛ informacjami na temat działania ich programów,
zatem można było je pozyskiwać jedynie z dokumentacji i opisów funkcjonalności
aplikacji. Publikacje naukowe czestokroć
˛
dość pobieżnie opisywały omawiane zagadnienia koncentrujac
˛ sie˛ bardziej na uzyskanych wynikach. Jednakże, na bazie
tych informacji pojawiała sie˛ wstepna
˛
koncepcja rozwiazania.
˛
Drugim etapem, jako, że bardzo zależało mi na przygotowaniu działania aplikacji
dla systemu Android, było sprawdzenie, czy zaprojektowanie i wykonanie takiej
aplikacji jest w ogóle możliwe. Wiazało
˛
sie˛ to z zapoznaniem sie˛ z dokumentacja˛
systemu Android [2]. Okazało sie˛ także, że istnieje biblioteka OpenCV służaca
˛
do przetwarzania grafiki i ma ona swoja˛ wersje˛ działajac
˛ a˛ pod tym systemem,
zapewniajac
˛ a˛ prawie pełna˛ funkcjonalność oryginalnej wersji dla jezyków
˛
C i C++.
Należało zapoznać sie˛ z jej możliwościami. W tym celu przeczytałem dokumentacje˛
dost˛epna˛ w Internecie [4] oraz ksia˛żke˛ „Learning OpenCV” [10]. Obie te pozycje były
również bardzo pomocne podczas pisania samego programu zapewniajac
˛ wsparcie
i objaśnienia na temat opisów działania i składni poszczególnych funkcji, obiektów
i algorytmów.
Kiedy została podje˛ ta decyzja, że wektoryzowane bed
˛ a˛ schematy układów cyfrowych, w celu zapewnianie zgodności przetwarzanych symboli ze standardem
zapoznałem sie˛ z dokumentem standaryzujacym
˛
IEEE [8] oraz z przykładowymi
schematami i symbolami użytymi w ksia˛żce „Podstawy elektroniki cyfrowej” [14].
W trakcie analizy zagadnienia układów cyfrowych posiłkowałem sie˛ także ksia˛żka˛
„Podstawy projektowania układów cyfrowych” [12].
˛
10
W mie˛ dzyczasie porównywałem dostepne
˛
sposoby i formaty zapisów plików wektorowych. Wybór formatu SVG był jednak dość oczywisty ze wzgledu
˛
na powszechność jego użycia, otwartość standardu oraz łatwość zapisu.
Kiedy tematyka przetwarzanych obrazów, platforma systemowa, biblioteki, je˛
zyk programowania i sposób zapisu zostały ustalone należało zastanowić sie˛ nad
koncepcja˛ samego algorytmu przetwarzania schematów. Ze wzgledu
˛
na prostote˛
zapisu, wydawało mi sie˛ oczywiste, że analizowanie należy zaczać
˛ od przetworzenia
obrazu na wersje˛ dwubarwna˛ oraz próbować wydobyć z obrazu cechy charakteryzujace
˛ symbole układu logicznego. Tym samym wykorzystanie detekcji krawedzi
˛
i wierzchołków wydawało sie˛ mieć duży potencjał. O ile wykryte punkty niosa˛
w sobie jakieś informacje o strukturze obrazu, to detektor krawedzi
˛
Canny’ego
przekształca jedynie jeden obraz w drugi. Konieczne stało sie˛ zatem wydobycie
informacji o istniejacych
˛
w obrazie odcinkach i prostych. W tym celu chciałem wykorzystać transformate˛ Hougha, która pozwala na wydobycie informacji z obrazu
np. o współrze˛ dnych wierzchołków odcinków. Dysponujac
˛ takimi danymi, na bazie
informacji wynikajacych
˛
m.in. ze standardu ICE, można przetwarzać zgromadzone
dane w celu rozpoznawania elementów układów cyfrowych w obrazie. Jak dokładnie ten proces przebiegał, zostało opisane w rozdziale 6, zaś informacje na temat
wykorzystanych technologi, w rozdziale 5.
5. Technologie i narzedzia
˛
5.1. Platforma systemu Android
Projektowana aplikacja przygotowana została dla systemu operacyjnego Android. Producentem systemu jest stowarzyszenie biznesowe Open Handset Alliance,
ale w praktyce jego rozwój pozostaje pod dużym wpływem firmy Google. Android został oparty na jadrze
˛
systemu Linux (starsze na wersji 2.6, a najnowsze na 3.0 oraz
3.1) i przewidziany jest do zastosowania w urzadzeniach
˛
mobilnych korzystajacych
˛
z procesora ARM jak np. smartfony czy tablety. W chwili obecnej (sierpień 2012)
najnowsza˛ stabilna˛ wersja˛ systemu jest wersja 4.1 Jelly Bean, lecz przygotowywana aplikacja powstaje z myśla˛ o najpopularniejszej w tej chwili wersji systemu:
2.3 Gingerbread (60,6% udziału w runku [1]). Wynikało to też poniekad
˛ wprost
z wymagań biblioteki OpenCV, która działa pod systemem Android w wersji 2.2
lub wyższej. Programowanie aplikacji działajacych
˛
pod kontrola˛ systemu Android
wymaga zgoła innego podejścia niż programowanie aplikacji dla systemu Windows
czy Linux.
Interfejs programowania aplikacji (API) systemu Android zapewnia:
1. obsługe˛ „cyklu życia” aplikacji – w uproszczeniu: wyjście z działajacej
˛
aplikacji
przenosi ja˛ zazwyczaj w stan zawieszenia (funkcja systemowa onPause()) i o ile
inna aplikacja z wyższym procesem nie zgłosi żadania
˛
przydziału zajetej
˛
pamieci,
˛
b˛edzie ona działać aż do czasu wznowienia (funkcja systemowa onResume()).
W praktyce jedynie jawne i świadome wywołanie funkcji onStop() kończy aplikacje˛ .
2. dynamiczne przydzielanie pamieci
˛ w zależności od chwilowego na nia˛ zapotrzebowania oraz statusu aplikacji
3. podstawowe elementy składowe interfejsu użytkownika aplikacji tj. zunifikowany wyglad
˛ pól, przycisków, pasków przewijania itp.
12
4. obsługe˛ zdarzeń zewne˛ trznych a w szczególności: reakcji ekranu dotykowego na
dotknie˛ cia, przeciaganie
˛
i inne gesty, wciśniecia
˛
przycisków fizycznych i dotykowych na obudowie, obsługe˛ systemów: GPS, akcelerometru, czujnika zbliżeniowego, cyfrowego kompasu, miernika nate˛ żenia oświetlenia itp.
5. przechowywanie ustawień aplikacji pomiedzy
˛
uruchomieniami w dowolnie definiowalnej klasie SharedPreferences (forma dedykowanego kontenera w pamie˛ ci stałej dla pojedynczej aplikacji)
Programowanie aplikacji na platforme˛ Android nie nastrecza
˛
wiekszych
˛
problemów i nie wymaga ponoszenia żadnych kosztów finansowych. Najprościej wykorzystać do tego środowisko programistyczne Eclipse, wspierajace
˛ jezyk
˛
Java, który
w nieco zmodyfikowanej wersji jest jezykiem
˛
programowania używanym dla urza˛
dzeń mobilnych Android. Dodatkowo należy ze strony Android Developers [2] pobrać Android Software Development Kit (SDK) a także wtyczke˛ Android Development
Tool (ADT) dla Eclipse. Tak skonfigurowane środowisko pozwala na bezproblemowe
projektowanie i rozwijanie aplikacji. Wtyczka dla Eclipse pozwala na korzystanie
z perspektywy DDMS1 , która daje możliwość programiście dostepu
˛
do logów systemowych Android, działajacych
˛
urzadze
˛
ń, aktywnych watków,
˛
emulacji parametrów
oraz podgladu
˛
całego systemu plików. Co istotne, nie jest wymagane posiadanie
własnego smartfona czy tabletu, gdyż SDK posiada menadżera maszyn wirtualnych (AVD Manager). Pozwala to nie tylko na sprawdzenie jak aplikacja działa pod
różnymi wersjami systemu, ale umożliwia zmiane˛ rozmiaru i rozdzielczości ekranu,
symuluje wskazania odbiornika GPS, akcelerometru, czujnika zbliżeniowego oraz
prac˛e kamery czy aparatu. Na rysunku 5.1 przedstawiono zrzut ekranu z maszyny
wirtualnej Android. Po lewej stronie widoczny jest interfejs użytkownika, zaś po
prawej klawiatura oraz fizyczne przyciski wystepuj
˛
ace
˛ na obudowach telefonów i
smartfonów (regulacji głośności, menu, obsługi rozmowy oraz przycisk aparatu).
OpenCV jest biblioteka˛ napisana˛ w jezykach
˛
C i C++, stworzona˛ przez firme˛ Intel
i rozwijana˛ obecnie jako wolne oprogramowanie przy współpracy z firmami Willow
Garage oraz Itseez. Głównym jej zastosowaniem jest szeroko pojete
˛ przetwarzanie obrazu (rozpoznawanie twarzy, gestów, obiektów; śledzenie ruchu; widzenie
stereoskopowe itp.). W aplikacji przygotowanej na potrzeby pracy inżynierskiej wykorzystywana jest wersja OpenCV 2.3.1 z 12 września 2011 roku, używajaca
˛ klas
1
ang. Dalvik Debug Monitor Server
13
Rysunek 5.1. Zrzut ekranu maszyny wirtualnej z uruchomionym systemu Android
2.2
14
opakowujacych
˛
przeznaczonych specjalnie do programowania aplikacji na mobilnych urzadzeniach
˛
działajacych
˛
pod kontrola˛ systemu operacyjnego Android.
OpenCV dzieli funkcje w zależności od przeznaczenia na poszczególne klasy:
1. Funkcje i obiekty podstawowe (klasa Core) – Sa˛ to przede wszystkim macierze
i wszelkie operacje wykonywane na nich, własne funkcje matematyczne i stałe,
operacje kreślenia fontów i rysowania podstawowych kształtów jak np. kół,
wielokatów,
˛
prostokatów.
˛
Znajduja˛ sie˛ tu także funkcje odpowiedzialne za
zarzadzanie
˛
pamie˛ cia.
˛
2. Przetwarzanie obrazu (klasa Imgproc) – Ta klasa zapewnia metody implementujace
˛ różnego rodzaju filtrowania, transformacje, obliczanie histogramów czy
analize˛ strukturalna.
˛ Znalazły sie˛ tu także deskryptory kształtu, funkcje śledzenia obiektów, wykrywania ruchu, czy metody ekstrakcji cech.
3. Interfejs użytkownika i obsługa plików (klasa Highgui) – Klasa implementuje
prosty interfejs graficzny oraz zapewnia odczyt i zapis obrazu z pliku lub kamery,
jak również obsługe˛ myszy i klawiatury.
4. Analiza obrazu wideo (klasa Video) – Sa˛ to przede wszystkim funkcje analizy
ruchu i śledzenia obiektów.
5. Rekonstrukcja 3D i kalibracja (klasa Calib3d) – Funkcje kalibracji i rekonstrukcji 3D dla kamer fotografii otworkowej.
6. Analiza cech 2D (klasa Features2d) – Klasa zawiera deskryptory i funkcje
rozpoznawania cech (m.in. deskryptory ORB, MSER, FAST) oraz funkcje kategoryzujace
˛ obiekty.
7. Rozpoznawanie obiektów (klasa Objdetect) – Funkcje odpowiedzialne za implementacje metod rozpoznawania obiektów za pomoca˛ m.in. klasyfikatora kaskad Haara.
8. Uczenie maszynowe (klasa Ml) – Zaimplementowany został własny model statystyczny, klasyfikator Bayesa, drzewa decyzyjne, sieci neuronowe, algorytm
k najbliższych sasiadów
˛
itp.
9. Grupowanie i przeszukiwanie w przestrzeniach wielowymiarowych (klasa
Flann) – Interfejs do biblioteki FLANN oraz funkcja zapewniajaca
˛ klastrowanie
bazujace
˛ na hierarchicznym algorytmie k średnich.
10. Funkcje wspierajace
˛
obliczenia na karcie gragficznej (klasa Gpu) – Sa˛ to
oddzielne struktury danych, macierze, operacje oraz funkcje analogiczne do tych
z innych klas, ale obsługujace
˛ wsparcie obliczeń przez karte˛ graficzna.
˛
11. Przetwarzanie fotografii (klasa Photo) – W praktyce jest to jedna funkcja:
inpaint() służaca
˛ do restauracji starych zdjeć
˛ - usuwania z nich ubytków i
zarysowań.
5.3. Format Scalable Vector Graphics
15
12. Łaczenie
˛
obrazów (klasa Stitching) – Klasa zaawansowanych algorytmów
łaczenia
˛
wielu obrazów za pomoca˛ cech, deskryptorów i elementów wspólnych.
Zapewnia algorytmy łaczenia,
˛
wygładzania, transformacji i dopasowywania.
13. Algorytmy chronione patentem w niektórych krajach (klasa Nonfree) –
Dwa algorytmy: SIFT 2 - pozwalajacy
˛ wykryć i opisać lokalne cechy w obrazie
oraz SURF 3 - algorytm detekcji cech inspirowany poprzednim, kilkakrotnie od
niego szybszy i bardziej odporny na pojawiajace
˛ sie˛ w obrazie zakłócenia. Oba
wykorzystywane sa˛ w rozpoznawaniu obiektów oraz modelowaniu trójwymiarowym.
14. Funkcje eksperymentalne (klasa Contrib) – Funkcje nad którymi trwaja˛
aktualnie prace, czekaja˛ na zoptymalizowanie lub dopracowanie.
15. Algorytmy nieaktualne (klasa Legacy) – Funkcje zastapione
˛
nowymi.
Spośród wymienionych wyżej funkcjonalności w procesie wektoryzacji został
użyty jedynie niewielki ich fragment. Podstawowymi elementami wykorzystanymi
w aplikacji sa˛ funkcje klas Imgproc, Highgui oraz Core:
1. wczytywanie plików graficznych (JPG, PNG, BMP itp.): Highgui.imread()
2. probabilistyczna transformata Hougha: Imgproc.HoughLinesP()
3. detektor krawe˛ dzi Canny’ego: Imgproc.Canny()
4. filtr Gaussa: Imgproc.GaussianBlur()
5. detektor wierzchołków Harrisa: Imgproc.goodFeaturesToTrack()
6. funkcje rysowania okre˛ gów i kół: Core.circle()
7. funkcje rysowania linii: Core.line()
8. funkcje rysowania wielokatów:
˛
Core.fillConvexPoly()
9. wstawianie napisów: Core.putText()
10. zapis plików graficznych: Highgui.imwrite()
SVG jest wolnym, uniwersalnym wektorowym formatem zapisu grafiki dwuwymiarowej tworzonym przez organizacje˛ W3C. Pliki zapisane w tym formacie maja˛
rozszerzenie *.svg lub *.svgz (skompresowane formatem gzip). Najszerszym zastosowaniem tego formatu jest grafika wykorzystywana w Internecie m.in. na stronach
WWW. Umożliwia on wykorzystanie w obrazie zarówno prostych kształtów geometrycznych jak koła, elipsy i wielokaty,
˛
ale także skomplikowanych ścieżek, których
składowymi moga˛ być odcinki, krzywe Béziera albo krzywe eliptyczne. Wspiera
2
3
ang. Scale Invariant Feature Transform
ang. Speeded Up Robust Features
16
także wstawianie znaków w kodowaniu Unicode, co ze wzgledu
˛
na konieczność
umieszczenia w obrazie np. symbolu „≥ 1”, było bardzo przydatne. Atrybuty obiektów, jak kolor, grubość linii itp., moga˛ być wyrażone zarówno w postaci poszczególnych argumentów, albo zbiorowo w stylu znanym z kaskadowych arkuszy stylów.
SVG obsługuje dodatkowo wiele przydatnych, ale nie wykorzystanych w aplikacji
funkcji. Pozwal na umieszczanie w kodzie metadanych, pisanie skryptów w je˛ zyku
ECMAScript, definiowanie animacji czy umieszczanie hiperlinków. Dla potrzeb aplikacji wykorzystałem także możliwość wykonywania transformacji - skalowania oraz
obrotów. Podzbiór zbioru, czyli wszystkie te elementy formatu SVG, które zostały
wykorzystane podczas przygotowania pracy przedstawiono na wydruku 5.1 prezentujacym
˛
minimalny, ale w pełni funkcjonalny plik wektorowy:
1. nagłówek definiujacy
˛ parametry obrazu – linie 4–8
2. prostokaty
˛ – linie 10–15
3. wielokaty
˛ – linie 17–21
4. linie – linie 23–29
5. okre˛ gi i koła – linie 31–37
6. napisy – linie 39–44
1
2
3
4
5
6
7
8
<?xml version="1.0" encoding="utf−8" standalone="no"?>
<!DOCTYPE svg PUBLIC "−//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg
xmlns="http://www.w3.org/2000/svg"
version="1.1"
width="1024px"
height="768px">
9
10
11
12
13
14
15
<rect
x="858.0" y="341.0"
width="54.0" height="41.0"
fill="white"
stroke="black"
stroke−width="1"/>
16
17
18
19
20
21
<polygon
points="−4.0,51.0 −4.0,58.0 41.0,58.0 41.0,51.0"
fill="blue"
stroke="black"
22
23
24
25
26
27
28
29
<line
x1="676.0"
y1="138.0"
x2="688.0"
y2="133.0"
stroke="red"
30
31
32
33
34
35
36
37
<circle
cx="283.0"
cy="88.0"
r="3"
fill="yellow"
stroke="black"
38
39
40
41
42
43
44
<text
x="858.0"
y="382.0"
style="font−family: Serif; font−size: 41.0pt;">
≥1
</text>
45
46
</svg>
Wydruk 5.1. Przykładowy plik SVG
17
6. Proces wektoryzacji
Wymagania funkcjonalne aplikacji wektoryzujacej
˛
jasno określaja˛ charakter
i rodzaj wejściowych obrazów rastrowych. Dla założonego problemu wektoryzacji schematów cyfrowych układów logicznych, wymaga sie˛ konkretnego podejścia.
Obrazy rastrowe przedstawiajace
˛ schematy układów charakteryzuja˛ sie˛ niewielkim
stopniem skomplikowania formy graficznej, a zazwyczaj jednolite tło i nieskomplikowane kolorowanie ułatwiaja˛ cały proces przetwarzania. Dla potrzeb pracy inżynierskiej, ograniczony został także zbiór możliwych do wystapienia
˛
elementów. Na
schemacie moga˛ znaleźć sie˛ bramki logiczne wszystkich typów i przerzutniki.
Pierwszym krokiem jest, ze wzgledu
˛
na wrażliwość algorytmu na wypoziomowanie obrazu, sprawdzenie obrócenia schematu i ewentualna jego korekta. W dalszych krokach, w celu uzyskania najlepszych wyników, algorytm bierze pod uwage˛
nie tylko wykryte kształty, mogace
˛ być później zdefiniowane jako prymitywy graficzne, ale również ma na uwadze zgodność położenia punktów charakterystycznych obrazu z faktycznym położeniem wierzchołków figur. W tym celu standardowe podejście polegajace
˛ na ekstrakcji krawedzi
˛
detektorem Canny’ego oraz bazujaca
˛
na nim detekcja prostych i odcinków przy użyciu transformaty Hougha,
wsparte zostało przez wyniki detekcji wierzchołków uzyskane operatorem Harrisa.
Tak otrzymane zbiory danych sa˛ w końcowym etapie analizowane pod wzgl˛edem
logicznej struktury układu cyfrowego. Wykrywane sa˛ m.in. obrysy bramek logicznych, znajomość położenia których, znacznie przyspiesza dalsze przetwarzanie.
Bazujac
˛ na detekcji przecie˛ ć i kolizji potencjalnych wielokatów
˛
z innymi już wykrytymi elementami tworzona jest sieć połacze
˛ ń. Na bazie wykrytych odcinków
i wierzchołków położonych wewnatrz
˛
znalezionych kształtów przebiega dalszy proces wykrywania napisów w schemacie. Końcowym etapem jest proces tworzenia
plików wynikowych: rastrowego podgladu
˛
w formacie PNG oraz formy wektorowej
zapisanej w pliku SVG.
Schemat zależności mie˛ dzy poszczególnymi elementami algorytmu wektoryzacji
przedstawiony jest na rysunku 6.1. Poniższy opis algorytmów dotyczy ich wersji
zaimplementowanej w bibliotece OpenCV.
6.1. Korekta obróconego obrazu wejściowego
19
Rysunek 6.1. Schemat algorytmów składowych aplikacji wektoryzujacej.
˛
W dalszych krokach przedstawione zostana˛ elementy składowe procesu wektoryzacji. Dla uproszczenia, wszystkie operacje dokonywane były na tym samym
schemacie widocznym na rysunku 6.2.
6.1. Korekta obróconego obrazu wejściowego
Transformata Hougha, której wykorzystanie do wykrywania odcinków opisane
jest w punkcie 6.3, przydatna jest także w poczatkowej
˛
fazie analizy obrazu. Dopuszczalne jest, aby obraz wejściowy był obrócony. Opisany dalej algorytm silnie
zależy od prawidłowego ułożenia obrazu, zatem taki obrót powinien być korygowany. Transformata Hougha, w wersji przez mnie zastosowanej, w wyniku działania zwraca liste˛ par wierzchołków bed
˛ acych
˛
końcami odcinków odnalezionych
w obrazie. Wykorzystujac
˛ przekształcenie równania prostej, na której leży odcinek,
do postaci normalnej oraz majac
˛ na uwadze zależności trygonometryczne, możemy
uzyskać liste˛ katów
˛
odchyleń wszystkich odcinków (w układzie współrzednych
˛
biegunowych jest to wartość kata
˛ skierowanego pomiedzy
˛
półprosta˛ osi współrzednych
˛
a odcinkiem be˛ dacym
˛
odległościa˛ prostej od poczatku
˛
układu). Sortujac
˛ katy
˛ i wyznaczajac
˛ średnia˛ z otoczenia o zadanym promieniu wokół mediany listy można
uzyskać wartość kata
˛ obrócenia całego obrazu z dokładnościa˛ do dziesiatych
˛
lub
˛
Canny’ego
20
Rysunek 6.2. Rastrowy plik wejściowy w formacie PNG.
nawet setnych cze˛ ści stopnia. Taka dokładność wystarczy, aby obraz przetwarzany
był dalej bez przeszkód.
˛
Canny’ego
Detektor Canny’ego jest wieloetapowym algorytmem wykrywania krawedzi
˛
w obrazie. Jest to także najcze˛ ściej pierwszy krok w procesie wektoryzacji [17, 19, 20].
Spośród wszystkich detektorów krawedzi,
˛
detektor Canny’ego w [11] uważany jest
za optymalny, gdyż zapewnia:
— dobra˛ detekcje˛ – wykrywa tak dużo krawedzi,
˛
jak to tylko możliwe
— dobre umiejscowienie – wykryta krawedź
˛
leży możliwie blisko krawedzi
˛
rzeczywistej
— minimalna˛ odpowiedź – szum z obrazu wejściowego nie powinien tworzyć kraw˛edzi fałszywych, a znalezione krawedzie
˛
sa˛ oznaczane tylko jeden raz.
Powyższe wymagania sa˛ spełnione, gdyż detektor Canny’ego wykorzystuje rachunek wariacyjny za pomoca˛ którego wyszukiwana jest funkcja optymalizujaca
˛
˛
Canny’ego
21
Rysunek 6.3. Krawe˛ dzie wykryte przy użyciu detektora Canny’ego.
dany funkcjonał. Optymalna funkcja opisana jest przez sume˛ czterech wykładniczych warunków, ale może być przybliżona pierwsza˛ pochodna˛ funkcji Gaussa.
Wynik działania detektora krawedzi
˛
Canny’ego na przykładowym obrazie przedstawiono na rysunku 6.3.
6.2.1. Redukcja szumu
Detektor krawe˛ dzi Canny’ego wykorzystuje filtr bazujacy
˛ na pierwszej pochodnej
funkcji Gaussa, ponieważ jest czuły na obecność szumu w obrazie. Poczatkowym
˛
krokiem, jest zatem dokonanie splotu obrazu z filtrem Gaussa. Efektem tego działania jest rozmazany obraz, który charakteryzuje sie˛ brakiem znacznych zakłóceń.
Macierz rozmycia Gaussa może być dowolna˛ macierza˛ kwadratowa.
˛ We wzorze 6.1
przedstawiono macierz filtra 5 × 5 używanego w bibliotece OpenCV, wykorzystywanego do obróbki obrazu ze współczynnikiem σ = 1.4. Zgodnie z dokumentacja˛ [4],
odchylenie standardowe filtru Gaussa jest pierwszym z sześciu parametrów metody. Im jest ono wie˛ ksze, tym mniej „fałszywych” krawedzi
˛
zostanie rozpoznanych,
jednocześnie wydłużajac
˛ czas samej konwolucji.
22
˛
Canny’ego


2 4 5 4 2


4 9 12 9 4


1 

B=
5 12 15 12 5 ∗ A

59 
4 9 12 9 4


2 4 5 4 2
(6.1)
6.2.2. Wyszukiwanie nate˛ żenia gradientu
W zwiazku
˛
z faktem, że wykryta w obrazie krawedź
˛
może być skierowana w różnych kierunkach, algorytm Canny’ego wykorzystuje cztery filtry do detekcji poziomych, pionowych oraz ukośnych krawedzi
˛
na wstepnie
˛
wygładzonym obrazie. Inne
operatory detekcji krawe˛ dzi (np. Krzyż Robertsa, Prewitt, Sobel) zwracaja˛ wartości
pierwszej pochodnej jedynie dla kierunku poziomego (Gy ) i kierunku pionowego
(Gx )( [21] s. 113). Gradient krawedzi
˛
oraz jej kierunek moga˛ być określone na
podstawie wzorów: odpowiednio
q
G = Gx 2 + Gy 2
(6.2)
Gy
).
Gx
(6.3)
oraz
Θ = arctan (
Kat
˛ wykrytej krawe˛ dzi zaokraglony
˛
jest do 45◦ dajac
˛ cztery podstawowe przypadki reprezentujace
˛ odpowiednio: pion (N −S), poziom (E −W ) oraz dwie przekatne
˛
(SE − N W ) i (SW − N E).
6.2.3. Usuwanie niemaksymalnych pikseli
Usuwanie niemaksymalnych pikseli w wykrytych krawedziach
˛
sprowadza sie˛ do
„pocieniania” krawe˛ dzi w sposób zapewniajacy
˛ ich ciagłość
˛
i zachowanie szerokości jednego piksela. Dla każdego z pikseli rozpatrywane sa˛ dwa piksele sasiednie
˛
wybrane na podstawie najmniejszego, uprzednio obliczonego gradientu. Jeśli właściwy piksel nie ma intensywności wiekszej
˛
niż sasiedzi,
˛
jest zerowany.
6.2.4. Progowanie z histereza˛
Progowanie z histereza˛ wymaga podania dwóch wartości progowych gradientu:
T1 oraz T2 . Jeśli intensywność krawedzi
˛
jest wieksza
˛
niż T2 , krawedź
˛
uznaje sie˛ za
pewna,
˛ zaś jeśli jest mniejsza niż T1 , jest ona usuwana z obrazu. Dla wartości pośrednich, do już wykrytych krawedzi
˛
sa˛ dołaczane
˛
nastepne
˛
piksele mimo spadku
6.3. Wykorzystanie transformaty Hougha przy wykrywaniu odcinków
23
intensywności, aż do osiagni
˛ ecia
˛
dolnego progu wykrywania. Takie postepowanie
˛
zapobiega dzieleniu krawe˛ dzi w miejscach słabszego kontrastu.
Wywołanie detektora Canny’ego z parametrami użytymi w programie przedstawiono na wydruku 6.1.
1
2
3
4
5
6
Imgproc.Canny(
source, // Macierz wejsciowa
result, // Macierz wyniku
50, // Mniejszy parametr histerezy
200 // Wiekszy parametr histerezy
);
Wydruk 6.1. Wywołanie funkcji detektora krawedzi
˛
Canny’ego.
Transformata Hougha jest technika˛ ekstrakcji cech w procesie przetwarzania
i analizy obrazów. Pozwala ona na znalezienie wystapie
˛ ń obiektów zdefiniowanych
w klasach kształtów za pomoca˛ procedury głosowania. Proces ten jest w praktyce
znajdowaniem współrze˛ dnych punktów lokalnych wartości maksymalnych umieszczonych w przestrzeni głosowania. Standardowym zastosowaniem klasyfikacji za
pomoca˛ algorytmu Hougha jest wykrywanie prostych i odcinków, ale rozszerzona
wersja transformaty pozwala na identyfikacje innych kształtów analitycznych, najcz˛eściej okre˛ gów i elips. Bazujac
˛ na wnioskach z doświadczeń wykrywania odcinków zaprezentowanego w [13], zastosowanie transformaty Hougha wydaje sie˛ być
najwłaściwszym sposobem detekcji prostych w obrazie.
Wiedzac,
˛ że każde równanie kierunkowe prostej:
y = ax + b,
(6.4)
opisujace
˛ prosta˛ na płaszczyźnie, można również opisać za pomoca˛ równania ogólnego:
Ax + By + C = 0.
(6.5)
Tym samym wektor [−B, A] jest wtedy wektorem kierunkowym tej prostej. Aby
sprowadzić powyższe równanie do postaci normalnej należy podzielić współczynniki
przez norme˛ wektora kierunkowego. Dla C 6 0 otrzymujemy:
√
a dla C > 0:
B
C
A
x+ √
y+√
=0
2
2
2
2
+B
A +B
A + B2
A2
(6.6)
24
Rysunek 6.4. Parametry równania normalnego prostej.
√
−A
−B
−C
x+ √
y+√
=0
2
2
2
2
A +B
A +B
A2 + B 2
(6.7)
Dla ułatwienia dalszych obliczeń przyjmijmy, że Z bedzie
˛
długościa˛ przeciwprostokatnej
˛
trójkata
˛ wyznaczonego prosta˛ i osiami współrzednych,
˛
jak na rysunku
6.4.
s
Z=
−C 2
−C 2
(
) +(
) =
A
B
r
Zatem:
sin(θ) =
oraz:
cos(θ) =
1
1
C 2( 2 + 2 ) = C
A
B
−C
A
Z
−C
B
Z
=
=
C
AB
C
AB
√
√
−C
A
A2 +
−C
B
A2 +
r
B2
B2
A2 + B 2
C p 2
=
A + B2
A2 B 2
AB
−B
A2 + B 2
(6.9)
−A
.
A2 + B 2
(6.10)
=√
=√
(6.8)
25
Rysunek 6.5. Zbiór punktów tworzacych
˛
prosta˛ (po lewej) oraz ich reprezentacja
w przestrzeni głosowania Hougha (po prawej).
Dodatkowo, porównujac
˛ wzory na pole trójkata
˛ utworzonego przez osie i prosta˛
otrzymujemy:
1
1 −C −C
Zρ =
2
2 B A
1 C p 2
1 C2
A + B2ρ =
2 AB
2 AB
p
2
2
A +B ρ=C
ρ= √
C
+ B2
A2
(6.11)
Podstawiajac
˛ do wzoru 6.6 lub 6.7 wartości uzyskane we wzorach 6.9, 6.10 oraz
6.11 otrzymujemy postać normalna:
˛
x cos (θ) + y sin (θ) − ρ = 0,
(6.12)
gdzie ρ - odległość prostej od punktu (0,0), a θ - kat
˛ miedzy
˛
ρ, a OX (0 6 θ 6 2π).
Odwzorowanie przekształcenia punktów leżacych
˛
na jednej prostej w sinusoidy
w przestrzeni głosowania Hougha przedstawiono na rysunku 6.5, gdzie każdemu
punktowi w przestrzeni kartezjańskiej odpowiada sinusoidalna krzywa w przestrzeni Hougha, a przez punkt przechodzi nieskończenie wiele prostych (pek).
˛
Wynika z tego, że punkty leżace
˛ na tej samej prostej koresponduja˛ z sinusoidami przechodzacymi
˛
przez wspólny punkt w przestrzeni Hougha. Tym samym, znalezienie
prostej w układzie X, Y sprowadza sie˛ do znalezienia punktu w układzie θ, ρ o maksymalnej wartości i dokonania przekształcenia odwrotnego do przekształcenia ze
wzoru 6.12.
26
Rysunek 6.6. Odcinki wykryte przy pomocy transformaty Hougha.
Zaletami takiego rozwiazania
˛
jest to, że każdy punkt obrazu traktowany jest
niezależnie, a tym samym istnieje ewentualna możliwość zrównoleglenia obliczeń.
Metoda ta pozwala także na rozpoznawanie obiektów cześciowo
˛
zniekształconych
lub przy segmentacji obrazów słabej jakości. Do wad można zaliczyć duże zapotrzebowanie na pamie˛ ć dla tymczasowego akumulatora wyniku oraz znaczna˛ złożoność
obliczeniowa.
˛ Wynik działania transformaty Hougha w procesie wykrywania odcinków i linii w obrazie be˛ dacym
˛
wynikiem działania detektora Canny’ego (rysunek
6.3), przedstawiono na rysunku 6.6.
Parametry
1
2
3
4
5
6
7
8
9
wywołania
dajacy
˛
taki
efekt
załaczono
˛
na
wydruku
Imgproc.HoughLinesP(
lines, // Wektor przechowujacy wyniki.
1, // Rozdzielczosc akumulatora wyrazona w pikselach.
Math.PI / 180, // Rozdzielczosc katowa akumulatora.
10, // Minimalny poziom ,,glosow’’ do zachowania odcinka w procesie glosowania.
10, // Minimalna dlugosc docinka. Linie krotsze sa odrzucane.
10 // Maksymalny odstep miedzy punktami tego samego odcinka pozwalajacy je polaczyc.
);
Wydruk 6.2. Wywołanie funkcji transformaty Hougha.
6.2.
27
6.4. Detektor wierzchołków Harrisa
Rysunek 6.7. Idea działania detektora Harrisa.
Transformata Hougha, mimo kompleksowego podejścia do problemu wykrywania odcinków, cze˛ stokroć daje w odpowiedzi odcinki utworzone z pozornie powia˛
zanych ze soba˛ punktów lub rozdziela linie, które powinny być połaczone.
˛
W celu
polepszenia wyników całego procesu wektoryzacji, wyniki detekcji odcinków konfrontowane sa˛ z punktami wykrytymi detektorem Harrisa.
Obraz w poszukiwaniu wierzchołka obserwowany jest przez przesuwajac
˛ a˛ sie˛
nad nim okno, badajac
˛ zmiane˛ pochodnej intensywności w stosunku do kierunku
przesuwania, jak na rysunku 6.7. Dla wierzchołka, przesuwanie okna w którakol˛
wiek strone˛ powinno dać duża˛ odpowiedź.
Aby ustalić współrze˛ dne wierzchołka używa sie˛ uśrednionej w oknie zmiany
intensywności dla zadanego przesuniecia
˛
[u, v] wyrażonej wzorem:
E(u, v) =
X
w(x, y)[I(x + u, y + v) − I(x, y)]2 ,
(6.13)
x,y
gdzie funkcja˛ okna w(x, y) jest funkcja Gaussa:
w(x, y) = G(x, y, σ) =
1 (− x2 +y2 2 )
e 2σ .
2πσ 2
(6.14)
Wykorzystujac
˛ obliczona˛ zmiane˛ intensywności w oknie oraz wiedzac,
˛ że dla
małych przesunie˛ ć możemy przyjać
˛ przybliżenie E(u, v) wyrażone wzorem 6.15
jesteśmy w stanie otrzymać macierz M .
" #
h
i
u
E(u, v) ∼
= u v M
v
(6.15)
28
Rysunek 6.8. Elipsa kowariancji.
M jest macierza˛ 2x2 wyliczona˛ na podstawie pochodnych obrazu zgodnie ze
wzorem:
"
M=
X
w(x, y)
x,y
Ix 2
Ix Iy
Ix Iy
Iy 2
#
.
(6.16)
Obliczajac
˛ wartości własne macierzy M otrzymujemy elipse˛ kowariancji zmian
intensywności, jak na rysunku 6.8. Długości półosi elipsy oznaczane jako λ1 oraz
λ2 pozwalaja˛ określić, która cześć
˛ obrazu obserwowana była przez okno.
Na rysunku 6.9 przedstawiono wykres decyzyjny zależny od λ1 oraz λ2 . Zgodnie
z nim detektor Harrisa pozwala stwierdzić istnienie:
— płaskiego regionu, gdy λ1 oraz λ2 sa˛ małe, a E prawie stałe w każdym kierunku
— krawe˛ dzi, gdy λ1 λ2 albo λ2 λ1
— wierzchołka, gdy λ1 oraz λ2 sa˛ duże i porównywalne, a E zmienia sie˛ w każdym
kierunku.
Wynik działania wywołania detektora wierzchołków Harrisa przedstawionego na
wydruku 6.3 na przykładowym obrazie pokazano na rysunku 6.10, a kombinacje˛
wykrytych odcinków i wierzchołków na rysunku 6.11.
Rysunek 6.9. Wykres decyzyjny detektora Harrisa.
29
6.5. Przetwarzanie zebranych danych
30
Rysunek 6.10. Efekt działania detektora wierzchołków Harrisa.
1
2
3
4
5
6
7
8
9
10
11
Imgproc.goodFeaturesToTrack(
detectedCorners, // Wektor przechowujacy wyniki
999, // Maksymalna liczba wierzcholkow
0.01, // Miara jakosci najgorszego wierzcholka wyrazona ulamkiem wartosci najlepszego.
1, // Minimalna odleglosc miedzy wierzcholkami
source, // ROI (ang. Region of interest)
3, // Rozmiar bloku okreslajacego sasiedztwo.
true, // Gdy ,,true’’ uzywany jest detektor Harrisa, dla ,,false’’ funkcja cornerMinEigenVal().
0.01 // Wolny parametr detektora Harrisa
);
Wydruk 6.3. Wywołanie funkcji detektora wierzchołków Harrisa.
Wyżej wymienione elementy przetwarzania obrazu pozwalaja˛ na zebranie danych o logicznej strukturze obrazu. Definiuja˛ one położenie linii i odcinków wykrytych transformata˛ Hougha (przechowywanych w programie w liście lines jak
również „mocnych” wierzchołków jako efekt działania detektora Harrisa (przechowywanych w freeCorners). Takie dane same nie zapewniaja˛ możliwości utworzenia obrazu wynikowego i musza˛ zostać poddane dalszej analizie. Ze wzgledu
˛
na
31
Rysunek 6.11. Kombinacja detektora Harrisa i wyników działania transformaty
Hougha.
32
sprecyzowane zastosowanie aplikacji, do poprawnego odwzorowania obrazu rastrowego oprócz zebranych informacji o wykrytych obiektach, wykorzystałem właściwości wektoryzowanych schematów układów cyfrowych. Bazujac
˛ na informacjach
dotyczacych
˛
rozmiarów i kształtów elementów układów cyfrowych, które zawarte
sa˛ w dokumentacji standaryzujacej
˛
[8], można cały proces znacznie przyspieszyć,
poprawić efekty i zmniejszyć wynikowy rozmiar pliku grafiki wektorowej.
Ważnym elementem w dalszym procesie sa˛ także informacje zgromadzone podczas wczytywania obrazu np.
jego rozmiar.
Dane o poszczególnych pikselach
umieszczane sa˛ w klasie biblioteki OpenCV - Mat bed
˛ acej
˛
dwuwymiarowa˛ reprezentacja˛ tablicy, na której można wykonywać operacje macierzowe. Rozmiar otrzymany z takiej struktury jest pomocny podczas definiowania nagłówka pliku wektorowego jak również w procesie skalowania np. do utrzymania stałego współczynnika proporcjonalności boków.
6.5.1. Odnajdywanie wierzchołków prostokatów
˛
Pierwszym krokiem, bazujac
˛ na proporcjach boków prostokatów
˛
okalajacych
˛
obramowanie symbolu bramki logicznej, jest znalezienie wśród wykrytych wierzchołków (freeCorners) takich, które te proporcje spełniajac
˛ tworzyłyby prostokat.
˛ Przeprowadzone w poczatkowej
˛
fazie testy wykazały, że niezależnie od jakości
i rozmiaru obrazu, wierzchołki prostokatów
˛
znajdowane sa˛ zawsze, co wynika ze
specyfiki detektora Harrisa. Wierzchołki położone na styku dwóch prostopadłych
do siebie odcinków daja˛ bardzo dobra˛ odpowiedź podczas przesuwu okna nad nimi,
a tym samym w późniejszym etapie detekcji, ich „wskaźnik jakości” jest wysoki.
Takie podejście mimo zakładanej dużej złożoności obliczeniowej, dzieki
˛ optymalizacji przerwań przeszukiwań nie zwieksza
˛
w dużym stopniu czasu wektoryzacji,
a odnalezione w pierwszym kroku wierzchołki, które tworza˛ prostokaty,
˛
znacznie
zaw˛eżaja˛ dalsze zbiory przeszukiwań i wykorzystywane sa˛ jako struktury pomocnicze w każdym kolejnym kroku. Zbiór odnalezionych wierzchołków przechowywany
jest w liście rectCorners, w której wierzchołki bramek logicznych lub przerzutników zgrupowane sa˛ po cztery oraz posortowane rosnaco
˛ po współrzednej
˛
x a nast˛epnie współrze˛ dnej y. Zbiór takich wierzchołków usuwany jest sukcesywnie ze
zbioru wierzchołków wolnych freeCorners.
6.5.2. Odnajdywanie obramowania prostokatów
˛
Bazujac
˛ na punktach be˛ dacych
˛
czterema wierzchołkami wewnetrznego
˛
prostokata
˛ na podstawie dokumentacji IEEE obliczany jest właściwy kształt. Wymiary,
33
grubość krawe˛ dzi i inne parametry wygladu
˛
obramowania bramki logicznej zdefiniowane sa˛ w dokumencie standaryzacyjnym jako wartości zależne od grubości pojedynczej linii sygnałowej. Dla każdego wykrytego obramowania tworzona jest także
instancja obiektu typu Rectangle. Wykorzystywane sa˛ one później do kreślenia
obrazu wektorowego i rastrowego podgladu.
˛
W tej klasie umieszczone sa˛ także metody, które na podstawie odczytanych wymiarów dobieraja˛ odpowiednia˛ szerokość
kreślenia krawe˛ dzi. Każde pojedyncze odnalezienie obramowania umieszczane jest
w liście rectangles.
6.5.3. Odnajdywanie punktów wewnetrznych
˛
Kolejnym krokiem jest znalezienie punktów wewnatrz
˛
prostokatów.
˛
Ten zbiór
nie dość, że ograniczy dalsze poszukiwanie to bedzie
˛
wykorzystany w procesie detekcji symboli. Istotne ze wzgledu
˛
na dalsza˛ konieczność utworzenia otoczki okalajacej
˛
te punkty jest zawarcie nie tylko wierzchołków Harrisa, ale także punktów be˛ dacych
˛
końcami wykrytych odcinków i leżacych
˛
w całości wewnatrz
˛
prostokata.
˛
Punkty, o ile zostana˛ uznane, że leża˛ wewnatrz
˛
prostokata
˛ trafiaja˛ do listy
textCorners oraz usuwane sa˛ z listy wierzchołków wolnych. Dalsza ich analiza
przedstawiona jest w punkcie 6.5.5.
6.5.4. Wykrywanie punktów i wielokatów
˛
połacze
˛
ń
Bazujac
˛ na położeniu pozostałych wolnych wierzchołków wzgledem
˛
ograniczenia
konturu bramki logicznej nastepuje
˛
podział na wierzchołki tworzace
˛ doprowadzenia
sygnału do wejścia bramek (z lewej strony) oraz wyprowadzenia (z prawej). Wyjście
sygnałowe może tworzyć bardziej skomplikowany kształty - ukośnie odchodzace
˛
podłaczenie,
˛
co symbolizuje negacje˛ wyjścia np. w bramce typu NOT, NAND, NOR,
XNOR lub w przypadku przerzutnika typu D. W zależności, czy na przedłużeniu
linii wchodzacej
˛
lub wychodzacej
˛
z bramki znajduja˛ sie˛ inne znalezione punkty lub
inne elementy, jak np. krawe˛ dzie symbolu bramki, linia sygnałowa jest dołaczana
˛
do napotkanego elementu lub też nie. Jeśli nie nastapiła
˛
detekcja przedłużenia z innym elementem, wyjście lub wejście zdefiniowane sa˛ określona˛ odległościa.
˛ Wierzchołki wykryte i zidentyfikowane jako należace
˛ do wejść i wyjść bramek trafiaja˛
odpowiednio do list inputCorners oraz outputCorners. Sa˛ one także usuwane z
listy freeCorners. Jednocześnie tworzone sa˛ cześci
˛
układów tworzace
˛ połaczenia.
˛
Odpowiednio w liście inputPolygons dla wejść oraz outputPolygons dla wyjść
sygnałowych.
34
6.5.5. Odnajdywanie symboli
Ze wzgle˛ du na skomplikowany kształt elementów (fontów wykorzystanych do
wykreślenia symboli bramki) umieszczonych wewnatrz
˛
prostokatów,
˛
a w szczególności dla znaku „&” oraz symboli przerzutnika, w miejscu ich umieszczenia wyste˛
puje duże nagromadzenie wykrytych odcinków i wierzchołków. Bazujac
˛ zarówno
na wykrytych odcinkach położonych całkowicie wewnatrz
˛
zarysu bramki jak i na
punktach, wewnatrz
˛
każdej z nich znajdowana jest prostokatna,
˛
równolegle położona wobec krawe˛ dzi, otoczka wyznaczona przez minimalne i maksymalne współrz˛edne punktów lub końce odcinków. Jest to podstawa˛ do analizy symbolu. Jako
że zbiór oznaczeń wewnatrz
˛
bramek logicznych jest niewielki (jedynie znaki: „1”,
„= 1”, „≥ 1” oraz „&”) nie ma konieczności stosowania zaawansowanych algorytmów
rozpoznawania tekstu, lecz jedynie bazujac
˛ na stosunku szerokości do wysokości
otoczki, definiować jaki symbol jest w środku. Współczynniki rozmiarów różnia˛ sie˛
nieznacznie wzgle˛ dem siebie - 7 : 4 dla symbolu „= 1”, 5 : 4 dla „≥ 1”, 4 : 4 dla „&”
oraz 2 : 4 dla symbolu „1”. Dla symboli przerzutnika typu D proporcje wykrytych
symboli (1.8 : 4) sa˛ zbliżone do bramki NOT (2 : 4). Tym samym w procesie rozpoznawania brany jest pod uwage˛ także stosunek rozmiaru (wysokości) pola wykrytych
elementów fontów do rozmiaru całej bramki. Wyniki detekcji symboli tworza˛ liste˛
wynikowa˛ textes elementów typu Text, która wykorzystywana jest do tworzenia
plików końcowych. Dla celów porównawczych zapisywane sa˛ także otoczki wykrytych symboli w liście textBoundaries. Wyniki odnajdowania symboli bramek
widoczne sa˛ na rysunku 6.12.
6.5.6. Łaczenie
˛
pozostałych wierzchołków wolnych
W końcowym etapie łaczone
˛
sa˛ pozostałe „wolne” wierzchołki. Taka sytuacja ma
najcze˛ ściej miejsce, gdy przebieg linii sygnałowej na schemacie jest skomplikowany
i w całości nie jest rozpoznana w poprzednich krokach algorytmu. Także dla rozgał˛ezień połacze
˛ ń lub ich przeciecia
˛
ten krok zapewnia poprawna˛ detekcje.
˛ Wierzchołki w takim wypadku zazwyczaj leża˛ na przeciwnych rogach poszukiwanego
segmentu wyznaczajacego
˛
połaczenie.
˛
Tym samym nie wystarczy połaczyć
˛
je, gdyż
prowadziłoby to do powstawania przekłamań i niezgodności z obrazem wejściowym.
Rozwiazaniem
˛
tego problemu jest badanie w otoczeniu potencjalnego połaczenia
˛
obecności wykrytych wcześniej odcinków. Jeśli ich obecność, położenie i ulokowanie wierzchołków odpowiada prawdowpodobnemu położeniu wielokata
˛ wyznaczononego na podstawie tylko wierzchołków nastepuje
˛
połaczenie.
˛
Także dla przecieć
˛
konieczna była detekcja dużego nagromadzenia wierzchołków w małym otoczeniu,
Rysunek 6.12. Wykryte elementy tworzace
˛ napisy na obrazie.
35
36
6.6. Rysowanie
a dla rozgałe˛ zień wykrycie nawet wiekszej
˛
ich liczby. Analiza wzglednego
˛
położenia i rozmieszczenia wierzchołków na schemacie zapewnia rozpoznanie symbolu
kropki oraz poprawne połaczenie
˛
wszystkich krawedzi.
˛
W tym etapie analizowane
były wierzchołki freeCorners i w procesie analizy usuwane, a nie przenoszone
do innych list. Pozwalały one jednak na ustalenie położeń punktów rozgałezienia
˛
połacze
˛ ń i zapisu ich w liście connectionCorners.
6.6. Rysowanie
W momencie, kiedy wszystkie elementy zostały już rozpoznane i umieszczone
w odpowiednich klasach końcowym etapem jest proces rysowania. Ze wzgledu
˛
na
problem z niewspieraniem wyświetlania grafiki wektorowej bezpośrednio w systemie Android wyste˛ puje konieczność generowania dwóch plików: SVG oraz PNG
służacego
˛
za podglad
˛ w aplikacji. O ile plik SVG tworzony jest zgodnie z przykładem przedstawionym na wydruku 5.1, to rysowanie elementów pliku PNG przebiega
inaczej.
Poszczególne elementy rysowane sa˛ lub sa˛ pomijane w zależności od
ustawienia flagi determinujacej
˛
wersje˛ obrazu.
wane sa˛ elementy przechowywane w listach:
Dla wersji końcowej rysorectangles, inputPolygons,
outputPolygons, textes oraz koła z listy connectionCorners bed
˛ ace
˛
miejscami rozgałe˛ zień linii sygnału.
niane sa˛ listy:
Dla wersji testowej dodatkowo uwzgled˛
freeCorners, rectCorners, textCorners, inputCorners,
outputCorners, lines oraz textBoundaries. W zależności od wartości flagi,
zmieniane sa˛ także kolory rysowania. Dla wersji testowej sa˛ one ustalone odgórnie,
a w wersji końcowej definiowane każdorazowo przez użytkownika aplikacji. Wszystkie cze˛ ści składowe obrazu rysowane sa˛ przy użyciu funkcji bibliotecznych OpenCV.
Tym samym obramowania bramek kreśli funkcja Core.rectangle(), połacze˛
nia elementów Core.fillConvexPoly(), linie Core.line(), wykryte wierzchołki
Core.circle(), zaś funkcja˛ odpowiedzialna˛ za wstawianie tekstowych oznaczeń
poszczególnych typów bramek jest Core.putText(). Ostatnim etapem jest wykorzystanie funkcji Highgui.imwrite() do zapisania obrazu PNG.
Po zapisaniu, wszystkie pomocnicze elementy uzyskane w procesie wykrywania,
analizy i wektoryzcji wygladaj
˛ a˛ podobnie jak te widoczne na rysunku 6.13, a wersja
finalna przedstawiona została na rysunku 6.14.
37
6.6. Rysowanie
=1
=1
≥1
≥1
&
1
&
Rysunek 6.13. Pośredni etap wektoryzacji obrazu.
38
6.6. Rysowanie
=1
=1
≥1
≥1
&
1
&
Rysunek 6.14. Wynikowy plik grafiki wektorowej.
7. Interfejs użytkownika
Interfejs użytkownika stworzony został z elementów dostepnych
˛
w środowisku
systemu operacyjnego Android. Zgodnie z ogólnym trendem i zaleceniami twórców
systemu, zarówno wyglad
˛ aplikacji, jak i poszczególne napisy, które sa˛ w niej osadzone definiowane sa˛ w oddzielnych plikach formatu XML. Ułatwia to kształtowanie wygladu
˛
aplikacji, a rozdzielenie warstwy tekstu od wygladu
˛
czyni ewentualna˛
internacjonalizacje˛ łatwiejsza.
˛
Po uruchomieniu programu pojawia sie˛ jego główne okno (rysunek 7.1(a)).
W dolnej cze˛ ści ulokowane sa˛ trzy przyciski i pole tekstowe pozwalajace
˛ wprowadzić ścieżke˛ do pliku. Plik identyfikowany jest za pomoca˛ ścieżki bezwzglednej.
˛
Takie rozwiazanie
˛
pozwala na dostep
˛ do wszystkich plików widocznych w systemie
Android. W momencie startu aktywny sa˛ tylko przyciski OK oraz Foto.
Po naciśnie˛ ciu przycisku Foto, wykonaniu i zaakceptowaniu fotografii (rysunek
7.1(b)) lub po wprowadzeniu ścieżki do pliku i wciśnieciu
˛
przycisku OK pojawi
si˛e niewielkie okno dialogowe sygnalizujace
˛
konieczność wykonania akcji przez
użytkownika (rysunek 7.1(c)). Zmiana rozmiaru polega na wprowadzeniu w pola
tekstowe zakładanej wysokości lub szerokości wyrażonej w pikselach i wciśnieciu
˛
przycisku Skaluj. Jeśli nie podano któregokolwiek z nich lub jednego, wymiar
nie wprowadzony pobierany jest z właściwości obrazu wejściowego.
Wynikowy
rozmiar wyświetlany jest w prawym górnym rogu okna dialogowego. Użytkownik
ma także możliwość podania kata
˛ o jaki należy obrócić obraz końcowy (wyrażonego
nieujemna˛ liczba˛ całkowita),
˛ a także wyboru koloru na palecie1 (rysunek 7.1(d))
dla każdego z trzech elementów oddzielnie, po uprzednim wybraniu, czy zmiana
odbywa sie˛ dla fontów, linii czy tła schematu.
Po wciśnie˛ ciu przycisku OK nastepuje
˛
proces wektoryzacji. Użytkownik informowany jest o trwajacym
˛
w tle przetwarzaniu obrazu za pomoca˛ animowanej informacji wyświetlonej nad wygaszonym oknem aplikacji (rysunek 7.2(a)).
1
Wykorzystano w tym celu bibliotek˛e „AmbilWarna” dost˛epna˛ online: code.google.com/p/
android-color-picker/
40
W przypadku powodzenia i zakończenia wektoryzacji wyświetlany jest stosowny
komunikat oraz odblokowywany przycisk prezentacji wyniku (rysunek 7.2(b)). Gdy
podany plik nie zostanie odnaleziony widoczny bedzie
˛
stan jak na rysunku 7.2(c).
Na rysunku 7.2(d) przedstawiono okno podgladu
˛
wyniku. Mimo, że wynikowy
plik wektorowy SVG generowany jest podczas działania aplikacji, to ze wzgledu
˛
na
ograniczenia wynikajace
˛ z systemu operacyjnego nie ma możliwości bezpośredniego
wyświetlania go. Podglad
˛ widoczny w dolnej cześci
˛
rysunku jest obrazem wektorowym narysowanym na podstawie danych zebranych w procesie wektoryzacji.
W górnej cze˛ ści podgladu
˛
widnieje podglad
˛ pliku oryginalnego.
41
(a) Główny widok
(b) Podglad
˛ zdj˛ecia wykonanego wbudowanym aparatem
(c) Okno edycji parametrów
(d) Paleta wyboru koloru
Rysunek 7.1. Wyglad
˛ okna aplikacji w systemie Android
42
(a) Sygnalizacja trwajacej
˛
wektoryzacji
(b) Poprawne zakończenie
(c) Niepoprawna ścieżka pliku
(d) Podglad
˛ wyników
Rysunek 7.2. Wyglad
˛ okna aplikacji w systemie Android cd.
8. Testowanie
8.1. Sprawdzanie działania aplikacji
Proces testowania aplikacji, ze wzgledu
˛
na brak wsparcia wyświetlania grafiki
wektorowej w formacie SVG w systemie Android, wymusił modyfikacje˛ podejścia do
problemu. Korzystajac
˛ z możliwości oferowanych przez biblioteke˛ OpenCV podglad
˛
efektów wektoryzacji wyświetlany jest w sasiedztwie
˛
obrazu wejściowego. Nie jest to
jednak forma wektorowa obrazu lecz plik grafiki rastrowej wiernie ja˛ odwzorowujacy.
˛
Podczas procesu wektoryzacji aplikacja tworzy zbiory elementów wykrytych
na obrazie (odcinki, napisy, punkty itp.), które przechowywane sa˛ w odpowiednich
klasach. W momencie zakończenia procesu tworzone sa˛ pliki wyjściowe, zarówno
w postaci pliku PNG jak i SVG. O ile plik wektorowy może zostać podejrzany na
innych urzadzeniach
˛
np. komputerze, to plik PNG wykorzystywany jest głównie do
generowania podgladu.
˛
Jedyna˛ różnica˛ miedzy
˛
plikiem SVG a podgladem
˛
wyników
jest kształt fontów. Specyfika SVG wymusza inny kształt poszczególnych znaków,
jednakże co do treści poszczególnych napisów istnieje zgodność miedzy
˛
postacia˛
wektorowa˛ i rastrowa.
˛ Wynikowy obraz podgladu
˛
jest skalowany i obracany identycznie jak obraz wektorowy.
Testowanie aplikacji musiało uwzgledniać
˛
możliwość wystapienia
˛
problemów
na różnych płaszczyznach, zarówno na poziomie błedów
˛
interfejsu użytkownika,
funkcjonalności jak i niedoskonałości algorytmów. Testy uwzgledniały:
˛
1. Sprawdzenie poprawności rozpoznawania pojedynczych symboli (bramek, przerzutnika, połacze
˛ ń, przecieć)
˛ jak i całych układów, również dla obrazów obróconych np. podczas skanowania.
2. Kontrola obrazu wyjściowego w przypadku zmiany przez użytkownika kata
˛ obrotu obrazu wyjściowego.
3. Sprawdzanie poprawności generowanych plików dla różnych współczynników
skalowania, tj. czy elementy dla dużych i małych współczynników skalowania
zachowuja˛ wzgle˛ dne odległości od siebie i czy nie zachodza˛ inne anomalie.
Badano także, czy wyliczanie wymiarów odbywa sie˛ poprawnie.
8.2. Strojenie parametrów aplikacji
44
4. Testowanie zgodności wybranych kolorów dla każdej z trzech grup elementów.
5. Badanie zgodności generowanego podgladu
˛
(PNG) z otrzymanymi plikami wektorowymi (SVG).
6. Sprawdzanie wpływu poszczególnych modyfikacji na siebie w przypadku jednoczesnego użycia (np. czy skalowanie i obrót nie spowoduje ucinania cześci
˛
obrazu).
7. Sprawdzanie zachowania aplikacji na pliki wejściowe o różnych rozszerzeniach.
Testowane były zarówno poprawne rozszerzenia plików graficznych: *.bmp,
*.dib, *.png, *.jpeg, *.jpg, *.jpe, *.jp2, *.tiff, *.tif, *.pbm, *.pgm, *.ppm, *.sr,
*.ras, jak i odpowiedź mechanizmu kontroli dla kilku plików niepoprawnych
m.in: *.txt, *doc, *.pdf.
8. Obiektywne porównywanie wyników uzyskiwanych w procesie wektoryzacji
z wersja˛ oryginalna˛ oraz analizowanie pliku pośredniego (rysunek 6.13) w celu
sprawdzenia, czy sam proces odbywał sie˛ poprawnie. Wektoryzacje˛ przeprowadzano dla obrazów przedstawiajacych
˛
układy cyfrowe różnego typu.
9. Sprawdzanie zachowania aplikacji na różne niepoprawne ścieżki dostepu
˛
do
plików.
10. Sprawdzanie działania aplikacji dla niepoprawnych co do zawartości plików
graficznych np. zdje˛ ć czy pustych plików graficznych. Ze wzgledu
˛
na charakter
aplikacji, takie obrazy nie bed
˛ a˛ wektoryzowane.
11. Badanie stabilności aplikacji, także na nietypowe zachowania użytkownika
oraz te wynikajace
˛ ze sposobu obsługi aplikacji w systemie operacyjnym Android. Badane było, zachowanie w przypadku próby przerwania procesu wektoryzacji przyciskiem „wstecz” lub „ekran główyny”, próby wciśniecia
˛
wie˛ kszej
liczby przycisków itp.
Wyniki testowania obrazów przykładowych przedstawiono na rysunkach 8.1
oraz 8.2.
Na potrzeby zaliczenia projektu z przedmiotu Techniki kompilacji przygotowałem parser własnego je˛ zyka skryptowego, którego główna˛ funkcjonalnościa˛ miało
być wsparcie doboru odpowiednich parametrów różnych funkcji biblioteki OpenCV
w toku pracy nad tworzeniem aplikacji wektoryzujacej.
˛
Dzieki
˛ niemu mogłem ustalić wspływ poszczególnych parametrów na uzyskiwane wyniki. Dla funkcji wykrywajacej
˛
odcinki (transformaty Hougha), były to m.in. wartości progowe użytego
detektora Canny’ego, minimalne długości poszczególnych odcinków i maksymalny
45
(a) Obraz testowy 1
(b) Obraz wynikowy 1 (szerokość 2:1,
wysokość 1:1, kat
˛ 15◦ , kolor fontów:
czerwony, kolor elementów: żółty, kolor
tła: granatowy)
(c) Obraz testowy 2
(d) Obraz wynikowy 2 (szerokość 1:1,
biały, kolor elementów: biały, kolor tła:
bł˛ekitny)
Rysunek 8.1. Wyniki testów
46
(a) Obraz testowy 3
(b) Obraz wynikowy 3 (szerokość 1:1,
wysokość 1.3:1, kat
czarny, kolor elementów: czarny, kolor
tła: biały)
(c) Obraz testowy 4 (obraz obrócony)
(d) Obraz wynikowy 4 (szerokość 1:1,
czarny, kolor elementów: różowy, kolor
tła: zielony)
Rysunek 8.2. Wyniki testów cd.
47
rozmiar przerw mie˛ dzy nimi. Dla funkcji detektora Harrisa skrypt pozwalał na
modyfikacje˛ liczby zwracanych wierzchołków, ich minimalnej „jakości”, odległości
pomi˛edzy poszczególnymi wystapieniami
˛
oraz definiowanie rozmiaru okna sasiedz˛
twa. Możliwość jaka˛ dawał parser, tj. każdorazowego zapisu wyniku do innego
pliku, pozwalała na obiektywne porównywanie zastosowanych parametrów i znacznie skróciła całkowity czas dopasowywanie ich do otrzymania najlepszych wyników.
W celu stworzenia zarówno leksera jak i parsera wykorzystałem możliwości programu ANTLR v3., który na podstawie zadanej gramatyki generuje parser typu
LL(*). W zwiazku
˛
z koniecznościa˛ wielokrotnego testowania różnych funkcji aplikacji przetwarzania obrazów bitmapowych z różnymi parametrami, interpreter zapewnia taka˛ możliwość, bez konieczności każdorazowej kompilacji. Wielokrotne wywołania moga˛ zostać zastapione
˛
przez petle
˛
do...while, a parametry funkcji moga˛
być zależne od zmiennych. Skrypt powinien zostać przygotowany zgodnie z opisem i uwzgle˛ dnieniem przeznaczenia zmiennych i wywołań podanymi w dodatku
A w wydruku A.1, a dokładna gramatyka w notacji EBNF została przedstawiona
w wydruku A.2.
Parser zapewnia naste˛ pujace
˛ funkcjonalności:
— parsowanie skryptów zapisanych w plikach tekstowych
— umożliwienie wielokrotnego wykonywania wywołań zamknietych
˛
w petli
˛
do...while i zależnych od iteratora
— przestrzeganie logicznego porzadku
˛
wczytanie-funkcje-zapis
— możliwość wywoływania funkcji wielokrotnie i w dowolnej kolejności
— kontrole˛ poprawności wprowadzonych danych, np. zgodności wartości argumentów funkcji (typu całkowitego i podwójnej precyzji) z definicja˛
— informowanie użytkownika, w którym miejscu skryptu wystapił
˛ bład
˛
— sprawdzanie, czy zmienna użyta w funkcji, została wcześniej zainicjowana
— dynamiczne typowanie i ewentualne rzutowanie
— pomijanie białych znaków w tekście
Przykładowy kod źródłowy skryptu wczytujacy
˛
obraz rastrowy, dokonujacy
˛
transformaty Hougha dla odcinków i wywołujacy
˛ funkcje˛ detektora wierzchołków
Harrisa oraz zapisujacy
˛ wyniki do pliku wektorowego przedstawiono w wydruku
8.1.
1
2
3
4
load("/mnt/sdcard/camera/DCIM1209.jpeg")
houghL(1, 0.02, 10, 5, 20, 75, 100)
harris(99, 0.01, 58, 3, true, 0.04)
save("/mnt/sdcard/test/test.svg")
Wydruk 8.1. Skrypt: Wykrywanie odcinków i wierzchołków.
9. Dokumentacja projektu
Aplikacja wektoryzujaca
˛ podzielona została na pieć
˛ pakietów, z których każdy
agreguje klasy o innym przeznaczeniu. Podział klas i pakietów wraz z krótkim opisem zamieszczono poniżej. Diagram przypadków użycia przedstawiono na rysunku
9.1, a diagram klas, obrazujacy
˛ zależności miedzy
˛
klasami, na rysunku 9.2. Dokładniejsze wyjaśnienia działania oraz przeznaczenia danych zmiennych i funkcji
można znaleźć w kodzie programu.
1. pl.edu.pw.elka.pjastrz2.android.application
— Consts – Stałe programu. Opcje dla kompilacji Release i Debug.
— MainApplication – Klasa główna aplikacji. Przechowuje kontekst globalny.
2. pl.edu.pw.elka.pjastrz2.android.activity
— ImageActivity – Activity prezentacji wyników.
— StartActivity – Główne Activity aplikacji. Obsługuje zdarzenia naciśniecia
˛
przycisków i wprowadzania ścieżki pliku.
3. pl.edu.pw.elka.pjastrz2.android.operations
— CornerDetection – Klasa implementujaca
˛ wykrywanie rogów metoda˛ Harrisa.
— EdgeDetection – Klasa implementujaca
˛
wykrywanie krawedzi
˛
metoda˛
Canny’ego.
— RotateImage – Klasa zapewniajaca
˛ obrót obrazu tak, aby był wypoziomowany.
— HoughLine – Klasa implementujaca
˛ wykrywanie odcinków transformata˛ Hougha.
4. pl.edu.pw.elka.pjastrz2.android.data
— DataContainer – Kontener przechowujacy
˛ wszystkie elementy, które moga˛
być rysowane na obrazie.
— Polygon – Klasa definiujaca
˛ wielokaty
˛ wykryte w obrazie.
— Line – Klasa definiujaca
˛ odcinki wykryte w obrazie.
— Rectangle – Klasa definiujaca
˛ prostokaty
˛ wykryte w obrazie.
— Text – Klasa definiujaca
˛ napisy wykryte w obrazie.
— Corner – Klasa definiujaca
˛ wierzchołki wykryte w obrazie.
49
Rysunek 9.1. Diagram przypadków użycia
5. pl.edu.pw.elka.pjastrz2.android.utilities
— PointComparator – Comparator sortowania listy tablic double po rosnacym
˛
X a potem Y.
— ProcessImage – Główna klasa przetwarzajaca
˛ obraz.
— SaveToSvgFile – Klasa implementujaca
˛ metody zapisu do pliku SVG.
— SaveToPngFile – Klasa implementujaca
˛ metody zapisu do pliku PNG.
Rysunek 9.2. Diagram klas aplikacji wektoryzujacej
˛
50
10. Podsumowanie
10.1. Spełnienie założeń
Podstawowym założeniem pracy inżynierskiej było przygotowanie projektu aplikacji pozwalajacej
˛
na wektoryzowanie pewnego ściśle określonego typu obrazów rastrowych. Wybór rodzaju tych obrazów nie był wcale oczywisty. Czytajac
˛ artykuły
naukowe na IEEE Xplore [6] dotyczace
˛ różnego typu wektoryzacji zastanawiałem
si˛e, czy problem mnie nie przerósł i czy mu podołam. Tym bardziej, że niektóre
z nich dotyczyły wektoryzacji materiału bardzo trudnego w przetwarzaniu - obrazów fotorealistycznych.
Ze wzgle˛ du na che˛ ć pogłe˛ bienia znajomości coraz popularniejszej ostatnio biblioteki przetwarzania obrazu w czasie rzeczywistym - OpenCV, chciałem, żeby w moim
projekcie w jak najszerszym możliwym spektrum wykorzystać i poznać algorytmy
w niej zaimplementowane, aby jej użycie było podyktowane nie tylko łatwościa˛ rozwiazywania
˛
podproblemów, ale żebym w trakcie pracy rozumiał co i jak dokładnie
dzieje sie˛ przy wywołaniu każdej funkcji. Tym bardziej przemawiał do mnie fakt,
że kierunek rozwoju biblioteki zbiegał sie˛ z moim drugim zainteresowaniem - programowaniem aplikacji na platformy mobilne. Rozwój biblioteki jest ciagły
˛
i obejmuje coraz szersze spektrum systemów operacyjnych: pierwsza oficjalna wersja
przygotowana została dla systemów Windows, Linux oraz Mac OS 19 października
2006 roku, wersja przeznaczona dla systemu operacyjnego Android pojawiła sie˛ 12
września 2011 roku a dla iOS - już 4 sierpnia 2012 roku.
To właśnie ze wzgle˛ du na zainteresowanie technologiami mobilnymi a najbardziej programowaniem w środowisku systemu Android postanowiłem połaczyć
˛
te
dwie technologie - wykorzystać biblioteke˛ OpenCV do przygotowania aplikacji wektoryzujacej
˛
działajacej
˛
pod kontrola˛ systemu Android. Przeszukanie repozytorium
aplikacji dla systemu Android - Google Play [5] - wykazało, że takiej, ani podobnej
do niej aplikacji jeszcze nie ma, a co ważniejsze - istnieje coraz to wieksze
˛
zapotrzebowanie na wyspecjalizowane programy graficzne jak np. Adobe Photoshop
Touch firmy Adobe Systems oraz techniczne np. AutoCAD WS firmy Autodesk Inc.
10.1. Spełnienie założeń
52
dost˛epne w sklepie Android. Tym samym zwiazałem
˛
silnie mój projekt z jezykiem
˛
Java, który jest mi znany, ale w formie jezyka
˛
aplikacji Android zapewnia mechanizmy, funkcje i wzorce, które z pewnościa˛ były ciekawe i nieraz innowacyjne. Wymagało to także poznania architektury i działania systemu operacyjnego z niższego
poziomu, co na pewno jest ważnym doświadczeniem.
W toku pracy nad aplikacja˛ udało mi sie˛ znacznie poszerzyć swoja˛ wiedze˛ na
temat zagadnień przetwarzania obrazu - zarówno algorytmów jak i stosowanych
bibliotek. Wykorzystanie jednej z nich - powszechnie stosowanej biblioteki OpenCV
otwiera droge˛ do dalszego rozwijania sie˛ w kierunku grafiki komputerowej. Dodatkowo fakt, że środowiskiem uruchomieniowym sa˛ urzadzenia
˛
mobilne działajace
˛ pod systemem Android nie pozostaje bez znaczenia. Obserwuje sie˛ aktualnie
znaczny wzrost liczby przenośnych urzadze
˛
ń działajacych
˛
pod kontrola˛ tego systemu, zarówno telefonów komórkowych jak i tabletów. Znajomość architektury,
właściwości systemu oraz specyfiki tworzenia dedykowanych aplikacji jest także
bardzo pożadana
˛
na obecnym rynku pracy.
Zastosowane podejście oparte na wykrywaniu podstawowych kształtów oraz detekcji wierzchołków wsparte algorytmami analizy logicznej zgromadzonych danych
dedykowanymi tylko dla schematów układów cyfrowych zapewnia bardzo zadowalajace
˛ wyniki dla przykładowych obrazów wejściowych, z myśla˛ o których algorytm
został zaprojektowany. Dla przykładowych urzadze
˛
ń testowych pracujacych
˛
pod
kontrola˛ systemu Android (Samsung Galaxy S Plus oraz HTC Wildfire), wyniki wektoryzacji prostych schematów uzyskiwano w średnim czasie kilku sekund w zależności od rozmiarów plików wejściowych, a co ważniejsze stopnia skomplikowania
rysunku. Stanowi to bardzo dobry rezultat i punkt wyjściowy do ewentualnej dalszej optymalizacji.
Jednakże, dla zaplanowanej w trakcie rozwoju aplikacji funkcjonalności wektoryzacji zdje˛ ć zrobionych przy pomocy wbudowanej kamery program nie daje zadowalajacych
˛
wyników. Głównym powodem jest sam algorytm nastawiony na dokładne i precyzyjnie wykonane obrazy schematów wejściowych. Trzeba przyznać,
że wi˛ekszość algorytmów działa na zasadzie detekcji obszarów podobnych np. kolorem i grupowaniu ich w wie˛ ksze agregaty. Nastepnie
˛
ma miejsce zapisywanie tych
obszarów w postaci wektorowej jako wielokatów.
˛
Ze wzgledu
˛
na algorytmy wykorzystane w mojej aplikacji, obraz wejściowy powinien być dość dokładny. Transformacja,
˛ która nie wpływa na wynik końcowy, gdyż jest wpływ kompensowany
jest odpowiednimi algorytmami, jest obrót obrazu. Inne zniekształcenia, jak te
wynikajace
˛ z transformacji oraz znaczne zakłócenia obrazu powoduja,
˛ że proces
wektoryzacji trwa znacznie dłużej, a otrzymane efekty sa˛ bardzo niskiej jakości.
53
10.2. Porównanie wyników
Jedyne funkcje, które daja˛ poprawne efekty to funkcja automatycznego obrotu obrazu, wykrywania odcinków i wierzchołków. Dalsza analiza logiczna wykrytych
elementów obrazu zachodzi nieprawidłowo, co można zaobserwować na wynikach
przetwarzania zdje˛ ć przedstawionych na rysunku 10.1(f). Zmiany konieczne do
otrzymania poprawnych wyników prawdopodobnie wiazałyby
˛
sie˛ z koniecznościa˛
całkowitego przeprojektowania aplikacji i napisania jej od podstaw na nowo.
Dla porównania i potwierdzenia założenia, że narzedzia
˛
dedykowane do rozwia˛
zywania konkretnych problemów lepiej sprawdzaja˛ sie˛ od rozwiaza
˛ ń ogólnych skorzystałem z darmowego programu Inkscape w wersji 0.48.2, płatnego programu
CorelDraw w wersji X5 oraz dwóch aplikacji działajacych
˛
online - Vector Magic oraz
AutoTrace, a także dokonałem wektoryzacji przygotowana˛ przeze mnie aplikacja.
˛
Do porównania wyników wykorzystałem przygotowane pieć
˛ różnych plików przedstawiajacych
˛
schematy cyfrowych układów logicznych o różnym stopniu skomplikowania i różnej liczbie elementów.
Wszystkie programy dobrze poradziły sobie z odwzorowaniem tego, co na obrazie
si˛e znajdowało, jedynie AutoTrace zniekształcił nieco obraz. Porównanie fragmentów schematu przedstawiono na rysunku 10.2, a w powiekszeniu
˛
można je zobaczyć na rysunku 10.3. Warto zauważyć, że kształt fontu uzyskany w przypadku
mojej aplikacji jest inny niż w obrazie wejściowym, ale najdokładniejszy. Wynika
to z tego, że jest on w toku analizy rozpoznawany jako dany znak i w takiej formie
umieszczany w pliku wyjściowym. Pozostałe algorytmy nie dokonuja˛ takiej analizy
i traktuja˛ litery jak każdy inny kształt.
Najwie˛ ksza˛ przewage˛ pokazuje moja aplikacja w przypadku brania pod uwage˛
rozmiaru plików wyjściowych. Jako, że jest to narzedzie
˛
dedykowane tworzy ono
prawie zawsze najmniejsze pliki wynikowe, niezależnie od liczby elementów i stopnia skomplikowania. Wyniki zestawione w tablicy 10.1 oraz przedstawione graficznie na rysunku 10.5, pokazuja˛ zależność miedzy
˛
programem wektoryzujacym
˛
a rozmiarem pliku SVG. Pliki jakimi posłużyłem sie˛ do testowania widoczne sa˛
na rysunku 10.4. Warto wspomnieć, że AutoTrace generuje pliki SVGZ czyli pliki
skompresowane algorytmem gzip.
Zapewnia to średnio uzyskanie plików 50%
mniejszych od oryginału. Do właściwego porównania pliki zostały rozpakowane
i ten rozmiar został podany w tablicy. Warto wspomnieć, że wszystkie programy
54
(a) Zdj˛ecie nr 1. z monitora
(b) Wynik przetwarzania zdj˛ecia nr 1.
(c) Zdj˛ecie nr 2. z monitora
(d) Wynik przetwarzania zdj˛ecia nr 2.
(e) Zdj˛ecie nr 3. z wydruku
(f) Wynik przetwarzania zdj˛ecia nr 3.
(g) Zdj˛ecie nr 4. z rysunku
(h) Wynik przetwarzania zdj˛ecia nr 4.
Rysunek 10.1. Porównanie wyników wektoryzacji zdjeć
˛ wejściowych z wbudowanej
kamery telefonu
55
=1
=1
≥1
≥1
&
&
1
&
&
=1
(a) Obraz wejściowy (PNG)
(b) Omawiana aplikacja (SVG)
(c) CorelDraw (SVG)
(d) Inkscape (SVG)
(e) Vector Magic (SVG)
(f) Auto Trace (SVG)
Rysunek 10.2. Porównanie wyników aplikacji wektoryzujacych
˛
z obrazem wzorcowym
56
(a) Obraz wejściowy (PNG)
(b) Omawiana aplikacja (SVG)
(c) CorelDraw (SVG)
(d) Inkscape (SVG)
(e) Vector Magic (SVG)
(f) Auto Trace (SVG)
Rysunek 10.3. Porównanie wyników aplikacji wektoryzujacych
˛
z obrazem wzorcowym (w powiekszeniu)
˛
57
10.3. Perspektywy rozwoju aplikacji
testowane były z domyślnymi ustawieniami (CorelDraw z opcja˛ „szybkie trasowanie”). Można zauważyć, że Vector Magic i AutoTrace zawsze generowały pliki wynikowe wie˛ ksze niż oryginalny obraz. AutoTrace ten rozmiar potrafił zwiekszyć
˛
nawet 8 razy. Z drugiej zaś strony Inkscape i przygotowana przeze mnie aplikacja
zazwyczaj generowały pliki mniejsze od oryginalnych. Ze wzgledu
˛
na dostosowanie
algorytmów do charakteru obrazów aplikacja dla systemu Android generowała pliki
nawet 4 razy mniejsze.
Tablica 10.1. Porównanie rozmiarów plików.
1
2
3
4
5
PNG
Plik rastrowy
4538 B
10205 B
12115 B
16333 B
35956 B
Android
6795 B
4134 B
5015 B
7098 B
8841 B
CorelDRAW
1897 B
4405 B
5158 B
7331 B
9152 B
SVG
Inkscape
3410 B
9032 B
10112 B
14563 B
18508 B
Vector Magic
2682 B
12064 B
14125 B
19806 B
27199 B
AutoTrace
21680 B
77819 B
86848 B
133430 B
177176 B
Dalsze rozwijanie aplikacji powinno poda˛żać w kierunku otrzymywania coraz
lepszych wyników w procesie wektoryzacji niezależnie od charakteru danych wejściowych. Rozsadnym
˛
byłoby zaimplementowanie funkcjonalności rozpoznawania
opisów schematów, zarówno pomocniczych jak i etykietowania sygnałów.
Od-
dzielna ich wektoryzacja zapewniałaby wysoka˛ jakość otrzymywanych wyników.
Dodatkowa˛ funkcjonalnościa˛ mogłoby być przechwytywanie obrazu schematów
z wbudowanej kamery np. z rysunków wydrukowanych na papierze lub narysowanych odre˛ cznie. Konieczne byłoby usuwanie różnego typu zakłóceń i niepotrzebnych cze˛ ści zdje˛ cia a także uodpornienie algorytmu przetwarzania na zniekształcenia i wykrywanie transformacji, od prostych euklidesowych poprzez podobieństwa,
przekształcenia afiniczne, aż po zniekształcenia wynikajace
˛ z budowy kamery i jej
odległości od obiektu - przekształcenia projekcyjne.
Przy coraz powszechniejszym dostepie
˛
do urzadze
˛
ń mobilnych i drastycznie spadajacych
˛
cenach transmisji danych w sieciach komórkowych, zauważa sie˛ także
tendencje˛ do stosowania rozwiaza
˛ ń aplikacji działajacych
˛
po stronie serwera. Powodem jest, krótszy czas zwrócenia wyniku w przypadku przesłania danych, przetworzenia i odesłania z powrotem w porównaniu do przetwarzania ich na ciagle
˛
stosunkowo słabych obliczeniowo urzadzeniach
˛
mobilnych. Takie rozwiazanie
˛
sprowadza
aplikacje˛ mobilna˛ do roli aparatu fotograficznego i tzw. cienkiego klienta, a cały
proces wektoryzacji odbywałby sie˛ na wysokowydajnych serwerach zdalnych.
58
(a) Obraz nr 1.
(b) Obraz nr 2.
(c) Obraz nr 3.
(d) Obraz nr 4.
(e) Obraz nr 5.
Rysunek 10.4. Schematy wykorzystane do porównań rozmiaru plików
59
Rysunek 10.5. Graficzne porównanie rozmiarów plików.
Dodatkowo nowe wersje systemu Android w wersji 3 i wyższych wspieraja,
˛ poprzez wbudowana˛ przegladark
˛
e,
˛ wyświetlanie plików zapisanych w formacie SVG.
Przewidujac
˛ migracje˛ wie˛ kszej liczby użytkowników na wersje nowsze niż 2.* warto
byłoby rozważyć wykorzystanie tego wsparcia w projekcie. Innym rozwiazaniem
˛
byłoby wykorzystanie nowo powstajacej
˛
biblioteki svg-android zapewniajacej
˛
pewne
wsparcie wyświetlania obrazów wektorowych.
A. Jezyk
˛
skryptowy
1
2
3
load(
path) //bezwzgledna sciezka obrazu
4
5
6
7
8
9
hough_c(
dp, //odwrocony wspolczynnik proporcjonalnosci akumulatora (I)
minDist, //minimalna odleglosc pomiedzy srodkami okregow (D)
gaussSize, //rozmiar maski filtra Gaussa (D)
gaussSigma) //wspolczynnik sigma filtra Gaussa (D)
10
11
12
13
14
15
16
17
18
hough_l(
rho, //rozdzielczosc akumulatora w pikselach (I)
theta, //rozdzielczosc akumulatora w radianach (D)
threshold, //wartosc progowa akumulatora (I)
minLineLength, //minimalna dlugosc odcinka (I)
maxLineGap, //maksymalna dlugosc przerwy (I)
cannyT1, //mniejsza wartosc progowa detektora Cannyego (I)
cannyT2) //wieksza wartosc progowa detektora Cannyego (I)
19
20
21
22
23
24
25
26
harris(
maxCorners, //maksymalna liczba zwracanych wierzcholkow (I)
qualityLevel, //minimalna "jakosc" wierzcholka (D)
minDistance, //minimalna odleglosc miedzy zwracanymi wierzcholkami (I)
blockSize, //rozmiar sasiedztwa (I)
useHarris, //korzysta z~detektora Harrisa dla "true", dla "false" z~cornerMinEigenVal() (D)
k) //wolny parametr detektora Harrisa (D)
27
28
29
save(
path) //bezwzgledna sciezka rezultatu
30
31
32
33
34
35
36
do
{...} //funkcje w petli
while(
var //zmienna lub wartosc
op //relacja: <, >, <=, >=, ==, !=
n) //zmienna lub wartosc
37
38
39
40
var //nazwa zmiennej
=
n //przypisywana wartosc lub wyrazenie
41
42
43
44
var //nazwa zmiennej (jedna litera)
op //operator +=, −=, /=, ∗=
n //zmiana wartosci zmiennej lub wyrazenie
45
46
progress //znacznik postepu
Wydruk A.1. Opis struktur poszczególnych funkcji
A. Jezyk
˛
skryptowy
1
2
3
4
5
6
7
8
9
10
11
eval
: (load
|save
|houghc
|houghl
|harris
|doWhileLoop
|ass
|mod
|PROGRESS )+ ;
12
13
14
15
16
17
18
19
20
load
: LOAD
ROUND_LEFT_BRACKET
QUOTATION_MARK
path
EXTENSION_IN
QUOTATION_MARK
ROUND_RIGHT_BRACKET ;
21
22
23
24
25
26
27
28
29
save
: SAVE
ROUND_LEFT_BRACKET
QUOTATION_MARK
path
EXTENSION_OUT
QUOTATION_MARK
30
31
32
33
34
35
36
37
38
path
: (pathPart)+
(
’+’
VAR
’+’
)?
’.’ ;
39
40
41
pathPart
: ’/’ ( VAR | INT )+ ;
42
43
44
45
46
47
48
49
50
51
52
53
houghc
: HOUGHC
ROUND_LEFT_BRACKET
additionExp
COMA
additionExp
COMA
additionExp
COMA
additionExp
54
55
56
57
58
59
houghl
: HOUGHL
ROUND_LEFT_BRACKET
additionExp
COMA
61
A. Jezyk
˛
skryptowy
60
61
62
63
64
65
66
67
68
69
70
71
additionExp
COMA
additionExp
COMA
additionExp
COMA
additionExp
COMA
additionExp
COMA
additionExp
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
harris
: HARRIS
ROUND_LEFT_BRACKET
additionExp
COMA
additionExp
COMA
additionExp
COMA
additionExp
COMA
logic_val
COMA
additionExp
88
89
90
91
92
93
94
95
96
97
98
99
100
doWhileLoop
:
DO
CURLY_LEFT_BRACKET
eval
CURLY_RIGHT_BRACKET
WHILE
ROUND_LEFT_BRACKET
additionExp
REL
additionExp
101
102
103
104
105
ass
: VAR
EQUALS_SIGN
additionExp ;
106
107
108
109
110
mod
: VAR
OPERATOR
additionExp ;
111
112
113
114
115
additionExp
: multiplyExp
(’−’ multiplyExp
|’+’ multiplyExp)∗ ;
116
117
118
119
multiplyExp
: atomExp (’∗’ atomExp | ’/’ atomExp )∗ ;
62
A. Jezyk
˛
skryptowy
120
121
122
123
124
atomExp
: (MINUS)?
(NUM
| VAR
|’(’ additionExp ’)’ );
125
126
127
logic_val
: (’TRUE’ | ’true’) | (’FALSE’ | ’false’);
128
129
MINUS : ’−’;
130
131
QUOTATION_MARK : ’"’;
132
133
ROUND_LEFT_BRACKET : ’(’;
134
135
ROUND_RIGHT_BRACKET : ’)’;
136
137
CURLY_LEFT_BRACKET : ’{’;
138
139
CURLY_RIGHT_BRACKET : ’}’;
140
141
COMA : ’,’;
142
143
EQUALS_SIGN : ’=’;
144
145
146
EXTENSION_IN : ’jpg’ | ’jpeg’ | ’bmp’ | ’gif’ | ’png’
|’JPG’ | ’JPEG’ | ’BMP’ | ’GIF’ | ’PNG’;
147
148
EXTENSION_OUT : ’svg’ | ’SVG’;
149
150
LOAD : ’load’;
151
152
SAVE : ’save’;
153
154
ASS : ’ass’;
155
156
MOD : ’mod’;
157
158
HOUGHC : ’houghC’;
159
160
HOUGHL : ’houghL’;
161
162
HARRIS : ’harris’;
163
164
DO : ’do’;
165
166
WHILE : ’while’;
167
168
PROGRESS: ’progress’;
169
170
VAR : (’a’..’z’|’A’..’Z’) (’a’..’z’|’A’..’Z’|’0’..’9’|’_’)∗;
171
172
REL : ’<’ | ’>’ | ’<=’ | ’>=’ | ’==’ | ’!=’ ;
173
174
VARDEP : OPERATOR VAR;
175
176
OPERATOR : ’−=’|’+=’|’∗=’|’/=’ ;
177
178
179
NUM : INT|DBL;
63
A. Jezyk
˛
skryptowy
180
INT : (’0’..’9’)+;
181
182
183
184
DBL : ((’0’..’9’)+ ’.’ (’0’..’9’)∗ EXPONENT?
|’.’ (’0’..’9’)+ EXPONENT?
|(’0’..’9’)+ EXPONENT);
185
186
EXPONENT: (’e’|’E’) (’+’|’−’)? (’0’..’9’)+ ;
187
188
189
190
COMMENT : ’//’ ~(’\n’|’\r’)∗ ’\r’? ’\n’
|’/∗’ ( options {greedy=false;} : . )∗ ’∗/’
;
191
192
193
194
195
196
WS : ( ’ ’
| ’\t’
| ’\r’
| ’\n’
);
Wydruk A.2. Gramatyka jezyka
˛
w notacji EBNF
64
Bibliografia
[1] Android Dashboards. Dostepne
˛
w Internecie: http://developer.android.com/
about/dashboards, data dostepu:
˛
08.08.2012.
[2] Android Developers. Dostepne
˛
w Internecie: http://developer.android.com, data
dostepu:
˛
08.08.2012.
[3] AutoTrace. Dostepne
˛
w Internecie: http://autotrace.sourceforge.net, data dostepu:
˛
08.08.2012.
[4] Dokumentacja OpenCV. Dostepne
˛
w Internecie: http://docs.opencv.org/, data
dostepu:
˛
08.08.2012.
[5] Google play. Dostepne
˛
w Internecie: http://play.google.com, data dostepu:
˛
08.08.2012.
[6] IEEE Xplore. Dostepne
˛
w Internecie: http://ieeexplore.ieee.org, data dostepu:
˛
08.08.2012.
[7] Vector Magic. Dostepne
˛
w Internecie: http://vectormagic.com, data dostepu:
˛
08.08.2012.
[8] IEEE Standard Graphic Symbols for Logic Functions. 1984.
[9] Bera A. Fast vectorization and upscaling images with natural objects using canny
edge detection. International Conference on Electronics Computer Technology (ICECT)
2011 Proceedings., 2011.
[10] Kaehler A. Bradski G. Learning OpenCV. O’Reilly, 2008.
[11] Bołdak C. Cyfrowe przetwarzanie obrazów. Dostepne
˛
w Internecie: http://aragorn.
pb.bialystok.pl/~boldak/DIP/Wyklady.html, data dostepu:
˛
08.08.2012.
[12] Zieliński C. Podstawy projektowania układów cyfrowych. Wydawnictow Naukowe
PWN, 2003.
[13] Tombre K. Hiliaire X. Robust and accurate vectorization of line drawings. IEEE Trans.
Pattern Anal. Mach. Intell, 2006.
[14] Kalisz J. Podstawy elektorniki cyfrowej. Wydawnictwa Komunikacji i Łaczności,
˛
1993.
[15] Dani L. Johannes K. Depixelizing pixel art. ACM Trans. Graph., 2011.
[16] Hong Yan Ju Jia Zou. Cartoon image vectorization based on shape subdivision.
Computer Graphics International 2001 Proceedings, 2001.
[17] Jo K-H. Kirsanov A., Vavilin A. Contour-based algorithm for vectorization of satellite
images. IFOST 2010 Proceedings, 2010.
[18] Prasad L. Raster to Vector Conversion of Images for Efficeint SVG Reprezentation. Dostepne
˛
w Internecie: http://www.svgopen.org/2005/papers/Prasad_Abstract_
R2V4SVG, data dostepu:
˛
08.08.2012, 2005.
[19] Hamouda A. Naouai M., Narjess M. Line extraction algorithm based on image vectorization. International Conference on Mechatronics and Automation (ICMA) 2010 Proceedings, 2010.
[20] Grooch B. Olsen S. Image Simplification and Vectorization. NPAR ’11 Proceedings
of the ACM SIGGRAPH/Eurographics Symposium on Non-Photorealistic Animation and
Rendering, 2011.
[21] Korohoda P. Tadeusiewicz R. Komputerowa analiza i przetwarzanie obrazów. Wydawnictwo Fundacji Postepu
˛
Telekomunikacji, 1997.
[22] Yu Y. Xia T., Liao B. Patch-based image vectorization with automatic curvilinear
feature alignment. ACM Trans. Graph., 2009.

Wektoryzacja prostych schematów układów

Transkrypt

Podobne dokumenty

Projekt

Zadanie: LINES Brzydkie odcinki

Drukuj opis produktu do pdf - PC-AKME

KONCERT CHARYTATYWNY

Android Developer

Sylabus

28 października 2016 TAURON Arena Kraków