Kamil Zieli ński PÓŁAUTOMATYCZNE POZYSKIWANIE DANYCH Z ...holmes.iigw.pl/~rszczepa/dyplomy/2139_Kamil_Zielinski.pdf · w aplikacji, omówienie jej składników, prezentacja jej

ul. Warszawska 24, 31-155 Kraków tel/fax (+48 12) 628 20 41 e-mail: [email protected] internet: www.iigw.pl

INSTYTUT INśYNIERII I GOSPODARKI WODNEJ

POLITECHNIKA KRAKOWSKA im. TADEUSZA KOŚCIUSZKI

Kamil Zieliński

PÓŁAUTOMATYCZNE POZYSKIWANIE DANYCH Z ROCZNIKÓW OPADOWYCH

praca magisterska

studia dzienne

kierunek studiów: informatyka

specjalność: informatyka stosowana w inŜynierii środowiska

promotor: dr inŜ. Robert Szczepanek

nr pracy: 2139

KRAKÓW 2008

Chciałbym serdecznie podziękować

dr inŜ. Robertowi Szczepankowi,

Damianowi i Rafałowi

oraz wszystkim bliskim.

Bez Was ta praca by nie powstała.

Spis treści

1. Wstęp.............................................................................................................. 1

1.1. Cel.............................................................................................................2

1.2. ZałoŜenia ...................................................................................................2

1.3. Zawartość pracy..........................................................................................3

2. Roczniki opadów atmosferycznych...................................................................... 5

3. OCR - Optyczne rozpoznawanie znaków.............................................................11

3.1 Techniki OCR.............................................................................................12

3.2. Wybrane narzędzie OCR ............................................................................16

3.2.1 FineReader wersja 9.0 .........................................................................17

3.2.2 FineReader wersja 8.0 .........................................................................18

3.3. Format pliku wyjściowego..........................................................................19

3.3.1 TXT ...................................................................................................19

3.3.2 XML ...................................................................................................20

3.3.3 HTML.................................................................................................20

3.4. Szablony bloków .......................................................................................22

3.5. Funkcja douczania.....................................................................................26

3.6. Badania skuteczności rozpoznawania znaków ..............................................27

3.6.1. Wnioski z badań wstępnych ................................................................27

3.6.2. Strategia badań .................................................................................28

3.6.3. Jakość obrazów..................................................................................32

3.6.4. Douczanie .........................................................................................52

3.6.5. Zaznaczanie niepewnych znaków.........................................................56

3.7. Analiza wyników i wnioski ..........................................................................60

3.7.1. Jakość obrazów..................................................................................60

3.7.3. Douczanie .........................................................................................64

3.7.4. Zaznaczanie niepewnych znaków.........................................................65

3.7.5. Inne wnioski z badań..........................................................................66

3.7.6. Podsumowanie badań.........................................................................69

4. Aplikacja pozyskująca dane z pliku tekstowego...................................................71

4.1. Uwagi wstępne .........................................................................................72

4.2. Podstawy aplikacji .....................................................................................72

4.3. Ekstrakcja danych z pliku HTML..................................................................75

4.3.1 Próby zastosowania istniejących modułów PHP......................................75

4.3.2. Własne rozwiązanie programistyczne ...................................................78

4.4. Sprawdzanie poprawności pozyskanych danych przy uŜyciu aplikacji..............84

4.4.1. Klasa Sprawdzacz...............................................................................85

4.4.2. Wykorzystanie aplikacji do badań skuteczności rozpoznawania znaków...86

4.5. Baza danych .............................................................................................87

4.6. Prezentacja aplikacji ..................................................................................89

5. Weryfikacja opracowanego systemu ..................................................................94

5.1 Przeprowadzone testy ................................................................................95

5.2. Test systemu ............................................................................................95

5.3. Test manualnego wprowadzania danych .....................................................97

5.4. Wnioski z testów.......................................................................................98

6. Podsumowanie ................................................................................................99

Spis tabel .......................................................................................................... 102

Spis rysunków ................................................................................................... 104

Bibliografia ........................................................................................................ 106

Netografia ......................................................................................................... 107

Abstrakt ............................................................................................................ 108

Abstract in English ............................................................................................. 109

1

Praca magisterska Kamil Zieliński

Półautomatyczne pozyskiwanie danych z roczników opadowych

1.

Wstęp

W pierwszym rozdziale przedstawiony jest cel pracy, podane są podstawowe

załoŜenia i krótko zaprezentowana jej zawartość.

2



1.1. Cel

Praca stanowi próbę wdroŜenia komputerowych technik przetwarzania obrazu

i tekstu do procesu półautomatycznego pozyskiwania danych ze zbiorów drukowanych.

Jest w niej zawarty opis moŜliwych do zastosowania technik oraz strategii działań

wspomagających i uskuteczniających cały proces.

Zagadnienie opracowałem na przykładzie roczników opadów atmosferycznych.

1.2. ZałoŜenia

Starając się, aby praca ta była rzeczowa i konstruktywna postanowiłem uściślić

zagadnienie. Skupiłem się na przetwarzaniu stron roczników opadowych, które

zawierają dane o wielkościach dobowych opadów. Dzięki temu mogłem poświęcić się

dokładnemu zbadaniu zagadnienia. Wszystkie wnioski z badań i zaproponowaną

strategię działań, a takŜe cały opracowany system pozyskiwania danych moŜna

z powodzeniem wykorzystywać w innych tego typu przedsięwzięciach. Szczególnie

łatwe byłoby wdroŜenie stworzonych przeze mnie rozwiązań do pozyskania wszystkich

danych dostępnych w rocznikach opadowych.

Strony zawierające wielkości dobowe opadów są najtrudniejsze do rozpoznania

a zarazem najbardziej odpowiednie do przebadania z następujących powodów:

• czcionka uŜyta na nich jest najmniejszego rozmiaru, jaki moŜna spotkać

w roczniku;

• zawierają największą ilość danych na stronę, największą liczbę znaków;

• występują na nich dodatkowe znaki powodujące utrudnienia w rozpoznawaniu

(znaki symboli opadów atmosferycznych, pokreślenia, kropki i kreski w danych

pomiarowych);

• zawierają jedne z najbardziej znaczących, podstawowych danych zawartych

w rocznikach;

3



• dwie kolejne tablice zawarte na innych stronach rocznika mogą zostać

utworzone na ich podstawie. JeŜeli strony z tymi tablicami zostaną przetworzone

niezaleŜnie umoŜliwi ą weryfikację odczytu.

Wszystkie badania opisane w niniejszej pracy zostały przeprowadzone

na roczniku „Opady atmosferyczne 1976”.

1.3. Zawartość pracy

Nikogo nie trzeba przekonywać o zaletach gromadzenia danych w postaci

elektronicznej. Obecnie wszystkie instytucje i firmy magazynują dane przede

wszystkim przy uŜyciu systemów komputerowych. Ale co z danymi z przed lat? Co ze

wszystkimi zbiorami zgromadzonymi w postaci drukowanej? Czy jest moŜliwe

przetworzenie tych danych na formę elektroniczną? W jaki sposób to zrobić? Na te

i inne pytania odpowiada niniejsza praca.

Na początku pracy przedstawiłem informacje na temat roczników opadowych.

Opisałem jakie dane zawierają roczniki i jaka jest struktura stron z danymi o wysokości

opadów. Informacje te znajdują się w rozdziale drugim.

Rozdział trzeci dotyczy pierwszego etapu przetwarzania danych – zamiany pliku

z obrazem strony rocznika na plik tekstowy. W rozdziale tym opisałem techniki, jakie

stosowane są w optycznym rozpoznawaniu znaków, przedstawiłem wybrane do tego

zadania narzędzie i określiłem format pliku wyjściowego. Jedną z najwaŜniejszych

części pracy są badania jakie przeprowadziłem poszukując metod podniesienia

skuteczności rozpoznawania znaków. Ich strategię, wyniki i wnioski wyciągnięte na ich

podstawie takŜe zawarłem w trzecim rozdziale.

Drugim etapem przetwarzania danych jest ich ekstrakcja z pliku tekstowego

i zapisanie w bazie danych. W celu realizacji tego zadania stworzyłem aplikację opartą

na technologiach PHP, HTML i CSS. Podstawy algorytmów zastosowanych

w aplikacji, omówienie jej składników, prezentacja jej interfejsu oraz projekt bazy

danych zawarte są w rozdziale czwartym.

4



Ostatnim zadaniem, które wykonałem i opisuję w rozdziale piątym była

weryfikacja opracowanego systemu pozyskiwania danych. Podjąłem próbę oceny

skuteczności półautomatycznego przetwarzania danych z uwzględnieniem czasu, jaki

trzeba włoŜyć w realizację tego procesu.

Ostatni, ósmy rozdział stanowi podsumowanie i zawiera końcowe uwagi.

5



2.

Roczniki opadów atmosferycznych

W drugim rozdziale omówiona jest zawartość roczników opadowych oraz

struktura stron zawierających dane o wysokościach dobowych opadów.

6



Od roku 1954 wydawane są roczniki z serii „Opady atmosferyczne”. Prezentują

one wyniki z obserwacji opadowych przeprowadzonych na terenie Polski. Dane

zestawione są w tablicach oraz uzupełnione dodatkowymi mapami. Roczniki zawierają

charakterystyczne dane o opadach zebrane na podstawie obserwacji w sieci stacji

pomiarowych. KaŜda stacja pomiarowa ma przypisany numer, na podstawie którego

moŜna jednoznacznie ją zidentyfikować.

Oto zawartość rocznika „Opady atmosferyczne 1976” wraz z tablicami, mapami

i ich nazwami:

• Tablica - Alfabetyczny spis stacji,

• Tablica I - Wysokości dobowe opadów w mm,

• Tablica II – Miesięczne i roczne sumy opadów oraz maksymalne wartości,

dobowe i daty ich występowania,

• Tablica III - Liczba dni z opadem ≥ 0,1, ≥ 1,0, ≥ 10,0 mm,

• Tablica IV - Liczba dni z burzą,

• Tablica V - Wyniki pomiarów wysokości opadów dokonanych za pomocą

totalizatorów,

• Tablica VI – Wysokości dobowe pokrywy śnieŜniej w cm,

• Tablica VII – Maksymalne wysokości pokrywy śnieŜniej w cm, liczba dni,

z pokrywą oraz długość okresu bez pokrywy,

• Tablica VIII – Zapas wody w śniegu,

• Tablica IX - Ulewy i deszcze nawalne,

• Mapa – Stacje i posterunki z obserwacjami drukowanymi in extenso,

• Mapa – Roczne sumy opadów,

• Mapa – Odchylenia opadów w roku 1976 od wartości wieloletnich 1931-1960,

• Mapa – Liczba dni z opadem ≥ 1,0 mm,

• Mapa – Liczba dni z pokrywą śnieŜną.

Przeglądając inny rocznik opadowy zauwaŜyłem nieznaczne róŜnice w układzie

treści. Odmienna była numeracja tabel - tabela z alfabetycznym spisem stacji była

opatrzona numerem I. MoŜna jednak powiedzieć, Ŝe kolejne roczniki nie róŜnią się od

7



siebie na tyle, aby proces przetwarzania danych opracowany dla jednego z nich nie

mógł być zastosowany dla wszystkich.

Struktura stron z tabelą „Wysokości dobowe opadów”

Jak wspomniałem w załoŜeniu, w pracy skupię się na przetwarzaniu danych

z tabeli I rocznika opadowego. Zawiera ona dane o wysokościach dobowych opadów

podane w mm. Aby dobrze zrozumieć mechanizmy jakie zastosowałem do pozyskania

danych trzeba poznać strukturę tej strony. Będę się do niej odwoływał przy

przedstawianiu algorytmu ekstrakcji danych. Schemat struktury przedstawiłem na

rysunku 1.

8



Rysunek 1. Schemat struktury strony rocznika opadowego zawierającej dane o wysokościach opadów.

Cyfry wyróŜnione na rysunku 1 kolorem czerwonym oznaczają główne

składniki struktury strony. Ich omówienie znajduje się w tabeli 1.

9



Tabela 1. Budowa strony rocznika opadowego zawierającej dane o wysokościach opadów.

Lp. Składnik Poło Ŝenie Zawarto ść

1 Numer tablicy Prawy górny róg Niezmienna „TABL. I”

2 Tytuł tablicy Góra, centrum Niezmienna „WYSOKOŚCI DOBOWE OPADÓW w mm”

3 Miesiąc i rok Lewy górny róg Zmienna np. „STYCZEŃ 1976”

4 Tabela z wysokościami opadów

Centrum, zajmuje większość obszaru strony

Zmienna (omówienie w dalszej części rozdziału)

5 Numer strony Lewy lub prawy dolny róg Zmienna, np. „56”

Tabela z wysokościami opadów składa się z czterech głównych kolumn.

Pierwsza zawiera numer posterunku, druga jego nazwę, trzecia przedstawia wysokości

opadów w kolejnych dniach miesiąca, a czwarta sumę tych opadów. Wszystkie dane

ułoŜone są w wierszach w kolejności rosnącej według numerów posterunków. Pierwszy

wiersz tabeli jest wierszem tytułowym.

W tabeli znajdują się takŜe wiersze zawierające informacje o zlewni, do której

naleŜą stacje podane poniŜej tego wiersza. Taki wiersz posiada wypełnioną tylko jedną

komórkę, naleŜącą do kolumny z nazwą posterunku. Jest w nim podana nazwa zlewni

pisana duŜymi literami z podkreśleniem. Niekiedy zdarzają się takie wiersze jeden pod

drugim. Wtedy rzeka podana poniŜej naleŜy do dorzecza rzeki zapisanej powyŜej.

W nazwach posterunku moŜe się pojawić dodatkowy znak „/M/” określający

stacje meteorologiczną wyŜszego rzędu. JeŜeli nazwa posterunku jest dłuŜsza niŜ

szerokość kolumny wtedy zostaje ona zapisana w dwóch wierszach.

Poszczególne dane z kolumny z wysokością opadów określają jego wartość

w kolejnych dniach miesiąca. JeŜeli opad występował w postaci deszczu opisany jest

samą liczbą z dokładnością do jednej dziesiątej. Część dziesiętna oddzielona jest

przecinkiem.

Do oznaczenia innych zjawisk atmosferycznych uŜyto szeregu symboli.

Zaprezentowałem je w tabeli 2.

10



Tabela 2. Symbole opadów atmosferycznych zastosowane w roczniku opadowym.

Typ opadu Symbol

śnieg

śnieg ziarnisty

krupy śnieŜne

ziarna lodowe

grad

burza

burza odległa

Symbol zjawiska atmosferycznego znajduje się tuŜ nad liczbą określającą

wysokość opadu. Symbole te oczywiście mogą występować grupowo (nawet kilka

symboli przypisanych do jednej wartości).

Wartości maksymalnego opadu dla stacji w danym miesiącu są dodatkowo

oznaczone podkreśleniem. JeŜeli wystąpiło kilka dni z takim samym opadem, który jest

opadem maksymalnym w danym miesiącu wszystkie są podkreślane.

Ostatnia kolumna zawiera sumę wartości opadowych dla stacji w danym

miesiącu. Liczba jest takiego samego formatu jak wartość opadu.

Wśród danych o wysokości opadu mogą pojawić się znaki dodatkowe, inne od

liczbowych:

• symbol „-” oznaczający brak zjawiska,

• symbol „.” oznaczający brak danych,

• liczba ze znakiem zapytania oznaczająca wartość wątpliwą,

• liczba podana w nawiasach oznaczająca wartość oszacowaną.

Tabela nie jest ograniczona krawędziami bocznymi ani krawędzią dolną.

Posiada krawędź górną i drugą linię poziomą oddzielającą wiersz tytułowy od danych.

W szkicu tabeli uŜyte jest pięć linii pionowych. Trzy rozdzielające główne kolumny

numeru stacji, nazwy, wysokości opadów i sumy oraz dwie dodatkowe znajdują się po

dziesiątym i dwudziestym dniu miesiąca.

11



3.

OCR - Optyczne rozpoznawanie znaków

W rozdziale trzecim omówiony został pierwszy etap przetwarzania danych,

którym jest pozyskanie tekstu z obrazu przedstawiającego stronę rocznika opadowego.

12



3.1 Techniki OCR

Akronim OCR (ang. Optical Character Recognition) tłumaczony jest jako

“optyczne rozpoznawanie znaków”. Jest to zestaw technik, który pozwala na

przetworzenie obrazu zawierającego tekst do pliku edytowalnego. Najczęściej techniki

te stosowane są w połączeniu z pozyskiwaniem obrazu z tekstu drukowanego

(skanowaniem). Cały ten proces umoŜliwia więc pozyskanie tekstu do dalszej obróbki

i przetwarzania komputerowego z dowolnego zbioru drukowanego.

Historia

Historia OCR zaczyna się w 1929 roku, gdy austriacki inŜynier Gustav

Tauschek opatentował urządzenie mechaniczne słuŜące do rozpoznawania znaków

pisma. Maszyna przy pomocy fotodetektora badała ilość światła, jaka przedostała się za

wzorzec i literę ustawione w jednej linii. Najmniejsze natęŜenie światła odpowiadało

największej zgodności. Kolejnym krokiem było opracowanie w 1953 roku przez

Amerykanina David’a Shepard’a systemu Gismo przetwarzającego tekst drukowany na

tekst maszynowy ówczesnych komputerów. Shepard załoŜył później korporacje, która

opracowała pierwsze komercyjne systemy OCR uŜyte przez Readers Digest w 1955

roku. Od 1965 roku amerykańska poczta zaczęła uŜywać systemów rozpoznawania

znaków do sortowania poczty. Obecnie systemy te są w powszechnym uŜyciu w wielu

instytucjach rządowych i jednostkach administracyjnych [http://wikipedia.org; Gajer,

2008].

Zastosowanie

Zadania, do jakich wykorzystywane są współczesne systemy OCR to[Bieniecki,

2005]:

• archiwizacja i udostępnianie dokumentów (przetwarzanie do postaci

elektronicznej ksiąŜek, gazet, a takŜe zapisu równań matematycznych i nut);

• systemy odczytu dla niewidomych (np. pracownia tyfloinformatyczna na AGH);

• systemy odczytu danych z formularzy i dokumentów wypełnianych ręcznie;

• interfejsy komunikacji w palmtopach;

13



• Analiza zdjęć w diagnostyce medycznej;

• Systemy identyfikacji i monitorowania (np. rozpoznawanie tablic

rejestracyjnych samochodów).

OCR współcześnie

Skuteczność narzędzi OCR w przypadku dobrej jakości druków dawno

przekroczyła 99% [Ormowski, 2004]. Aktualnie badaniom podlegają bardziej złoŜone

i skomplikowane zagadnienia związane z optycznym rozpoznawaniem znaków. W

ostatnich woluminach „International Journal on Document Analysis and Recognition”

poruszane są problemy rozpoznawania pisma odręcznego. Jest to jedno z największych

wyzwań stawianych współczesnym OCR’om. Rezultaty przetwarzania tego rodzaju

pisma są nadal niezadowalające, w duŜej mierze zaleŜą bowiem od staranności osoby

piszącej. Inne, poruszane ostatnimi czasy zagadnienia z dziedziny OCR to

rozpoznawanie dokumentów złej jakości, zawierających duŜe ilości szumów.

Podejmowane są próby przetwarzania starych wydawnictw i dokumentów

historycznych. Wyzwaniem dla projektantów systemów OCR jest takŜe rozpoznawanie

pism w językach opartych na alfabecie innym niŜ łaciński. Ponad jeden miliard ludzi

wywodzi się z cywilizacji arabskiej, półtora miliarda posługuje się językiem

wywodzącym się ze staroŜytnego Indii i tyle samo pismem opartym na chińskich

ideogramach. Forma drukowana tekstów w tych alfabetach niewiele róŜni się od pism

odręcznych. Trudno jest wyodrębnić pojedyncze znaki, a często ten sam znak przyjmuje

róŜne formy graficzne [Gajer, 2008]. Przed projektantami systemów OCR stoi więc

jeszcze wiele wyzwań i duŜo problemów do rozwiązania. Powoduje to ciągły rozwój

algorytmów, które stają się coraz bardziej wyspecjalizowane.

Zasada działania

Pierwszym zadaniem, jakie wykonuje program OCR jest wydzielenie bloków

rozpoznawania. Na obszarze obrazu wyznaczane są pola, w których znajduje się tekst,

obraz lub tablica. Ustalana jest kolejność ich przetwarzania. W większości programów

jest moŜliwość ingerencji uŜytkownika w tę część procesu. Do późniejszego

rozpoznania moŜna wybrać jedynie interesującą nas część. Wyznaczenie obszarów

14



przez uŜytkownika moŜe takŜe zwiększyć skuteczność rozpoznawania, gdyŜ eliminuje

błędy występujące na tym etapie [Czajkowska, 2000].

Kolejny etap to wyznaczenie poszczególnych znaków, wyodrębnienie ich

z całości tekstu. KaŜda litera czy liczba musi być reprezentowana przez pojedynczy

mikroobszar. Segmenty te są następnie poddawane głównemu procesowi

rozpoznawania. Tu zastosowanie znajdują specjalnie opracowane algorytmy. Segmenty

zawierające pojedyncze znaki porównywane są z wzorcami w bazie programu

i kaŜdemu z nich zostaje przypisany odpowiadający mu znak. Automatyczna

klasyfikacja wzorców to zadanie z zagadnień sztucznej inteligencji. Zwykle na tym

etapie wykorzystywane są sieci neuronowe [Boniecki, 2006]. W wielu programach

istnieje moŜliwość uzupełnienia bazy programu o własne wpisy. MoŜliwe jest

stworzenie własnych wzorców przez przypisanie wycinkom obrazu odpowiadających

im znaków.

Do kolejnego etapu przetwarzania zostaje wykorzystany słownik językowy.

Uzyskany tekst sprawdzany jest pod względem poprawności zapisu słów, gramatyki

i ortografii. Przykładowo, jeŜeli program zidentyfikował w słowie „tekst” litery „t”, „k”,

„s”, „t” tworz ąc zbiór „t.kst” (kropka oznacza brakujący znak), moŜe poprawnie

rozpoznać całe słowo korzystając z wpisu w słowniku.

Tak rozpoznany tekst jest przedstawiany uŜytkownikowi, który moŜe dokonać

dodatkowej „ręcznej” korekcji przed zapisaniem go do pliku lub wyeksportowaniem do

innego programu. Wiele programów posiada dodatkową funkcję oznaczającą elementy,

z którymi program miał największe problemy. Sugerują one miejsca, w których

przypuszczalnie mogą pojawić się błędy.

Przykładowy algorytm

Ciekawy sposób podejścia do zagadnienia zaproponował Mirosław Gajer [Gajer,

2008], dlatego przedstawię pokrótce opracowany przez niego algorytm.

Plik obrazu na wstępie podlega binaryzacji – kaŜdemu pikselowi przypisywany

jest kolor biały lub czarny. Ma to na celu wyróŜnienie z obrazu znaków, którym

przypisywany jest kolor czarny. Całe tło przybiera kolor biały. Oczywiście proces ten

nie jest doskonały. Dlatego tak przygotowany obraz podlega dodatkowej filtracji. W

tym celu zostaje wykorzystane złoŜenie dwóch filtracji nieliniowych. Najpierw zostaje

15



uŜyty filtr minimalny a następnie maksymalny. Oba filtry mają identyczną maskę

(rys.2).

Rysunek 2. Maska filtra maksymalnego i minimalnego stosowanego do binaryzacji obrazu [źródło: Gajer, 2008]

Filtr minimalny działa w ten sposób, Ŝe przypisuje pikselowi kolor czarny

wtedy, gdy on sam jest czarny i wszystkie cztery piksele z nim sąsiadujące (A, B, C, D)

są czarne. Pozwala to na pozbycie się z obrazu pojedynczych, czarnych pikseli i ich

małych zgrupowań. Niestety po tym procesie wszystkie obiekty na obrazie stracą nieco

ze swej grubości. W celu przywrócenia ich pierwotnych wymiarów stosuję się jako

drugi filtr maksymalny. Filtr ten zamienia kaŜdy biały piksel na czarny, gdy

którykolwiek z jego sąsiadów (piksele: A, B, C, D) jest koloru czarnego.

Tak przetworzony obraz podlega segmentacji w celu wydzielenia pojedynczych

znaków. KaŜdy wyodrębniony znak wpisywany jest w prostokąt o wymiarach

odpowiadających jego szerokości i wysokości. Następnie prostokąt ten zostaje

przeskalowany przyjmując kształt kwadratu. Oba wymiary przyjmują wartość równą

długości większego boku. Tak zdeformowany obraz dzielony jest następnie przez pięć

kolumn i pięć wierszy na dwadzieścia pięć sektorów o jednakowych wymiarach

(rys. 3).

Rysunek 3. Podział obrazka z pojedynczym znakiem na dwadzieścia pięć sektorów [źródło: Gajer, 2008]

W kaŜdym z tak wyznaczonych segmentów zliczana jest następnie liczba

czarnych pikseli. Powstaje w ten sposób dwudziestopięcioelementowy wektor. Aby

16



uniezaleŜnić wyniki od rozmiarów obrazka zawierającego dany znak naleŜy jeszcze

podzielić kaŜdą wartość przez liczbę wszystkich pikseli na obrazie. Tak

znormalizowane wektory stanowią dane wejściowe do kolejnego etapu przetwarzania,

jakim jest klasyfikacja według wzorców.

Przedstawiony algorytm jest czytelny i stanowi bardzo proste, ale ciekawe

podejście do problemu optycznego rozpoznawania znaków pisma. Obecnie stosowane

są takŜe metody wyodrębniania charakterystycznych cech znaków. Nazywane jest to

„ekstrakcją właściwości” (ang. Feature Recognition). Metoda polega na analizie

kształtów znaku i porównaniu ich z zestawem reguł. Przykładowo litera „a” moŜe

zostać opisana jako okrąg z pionową linią przylegającą po prawej i łukiem na górze.

Program OCR porównując zestawy reguł odnośnie stosunków długości składowych

znaku, kątów łuków i innych cech matematyczno-geometrycznych klasyfikuje wzorce

liter dla danego obrazu [Dołęga, 1998].

3.2. Wybrane narzędzie OCR

Wybierając narzędzie OCR bazowałem na niezaleŜnych opiniach i rankingach

pism komputerowych z całego świata, a takŜe na materiałach ze stron i forów

internetowych. Wybrałem produkt firmy ABBYY: FineReader 8.0 Proffesional Edition

ze względu na jego popularność i dobrą opinie, a takŜe znakomite wyniki w testach.

Seria programów FineReader zdobyła ponad 150 nagród przyznanych przez

czołowe czasopisma branŜowe [http://www.finereader.pl]. Wśród programów OCR od

lat uznawana jest za produkt bezkonkurencyjny. Oto fragment artykułu z polskiego

czasopisma PC Format, które przetestowało program: „Programem FineReader firma

ABBYY postawiła swego czasu niezwykle wysoko poprzeczkę aplikacjom słuŜącym do

rozpoznawania tekstu. Osiągnął on zresztą taką skuteczność, Ŝe trudno juŜ o lepsze

wyniki w przypadku typowych dokumentów pochodzących z róŜnego typu

drukarek […]” [PC Format 01/2006]. Czasopismo Enter potwierdza powyŜszą opinię:

„Parametry wskazują jednoznacznie - FineReader jest lepszy. Jest zarówno

skuteczniejszy w rozpoznawaniu tekstu, zwłaszcza z niewyraźnych skanów, jak

i obsługuje więcej formatów plików wynikowych.”[ Enter 02/2006].

17



Jako dodatkowe atuty programu naleŜy uznać intuicyjny interfejs w języku

polskim, wbudowanie polskiego słownika i szerokie moŜliwości w definiowaniu

formatów plików wynikowych.

3.2.1 FineReader wersja 9.0

Rozpoczynając pracę z programem sięgnąłem po jego najnowszą wersję

(w marcu 2008 była to wersja 9.0) jednak juŜ na początku pracy z tą wersją pojawiły się

problemy. Podczas rozpoznawania niektórych stron wyświetlany był komunikat

o niepowodzeniu procesu spowodowanym brakiem pamięci. Z komunikatu tego nie

mogłem wywnioskować o jaką pamięć chodzi. Zwiększyłem zasoby pamięci RAM do

1,5 GB, mimo Ŝe według danych producenta program wymaga jedynie 512MB. Błąd

niestety pojawiał się dalej. RóŜne kombinacje ze zmianą rozmiaru pliku stron takŜe nie

przyniosły rezultatu. Próby na komputerze z pamięcią RAM 4GB i procesorem Intel

Core 2 Duo 2,33 GHz oraz 55GB wolnego miejsca na dysku systemowym takŜe

zakończyły się niepowodzeniem.

Wszystkie testy przeprowadziłem na wersji demo programu nie mogło być to

jednak powodem błędu, bo jak podaje producent wersja ta nie była ograniczona

w Ŝaden inny sposób niŜ limit uŜytkowania przez czternaście dni i pięćdziesięciu

skanowanych stron.

Postanowiłem skontaktować się ze wsparciem technicznym producenta. Po tym

jak przedstawiłem problem i posłałem przykładowe pliki wywołuj ące błąd dostałem

odpowiedź od Pana Jacka Opary, iŜ problem został przesłany do deweloperów, którzy

spróbują go rozwiązać. Radzono mi takŜe ręczne ustawianie szablonu bloków1, co

miało wykluczyć błędy. Niestety zastosowanie się do tej rady takŜe nie przyniosło

rezultatów.

WyŜej opisany problem pojawiał się przy około pięćdziesięciu procentach prób

rozpoznania obrazu ze stroną rocznika opadowego. Nie stwierdziłem przypadków jego

wystąpienia przy rozpoznawaniu innych plików z obrazami stron ksiąŜek i czasopism.

1 Czym są szablony bloków napisałem w rozdziale 3.4.

18



3.2.2 FineReader wersja 8.0

Z powodu błędów, które zupełnie wykluczały moŜliwość zastosowania wersji

9.0 zdecydowałem się na dokonanie prób na wersji poprzedniej, czyli 8.0. Posiada ona

nieco mniej intuicyjny interfejs. Niestety według producenta jest takŜe mniej skuteczna

w rozpoznawaniu. Mimo to jest ona narzędziem o wysokiej skuteczności

rozpoznawania w porównaniu z innych dostępnych na rynku. Opinie przytoczone

wcześniej z czasopism Enter i PC Format dotyczą właśnie wersji 8.0.

Aby zapoznać czytelnika ze środowiskiem pracy programu na rysunku 4

przedstawiłem zrzut ekranu przedstawiający okno pracy FineReadera 8.0.

Rysunek 4. Zrzut ekranu środowiska pracy programu Finereader 8.0.

19



3.3. Format pliku wyjściowego

Dane zawarte na stronach rocznika przedstawione są w sposób

usystematyzowany. Wysokości opadów w poszczególnych miesiącach roku są podane

w formie tabelarycznej2 . Liczby oznaczające wysokość opadu atmosferycznego są

przypisane do dnia miesiąca poprzez umiejscowienie w odpowiedniej kolumnie i do

stacji pomiarowej poprzez połoŜenie w odpowiednim wierszu tabeli. Nie moŜe zajść

sytuacja, w której połoŜenie liczby w rozpoznanym dokumencie (skanie przerobionym

na tekst) zostanie zmienione. Format pliku, w którym zostaną zapisane przetwarzane

dane musi, więc mieć moŜliwość przedstawiania danych w formie tabeli. Oczywiście

nie jest konieczne, zachowanie idealnie takiego samego sposobu prezentacji danych,

chodzi o to, aby wspomniana wcześniej struktura przypisania danej do odpowiedniego

wiersza i kolumny została zachowana.

Z formatów, w jakich FineReader umoŜliwia zapisanie pliku wyjściowego,

poszukiwałem takiego, który byłby najbardziej uniwersalny, w którym pliki z kolejnymi

przetworzonymi stronami będą przedstawione w tej samej formie. Dokumenty musiały

zachować niezmienną strukturę, aby było moŜliwe stworzenie jednego wzorca do

przerabiania wszystkich plików z tymi samymi danymi. Chciałem, aby wybrany format

był powszechnie uŜywany, tak, aby ewentualne przeróbki, czy wdraŜanie stworzonego

systemu do innych rozwiązań, niekoniecznie wykorzystujących ten sam program OCR,

było jak najłatwiejsze. Podejmując próbę stworzenia uniwersalnego rozwiązania

sięgałem po popularne, powszechne w uŜyciu formaty.

3.3.1 TXT

Pierwszym formatem, jaki rozpatrywałem do uŜycia był format TXT. Jest to

najmniej złoŜony format z dostępnych w programie. Jest prosty w prezentacji danych

i łatwy do obróbki, bo nie zawiera Ŝadnych dodatkowych znaków poza zawartymi

w pliku wejściowym. Nie umoŜliwia niestety przedstawienia danych w tabeli. Istnieje

2 Więcej o strukturze tabeli z danymi o wysokościach opadów pisałem w rozdziale 2.

20



moŜliwość ułoŜenia danych w wierszach i zachowanie odpowiednich odstępów

pomiędzy znakami tak, aby ich ułoŜenie odzwierciedlało strukturę tabeli, nie jest to

jednak odzwierciedlenie dokładne. Poszczególne komórki w wierszu tabeli musiałby

zostać jednoznacznie wydzielone.

W plikach stworzonych przez FineReader’a poszczególne komórki jednego

wiersza tabeli są rozdzielane przez znak „space” (kod ASCII: 32). Niestety podczas

przeglądania plików znalazłem przypadki, gdy pojedyncza komórka została podzielona

przez ten znak, tak jakby były to dwie komórki. Znak ten moŜe być takŜe częścią

zawartości komórki (przed właściwą daną lub po niej), co ponownie zaburza strukturę

w wierszu. Częstym przypadkiem jest takŜe nierozpoznanie znaku braku zjawiska

atmosferycznego (oznaczonego poziomą kreską). Komórka tabeli zawierająca ten znak

moŜe zostać uznana za pustą. Występuje, więc niejednolite oznakowanie takiej

komórki: moŜe ona nie być reprezentowana przez Ŝaden znak lub przez znak „space”,

co powoduje kolejne zaburzenia w strukturze.

Z powyŜszych powodów zrezygnowałem z zastosowania formatu TXT

w projekcie.

3.3.2 XML

FineReader umoŜliwia zapisanie pliku w formacie XML. Jest to plik zgodny ze

standardem Microsoft Word XML, a dokładniej tylko z Microsoft Office Professional

Edition 2003. Standard ten nie jest popularny, dlatego nie spełniał wymagań

o uniwersalności i przenośności, jakie postawiłem przy wyborze formatu plików.

Dlatego został on odrzucony.

3.3.3 HTML

Jednym z formatów, które w najprostszy sposób są w stanie odtworzyć strukturę,

jaka znajduje się na skanowanych dokumentach jest HTML. Jest to format popularny

i powszechny w zastosowaniach internetowych.

21



Dodatkowym argumentem na zastosowanie tego formatu jest to, Ŝe na kolejnym

etapie przetwarzania mogłem wykorzystać gotowe narzędzia programistyczne

ułatwiające ten proces3.

Aby dodatkowo usprawnić przetwarzanie trzeba zmienić w programie

ustawienia formatów dla HTML tak, jak opisuję poniŜej.

Układ strony naleŜy ustawić na „Remove all formating”, czyli usuwanie

formatowania, gdyŜ nie jest potrzebne, aby w pliku były zapisywane informacje

o rozmiarze czcionki, o tym czy jest ona pogrubiona w danym miejscu, czy posiada

jakieś inne cechy formatowania. Nie potrzebne są takŜe informacje o rozmiarach

poszczególnych komórek tabeli. Takie ustawienia ułatwiają zachowanie oryginalnej

struktury danych bez dodatkowego obciąŜania pliku zbędnymi informacjami.

JeŜeli układ strony będzie ustawiony na „Remove all formating” nie ma

znaczenia, jaki tryb zapisu zostanie wybrany,. Porównywanie zawartości plików przy

pomocy programu Windows Commander nie wykazało Ŝadnych róŜnic pomiędzy

plikami zapisanymi w róŜnych trybach.

W ustawieniach tekstu takŜe nie ma róŜnicy czy zostanie wybrane zachowanie

końca linii, czy nie, gdyŜ pliki stworzone z tymi ustawieniami są takie same.

Kodowanie znaków naleŜy ustawić na ISO Europa centralna (8859-2) poniewaŜ

jest to standardowy sposób kodowania polskich znaków.

Przykładowe okno ustawień formatów dla HTML przedstawiłem na rysunku 5.

3 Więcej na ten temat w rozdziale 4.3.1.

22



Rysunek 5. Przykładowe okno ustawień formatu HTML pliku z rozpoznanym tekstem .

3.4. Szablony bloków

Program rozpoznając obraz wyznacza na nim sektory zwane blokami. KaŜdy

pojedynczy obszar bloku określa pole zawierające znaki, które mają być przerobione.

Program rozpoznaje cztery typy bloków: tekstowy, tabeli, graficzny i kod kreskowy.

Bloki moŜna dowolnie modyfikować ustalając ich obszary, usuwając je, dodając nowe

lub zmieniając typ bloku. W bloku tabeli jest dodatkowo moŜliwość modyfikacji jej

struktury. MoŜna usuwać i tworzyć separatory pionowe i poziome wyznaczające

kolumny i wierszy tabeli.

Stworzenie uniwersalnego algorytmu umoŜliwiającego przekształcanie plików

sekwencyjnie (jednego po drugim, bez uciąŜliwego zmieniania ustawień czy

parametrów pracy programu) wymaga stworzenia jednolitego wzorca. W związku z tym

konieczne jest wprowadzenie jednego schematu obszaru bloków dla kaŜdego obrazu.

23



Opracowany przeze mnie schemat jest jedynie poprawką schematu, jaki

automatycznie tworzy program. FineReader nie tworzy bowiem zawsze takiego samego

schematu, mimo Ŝe kolejne strony mają taką samą strukturę ułoŜenia danych.

W stworzonej przez program strukturze mogą się pojawić takie błędy jak rozpoznanie

części tabeli jako pojedynczych paragrafów.

Zaproponowany przeze mnie schemat zawiera pięć obszarów bloków i powstał

jako naturalne odzwierciedlenie struktury stron zawierających tabelę z danymi4. Trzy

obszary wyznaczają górne pola tekstowe. Pierwszy zawiera numer tablicy (tekst

„TABL. I”), kolejny - jej tytuł (tekst „WYSOKOŚCI DOBOWE OPADÓW w mm”),

a trzeci - nazwę miesiąca z rokiem (np. tekst „STYCZEŃ 1976”). Czwarty obszar to

pole tablicy zawierającej dane o wysokościach opadów. Ostatnim, piątym polem

zaznaczonym na obrazie jest kolejny blok tekstowy zawierający numer strony.

Najbardziej znaczącym polem jest obszar tabeli. Oczywiście liczba separatorów

jest w niej zmienna. Pionowe separatory są uzaleŜnione od liczby dni w miesiącu

a poziome od liczby stacji pomiarowych i częstości występowania symboli zjawisk

atmosferycznych. Separatory pionowe powinny być ustawione w kaŜdej linii, w której

przebiega naturalne rozgraniczenie danych tj. kolejno po kolumnie z numerem

posterunku, nazwą stacji pomiarowej, po kaŜdej kolumnie wyznaczającej dzień

miesiąca i ostatni wydzielający sumę opadów.

Separatory poziome naleŜy ustawić oddzielając kaŜdą stację pomiarową

i informację o dorzeczu. JeŜeli występują symbole zjawiska atmosferycznego naleŜy je

takŜe oddzielić, stwarzając dla nich oddzielny wiersz tabeli. Pozostawienie symbolu

w jednej komórce tabeli razem z danymi liczbowymi moŜe powodować błędne

odczytanie wartości, poniewaŜ program potraktuje symbol i liczbę jako jeden znak

o większej czcionce (tab. 3). Po stworzeniu obszaru tabeli naleŜy jeszcze podzielić

komórki tabeli. Niewykonanie tego kroku powoduje, Ŝe program moŜe łączyć komórki

tak, jakby nie były oddzielne separatorami i znaki zostaną odczytane błędnie, tak jak to

miało miejsce wcześniej.

4 Strukturę tę opisałem w rozdziale 2.

24



Tabela 3. Przykłady błędów spowodowanych nieprawidłowym podziałem szablonu na komórki.

Znaki w obrazie Znaki po przetworzeniu

Z powodu odchyleń w ułoŜeniu obrazu5 mogą wystąpić problemy z poprawnym

ustawieniem separatorów. W rozpatrywanych przeze mnie przypadkach nie było

większych problemów w ustawieniu separatorów pionowych. Linie określające

poszczególne komórki nie nachodziły na liczby. Niestety w przypadku separatorów

poziomych problem był dosyć często spotykany. Występowały problemy z takim

ustawieniem separatora, aby nie nachodził on na dane. Poprawne dopasowanie ułoŜenia

linii po jednej stronie dokumentu powodowało nachodzenie jej na liczbę po drugiej

stronie wiersza.

JeŜeli dokona się rozbicia komórek w tabeli, tak jak pisałem wcześniej, moŜna

przyjąć, Ŝe nachodzenie linii separatora na liczbę do ok. 30% jej wysokości nie

powoduje błędu. Program rozpoznaje ją jako jedną całość i przypisuje do komórki,

w której znajduje się większa część znaku. W przypadku cyfr symetrycznych jak „8”,

„0” czy „3” naleŜy zachować większą ostroŜność.

JeŜeli nie da się ustawić separatora tak, aby oddzielał on znaki opadów

atmosferycznych i liczb określających jego wielkość naleŜy taki separator pominąć.

Przy opracowywaniu algorytmu ekstrakcji danych moŜna bowiem wziąć pod uwagę, Ŝe

symbole opadu i jego wielkość mogą znajdować się w jednej komórce. NaleŜy zwrócić

jednak uwagę, aby symbol dopasować do odpowiedniej liczby, tzn. aby połączyć

5 Zagadnienie szerzej omówiłem w rozdziałach 3.6.3.1 i 3.7.1.1.

25



w jeden wiersz liczby i symbole sobie odpowiadające. Wiersz powinien zawierać wtedy

symbole w górnej swojej części, a liczby na dole, nie odwrotnie.

Wyznaczone bloki powinny być ponumerowane zgodnie z kolejnością, jaką

podałem. Program moŜe wstępnie przypisać inna kolejność, dlatego po modyfikacji

bloków naleŜy je przenumerować. Inna kolejność zmieni strukturę przetworzonego

pliku (kolejność paragrafów będzie inna). JeŜeli chodzi o wyodrębnianie danych

o wysokościach opadów nie ma to znaczenia, bo algorytm pobierający dane wydzieli

wstępnie tabelę, która je zawiera. JeŜeli jednak będziemy chcieli automatycznie

pozyskać informację o miesiącu, z którego dane pochodzą, a takŜe numer strony

kolejność musi być zachowana.

Najlepiej jest stworzyć ogólny zarys szablonu przed pierwszym rozpoznaniem

pliku, aby program nie wydzielił w tabeli bloków tekstowych, co często się zdarza.

Wtedy to struktura zostaje całkowicie zaburzona i jej ręczna modyfikacja jest bardzo

Ŝmudnym zajęciem. Wystarczy wstępnie wyznaczyć pola tekstowe i obszar tabeli,

przed pierwszym rozpoznaniem, Ŝeby temu zapobiec. W tabeli nie trzeba ustawiać

separatorów, zostaną one wprowadzone automatycznie. Później jednak trzeba je będzie

poprawić – niektóre usunąć, część dodać lub przesunąć. Jest to jednak bardziej

opłacalne pod względem czasowym niŜ ręczne ustawianie wszystkich separatorów na

początku.

Niestety nie da się wykorzystać raz utworzonego szablonu do rozpoznawania

wszystkich stron rocznika. PołoŜenie poszczególnych obszarów jest zmienne w obrazie.

Spowodował to czynnik ludzki – nie ma moŜliwości ułoŜenia skanowanego materiału

dokładnie tak samo za kaŜdym razem.

Wziąłem takŜe pod uwagę moŜliwość rozpoznawania obrazów wstępnie

przerobionych w programie graficznym. Ideą było kadrowanie obrazu tak by

wyselekcjonować z niego tylko tabelę z wysokościami opadów. Niestety takŜe wtedy

nie da się stworzyć uniwersalnego szablonu bloków, poniewaŜ liczba separatorów

poziomych jest zmienna ze względu na liczbę stacji pomiarowych oraz występowanie

informacji o dorzeczach i symboli opadów atmosferycznych.

Stworzony szablon moŜna zapisać, aby wykorzystać go przy kolejnym

rozpoznawaniu tej samej strony.

26



3.5. Funkcja douczania

Program OCR w procesie rozpoznawania znaków opiera się na wewnętrznej

bazie wzorców. KaŜdy znak ma swój wzorzec, a nawet wiele wzorców

przedstawiających go w róŜnych rodzajach czcionki. Program FineReader umoŜliwia

dodanie własnych wzorców stworzonych przez uŜytkownika.

Jak podaje podręcznik uŜytkownika programu: „Z trybu douczania warto

skorzystać, gdy:

1. rozpoznawany tekst napisany jest dekoracyjną, nietypową czcionką;

2. rozpoznawany tekst zawiera znaki specjalne (np. symbole matematyczne);

3. trzeba rozpoznać duŜe ilości dokumentów (więcej niŜ setki stron) o niskiej

jakości wydruku.”

Materiał, jaki podlega badaniu spełnia kaŜdy z podanych powyŜej warunków.

Czcionka, jaka została uŜyta do drukowania nie jest typową czcionką z rodzin czcionek

komputerowych. Obrazy stron rocznika zawierają takŜe dodatkowe symbole opadów

atmosferycznych. JeŜeli proces przetwarzania danych z roczników opadowych okaŜe się

być opłacalny liczba obrazów do rozpoznania to „więcej niŜ setki stron” - w jednym

roczniku strony z danymi o wysokościach opadów to ponad 80 stron.

Aby stworzyć własny wzorzec naleŜy rozpoznać obraz lub jego część

z dodatkowo włączoną opcją „douczanie wzorca”. W nowo otwartym oknie program

będzie pokazywał rozpoznawane znaki, które algorytm wskazuje jako trudne do

rozpoznania. MoŜna korygować obszar, jaki program wydzielił z tekstu jako

pojedynczy znak i przypisać mu odpowiednik z klawiatury lub przy uŜyciu tablicy

znaków. Wzorzec moŜna edytować. Tak stworzony wzorzec moŜna uŜywać przy

rozpoznawaniu kolejnych stron.

MoŜliwe są trzy ustawienia rozpoznawania:

1. Bez uŜycia dodatkowych wzorców uŜytkownika

2. Wykorzystanie wzorca uŜytkownika

3. Wykorzystanie wzorca uŜytkownika i wzorców wbudowanych

27



Niestety nie wiadomo jak dokładnie funkcjonuje algorytm doboru wzorca

w programie i kiedy rzeczywiście program uŜyje wzorca uŜytkownika, a kiedy będzie

korzystał z własnej bazy.

3.6. Badania skuteczności rozpoznawania znaków

Rozdział ten opisuje badania, jakie przeprowadziłem w celu opracowania metod

podniesienia skuteczności procesu rozpoznawania, a takŜe wyciągnięcia wniosków

odnośnie funkcjonowania całego systemu przetwarzania.

3.6.1. Wnioski z badań wstępnych

Przed przystąpieniem do właściwej części badań wykonałem szereg

niesklasyfikowanych prób rozpoznań stron rocznika opadowego. W ten sposób

nauczyłem się obsługi programu, ale przede wszystkim wyciągnąłem wnioski na temat

sposobu przeprowadzenia właściwych badań. Dzięki wstępnym testom byłem w stanie

określić jakie czynniki mogą wpływać na skuteczność. Opracowałem koncepcję

klasyfikacji wyników i szczegółową strategię, którą przedstawiam w rozdziale 3.6.2.

Jednym z najwaŜniejszych wniosków, jakie wyciągnąłem po badaniach

wstępnych jest konieczność rozdzielenie procesu pozyskiwania danych o opadach na

dwa etapy. Pojedyncza dana opadowa zawiera pełną informację wtedy, gdy znany jest

typ opadu i jego wysokość. Obie te dane podawane są na stronach rocznika

zawierających tablicę „Wysokości dobowe opadów”. JuŜ pierwsze testy wykazały, Ŝe

skuteczność rozpoznawania informacji o typie opadu jest znacznie mniejsza niŜ

pozostałych danych. Wynika to z faktu, iŜ są to symbole graficzne, a nie znaki

alfanumeryczne6. Zastosowanie funkcji douczania, która pozwoliła na zdefiniowanie

własnych wzorców znaków znacząco wpłynęło na wyniki rozpoznawania tych symboli.

Odmienne wynik zastosowania tej funkcji obserwowałem dla pozostałych danych.

Dlatego teŜ doszedłem do wniosku, Ŝe odseparowanie danych liczbowych i danych

6 Symbole typów opadów atmosferycznych przedstawiłem w rozdziale 2.

28



przedstawionych za pomocą symboli graficznych jest konieczne. Oddzielnie moŜna

pozyskać dane o wysokości opadu a oddzielnie o jego typie. Scalenie tych danych moŜe

zostać dokonane jako końcowy etap procesu.

W badaniach opisanych w kolejnych rozdziałach skupiłem się na części

dotyczącej danych liczbowych.

3.6.2. Strategia badań

Celem badań było sprawdzenie jak jakość pliku wejściowego i zastosowanie

dodatkowej funkcji douczania programu wpływa na skuteczność procesu

rozpoznawania. Poszukiwałem takiej konfiguracji, która dawałaby najlepszy wynik.

Dodatkowo notowałem inne luźne spostrzeŜenia, które mogłyby mieć znaczenie przy

opracowaniu algorytmu do następnego etapu przetwarzania.

Na pytanie o dostępność wyników jakichkolwiek testów skuteczności

rozpoznawania skierowane do działu wsparcia technicznego producenta otrzymałem

wymijającą odpowiedź i jedynie małą wskazówkę dotyczącą rozdzielczości

skanowania. Poszukiwania takich materiałów w oparciu o inne źródła doprowadziły

mnie jedynie do testów porównawczych programów róŜnych producentów. Testy te nie

przedstawiały szczegółowo wyników badań, stanowiły jedynie konfrontację wyników

procesu rozpoznawania z zastosowaniem róŜnych programów, a takŜe subiektywne

oceny testerów co do ergonomii i funkcjonalności programów. Testy te nie zawierały

informacji, jakich poszukiwałem.

W swoich badaniach wyodrębniłem cztery czynniki, jakie mogłyby wpływać na

efektywność procesu rozpoznawania:

• rozdzielczość obrazów,

• ułoŜenie obrazu w pliku,

• jasność i kontrast,

• zastosowanie wzorca znaków stworzonego przez uŜytkownika.

Te cztery czynniki będę dalej nazywał czynnikami wstępnymi.

29



Poszczególne strony rocznika zawierające wysokości opadów, mimo iŜ są

drukowane tą samą czcionka i są usystematyzowane w ten sam sposób róŜnią się pod

względem złoŜoności danych i jakości druku. Na złoŜoność danych wpływa ilość liczb

przedstawiających wartość opadu, a takŜe zawartość dodatkowych symboli opadów

atmosferycznych. W rocznikach moŜna znaleźć strony, które przedstawiają dane

z miesięcy zimowych z wieloma opadami w postaci śniegu i wtedy strona zawiera duŜo

danych liczbowych i symboli, ale moŜna teŜ znaleźć strony z niewielką ilością liczb.

Jakość druku na poszczególnych stronach takŜe jest róŜna. Niekiedy tekst i liczby są

wydrukowane wyraźnie, ale zdarzają się teŜ strony gdzie druk jest mało czytelny,

a oprócz znaków z danymi pojawia się teŜ wiele „brudów” takich jak małe kropki

atramentu, prześwitujący z drugiej strony tekst, czy inne plamki (przykładem jest strona

77 z badanego rocznika).

Z powyŜszych powodów do badań testowych nierozsądnym byłoby wybrać

kilka stron do siebie podobnych pod względem złoŜoności danych i jakości druku.

Wnioski, jakie mógłbym wyciągnąć dla tego materiału byłyby nie słuszne w przypadku

innych stron. Z tego względu postanowiłem wybrać cztery odmienne od siebie strony.

JeŜeli uda się wyciągnąć wnioski i jednoznacznie określić wpływ czynników wstępnych

dla tej grupy moŜna przyjąć, Ŝe będą one słuszne dla innych stron roczników.

Wybrane strony z rocznika 1976, na których zostały przeprowadzone badania to:

• strona 53 – zawiera duŜą ilość danych oraz duŜą liczbę symboli graficznych

(szczególnie śniegu);

• strona 128 – czytelna, „klasyczna” strona rocznika;

• strona 97 – zawiera symbole burzy i burzy odległej;

• strona 77 – jedna z najmniej czytelnych stron w roczniku.

KaŜdą ze stron badałem selekcjonując w niej 12 wierszy. Liczba ta jest

wystarczająca na wyciągnięcie wniosków. Większa liczba badanych wierszy wymagała

duŜych nakładów czasowych i była niewspółmierna z uzyskanymi informacjami, jakie

moŜna było na podstawie badania wyciągać. Ograniczając się do tej liczby

sprawdzanych wierszy mogłem wykonać większą liczbę prób. Wiersze do testowania

wybierałem tak, aby były one równomiernie rozłoŜone na stronie tworząc jej

reprezentatywną próbkę.

30



Wszystkie sprawdzane przeze mnie błędy i parametry miały określić wpływ

czynników wstępnych na skuteczność procesu rozpoznawania. SłuŜyły one takŜe

opracowaniu szczegółowych strategii postępowania dla charakterystycznych błędów

(które będzie moŜna wdroŜyć w algorytmie wyodrębniającym dane z tekstu) oraz

ukazywały wpływ czynników wstępnych na pracę programu.

Badaniu podlegały na określeniu:

• liczby błędnie rozpoznanych znaków,

• liczby błędów zaznaczonych i niezaznaczonych przez program.

Aby określić wpływ danego czynnika na skuteczność rozpoznawania

porównywałem kolejne wersje danej strony ze względu na liczbę błędnie rozpoznanych

znaków. Wersje strony są obrazami rastrowymi przedstawiający pojedynczą stronę

rocznika w róŜnych rozdzielczościach i z róŜnymi parametrami jasności i kontrastu.

Błędy rozpoznawania znaków

Jeden błędnie rozpoznany znak oznacza błąd w jednej danej tj. niepoprawną

nazwę stacji, wartość opadu, sumę opadów w miesiącu lub numer stacji. Nie

wprowadzałem dodatkowego podziału błędu ze względu na jego złoŜoność. Bez róŜnicy

czy w nazwie była zmieniona jedna litera czy było ich więcej jest to liczone jako jeden

błąd. Tak samo z danymi liczbowymi. Bez względu na to czy liczba była rozpoznana

jako w ogóle jej nie odpowiadające znaki literowe czy tylko róŜniła się od właściwej

jednym znakiem liczone jest to jako jeden błąd. Dokonałem takiej klasyfikacji,

poniewaŜ bez względu na złoŜoność błędu, z powodu jego wystąpienia tracona jest

jedna dana. Jako błąd nie była uznawana zamiana przecinka na kropkę w wartości

liczbowej, gdyŜ jest to problem łatwy do rozwiązania w algorytmie.

W części z danymi o wysokościach opadów brak zjawiska oznaczany jest

znakiem „-”. Po wykonaniu kilku wstępnych badań testowych zauwaŜyłem, Ŝe jest on

bardzo często rozpoznawany jako inny znak podobny do kreski lub kropki. Przyjąłem,

więc Ŝe kaŜde rozpoznanie tego znaku, o ile nie zawiera na początku cyfry jest

traktowane jako poprawne. Takie załoŜenie łatwo będzie wziąć od uwagę przy

31



tworzeniu algorytmu do dalszego przetwarzania. Wykluczy to jeden z najczęściej

występujących błędów w wynikach rozpoznania

Dodatkowo błędy klasyfikowałem ze względu na miejsce ich wystąpienia:

• numer posterunku,

• nazwa posterunku,

• wartość wysokości opadu,

• suma miesięczna.

W dalszej części pracy podając wyniki badań będę uŜywał sformułowania

„wszystkie błędy”, które oznacza ogół błędów, jakie wystąpiły przy pojedynczej próbie

rozpoznania. Jest to więc zsumowana liczba błędów w rozpoznaniu numerów

posterunków, nazw posterunków, wartości wysokości opadu i sumy miesięcznej.

Błędy zaznaczone i niezaznaczone

FineReader posiada funkcję, która w wynikowym tekście zaznacza znaki,

z którymi program miał problem w procesie rozpoznawania. Funkcja tam ma ułatwić

późniejszą ręczną poprawę zawartości pliku wyjściowego. Dla uŜytkownika stanowi

ona sugestię, które części w rozpoznanym dokumencie mogą zawierać błędy. Chcąc

sprawdzić efektywność tej funkcji programu i określić na ile moŜe być ona przydatna

w przypadku ręcznej obróbki wyniku rozpoznania kaŜdy błąd klasyfikowałem według

tego czy został on zaznaczony czy nie.

Sposób prezentacji wyników

Na kolejnych stronach zostaną przedstawione wyniki dotyczące aktualnie

omawianego czynnika. Oprócz liczby wszystkich błędów będę dodatkowo podawał,

liczbę błędów zawartych w najbardziej znaczącej dla mojego opracowania części, czyli

wysokościach opadów.

Dodatkowe wykresy słuŜą zobrazowaniu wyników.

32



Błąd względny

Chcąc wykorzystać uniwersalną miarę wpływu czynników wstępnych na wyniki

rozpoznawania niezaleŜnie od strony, jaka podlegała badaniu wyliczałem dodatkowo

błąd względny skuteczności rozpoznawania. Błąd względny jest wyraŜonym

w promilach ilorazem błędnie rozpoznanych znaków wśród danych o wysokości opadu

i wszystkich danych liczbowych zawartych w części z wysokościami opadów na danej

stronie. MoŜna to zapisać wzorem:

[ ][ ] [ ] ‰1000

__

____ ⋅

−−=

opadowychdanychliczba

opadowwsrodbledowliczbawzglednyBlad

Wartości błędu względnego wyraŜone w promilach są podane z zaokrągleniem

do części całkowitej.

Podanie tej wartości ma słuŜyć określeniu, jaki promil liczbowych danych

opadowych został błędnie rozpoznany. Błąd względny uwzględnia „złoŜoność” strony

pod względem liczby zawartych na niej danych, a dokładniej liczby danych w części

z wysokościami opadów innych niŜ brak zjawiska.

3.6.3. Jakość obrazów

Ta część badań miała wykazać czy i jak jakość pliku wejściowego z obrazem na

wpływ na skuteczność rozpoznawania. Zamierzeniem było opracowanie metody jak

najlepszego przygotowania obrazu zanim zostanie on poddany procesowi

rozpoznawania w programie FineReader. Odrzuciłem takie metody graficznej obróbki,

które byłyby niewspółmierne z zyskiem, jaki moŜna było po ich zastosowaniu uzyskać.

Nie brałem, więc pod uwagę przekształcania pojedynczych znaków a jedynie

całościową obróbkę pliku jako jednolitego materiału.

Skupiłem się na trzech, najbardziej znaczących, według mnie problemach:

• niepoprawne ułoŜenie skanowanego materiału w obrazie,

• rozdzielczość,

• jasność i kontrast.

33



Do tej części pracy wykorzystałem program graficzny Gimp w wersji 2.4.5. Jest

to popularne narzędzie do przetwarzania grafiki rastowej rozprowadzane na

Powszechnej Licencji Publicznej GNU. Na poziomie funkcjonalności, jaką chciałem

wykorzystać programowanie to z łatwością dorównuje takim komercyjnym projektom

jak Paint Shop Pro.

3.6.3.1. Obrócone obrazy

Jednym z głównych zadań, jakie załoŜyłem sobie do rozwiązania na wstępie,

było rozwiązanie problemu niepoprawnego ułoŜenia skanowanych obrazów. Czynnik

ludzki spowodował, Ŝe wiele spośród obrazów zawierało strony obrócone o małe kąty

(od dziesiątych części stopnia do kilku stopni). MoŜna przypuszczać, Ŝe wynik

rozpoznawania był w związku z tym gorszy, gdyŜ znaki nie były ułoŜone w idealnym

pionie, co powodowało ich zniekształcenie.

Wstępnie załoŜyłem wykonanie badań według wcześniej przedstawionej

strategii. Chciałem sprawdzić zaleŜność liczby błędów od kąta, pod jakim umieszczony

jest obraz w pliku. Bieg wydarzeń, jaki przedstawiam poniŜej pokierował jednak moje

badania w nieco inną stronę.

W pierwszym rozpoznawanym przeze mnie pliku program otworzył obraz obrócony

o około 0,4 stopnia w prawo. Spowodowało to pojedyncze błędy, przy odczytaniu

znaku z komórki, przez którą przechodziła linia pionowa oddzielająca główne kolumny

tabeli wydrukowanej na stronie rocznika. Kreska ta została odczytana jako znak „I”, „1”

lub powodowała inny błąd. Niepoprawne ułoŜenie danych w poziomie i pionie

uniemoŜliwiało teŜ precyzyjne rozmieszczenie separatorów w szablonie bloków7.

7 O tworzeniu szablonów i problemach tym związanym napisałem wcześniej (rozdział 3.4).

34



Tabela 4. Przykłady błędów rozpoznania wynikających z nieprawidłowej rotacji obrazu.

Znaki w obrazie Znaki po przetworzeniu

Zdecydowałem się obrócić plik w programie graficznym, aby połoŜenie wierszy

i kolumn było jak najbardziej precyzyjne, czyli Ŝeby wiersze znajdowały się w linii

poziomej. Ponowne otwarcie pliku w programie nie spowodowało znaczących zmian

w ułoŜeniu obrazu. Spróbowałem kolejny raz z nieco innymi kątem ułoŜenia obrazu –

wynik był ten sam. Próby z innymi obróconymi plikami dawały podobne wyniki.

Okazało się, Ŝe program otwierając plik automatycznie stara się ustalić jego

orientację. Nie określa jedynie czy obraz jest ułoŜony w pionie czy poziomie, ale stara

się dokładnie ustalić jego pozycję. FineReader koryguje ułoŜenie obrazów odchylonych

nawet o 2 stopnie. Niestety wynik jego działania nie jest dokładny. Obrazy są źle

zorientowane o około 0,3 stopnia, co powoduje błędy, o których juŜ wspomniałem.

Największe odchylenie, jakie znalazłem w skanowanych materiałach było rzędu

1,3 stopnia i program automatycznie je poprawił, tak, Ŝe po otworzeniu obrazu wynosiło

około 0,2-0,3 stopnia.

3.6.3.2. Rozdzielczość

Rozdzielczość jest jednym z podstawowych parametrów wpływających na

jakość obrazu rastrowego, a taki właśnie obraz moŜemy pozyskać skanując materiały

drukowane. Najczęściej uŜywaną miarą rozdzielczości jest dpi (ang. dots per inch)

określający ile plamek przypada na cal długości.

W badaniach zdecydowałem się przetestować wpływ trzech róŜnych

rozdzielczości na proces rozpoznawania: 300dpi, 600dpi, 1200dpi. Są to jedne

z najczęściej spotykanych rozdzielczości, w jakich występują komputerowe obrazy

35



rastrowe. Pliki z takimi parametrami są dostępne do pozyskania bezpośrednio

w procesie skanowania, zaleŜnie od ustawień skanera.

Według podręcznika uŜytkownika dostarczonego wraz z programem FineReader

rozdzielczość, jakiej naleŜy uŜyć do skanowania dokumentów o rozmiarze czcionki 10

lub więcej to 300 dpi, natomiast dla tekstów napisanych drobniejszą czcionką (9

punktów lub mniej) odpowiednią rozdzielczością jest 400-600 dpi. Rozmiar czcionki na

stronach rocznika zawierających dane opadowe jest wielkości około 5–6 punktów.

Chcąc, aby testy dały jak najbardziej miarodajne wyniki zdecydowałem się

przeprowadzić je na trzech róŜnych stronach rocznika. JuŜ pierwsze próby

rozpoznawania z rozdzielczością 300dpi i 1200dpi wykazały, Ŝe program nie toleruje

takich rozdzielczości. Przy rozpoznawaniu z rozdzielczością 1200dpi wywoływane było

ostrzeŜenie „Zmniejsz rozdzielczość skanowania do 600dpi lub mniej”, a przy 300dpi

„Zwi ększ rozdzielczość skanowania, aby poprawić dokładność rozpoznawania małego

tekstu”. Proces rozpoznawania był mimo to kontynuowany.

Chcąc poznać mechanizm, jaki w przypadku plików o tych rozdzielczościach

stosuje program skontaktowałem się ponownie z producentem. MoŜliwe, bowiem były

dwa schematy: program zmienia wewnętrznie rozdzielczość pliku i wtedy wykonuje

rozpoznanie, albo tylko generuje ostrzeŜenie, a rozpoznawania dokonuje z pliku, jaki

został dostarczony. Pan Krzysztof Gomoliszewski, przedstawiciel firmy Abbyy

w Polsce, udzielił mi niewiele wyjaśniającej odpowiedzi: „[…] zwiększanie

rozdzielczości powyŜej 600dpi nie daje juŜ podniesienia jakości przetwarzania obrazów

na tekst edytowalny”. Postanowiłem przeprowadzić własne, niezaleŜne testy, których

wyniki przedstawiam poniŜej.

36



W tabelach zgromadziłem wyniki procesu rozpoznania według trzech kryteriów:

liczby wszystkich błędów, liczby błędów w danych opadowych i wartości błędu

względnego.

Tabela 5. Liczba wszystkich błędów w rozpoznanych stronach zaleŜnie od rozdzielczości pliku z obrazem.

Rozdzielczo ść Numer

strony 300 600 1200

53 28 19 50

97 29 9 11

128 30 24 22

Tabela 6. Liczba błędów w danych opadowych rozpoznanych stron zaleŜnie od rozdzielczości pliku z obrazem.


strony 300 600 1200

53 23 12 44

97 24 7 10

128 17 18 17

Tabela 7. Wartość błędu względnego rozpoznania stron zaleŜnie od rozdzielczości pliku z obrazem.


strony 300 600 1200

53 78 41 150

97 156 48 59

128 112 90 82

37



Dwa poniŜsze wykresy (rys. 6 i rys. 7) obrazują zmiany skuteczności

rozpoznawania zaleŜnie od rozdzielczości dla trzech przebadanych stron. Na pierwszym

z rysunków miarą zmiany jest liczba wszystkich błędów, a na drugim błąd względny.

300600

1200strona 53

strona 97

strona 128

2224

30

119

29

50

19

28

0

5

10

15

20

25

30

35

40

45

50

Licz

ba b

łędó

wRozdzielczo ść [dpi]

Rysunek 6. Liczba wszystkich błędów rozpoznawania w zaleŜności od rozpoznawanej strony i rozdzielczości obrazu.

38



300600

1200strona 53

strona 97

strona 128

8290

112

59

48

156150

41

78

0

20

40

60

80

100

120

140

160

Błą

d w

zglę

dny

[‰]

Rozdzielczo ść [dpi]

Rysunek 7. Wartość błędu względnego rozpoznania w zaleŜności od rozpoznawanej strony i rozdzielczości obrazu.

3.6.3.3. Jasność i kontrast

Podczas wstępnej, graficznej obróbki plików skupiłem się na zmianie jasności

i kontrastu, poniewaŜ wpływają one w sposób znaczący na czytelność znaków na

obrazie. Te własności obrazu są dodatkowo łatwe do zmiany, nie pochłaniają duŜo

czasu, więc są moŜliwe do wykonania na większej grupie plików, co jest istotne

w całym procesie. O ile udałoby się stworzyć jednolity zestaw zadań do wykonania na

kaŜdym pojedynczym pliku, moŜliwe byłoby zastosowanie ich automatyzacji.

Tak jak podałem na wstępie rozdziału 3.6.3 korekcji ustawień jasności

i kontrastu dokonywałem przy uŜyciu programu Gimp. Obraz wejściowy moŜna było

zmieniać w skali od -127 do 127 jednostek zarówno dla jasności jak i dla kontrastu. Są

to wewnętrzne jednostki programu, jednak uznałem za stosowne ich podawanie gdyŜ

prezentują skalę zmian, jakie wykonywałem na poszczególnych obrazach. Wartości

podane w tych jednostkach moŜna odnosić do siebie porównując próbki.

39



Bardziej uniwersalnym sposobem na określenie jasności i kontrastu danego

obrazu jest histogram. Jest to graficzny sposób przedstawiania rozkładu jasności obrazu.

Dla obrazów rastrowych z 8-bitowym kodowaniem jednego kanału, kaŜdy piksel ma

jasność określoną w skali od 0 (piksel czarny) do 255 (piksel biały). Ta skala jasności

znajduje się na poziomej osi histogramu (rys. 8). Na osi pionowej zaznaczona jest liczba

pikseli odpowiadająca danej jasności. Rysunek 8 przedstawia przykładowy histogram

dla obrazu z przewaŜającą liczbą ciemnych pikseli.

Rysunek 8. Przykładowy histogram.

Dodatkowymi parametrami opisującymi rozkład cechy, jaką jest jasność pikseli

w obrazie są średnia, odchylenie standardowe i mediana. Średnia jest zwykłą średnią

arytmetyczną wartości jasności pikseli, określonej w przedstawionej wcześniej skali.

Mediana, zwana takŜe wartością środkową, to wartość jasności w szeregu

uporządkowanym powyŜej i poniŜej której liczba pikseli jest taka sama. Odchylenie

standardowe, ogólnie rzecz ujmując, mówi jak bardzo wartości jasności pikseli

w obrazie odbiegają od średniej. Im mniejsza wartość odchylenia tym wartości jasności

są bardziej zbliŜone do średniej. Dokładnie odchylenie standardowe wyliczane jest ze

wzoru:

21

2

µσ −=∑=

=

N

xNi

ii

, gdzie:

• σ – odchylenie standardowe,

• xi – kolejne wartości jasności piksela,

• µ – średnia arytmetyczna.

• N – liczba wszystkich pikseli.

40



Odchylenie standardowe jest więc średnią kwadratową z róŜnic pomiędzy

wartościami jasności a ich średnią arytmetyczną.

Wartości mediany i średniej rozkładu jasności w kaŜdym z plików bazowych

(wersje 0 próbek, obrazy prosto ze skanera) były bardzo wysokie. Mediana dla kaŜdego

z tych obrazów równa była wartości maksymalnej rozkładu: 255. Histogramy

wskazywały zdecydowaną przewagę najjaśniejszych pikseli w obrazie. Dlatego teŜ

zdecydowałem, Ŝe korekcji jasności będę dokonywał tylko w jednym kierunku tj. będę

zmniejszał jasność, aby średnia i mediana uzyskiwały mniejszą wartość.

Kontrast plików bazowych nie był natomiast wysoki. Chcąc poprawić ostrość

i wyrazistość znaków na obrazie zwiększałem jego wartość. RównieŜ ta część badań

przebiegała tylko w jednym kierunku – nie testowałem wpływu, jaki na skuteczność

rozpoznawania moŜe wywrzeć zmniejszenie kontrastu w obrazie.

W tabelach 8–11 prezentuję wyniki badań dla kaŜdej ze stron. Próbka

oznaczona jest numerem strony i wersją (strona-wersja). Kolejna wersja to ten sam

obraz poddany róŜnym obróbkom w programie graficznym. Próbka oznaczona

numerem 0 to próbka wejściowa, obraz otrzymany prosto ze skanera. W tabeli znajduje

się histogram odpowiadający danej próbce; dane statystyczne opisujące rozkład

jasności; ustawienia, jakie zastosowałem w programie Gimp, aby uzyskać daną próbkę

oraz liczba błędów w procesie rozpoznania.

41

Tabela 8. Wyniki rozpoznania kolejnych próbek strony 53 w zaleŜności od jasności i kontrastu obrazu, część I.

Dane statystyczne Ustawienia w

Gimp'ie Błędy

Próbka Histogram

Średnia Odchylenie

standardowe Mediana Jasno ść Kontrast Wszystkie

W danych

opadowych

Błąd

względny

53-0

245,49 29,38 255 0 0 37 32 109

53-1

242,98 39,02 255 -50 40 48 39 133

53-2

244,92 32,16 255 -20 15 56 47 160

42

Tabela 8. Wyniki rozpoznania kolejnych próbek strony 53 w zaleŜności od jasności i kontrastu obrazu, część II.


Gimp'ie Błędy

Próbka Histogram

Średnia Odchylenie


W danych

opadowych

Błąd

względny

53-3

201,91 25,13 210 -50 5 55 48 164

53-4

202,15 24,2 210 -45 0 27 20 68

43

Tabela 9. Wyniki rozpoznania kolejnych próbek strony 77 w zaleŜności od jasności i kontrastu obrazu.


Gimp'ie Błędy

Próbka Histogram

Średnia Odchylenie


W danych

opadowych

Błąd

względny

77-0

251,63 17,14 255 0 0 98 89 566

77-1

230,39 18,22 234 -45 20 72 69 416

44

Tabela 10. Wyniki rozpoznania kolejnych próbek strony 97 w zaleŜności od jasności i kontrastu obrazu, część I.


Gimp'ie Błędy

Próbka Histogram

Średnia Odchylenie


W danych

opadowych

Błąd

względny

97-0

248,69 25,67 255 0 0 34 32 172

97-1

220,73 25,5 227 -45 15 13 12 65

97-2

249,52 25,58 255 0 15 39 36 194

45

Tabela 10. Wyniki rozpoznania kolejnych próbek strony 97 w zaleŜności od jasności i kontrastu obrazu, część II.


Gimp'ie Błędy

Próbka Histogram

Średnia Odchylenie


W danych

opadowych

Błąd

względny

97-3

204,79 21,15 210 -45 0 9 8 43

97-4

229,17 23,68 235 -20 0 11 10 54

97-5

185,41 19,09 190 -65 0 17 16 86

46

Tabela 11. Wyniki rozpoznania kolejnych próbek strony 128 w zaleŜności od jasności i kontrastu obrazu.


Gimp'ie Błędy

Próbka Histogram

Średnia Odchylenie


W danych

opadowych

Błąd

względny

128-0

247,09 29,91 255 0 0 29 21 79

128-1

247,57 32,14 255 -10 30 22 18 67

128-2

218,46 28,43 226 -40 10 24 17 64

47


Półautomatyczne przetwarzanie danych

Do wizualnego przedstawienia wyników badań uŜyłem nietypowego wykresu

bąbelkowego. Ten typ wykresu wydaje się jednak najlepiej prezentować rezultaty

testów. Powierzchnia „bąbla” reprezentuje wartość danej. Na rysunkach 9–16 wyznacza

on liczbę wszystkich błędów procesu rozpoznawania danej próbki.

PoniŜej znajduje się pierwsza grupa wykresów (rys. 9–12). Prezentuje ona

zaleŜność liczby wszystkich błędów od średniej i odchylenia standardowego rozkładu

jasności. Liczby podane na wykresie to liczba wszystkich błędów jakie wystąpiły przy

rozpoznawaniu danej próbki. Dodatkowo w nawiasach podane są wartości mediany

odpowiadające danej próbce. Zastosowałem jednakowe wartości maksimum i minimum

skali dla danej grupy wykresów, aby ułatwić ich porównywanie. Jeden wykres

przedstawia badanie wykonane dla jednej strony.

Wersjastrony

53

37 (255)

48 (255)

56 (255)

55 (210)

27 (210)

10

15

20

25

30

35

40

45

180 190 200 210 220 230 240 250 260

Średnia

Odc

hyle

nie

stan

dard

owe

0

1

2

3

4

Rysunek 9. ZaleŜności liczby wszystkich błędów rozpoznania od średniej i odchylenia standardowego rozkładu jasności w próbkach strony 53

48



Wersjastrony

77

98 (255)72 (234)

10

15

20

25

30

35

40

45

180 190 200 210 220 230 240 250 260

Średnia

Odc

hyle

nie

stan

dard

owe

0

1

Rysunek 10. ZaleŜności liczby wszystkich błędów rozpoznania od średniej i odchylenia standardowego rozkładu jasności w próbkach strony 77.

Wersjastrony

97

34 (255)13 (227) 39 (255)

9 (210)11 (235)

17 (190)

10

1520

25

30

3540

45

180 190 200 210 220 230 240 250 260

Średnia

Odc

hyle

nie

stan

dard

owe

0

1

2

3

4

5


49



Wersjastrony128

29 (255)

22 (255)24 (226)

10

15

20

25

30

35

40

45

180 190 200 210 220 230 240 250 260

Średnia

Odc

hyle

nie

stan

dard

owe

0

1

2


50



Rysunki 13–16 to druga grupa wykresów. Prezentuje ona liczbę wszystkich

błędów zaleŜnie od ustawień, jakie zastosowałem w programie Gimp aby uzyskać daną

próbkę. Tak jak poprzednio liczby podane na wykresie to liczba wszystkich błędów dla

danej próbki. Jeden wykres przedstawia badanie wykonane dla jednej strony.

Wersjastrony

53

37

48 56

5527

-10

0

10

20

30

40

50

-70 -50 -30 -10 10

Ustawienia jasno ści

Ust

awie

nia

kont

rast

u

0

1

2

3

4

Rysunek 13. ZaleŜności liczby wszystkich błędów rozpoznania od ustawień jasności i kontrastu zastosowanych do otrzymania próbek strony 53.

51



Wersjastrony

77

98

72

-10

0

10

20

30

40

50

-70 -50 -30 -10 10


Ust

awie

nia

kont

rast

u

0

1


Wersjastrony

97

34

13 39

9 1117

-10

0

10

20

30

40

50

-70 -50 -30 -10 10


Ust

awie

nia

kont

rast

u 0

1

2

3

4

5


52



Wersjastrony128

29

22

24

-10

0

10

20

30

40

50

-70 -50 -30 -10 10


Ust

awie

nia

kont

rast

u

0

1

2


3.6.4. Douczanie

Chcąc sprawdzić moŜliwość wykorzystania funkcji douczania do polepszenia

skuteczności rozpoznawania stworzyłem własny wzorzec. Procesu douczania w wyniku

którego tworzony jest wzorzec uŜytkownika dokonałem na dwóch stronach: 53 i 106.

Wybrałem je jako dwie reprezentatywne strony rocznika. Strona 56 zawiera duŜą ilość

danych i wiele symboli opadów atmosferycznych charakterystycznych dla miesięcy

zimowych (szczególnie śniegu). Strona 106 zawiera natomiast wiele symboli burzy

i burzy odległej i jest średnio złoŜona pod względem zawartości danych.

Strony 53 i 106 skorygowałem delikatnie zmniejszając ich jasność zgodnie

z wnioskami z badań nad wpływem tego czynnika na skuteczność rozpoznawania.

Chciałem bowiem poddać badaniu nie tylko obrazy stron pozyskane prosto ze skanera,

ale takŜe te po obróbce graficznej. Stworzony wzorzec musiał być jak najbardziej

uniwersalny.

Próbki podlegające badaniu umieszczone w tabelach 12–14 i na wykresach 17–

18 są oznaczone numerem strony i wersją z badania nad jasnością i kontrastem (strona-

wersja). Tabele przedstawiają wyniki zastosowania trzech róŜnych zestawów wzorców

53



według trzech kryteriów: liczby wszystkich błędów, liczby błędów w danych

opadowych i wartości błędu względnego.

Tabela 12. Liczba wszystkich błędów rozpoznania zaleŜnie od zastosowanych wzorców znaków.

Zastosowane wzorce

Próbka Programowy

UŜytkownika i

programowy

Tylko

uŜytkownika

53-0 37 45 53

53-3 55 28 19

97-1 13 14 11

128-2 24 25 104

77-1 69 76 70

Tabela 13. Liczba błędów rozpoznania danych opadowych zaleŜnie od zastosowanych wzorców znaków.

Zastosowane wzorce

Próbka Programowy

UŜytkownika i

programowy

Tylko

uŜytkownika

53-0 32 40 43

53-3 48 24 6

97-1 12 12 9

128-2 17 17 84

77-1 72 85 89

54



Tabela 14. Wartość błędu względnego rozpoznania zaleŜnie od zastosowanych wzorców znaków.

Zastosowane wzorce

Próbka Programowy

UŜytkownika i

programowy

Tylko

uŜytkownika

53-0 109 137 147

53-3 164 82 41

97-1 65 65 48

128-2 64 64 315

77-1 416 491 514

Rysunki 17-18 przestawiają wyniki rozpoznawania z zastosowaniem trzech

róŜnych zestawów wzorców według dwóch kryteriów: liczby wszystkich błędów

rozpoznania i wartości błędu względnego rozpoznania.

Próbka

3745

5355

28

1913 14 11

24 25

104

6976

70

0

20

40

60

80

100

120

wzorzecprogramowy

wzorzecuŜytkownika iprogramowy

wzorzecuŜytkownika

Licz

ba b

łędó

w

53-0

53-3

97-1

128-2

77-1

Rysunek 17. Liczba wszystkich błędów rozpoznania próbek w zaleŜności od zastosowanych wzorców znaków.

55



Próbka

109137 147164

8241

65 65 4864 64

315

416

491514

0

100

200

300

400

500

600

wzorzecprogramowy

wzorzecuŜytkownika iprogramowy

wzorzecuŜytkownika

Błą

d w

zglę

dny

53-0

53-3

97-1

128-2

77-1

Rysunek 18. Wartość błędu względnego rozpoznania próbek w zaleŜności od zastosowanych wzorców znaków.

Kolejne dwie tabele zostały stworzone na podstawie danych przedstawionych

powyŜej w celu bardziej czytelnej prezentacji wyników.

Klasyfikacja w tabeli 15 przedstawia została według schematu ocen:

1 – zestaw wzorców, który wywołał najmniej błędów dla danej próbki.

3 – zestaw wzorców, który wywołał najwięcej błędów dla danej próbki.

2 – zestaw wzorców ze „średnią” liczbą błędów dla danej próbki.

Brane były pod uwagę wszystkie błędy procesu rozpoznania dla danej próbki.

56



Tabela 15. Klasyfikacja rozpoznań próbek przy zastosowaniu róŜnych zestawów wzorców według systemu ocen.

Próbka Zastosowane wzorce

53-0 53-3 97-1 128-2 77-1 Suma

Wzorzec programowy 1 3 2 1 1 8

Wzorzec u Ŝytkownika i

programowy 2 2 3 2 3 12

Wzorzec u Ŝytkownika 3 1 1 3 2 10

Tabela 16 przedstawia zsumowaną liczbę wszystkich błędów rozpoznania dla

wszystkich próbek zaleŜnie od zastosowanego zestawu wzorców.

Tabela 16. Suma wszystkich błędów rozpoznania prób wykonanych na wszystkich próbkach zaleŜnie od zastosowanych wzorców.

Zastosowane wzorce Suma wszystkich

błędów

Wzorzec programowy 198

Wzorzec u Ŝytkownika i

programowy 188

Wzorzec u Ŝytkownika 257

3.6.5. Zaznaczanie niepewnych znaków

Program FineReader posiada dodatkową funkcję zaznaczającą znaki, które

najtrudniej było rozpoznać. MoŜliwe jest ustawienie trzech poziomów wyświetlania

niepewnych znaków:

1. Brak

2. Standardowy

3. Gruntowny

57



Funkcja ta z załoŜenia ma pomagać uŜytkownikowi w ręcznej korekcji wyniku

rozpoznawania. Kiedy program rozpozna obraz istnieje moŜliwość porównania wyniku

rozpoznania, który znajduje się w jednym oknie, z obrazem znajdującym się w oknie

sąsiednim. Zaznaczone znaki mają sugerować miejsce potencjalnego błędu.

Podczas wykonywania testów do poprzednich badań dodatkowo

selekcjonowałem błędy, ze względu na to czy zostały one zaznaczone przez program

czy nie. Wyniki tego zestawienia miały pokazać na ile uŜyteczna jest funkcja

zaznaczania. Chciałem określić czy podczas ręcznej korekcji wyniku rozpoznania

uŜytkownik poszukując błędów moŜe się sugerować tym, co wskazał mu program.

Wszystkie badania zostały wykonane przy opcji zaznaczania niepewnych

znaków włączonej na poziomie standardowym.

W tabeli 17 i na rysunkach 19–20 przedstawiam wyniki testów dla danych

opadowych oraz danych o nazwach posterunków. Wybrałem te dwie grupy, poniewaŜ

jedna reprezentuje znaki liczbowe a druga znaki tekstowe.

58



Tabela 17. Liczba zaznaczonych i niezaznaczonych błędów w wynikach rozpoznania wszystkich próbek.

Błędy

w danych opadowych

Błędy

w nazwach stacji Próbka Zastosowane

wzorce Zaznaczone Niezaznaczone Zaznaczone Niezaznaczone

53-0 programowy 24 8 4 0





53-0 uŜytkownika i

programowy 20 20 4 0

53-3 uŜytkownika i

programowy 18 6 3 0

53-3 uŜytkownika 6 6 4 1







97-1 uŜytkownika i

programowy 8 4 0 0




128-2 uŜytkownika i

programowy 13 4 6 1




77-1 uŜytkownika i

programowy 36 40 5 0


Suma 517 332 78 10

59



Rysunki 19–20 przedstawiają procentowy udział błędów zaznaczonych

i niezaznaczonych w wynikach rozpoznania. Pierwszy rysunek prezentuje wyniki dla

danych liczbowych, a drugi dla danych tekstowych.

Zaznaczone 517; 61%

Niezaznaczone 332; 39%

Rysunek 19. Liczba oraz procentowy udział zaznaczonych i niezaznaczonych błędów rozpoznania danych opadowych we wszystkich próbkach.

Zaznaczone 78; 89%

Niezaznaczone 10; 11%

Rysunek 20. Liczba oraz procentowy udział zaznaczonych i niezaznaczonych błędów rozpoznania nazw stacji we wszystkich próbkach.

60



3.7. Analiza wyników i wnioski

W tym rozdziale przedstawiłem wnioski, jakie wyciągnąłem z badań testowych,

których sposób przeprowadzenia oraz wyniki zostały przedstawione w rozdziale

poprzednim.

3.7.1. Jakość obrazów

Rozdział ten prezentuje wnioski z poszczególnych badań nad wpływem jakości

obrazu rastrowego na skuteczność procesu rozpoznawania przeprowadzonego

w programie OCR.

3.7.1.1. Obrócone obrazy

Z przeprowadzonych badań dowiedziałem się, Ŝe program FineReader stosuje

wewnętrzny mechanizm do określenia ułoŜenie tekstu w obrazie. Niestety nie było

o tym ani jednej wzmianki w podręczniku uŜytkownika programu. FineReader nie

ustala jedynie orientacji obrazu ze względu na to czy jest on w poziomie czy w pionie,

ale wykonuje poprawkę odchylenia nawet o małe kąty. Niestety algorytm poprawiania

nie jest bezbłędny.

Nie da się pominąć tego procesu przez zastosowanie jakichkolwiek ustawień

w programie. Opcja „wykrywanie orientacji strony”, którą moŜna wyłączyć, określa

jedynie czy tekst ułoŜony jest w pionie czy poziomie. Nie odnosi się ona do

wykrywania ułoŜenia na poziomie kilku stopni. To dzieje się automatycznie.

W programie znajduje się takŜe polecenie „wyprostuj linie tekstu”. Jak podaje

podręcznik uŜytkownika słuŜy ona rozpoznaniu zniekształceń spowodowanych

skanowaniem grubych dokumentów. W miejscu łączenia mogą pojawić się wtedy

zakrzywienia linii tekstu. Opcja ta nie jest związana z problemem, jaki starałem się

rozwiązać i nie ma wpływu na ogólne ułoŜenie obrazu.

Nie ma więc moŜliwości własnoręcznej kontroli nad ułoŜeniem rozpoznawanego

obrazu. W wyniku otwierania pliku moŜe zajść sytuacja, w której wstępnie

61



przygotowany plik z poprawnie ułoŜonym obrazem zostanie przez program

umieszczony w pozycji z większym odchyleniem, niŜ wersja pierwotna, która zawierała

obrócony obraz.

FineReader radzi sobie jednak nawet z największymi odchyleniami obrazu, jakie

wystąpiły w testowanych plikach. MoŜna więc przyjąć, Ŝe jeŜeli odchylenie obrazu

w pliku nie przekracza 2 stopni, takich plików nie trzeba, a nawet nie naleŜy, wstępnie

poprawiać przez kalibrację ich ułoŜenia. Wszystkie analizowane pliki (obrazy stron

z jednego rocznika) spełniały to załoŜenie.

3.7.1.2. Rozdzielczość

Pierwszym skojarzeniem, jakie nasuwa się podczas określenia zaleŜności

skuteczności rozpoznawania od rozdzielczości jest to, Ŝe trzeba zwiększyć

rozdzielczość maksymalnie jak się da, a tym samym podniesie się jakość obrazu, co

z kolei pozytywnie wpłynie na efektywność rozpoznawania. Rzeczywistość nie jest

jednak tak prosta. Więcej informacji o danym elemencie wcale nie musi oznaczać, Ŝe

łatwiej będzie go zidentyfikować. Za mała ilość moŜe z kolei nie być wystarczająca.

Badania testowe przeprowadzone dla trzech rozdzielczości (300, 600 i 1200 dpi)

potwierdziły wstępne przypuszczenia oparte o informacje z podręcznika uŜytkownika

programu i wiadomość uzyskaną od producenta. Podręcznik uŜytkownika sugeruje

uŜycie rozdzielczości od 400 do 600dpi dla czcionki mniejszej niŜ 9 punktów. Na

badanych stronach rozmiar czcionki wynosi pomiędzy 5 a 6 punktów. Stosowną

rozdzielczością wydaje się więc być 600dpi. Zgodnie z informacją od producenta dalsze

zwiększanie rozdzielczości nie powoduje poprawy wyników rozpoznawania.

Dodatkowym argumentem przeciwko zastosowaniu rozdzielczości 300dpi i 1200dpi są

takŜe ostrzeŜenia, które program generuje przy próbach rozpoznawania obrazów w tych

rozdzielczościach.

Przeprowadzone przeze mnie badania zdają się potwierdzać przedstawione

przypuszczenia. Dla dwóch z trzech testowanych stron rozdzielczość, dla jakiej proces

rozpoznawania był najbardziej skuteczny to 600dpi. W procesie rozpoznawania strony

53 liczba wszystkich błędów przy rozdzielczości 600dpi jest o 32% mniejsza niŜ przy

zastosowaniu rozdzielczości 300dpi i aŜ o 62% przy niŜ dla 1200dpi. Dla strony 97

rozpoznawanie przy rozdzielczości 600dpi wywołało o 69% mniej wszystkich błędów

62



niŜ 300dpi i 18% mniej niŜ 1200dpi. JeŜeli wziąć pod uwagę liczbę błędów w danych

opadowych i wartość błędu względnego to rozdzielczością dającą najlepsze wyniki dla

tych dwóch stron jest takŜe 600dpi.

Badania wykonane na stronie 128 dają nieco odmienne wyniki. Rozdzielczość

300dpi spowodowała wystąpienie największej liczby błędów, ale to rozdzielczość

1200dpi a nie 600dpi okazała się dawać najlepsze wyniki. RóŜnica nie jest jednak duŜa.

Największa rozdzielczość wywołała o 18% mniej wszystkich błędów, ale liczba błędów

w danych opadowych róŜni się tylko o jeden.

Z tej części badań moŜna wnioskować, Ŝe rozdzielczość, z jaką naleŜałoby

skanować strony rocznika, aby skuteczność rozpoznawania była największa to 600dpi.

Aby mieć całkowitą pewność naleŜałoby jeszcze uwzględnić rozdzielczości, jakie nie

podlegały testom przeze mnie przeprowadzonym, a podręcznik uŜytkownika wskazuje

na moŜliwość ich zastosowania. Są to rozdzielczości z przedziału 400-600dpi.

Wszystkie przesłanki wskazują jednak na to, Ŝe wniosek pozostałby ten sam.

3.7.1.3. Jasność i kontrast

Ta część badań miała wykazać czy w procesie przetwarzania danych warto jest

uŜyć dodatkowego narzędzia – programu do obróbki graficznej plików. Próbowałem

określić, jaki wpływ na skuteczność rozpoznawania ma jasność i kontrast obrazu

poddanego temu procesowi.

Strona 97 została poddana największej liczbie badań. Cztery z nich były

przeprowadzone ze zmianą jasności przy stałym kontraście. JuŜ z tej, początkowej

części badań wnioskować moŜna, Ŝe jasność obrazu ma wpływ na skuteczność

rozpoznawania. Najmniejszą liczbę błędów zawierała próbka 97-3, w której jasność

została zmniejszona o 45 jednostek w programie Gimp. Mediana dla tej próbki wynosiła

210 a średnia 204,79. Dalsze zmniejszanie jasności nie poprawiło skuteczności.

Korekcja względem obrazu bazowego o 65 jednostek wywołała o 47% więcej błędów.

Mniejsza jasność takŜe odpowiadała mniejszej skuteczności. Zmniejszenie jasności o 20

jednostek w stosunku do wartości początkowej spowodowało o 18% więcej błędów.

Na stronie 97 zostały takŜe wykonane dwa testy zmiany kontrastu przy stałej

jasności. Zwiększenie kontrastu o 15 jednostek względem obrazu początkowego

wywołało o 13% więcej błędów.

63



Testy wykonane na stronie 53 potwierdziły wniosek, Ŝe zmniejszanie jasności

ma pozytywny wpływ na skuteczność rozpoznawania. Próbka 53-4 zawiera najmniej

błędów. Dla tej strony, tak jak dla strony 97, obniŜenie wartości jasności o 45 jednostek

najlepiej wpłynęło na wyniki. Mediana dla obrazu tak przetworzonego wynosiła 210,

czyli tyle co strony 97. Średnia miała takŜe zbliŜoną wartość: 202,15. Kontrast tej

próbki miał wartość bazową.

Porównanie próbek 53-1 i 53-3, których jasności została jednakowo obniŜona o

50 jednostek, moŜe wniosek sugerować, Ŝe zwiększenie kontrastu pozytywnie wpływa

na wyniki procesu rozpoznawania. W próbce 53-1 został on zwiększony o 40 jednostek,

a w próbce 53-3 o 5 i to pierwsza z nich zawierała o 13% mniej wszystkich błędów.

Wynik taki był spowodowany problemem programu z rozpoznawaniem liczby 3.

W próbce 53-3 znajdowało się aŜ 36 błędów rozpoznania tej cyfry jako cyfry 5.

Badania nad stroną 128 wykazują kolejny raz pozytywny wpływ obniŜania

jasności obrazu na liczbę błędów w pliku wyjściowym. Próbka 128-1, która była

poddana mniejszej korekcji jasności (-10) i większej poprawie kontrastu (30) niŜ 128-2

(jasność -40, kontrast 10) zawiera o 2 mniej wszystkich błędów ale liczba błędów

w danych opadowych jest o jeden mniejsza dla drugiej z tych próbek. Druga próbka

zawierała prawie dwa razy więcej błędów w nazwach stacji. Większy kontrast

i mniejsza jasność poprawiły więc skuteczność w rozpoznawaniu liter, ale zmniejszyły

ją dla liczb.

Dwa testy na 77 stronie rocznika, która charakteryzowała się bardzo słabą

jakością druku, wykazują zwiększenie efektywności przy zastosowaniu korekcji

jasności i kontrastu. Poprawki te zostały dokonane na podstawie wniosków

z poprzednich testów i potwierdzają ich słuszność. Rozpoznawanie po korekcji

wywołało o 27% mniej wszystkich błędów. W wyniku rozpoznania tej strony pojawił

się błąd prawie niespotykany do tej pory. Wynik rozpoznania zawierał puste komórki

w miejscach, w których powinny znaleźć się liczby. Zmniejszenie jasności

spowodowało spadek liczby wystąpień tego rodzaju błędów z 21 do 9.

Wynik rozpoznania strony 77 ze skorygowanymi parametrami obrazem nie jest

rewelacyjny, ale taka poprawa skuteczności potwierdza przypuszczenia o słuszność

korekcji graficznej obrazów zanim podda się je procesowi rozpoznania.

64



Przeprowadzone testy wykazały, Ŝe pozytywny wpływ na efektywność procesu

ma zmniejszenie jasności. Nadmierne zwiększanie kontrastu moŜe natomiast

niekorzystnie wpłynąć na jego wyniki, ale delikatne zmiany są wskazane. Nie da się

jednoznacznie określić parametrów obróbki obrazów pod względem ich jasności

i kontrastu tak, aby przyniosło to rezultaty w poprawie skuteczności rozpoznawania dla

wszystkich stron rocznika. JeŜeli proces rozpoznawania wywoła dla badanej strony

znaczną liczbę błędów w stosunku do ilości danych wskazane jest wykonanie kolejnych

prób rozpoznania po dokonaniu korekcji jasności i kontrastu.

3.7.3. Douczanie

Po przeczytaniu w podręczniku uŜytkownika programu FineReader paragrafu

o funkcji douczania byłem przekonany, Ŝe badania nad skutecznością rozpoznawania

nie będą pełne, jeŜeli nie weźmie się pod uwagę wpływu zastosowania własnoręcznie

stworzonych wzorców. Niestety uŜytkownik nie ma moŜliwości szczegółowego

wpływu na tą funkcjonalność. Nie wiadomo, jaki jest algorytm i kiedy program

rzeczywiście korzysta z wzorca stworzonego przez uŜytkownika, a kiedy wykorzystuje

swój wewnętrzny wzorzec. MoŜliwe są jedynie trzy ustawienia bez dodatkowych opcji8.

Podczas tej części badań przetestowałem pięć próbek – cztery strony, w tym

jedną w dwóch wariantach jasności. Badania miały wykazać, jaki zestaw wzorców daje

największą skuteczność procesu rozpoznawania.

Patrząc na wyniki zamieszczone w tabeli 16 pokazujące sumę wszystkich

błędów z wszystkich próbek zaleŜnie od wykorzystanego zestawu wzorców moŜna by

wyciągnąć prosty wniosek, Ŝe najlepiej jest korzystać z wzorca uŜytkownika

wspomaganego przez wzorzec wbudowany. Wszystkich błędów w przypadku jego

zastosowania było bowiem najmniej, ale jest to jedynie 5% mniej niŜ przy w przypadku

korzystania tylko w wzorca wbudowanego. Najgorszy wynik w tym daje wykorzystanie

wzorca uŜytkownika. Wszystkich błędów jest w tym wypadku więcej aŜ o 27% więcej

niŜ w najlepszym przypadku. Taki wynik jest spowodowany bardzo niekorzystnym,

w porównaniu z innymi, wynikiem badania próbki 128-2 przy wykorzystaniu wzorca

8 Więcej na ten temat w rozdziale 3.5.

65



uŜytkownika. Badanie tej próbki wykazało ponad cztery razy więcej błędów przy

zastosowaniu wzorca uŜytkownika niŜ dla pozostałych dwóch zestawów wzorców.

Gdyby nie brać pod uwagę tej próbki zestaw z wzorcem uŜytkownika uzyskałby

znacznie lepszy wynik.

Lepsze niŜ tablica 16 zestawienie umoŜliwiające wyciągnięcie obiektywnych

wniosków stanowi, według mnie, tablica 15. Prezentuje ona wyniki z pięciu

niezaleŜnych badań na pięciu róŜnych próbkach w formie eksponującej najlepszy

i najgorszy zestaw wzorców. Wzorzec programowy wywołał najmniej błędów aŜ

w trzech na pięć przypadków. Wzorzec uŜytkownika był najlepszy w dwóch

pozostałych próbach, a zastosowanie obu wzorców razem dało najgorsze wyniki.

Liczba wszystkich błędów dla próbki 77-1 wskazuje jednak niewielką róŜnicę, bo tylko

jednego błędu, pomiędzy zastosowaniem wzorca wbudowanego a wzorca uŜytkownika.

MoŜna więc powiedzieć, Ŝe dla tej próbki oba zestawy dały bardzo zbliŜone wyniki. Nie

biorąc pod uwagę wspomnianej wcześniej próbki 128-2, uznając ją za „skaŜoną”,

moŜna by stwierdzić, Ŝe zastosowanie wzorca wbudowanego i wzorca uŜytkownika

daje w przybliŜeniu takie same wyniki.

Po przeprowadzonych badaniach nie moŜna wyciągnąć wniosku jakoby jeden

z moŜliwych do zastosowania zestawów wzorców dawał wyraźnie lepsze wyniki niŜ

inne. W większości przypadków korzystanie ze standardowego wzorca wbudowanego

w program daje najlepsze wyniki, jednak niekiedy lepsze okazuje się wspomoŜenie go

wzorcem uŜytkownika, a są teŜ przypadki, kiedy uŜycie samego wzorca uŜytkownika

daje najlepsze efekty. Jednym pewnym wnioskiem jest to, Ŝe wyniki mogą się znacznie

od siebie róŜnić. Dlatego teŜ, o ile będzie to moŜliwe, naleŜałoby przeprowadzić

rozpoznanie z wszystkimi trzema wariantami i podczas ekstrakcji danych wybrać plik

zawierający najmniej błędów.

3.7.4. Zaznaczanie niepewnych znaków

Wykorzystanie funkcji zaznaczającej niepewne znaki mogłoby być bardzo

pomocne przy ręcznej korekcji wyników rozpoznawania. Funkcja, jeŜeli działałaby tak,

Ŝe zaznaczałaby miejsca, w których występują rzeczywiste błędy mogłaby znacznie

66



ułatwić poprawianie wyników. Przy niewielkim nakładzie pracy moŜliwa byłaby

znaczna poprawa jakości danych wejściowych następnego etapu przetwarzania.

Z wszystkich błędów rozpoznawania danych opadowych dla wszystkich próbek

aŜ 39% było niezaznaczone. Lepszą skuteczność działania badanej funkcji programu

moŜna zaobserwować dla znaków literowych. Zaznaczonych zostało 89% wszystkich

błędnie rozpoznanych nazw posterunków we wszystkich badanych próbkach.

Z wyników wnioskować moŜna, Ŝe niestety funkcja ta nie działa skutecznie,

jeŜeli chodzi o zaznaczanie danych liczbowych. Nie moŜna więc sugerować się jej

wskazaniami przy poszukiwaniu błędów wśród tego typu danych. Błędnie rozpoznane

znaki literowe są zaznaczane z duŜo większą skuteczności i kierowanie się wskazaniami

programu przy poszukiwaniu błędów wśród słów moŜe przynieść pozytywne rezultaty.

Testy nie zostały przeprowadzone na najlepszy z moŜliwych sposobów, z czego

zdaję sobie sprawę. Aby były pełne naleŜałoby podać takŜe liczbę znaków, które

program oznaczył jako niepewne a były rozpoznane prawidłowo. Wtedy moŜna by było

wyciągnąć bardziej konstruktywne wnioski. Niesklasyfikowane, dodatkowe

spostrzeŜenia potwierdzają jednak słuszność wcześniej przedstawionych wniosków.

3.7.5. Inne wnioski z badań

Podczas przeprowadzania badań notowałem wszystkie spostrzeŜenia, które

mogłyby okazać się znaczące na którymkolwiek etapie przetwarzania. Zapisywałem

więc uwagi odnośnie pracy programu OCR a takŜe wszystkie informacje mogące mieć

znaczenie przy projektowaniu algorytmu aplikacji pozyskującej dane z pliku HTML.

Błędy rozpoznania

Poszukując błędów rozpoznania wypracowałem kilka podstawowych kryteriów,

które pomagają w ich znalezieniu.

Oczywistym jest, Ŝe wśród danych liczbowych nie moŜe być znaków

literowych, a wśród nazw stacji nie powinno być cyfr. Takie błędy rozpoznania zdarzają

się jednak często. MoŜna je więc łatwo wychwycić, gdyŜ nie są trudne to zauwaŜenia.

67



W algorytmie pozyskiwania danych z pliku HTML moŜna zaimplementować

mechanizm wskazujący uŜytkownikowi, w której komórce tabeli wystąpiły powyŜej

opisane błędy. Mogłoby to bardzo pomóc przy ich odnajdywaniu.

Jednym z często pojawiających się błędów jest łączenie kilku sąsiednich

znaków. Wtedy to w wyniku rozpoznawania powstaje jeden znak zapisany większą

czcionką. Błędy te są takŜe stosunkowo łatwe do odnalezienia gdyŜ są proste do

wychwycenia wzrokiem.

Wśród błędów występujących w rozpoznanym pliku zauwaŜyłem kilka, których

moŜna łatwo pozbyć się programując proste reguły w algorytmie pozyskiwania danych.

Wymienię je teraz po kolei.

1. Rozpoznanie cyfry 0 jako litery „o” lub „O” wśród danych liczbowych.

2. Zamiana przecinka na kropkę w danych liczbowych.

3. Zamiana przecinka na literę zapisaną w indeksie dolnym. Najczęściej jest to

litera „f”.

4. Występowanie dwóch przecinków zamiast jednego.

5. Zamiana litery „Z” na cyfrę 2 wśród danych literowych.

6. Wśród liczb podkreślonych zamiana przecinka na znak „^”.

7. Znaki odstępu pomiędzy cyframi w liczbie.

Wprowadzenie reguł zapobiegających tym błędom moŜe znacząco wpłynąć na

wynik pozyskiwania danych.

Jednym z najczęściej pojawiających się błędów jest takŜe zamiana cyfr

zbliŜonych do siebie wyglądem. FineReader miał problem z rozpoznaniem cyfry 8

i kiedy znak był słabo wydrukowany często odczytywał go jako cyfrę 3. Najczęściej

pojawiającym się błędem tego typu była zamiana cyfry 3 na 5. Błąd ten szczególnie

często pojawiał się przy rozpoznawaniu strony 53.

Ustawienia w programie

Program FineReader umoŜliwia ustawienie kilku „dodatkowych opcji”, które

ułatwiają proces rozpoznawania.

68



Korzystne jest zaznaczenie opcji „Jedna linia tekstu w jednej komórce tabeli”.

Dzięki bardziej skutecznie działa funkcja ustalająca podział tabeli separatorami.

Zaznaczenie opcji „Brak komórek łączonych” powoduje, Ŝe w wyniku

rozpoznania program nie łączy komórek z danymi i automatycznie bardziej skutecznie

przypisuje jedną daną jednej komórce.

Podczas rozpoznawania odznaczałem takŜe opcję poszukiwania kodów

kreskowych, która w ustawieniach standardowych jest włączona.. MoŜe to mieć wpływ

na szybkość rozpoznawania, warto więc ją odznaczyć.

NaleŜy pamiętać, Ŝe plik zawierający przetwarzany dokument jest zapisywany

na bieŜąco. Chcąc posiadać plik zapisujący jeden z pośrednich etapów przetwarzania

naleŜy zapisywać go oddzielnie, np. pod inną nazwą.

Czasy pracy programu

Podczas kilku badań sprawdziłem czasy pracy programu. Zmierzyłem ile trwa

otwieranie pliku z obrazem i jego rozpoznawanie. Nie podawałem klasyfikacji tych

wyników w poprzednim rozdziale dotyczącym badań gdyŜ są to wartości bardzo

względne, zaleŜą bowiem od sprzętu na jakim uruchomiony jest program OCR. Testy

wykonane zostały na komputerze z procesorem AMD Athlon 3000+ o częstotliwości

2,0GHz i pamięci RAM 1,5 GB. Postanowiłem podać te czasy aby czytelnik mógł

zorientować się ile moŜe trwać cały proces.

Największy wpływ na czas otwierania pliku miała rozdzielczość obrazu.

Podczas gdy dla rozdzielczości 300dpi i 600dpi czasy były porównywalne i otwieranie

trwało od kilku do kilkudziesięciu sekund to przy rozdzielczości 1200dpi proces ten

trwał około trzech minut.

Czas trwania procesu rozpoznawania to od jednej minuty do około czterech

minut. Długość tego procesu zaleŜała głównie od ilości danych zawartych na stronie

i od jakości obrazu.

Znaki zawierające podkreślenia

Wśród danych o wysokości opadu podawanych w roczniku wartości

maksymalne dla danego miesiąca są wydrukowane czcionką z podkreśleniem.

Sprawdzenie czy wartość ta jest rzeczywiście najwyŜsza w zbiorze pozyskanych danych

69



mogłoby słuŜyć dodatkowej ich weryfikacji. Niestety okazuje się, Ŝe program

FineReader nie rozpoznaje podkreśleń czcionki. UniemoŜliwia to zastosowanie

dodatkowego kryterium weryfikacji danych, a takŜe stanowi dodatkowe utrudnienie.

Liczba błędów, którą program popełnia przy rozpoznawaniu podkreślonych liczb jest

znacząca, poniewaŜ FineReader podkreślenie pod cyfrą traktuje jako część całego

znaku.

Zaproponować mogę jedno rozwiązanie, którego wprowadzenie moŜe, ale nie

musi, wspomóc proces rozpoznawania podkreślonych znaków. MoŜna przeprowadzić

proces douczania tych znaków w ten sposób, Ŝe zaznaczając cyfrę i jej podkreślenie

zapiszemy ją jako samą cyfrę. Metoda ta jest eksperymentalna i dlatego naleŜałoby ją

dobrze przetestować przed zastosowaniem. MoŜe się bowiem zdarzyć, Ŝe program

zacznie źle rozpoznawać znaki, które składają się z poziomej linii na dole (np. cyfra 2).

3.7.6. Podsumowanie badań

Jak pisze Andrzej Śluzek [Śluzek, 1991]: „[…] poprawianie jakości obrazu jest

procesem, w którym podstawową rolę odgrywa eksperyment i doświadczenie

projektanta. Znalezienie algorytmów optymalnych dla danej klasy obrazów

i zapewniających poŜądany efekt wymaga zwykle przeprowadzenia wielu prób i testów.

Trudno jest wobec tego podać szczegółowy opis postępowania gwarantującego

zadowalającą poprawę jakości obrazów.” I rzeczywiście, nie jest procesem łatwym

znalezienie najbardziej odpowiedniego algorytmu obróbki obrazów tak, aby przyniósł

on efekt dla całej grupy plików. Testy wykazały, Ŝe nie zawsze to samo postępowanie,

tak samo wpływa na skuteczność procesu rozpoznawania dla róŜnych plików. Trudno

jest jednoznacznie określić schemat działań, jakiemu powinny podlegać obrazy.

Z przeprowadzonych badań wynika, Ŝe najbardziej korzystny wpływ na

skuteczność rozpoznawania moŜe wywrzeć zmiana jasności pliku z obrazem.

Przyciemnienie obrazu w większości przypadków powodowało wzrost jakości

rezultatów rozpoznawania. Lekkie zwiększenie kontrastu takŜe moŜe pozytywnie

wpłynąć na wynik procesu rozpoznawania.

70



Niestety nie da się wyciągnąć jednoznacznych wniosków odnośnie wpływu na

rezultaty zastosowania róŜnych rodzajów wzorców znaków. Najbezpieczniejsze wydaje

się standardowe ustawienie programu, czyli wykorzystanie jego własnych wzorców.

Najpewniejszym wnioskiem z badań jest wniosek odnośnie rozdzielczości.

Z trzech przebadanych rozdzielczość 600dpi jest najbardziej odpowiednia do

zastosowania przy przetwarzaniu plików z obrazem stron rocznika opadowego.

Kwestię bardziej szczegółowych badań zostawiam otwartą. Do ich

przeprowadzenia moŜe być pomocne uŜycie zaprogramowanej przeze mnie aplikacji,

o czym piszę w rozdziale 4.4.2.

71



4.

Aplikacja pozyskująca dane z pliku tekstowego

Niniejszy rozdział jest opisem aplikacji, którą zaprojektowałem do pozyskiwania

danych z pliku będącego wynikiem działania programu OCR.

72



4.1. Uwagi wstępne

Przetworzenie obrazu rastrowego na plik tekstowy to dopiero pierwszy etap

całego procesu pozyskiwania danych z rocznika. Drugi etap polega na ekstrakcji

właściwych danych ze zbioru, jakim jest plik i zapisaniu ich w bazie danych.

Do wykonania tego zadania wybrałem HTML, CSS, PHP i MySQL. Są to

technologie popularne i umoŜliwiają spełnienie wszystkich wymagań, jakie stawiałem

sobie przy realizacji projektu. Powszechność ich uŜycia ułatwia rozwiązywanie

problemów, na jakie moŜna natrafić w procesie tworzenia aplikacji. Ogólna dostępność

i popularność narzędzi umoŜliwia takŜe podjęcie ewentualnych kroków do rozszerzenia

funkcjonalności przez osoby inne niŜ pierwszy autor.

Zaproponowane przeze mnie rozwiązanie jest moŜliwe do wdroŜenia na wielu

platformach, niezaleŜnie od systemu operacyjnego. Aplikacja moŜe zostać uruchomiona

na dowolnym komputerze posiadającym serwer HTTP, interpreter PHP5, oraz silnik

bazodanowy MySQL. Za pośrednictwem przeglądarki internetowej moŜe być

uruchamiana na kaŜdym komputerze znajdującym się w jednej sieci z hostem.

W niniejszej pracy nie będę opisywał szczegółów całego projektu aplikacji lecz

skupię się na omówieniu tych zagadnień, które bezpośrednio dotyczą realizacji

stawianych przed nią celów. Nie będę więc pisał o tym w jaki sposób tworzyłem

strukturę pojedynczych dokumentów HTML, o obsłudze formularzy, czy tworzeniu

tabel w języku HTML. Opiszę ogólną strukturę aplikacji i zasady jej funkcjonowania

oraz sam algorytm ekstrakcji danych.

4.2. Podstawy aplikacji

Całość aplikacji moŜna podzielić na 2 główne części:

1. Struktura dokumentów tworzona przy uŜyciu HTML i ich szata graficzna

tworzona przy uŜyciu CSS.

2. Skrypty PHP wykonywane po stronie serwera.

73



Podstawę aplikacji stanowi część druga zawierająca algorytm do ekstrakcji

danych. Część pierwsza tworzy jej interfejs.

Przyjęte załoŜenia

Zgodnie z załoŜeniem pracy, przetwarzaniu miały podlegać strony rocznika

zawierające tabelę „Wysokości dobowe opadów w mm”. Strony te przedstawiają dane

o wysokościach opadów przypisane do stacji pomiarowych. Dane o stacjach

pomiarowych naleŜy jednak pozyskać niezaleŜnie. Znajdujący się na początku rocznika

„Alfabetyczny spis stacji” zawiera spis stacji pomiarowych wraz z danymi, jakich nie

ma na stronach zawierających tabelę I („Wysokości dobowe opadów”). Te dane to:

numer stacji, wysokość jej połoŜenia nad poziomem morza, szerokość i długość

geograficzna miejsca, w którym stacja się znajduje oraz informacja o dorzeczu.

Przyjąłem więc, Ŝe podczas ekstrakcji danych opadowych znane są informacje

o posterunkach, gdyŜ chcąc przeprowadzić proces pozyskiwania danych z rocznika

opadowego naleŜałoby postępować w takiej kolejności. Z powodu braku rzeczywistych

danych o stacjach pomiarowych implementacja algorytmu nie obejmuje zapisu wyniku

rozpoznania do bazy danych.

Dodatkowym załoŜeniem, jakie wynika z badań wstępnych opisanych

w rozdziale 3.6.1 było pozyskiwanie danych o wysokościach opadów bez informacji

o ich typie. Dane o rodzajach opadów określone są w roczniku opadowym przy pomocy

symboli i naleŜy je, tak jak dane o stacjach pomiarowych, pozyskać niezaleŜnie.

Interfejs uŜytkownika

Podczas tworzenia interfejsu uŜytkownika bazowałem na szablonie strony

pobranym z freeCSStemplates.org. Szablony umieszczone na tej stronie są udostępniane

na licencji Creative Commons Attribution 2.59. Jest to licencja zezwalająca na dowolną

modyfikację szablonu, a takŜe uŜycie go w celach komercyjnych pod jednym

warunkiem: naleŜy umieścić informację o autorze (np. odnośnik do jego strony).

Pobrany szablon to jedna, przykładowa strona HTML, plik CSS i pliki

z elementami graficznymi zawartymi na stronie. Stanowi on „opakowanie” aplikacji

9 Pełny tekst prawny w języku polskim: http://creativecommons.org/licenses/by/2.5/pl/legalcode

74



internetowej. Pozwala twórcy na skupienie się na głównej części programistycznej

przez podanie wzorca wyglądu graficznego dokumentów. Wzorzec ten moŜna dowolnie

modyfikować i uzupełniać. Dlatego teŜ zdecydowałem się na jego uŜycie.

Podstawowy algorytm

Na rysunku 21 przedstawiam uproszczony schemat blokowy podstawowego

algorytmu aplikacji realizującego proces pozyskiwania danych o wysokościach opadów.

Rysunek 21. Uproszczony schemat blokowy algorytmu pobierania danych o wysokościach opadów.

75



W algorytmie wykonywane są trzy główne zadania:

1. Ekstrakcja danych z pliku HMTL

2. Sprawdzenie poprawności danych

3. Zapisanie danych w bazie

Chcąc w jak najlepszy sposób zrealizować stawiane sobie cele zdecydowałem

się na wykorzystanie obiektowości języka PHP. Aplikacja składa się z czterech klas.

Jedna z nich obsługuje interfejs uŜytkownika i nie będzie omawiana. Pozostałe trzy

wykorzystywane są przy realizacji głównego zadania – ekstrakcji i zapisu danych i te

klasy omówię w kolejnych częściach pracy.

4.3. Ekstrakcja danych z pliku HTML

Pozyskanie danych z pliku otrzymanego z programu OCR wymaga

wyodrębnienia ich ze zbioru, jakim jest ten plik. Strukturalna budowa dokumentu

HTML, wybranego jako format zapisu pliku wyjściowego10 znacznie ułatwia to

zadanie. Do tej części chciałem wykorzystać istniejące mechanizmy, które miały

ułatwić wykonywanie tego zadania.

4.3.1 Próby zastosowania istniejących modułów PHP

Pracując nad ekstrakcją danych podjąłem próbę uŜycia narzędzi, popularnych

i często stosowanych do realizacji podobnych zadań. Dzięki ich wykorzystaniu

aplikacja stałaby się dodatkowo bardziej uniwersalna i łatwiejsza do interpretacji

i ewentualnego rozwoju przez innych programistów.

4.3.1.1. SimpleXML

SimpleXML jest modułem PHP5, który w prosty sposób umoŜliwia dostęp do

danych zawartych w pliku XML [Bergmann, 2005]. Wczytując plik XML za pomocą

10 Więcej na temat formatów pliku wyjściowego napisałem w rozdziale 3.3.

76



funkcji simplexml_load_file otrzymujemy drzewo obiektów i tablic. KaŜdy

znacznik w pliku jest reprezentowany przez oddzielny obiekt oraz tablicę asocjacyjną

z atrybutami. Za pomocą metod wywoływanych na tym obiekcie moŜna sprawdzić czy

zawiera on elementy potomne, uzyskać do nich dostęp, otrzymać przechowywany przez

niego tekst, dokonywać jego modyfikacji i wykonywać inne zadania.

Oto przykład dostępu do zawartości elementów podrzędnych w drzewie XML’a:

Przykładowa zawartość pliku XML o nazwie „przyklad.xml”:

Kod PHP, który wydrukuje zawartość elementu „title”:

Jak widać mechanizm jest prosty. Taka funkcjonalność znacznie ułatwia

operowanie na zawartości dokumentu XML. Chcąc ją zastosować do rozpatrywanego

problemu przetwarzania danych stanąłem przed znacznym utrudnieniem: plik, jaki

uzyskałem z programu jest zapisany w formacie HTML. Format ten jest bardzo

zbliŜony do XML, dlatego postanowiłem podjąć próbę jego adaptacji dla SimpleXML.

W formacie XML kaŜdy niepusty znacznik powinien posiadać odpowiadający

mu znacznik zamykający, a kaŜdy pusty powinien być zakończony znakiem „/”

(np. <br/>). Tego kryterium nie spełniają tagi „meta” w nagłówku pliku HTML.

Dlatego zanim treść pliku została przesłana do funkcji simplexml_load_string

(tworzącej obiekt SimpleXML ze zmiennej tekstowej) wydzielałem za pomocą

stworzonej na tą potrzebę funkcji część HTML’a zawartą pomiędzy znacznikami

<body> i </body> opuszczając wszystkie nagłówki. Niestety, nawet po wykonaniu tej

operacji funkcja simplexml_load_string zwracała wartość false świadcząca

<document> <menu>

<item> <title>zawartosc</title>

</item> </menu>

</document>

<?php $xml = simplexml_load_file('przyklad.xml'); echo $xml->menu->item->title;

?>

77



o wystąpieniu błędu. Okazało się, Ŝe przyjmuje ona standardowo, Ŝe znaki w zmiennej

tekstowej kodowane są w UTF-8. Zmieniłem kodowanie pliku, ale i to nie pomogło.

Kolejny problem związany był z encjami, których definicji brakowało

w formacie XML. Encje występujące w językach typu SGML (standardowych

uogólnionych językach znaczników) są stosowane do zastąpienia jednego ciągu znaków

innym – przewaŜnie krótszym.

Oto przykładowa deklaracja encji:

PowyŜsza deklaracja pozwalałaby na wyświetlanie tekstu „Kamil Zieliński”

w kaŜdym miejscu gdzie wystąpiłoby odwołanie do encji.

Odwołanie do encji „autor”:

W HTML encje są ona uŜywane do zapisania wielu znaków spoza zestawu

ASCII. W przeglądanych plikach znalazłem wystąpienia takich znaków jak „<”

zastępowanych przy uŜyciu encji ciągiem „<”, znaków „"” zastępowanych „"”

oraz najwięcej znaków „twardej spacji”, czyli „ ”.

Podjąłem próbę dekodowania encji przy pomocy funkcji PHP

html_entity_decode , a takŜe ich usuwania przy pomocy preg_replace , ale

nie przyniosło to rezultatu. Pojawiały się kolejne błędy i niezgodności z formatem

XML, dlatego zrezygnowałem z SimpleXML jako sposobu pozyskiwania danych.

4.3.1.2. DOMDocument

Kolejną próbą zastosowania gotowego rozwiązania programistycznego do

pobrania danych z pliku było wykorzystanie klasy DOMDocument. Klasa ta bazuje na

standardzie DOM stworzonym przez World Wide Web Consortium, organizację

zajmującą się ustanawianiem standardów internetowych. Standard DOM definiuje zespół

&autor;

<!ENTITY autor "Kamil Zieli ński">

78



klas i interfejsów umoŜliwiających dostęp do struktury dokumentów oraz jej

modyfikację, tworzenie i usuwanie [Bergmann, 2005].

Niestety DOM nie jest tak prosty w uŜyciu jak poprzednio omawiany moduł

SimpleXML. UmoŜliwia za to stworzenie obiektu DOMDocument bezpośrednio z pliku

w formacie HTML za pomocą funkcji loadHTMLFile . Z tak utworzonego obiektu

moŜna pobrać elementy określone przez podany tag HTML za pomocą funkcji

getElementsByTagName . Funkcja ta zwraca obiekt klasy DOMNodeList , który

moŜemy poddać dalszej obróbce, jednak po pozyskaniu z niego pojedynczego węzła

(jednego elementu) nie moŜna na nim zastosować funkcji wydzielającej inne elementy

danemu potomne. Próba ponownego stworzeniu obiektu klasy DOMDocument

z obiektu DOMNode zakończy się niepowodzeniem. Jest moŜliwość powrotu do

bazowego obiektu i działania na nim, jednak to wymagałoby ustalenia mało

intuicyjnych powiązań pomiędzy jego juŜ wydzielonymi elementami i ich potomkami,

które dopiero mogłyby zostać pozyskane.

Rozwiązanie to jest jak widać dość skomplikowane i wymaga wielu operacji na

obiektach róŜnych klas, aby wyodrębnić konkretne dane. Utrudnia to przejrzystość

stosowanych procedur. ZłoŜoność metody przetwarzania bazującej na modelu DOM

skłoniła mnie do sięgnięcia po inne rozwiązanie.

4.3.2. Własne rozwiązanie programistyczne

Niepowodzenia prób wykorzystania gotowych narzędzi programistycznych do

ekstrakcji danych z pliku HTML skłoniły mnie do opracowania własnego rozwiązania.

Oto dwa główne cele, jakie sobie stawiałem przy opracowywaniu algorytmu:

1. Stworzenie jak najbardziej uniwersalnego, prostego kodu.

2. MoŜliwość rozwinięcia aplikacji do zadania przetwarzania wszystkich

danych zawartych w roczniku opadowym.

79



4.3.2.1. Wydzielanie fragmentu kodu HTML (Klasa Wydzielacz)

Opis

Jest to bazowa klasa aplikacji. SłuŜy wykonaniu zadania, które jest podstawowe

i dla którego podjąłem wcześniej opisane próby wdroŜenia gotowych rozwiązań

programistycznych. Klasa ta umoŜliwia wydzielanie fragmentów kodu z pliku HTML..

Właściwości

Klasa posiada jedną właściwość: tekst . Jest to prywatna zmienna tekstowa.

Właściwość ta przechowuje kod HTML przetwarzanego pliku lub jego fragment. Kod

ten moŜe podlegać operacjom dzięki zastosowaniu metod klasy.

Metody

Klasa Wydzielacz zawiera trzy metody. Wszystkie metody tej klasy

wymagają podania parametru, którym jest string zawierający znacznik HTML.

Znacznik naleŜy podawać bez klamry zamykającej i otwierającej (np. „tr” gdy chodzi

o znacznik wiersza tabeli „<tr>”). Wszystkie metody wykonują operacje na zmiennej

tekst nie ingerując w jej zawartość.

Boolean sprawdz ( string $tag ) Metoda sprawdza czy zmienna tekst obiektu klasy Wydzielacz zawiera

znacznik HTML podany w parametrze $tag . Zwraca true w przypadku powodzenia,

false w przeciwnym razie.

Wydzielacz wydziel ( string $tag ) Metoda wydziela ze zmiennej tekst wszystkie znaki będące zawartością

znacznika podanego w parametrze $tag . Zwraca ona obiekt klasy Wydzielacz , na

którym moŜna wykonywać kolejne operacje. Metoda zwróci false , jeŜeli zmienna

tekst nie zawierała podanego znacznika. JeŜeli zmienna tekst zawiera więcej niŜ

jeden znacznik zwracana jest zawartość pierwszego z nich.

80



array wydzielTab ( string $tag ) Metoda ta wydziela ze zmiennej tekst zawartość wszystkich znaczników

takich jak podany z parametrze $tab . Zwracana jest tablica obiektów klasy

Wydzielacz lub false w przypadku niepowodzenia.

4.3.2.2. Pobieranie danych (Klasa Pobieracz)

Opis

Obiekty tej klasy przy wykorzystaniu obiektów klasy Wydzielacz dokonują

ekstrakcji danych. Zgodnie z załoŜeniem zaimplementowałem jedną metodę

umoŜliwiającą pobranie danych o wysokościach opadów.

Właściwości

Klasa posiada jedną właściwość: obWydzielacz . Jest to obiekt klasy

Wydzielacz , na którym metody klasy będą wykonywały operację w celu pozyskania

danych.

Metody

Zaprogramowałem jedną metodę pozyskującą dane o wysokościach opadów.

Chcąc pozyskiwać inne dane, jak np. dane o stacjach pomiarowych naleŜałoby

zaimplementować kolejne metody w tej klasie.

array wdo ( )

Nazwa metody jest akronimem frazy “wysokości dobowe opadów”, poniewaŜ

słuŜy ona pozyskaniu właśnie tych danych. Metoda nie przyjmuje Ŝadnych parametrów

gdyŜ wykonuje operację na obiekcie klasy Wydzielacz , który jest zapisany

w zmiennej obiektu. Nie ingeruje ona w zawartość tej zmiennej. Metoda zwraca tablicę

wyników zbudowaną według schematu:

• $wynik[$numer_wiersza][‘id’] – zawiera id posterunku;

• $wynik[$numer_wiersza][‘nazwa’] – zawiera nazwę posterunku;

81



• $wynik[$numer_wiersza][‘opad’] – zawiera tablicę z wysokościami

opadów;

• $wynik[$numer_wiersza][‘suma’] – zawiera sumę opadów dla

danego wiersza.

Zmienna $numer_wiersza to kolejny numerem wiersza tabeli, z której

pozyskano wyniki.

82



PoniŜej przedstawiłem kod źródłowy metody wdo.

1. public function wdo() { 2. 3. $tablica=array(); 4. $nrwiersza=-2; 5. 6. $row=$this->obWydziel->wydzielTab('tr'); 7. 8. foreach($row as $rowek){ 9. 10. $spr=$rowek->wydziel('td'); 11. $sprawdzenie=$spr->sprawdz('p'); 12. if(!$sprawdzenie) 13. continue; 14. 15. $nrwiersza++; 16. 17. if($nrwiersza==-1) 18. continue; 19. 20. $td=$rowek->wydzielTab('td'); 21. 22. $i=-2; 23. 24. foreach($td as $kom){ 25. $i++; 26. 27. $p=$kom->wydziel('p'); 28. if($i==-1){ 29. $tablica[$nrwiersza]['id']=$p->getTekst(); 30. } 31. else if($i==0) 32. $tablica[$nrwiersza]['nazwa']=$p->getTekst (); 33. else{ 34. if($p!=false){ 35. $zawartosc=$p->getTekst(); 36. $zawartosc=str_replace('o','0',$zawartosc ); 37. if(!preg_match('/^[0-9]$/D',$zawartosc[0] )) 38. $tablica[$nrwiersza]['opad'][$i]='-'; 39. else{ 40. $zawartosc=str_replace(',','.',$zawartos c); 41. $tablica[$nrwiersza]['opad'][$i]=$zawart osc; 42. } 43. } 44. else 45. $tablica[$nrwiersza]['opad'][$i]='-'; 46. } 47. } 48. 49. $tablica[$nrwiersza]['suma']=$tablica[$nrwiersz a]['opad'][$i]; 50. unset($tablica[$nrwiersza]['opad'][$i]); 51. } 52. return $tablica; 53. }

83



Omówienie algorytmu metody wdo

Dane o wysokościach opadów przechowywane są w formie tabelarycznej.

Odsyłam czytelnika do rozdziału 2, gdyŜ zrozumienie algorytmu wymaga wiedzy na

temat struktury tabeli „Wysokości dobowe opadów w mm”.

W poniŜszym opisie odwoływałem się do numerów linii w kodzie źródłowym

zamieszczonym powyŜej. UŜywam słowa „linia”, aby rozróŜnić, Ŝe mam na myśli

nawiązanie do kodu źródłowego, a nie do wiersza tabeli z danymi nazywanego słowem

„wiersz”. Słowo „tabela” odnosi się natomiast do tabeli w pliku HTML. Słowo

„tablica” oznacza zmienną tablicową zastosowaną w programie.

Na wstępie przy uŜyciu metody WydzielTab wydzielane są kolejne wiersze

tabeli (linia 6). Wynik tej operacji zapisywany jest w zmiennej tablicowej. W linii 8

zaczyna się główna pętla metody, umoŜliwiająca przetwarzanie kolejnych wierszy

tabeli. Zmienna określająca numer wiersza została tak zainicjowana, aby zebrane dane

były ponumerowane od wartości 0 (linia 4). Algorytm sprawdza zawartość pierwszej

komórki w wierszu. JeŜeli jest ona pusta oznacza to, Ŝe wiersz ten zawiera informacje

o dorzeczu a nie dane opadowe, dlatego zostaje on pominięty (linie 10-13). Pierwszy

wiersz tabeli takŜe jest pomijany, gdyŜ jest to wiersz tytułowy (linie 17-18).

Druga pętla zastosowana w algorytmie pozwala na przebadanie kolejnych

komórek nie pominiętego wiersza. KaŜda pierwsza komórka zawiera numer posterunku,

który zostaje zapisany w tablicy (linie 28-30). Druga komórka to nazwa posterunku

i takŜe ona zostaje zapisana (linie 31-32). Dane o wysokościach opadu zapisywane są

kolejno zgodnie z numerem dnia miesiąca. Ostatnia komórka zawiera dane o sumie,

dlatego zostaje ona zapisana w oddzielnej części tablicy (linia 49), a zmienna

przechowująca ją jako wartość opadu zostaje usunięta (linia 50).

Dane o wysokości opadu są zapisywane według dodatkowych kryteriów. JeŜeli

pierwszy znak w komórce jest inny niŜ cyfra wtedy dana zapisywana jest jako „-”, co

oznacza brak zjawiska (linie 37-38). Tak więc, aby dana została rozpoznana jako liczba

konieczne jest, aby pierwszy jej znak był cyfrą. ZałoŜenie to wynika z obserwacji

dokonanych podczas badań. Znak informujący o braku zjawiska był często

rozpoznawany jako róŜne kombinacje znaków podobnych do kropki lub kreski, a takŜe

84



jako znak literowy. Natomiast prawie nie występują przypadki, aby został on

rozpoznany jako liczba.

W linii 36, takŜe na podstawie wniosków z badań, umieściłem kod zamieniający

literę „o” na 0. Przypadek ten występuje często, a wiadomym jest, Ŝe w tej części

danych nie powinny występować znaki literowe. Kod ten pozwala na pozbycie się

dodatkowych błędów rozpoznania. MoŜna stworzyć inne, podobne reguły, które naleŜy

umieścić w tej części kodu.

Metoda kończy się po zwróceniu danych w postaci tabeli.

4.4. Sprawdzanie poprawności pozyskanych danych przy

uŜyciu aplikacji

Pozyskanie danych byłoby mało uŜyteczne gdyby nie dało się zweryfikować ich

poprawności. Posiadanie błędnych danych bywa gorsze niŜ ich brak. Badania wykazały,

Ŝe dane znajdujące się w pliku tekstowym powstałym po uŜyciu programu OCR

zawierają znaczną liczbę błędów. JeŜeli proces ten nie podlegałby weryfikacji

stosowanie go nie miałoby w ogóle sensu.

Weryfikacja podstawowa

Dzięki formie, w jakiej podawane są dane o wysokościach opadów w rocznikach

opadowych weryfikacja procesu pozyskiwania danych jest moŜliwa. Tabela

„Wysokości dobowe opadów” zawiera dane o wysokości opadu w kaŜdym kolejnym

dniu miesiąca. Są one wypisane w jednym wierszu tabeli odpowiadającemu jednej stacji

pomiarowej. Na końcu kaŜdego wiersza znajduje się dodatkowa komórka zawierająca

sumę opadów dla całego miesiąca. Pobrane dane są więc moŜliwe do zweryfikowania

przez porównanie sumy wyliczonej przez dodanie wartości opadu w kaŜdym dniu

z wartością wielkości opadu dla całego miesiąca podaną niezaleŜnie. Zadanie to

realizuje metoda sprawdzWDO klasy Sprawdzacz .

85



Inne moŜliwości weryfikacji

JeŜeli aplikacja byłaby rozwijana moŜliwe jest zaimplementowanie metod

pobierających dane z innych tabel rocznika, które zawierają m.in. wyselekcjonowane

informacje o wysokościach opadu. W roczniku znajdują się tabele „Miesięczne i roczne

sumy opadów oraz maksymalne wartości dobowe i daty ich występowania” i „Liczba

dni z opadem ≥ 0,1, ≥ 1,0, ≥ 10,0 mm”. Kiedy zgromadzone zostaną podstawowe dane

o wysokościach opadów dla kaŜdego dnia roku na po ich pozyskaniu z tabeli

„Wysokości dobowe opadów”, moŜna łatwo zaprogramować algorytm tworzący

zestawienie danych takie jak w dwóch pozostałych tabelach. Przez porównanie tych

niezaleŜnie stworzonych zestawów danych moŜna byłoby dokonać kolejnej weryfikacji.

Skuteczność procedur weryfikacji

Niestety, nawet przy zastosowaniu kilkustopniowej weryfikacji danych nie

moŜna być stuprocentowo pewnym, Ŝe nie zawierają one Ŝadnego błędu. W przypadku

zastosowania metody sprawdzaczWDO teoretycznie jest moŜliwa sytuacja, Ŝe

wartości wysokości opadów w kolejnych dniach miesiąca mogą zawierać błędy, ale ich

suma będzie się zgadzała z sumą miesięczną prawidłowych danych. TakŜe sprawdzenie

poprawności po rozpoznaniu dodatkowych tabel rocznika nie moŜe zapewnić, Ŝe dane

nie zawierają Ŝadnego błędu. I w tym przypadku błędne dane mogą w zestawieniu dać

takie same wyniki jak dane prawidłowe (praktycznie nie jest moŜliwe posiadanie

Ŝadnych danych „prawidłowych”, bo te pozyskane z innych tabel takŜe mogą zawierać

błędy).

Zagadnienie poprawności danych pozyskanych z rocznika jest jak widać bardzo

złoŜone. Badania nad tym problemem mogłyby stać się tematem innej pracy. Do

realizacji celów mojej pracy moŜna przyjąć, Ŝe jeŜeli dokonana byłaby weryfikacja

przeprowadzona na opisane powyŜej sposoby, jakość danych byłaby zadowalająca.

4.4.1. Klasa Sprawdzacz

Opis

Klasa ta jest wykorzystywana do sprawdzania poprawności danych pozyskanych

po wykonaniu metod na obiekcie klasy Pobieracz .

86



Właściwości

Klasa ta posiada jedną własność, która przechowuje ścieŜkę do pliku, z którego

pochodzą sprawdzane dane. Ta własność nosi nazwę sciezka .

Metody

Zaimplementowana metoda słuŜy sprawdzeniu poprawności pozyskanych

danych o wysokościach opadów. Podobnie jak w klasie Pobieracz naleŜałoby

zaimplementować kolejne metody w tej klasie chcąc sprawdzać poprawność innych

rodzajów danych.

void sprawdzWDO ( array $tab ) Metoda ta sprawdza poprawność danych opadowych. Metoda nie zwraca Ŝadnej

wartości, gdyŜ słuŜy ona takŜe do drukowania komunikatów pojawiających się

w dokumencie HTML. Wyświetla informację o ścieŜce do pliku, z którego zostały

pobrane dane i liczbę wierszy zawierających dane. W razie niepoprawności danych

wyświetlana jest takŜe informacja o wierszach, w których występują błędy. Gdy dane są

poprawne pojawia się komunikat o moŜliwości ich zapisania.

4.4.2. Wykorzystanie aplikacji do badań skuteczności

rozpoznawania znaków

Opracowany mechanizm weryfikacji danych moŜe być wykorzystany do

przeprowadzenia kolejnych badań nad skutecznością rozpoznawania. Metoda

sprawdzWDO informuje uŜytkownika ile wierszy z tabeli danych zostało poprawnie

rozpoznanych. Wiadomość tą moŜna wykorzystać, aby porównać z sobą wyniki pracy

programu OCR nad tymi samymi stronami rocznika przy róŜnych ustawieniach

programu i róŜnej jakości pliku z obrazem.

Wyniki tych badań nie mogą być jednak tak dokładne jak wyniki badań

opisanych w rozdziale 3.6, poniewaŜ stosowane jest tylko jedno kryterium do określenia

jakości pozyskanych danych. System ten byłby takŜe nieczuły na małe zmiany jakości

danych. MoŜliwa jest sytuacja, gdy w wyniku porównywania dwóch plików liczba

błędnie rozpoznanych wierszy będzie taka sama, ale liczba pojedynczych błędów

w danych o wysokości opadu będzie się znacząco róŜniła. Bez względu na to ile dany

87



wiersz zawiera pojedynczych błędów, w końcowym zestawieniu traktowany jest on tak

samo jak wiersz z jednym błędem.

Stron rocznika zawiera około pięćdziesięciu wierszy. Skala określająca jakość

wyniku byłaby więc mało rozpięta.

Mimo przedstawionych powyŜej niedogodności myślę, Ŝe osoba chcąca

kontynuować badania moŜe korzystać z wyników pozyskanych przy uŜyciu klasy

Sprawdzacz . Badania, które zostały przeprowadzone i opisane w rozdziale 3.6

stanowią dobry materiał bazowy. Opierając się na wnioskach z tych badań moŜna

podjąć próbę bardziej dokładnego określenia jaki wpływ na skuteczności

rozpoznawania ma jakość obrazu czy ustawienia zastosowane w programie OCR.

4.5. Baza danych

Zaproponowana przeze mnie struktura bazy danych słuŜy przechowaniu danych

o wysokościach opadów. Dodatkowo uwzględniłem takŜe moŜliwość zapisania danych

o typie opadu, których pozyskaniem, jak pisałem w rozdziale 3.6.1, naleŜy

przeprowadzić niezaleŜnie.

POSTERUNKI

* numer_posterunkunazwawyzszego_rzedutotalizatorwysokośc_npmszerokosc_geodlugosc_geodorzeczeuwagi

OPADY

numer_posterunkudatainfo_o_opadziewartośćtypstrona

1 ∞

Rysunek 22. Schemat relacyjnej bazy danych przechowującej dane o opadach.

88



Tabele 18 i 19 szczegółowo przedstawiają strukturę tabel bazy danych.

Dodatkowe komentarze znajdują się pod tabelami.

Tabela 18. Struktura tabeli POSTERUNKI bazy danych przechowującej dane o opadach.

Pole Typ Null Opis

Numer_posterunku int nie Przechowuje numer posterunku. Klucz podstawowy.

Nazwa char nie Przechowuje nazwę posterunku

wyzszego_rzedu enum(tak, nie)

nie Określa czy posterunek jest wyŜszego rzędu

totalizator enum(tak, nie)

nie Określa czy posterunek jest totalizatorem

wysokosc_npm int nie Przechowuje daną o połoŜeniu posterunku (wysokości nad poziomem morza)

szerokosc_geo float nie Przechowuje daną o połoŜeniu posterunku (szerokość geograficzna)

dlugosc_geo float nie Przechowuje daną o połoŜeniu posterunku (długość geograficzna)

dorzecze char nie Przechowuje informację o dorzeczu w jakim znajduje się posterunek

Uwagi text tak Przechowuje dodatkowe uwagi na temat posterunku

Tabela 19. Struktura tabeli OPADY bazy danych przechowującej dane o opadach.

Pole Typ Null Opis

Numer_posterunku int nie Przechowuje numer posterunku z tabeli POSTERUNKI

Data date nie Przechowuje datę wykonania pomiaru

info_o_opadzie

set(wartosc, brak zjawiska, brak danych, wartosc watpliwa, wartosc oszacowana)

nie Przechowuje informację o wartości opadu (więcej w opisie)

wartosc float tak Przechowuje wartość opadu

Typ

enum(deszcz, burza, burza odlegla, snieg, snieg ziarnisty, krupy sniezne, ziarna lodowe, grad)

nie Przechowuje daną o typie opadu

Strona int nie Przechowuje numer strony, z której pobrano dane

89



Baza danych składa się z dwóch tablic. Występuje w niej relacja typu „jeden do

wielu”. Jednemu posterunkowi odpowiada wiele pomiarów wysokości opadu. Numer

posterunku jest unikalny, moŜna więc potraktować go jako klucz tej relacji.

W tabeli POSTERUNKI oprócz informacji o stacjach pomiarowych

postanowiłem dodać pole przechowujące dodatkowe uwagi uŜytkownika. MoŜna w nim

zapisać na przykład notatki o ewentualnej zmianie połoŜenia posterunku.

Dane o wysokości opadu nie zawsze podane są w postaci liczby11. MoŜliwe jest,

Ŝe zjawisko nie wystąpiło lub nie ma o nim danych, dlatego pole przechowujące

wartość opadu moŜe być puste. Pomiar wysokości opadu moŜe być wątpliwy lub

oszacowany. Pole info_o_opadzie zostało stworzone, aby informacje o tym zostały

przechowane.

Zapisanie strony rocznika opadowego, z jakiej pochodzą dane, ułatwi

odnalezienie ich w zbiorze drukowanym. Informacje o roku moŜna pozyskać z daty.

4.6. Prezentacja aplikacji

Rozdział ten jest prezentacją aplikacji, która została nazwana „Nimbi 0.4”. Na

rysunkach 23–25 przedstawiłem zrzuty ekranu demonstrujące przebieg podstawowego

procesu, jaki został zaimplementowany, czyli pobierania danych o wysokościach

opadów. Pierwszy rysunek prezentuje aplikację w jej środowisku pracy – przeglądarce

internetowej.

11 Więcej na ten temat napisałem w rozdziale 2.

90



Rysunek 23. Zrzut ekranu aplikacji w środowisku pracy. Proces pobierania danych opadowych, część pierwsza - wybór pliku z danymi.

Rysunek 23 przedstawia aplikację w pierwszej część procesu. NaleŜy wybrać

rodzaj danych, jakie będzie zawierał plik. Domyślnie są to „wysokości dobowe

opadów”, gdyŜ ten element został oprogramowany. JeŜeli aplikacja będzie rozwijana

mogą znaleźć się tu opcje takie jak: „stacje pomiarowe” czy „wysokości dobowe

pokrywy śnieŜnej”. Po wybraniu pliku naleŜy kliknąć „Pobierz”.

91



Rysunek 24. Zrzut ekranu aplikacji. Proces pobierania danych opadowych, część druga - wynik pobierania, wiersze błędnie rozpoznane.

Rysunek 24 prezentuje aplikację podczas kolejnego etapu pobierania danych

opadowych. Drukowane są podstawowe informacje o operacji. Podawana jest ścieŜka

do pliku, z jakiego zostały pobrane dane i wynik operacji: liczba wszystkich wierszy

zawierających dane opadowe oraz liczba poprawnie rozpoznanych wierszy. PoniŜej

tych danych aplikacja drukuje takŜe informacje, które wiersze zostały źle rozpoznane.

Id i nazwa ułatwiają znalezienie wiersza z błedem w pliku, z którego dane zostały

pobrane. Pokazywana jest takŜe wyliczona suma, suma odczytana i róŜnica między

nimi. Te dane są pomocne przy szukaniu błędu. JeŜeli w którejś komórce kolumny

„Odczytana suma” znajduje się znak „-” znaczy to, Ŝe liczba określająca sumę została

błędnie rozpoznana, musiała zawierać znak inny niŜ liczba. JeŜeli róŜnica pomiędzy

obiema sumami jest dodatnia oznacza to, Ŝe wśród danych o opadach z kolejnych dni

miesiąca brakuje jakichś wartości. JeŜeli róŜnica jest ujemna to suma wyliczona

92



z danych jest większa od sumy rozpoznanej z pliku. Oba przypadki widać na rysunku

24. Znajomość liczby określającej róŜnicę jest takŜe bardzo pomocna, poniewaŜ

uŜytkownik moŜe łatwo dowiedzieć się czy poprawienie jednego błędu, który znalazł

w wierszu spowoduje poprawne odczytanie danych, czy naleŜy szukać kolejnych

błędów. Znając róŜnice moŜna takŜe poszukiwać w pliku wynikowym brakującej

liczby.

Sugeruję, aby pobieranie danych odbywało się tuŜ po przetworzeniu pliku

w programie OCR. Mając uruchomiony program OCR i widząc informacje o błędach

w aplikacji „Przetwarzasz”, moŜna dokonać ich łatwej korekcji. JeŜeli poprawiony

wynik rozpoznania zapiszemy do tego samego pliku wystarczy wybrać „Pobierz

ponownie” a proces pobierania danych odbędzie się powtórnie na bazie poprawionego

pliku.

Podczas pracy z aplikacją moŜemy wielokrotnie powracać do widoku, jaki

znajduje się na rysunku 24. Będzie się to działo za kaŜdym razem, gdy jakiś wiersz

zostanie rozpoznany niepoprawnie.

93



Rysunek 25. Zrzut ekranu aplikacji. Proces pobierania danych opadowych, część trzecia - dane pobrane poprawnie.

Na rysunku 25 znajduje się zrzut ekranu aplikacji, jaki pojawi się gdy proces

pobierania danych przebiegnie poprawnie. Obie sumy: rozpoznana z pliku i wyliczona

z rozpoznanych danych opadowych, są sobie równe. MoŜna zapisać dane do bazy

wybierając „Zapisz w bazie danych”.

94



5.

Weryfikacja opracowanego systemu

W rozdziale tym opisane są testy jakie przeprowadziłem w celu weryfikacji

skuteczności opracowanego systemu pozyskiwania danych.

95



5.1 Przeprowadzone testy

Po opracowaniu systemu półautomatycznego przetwarzania danych, chciałem

sprawdzić jak zaproponowane rozwiązanie funkcjonuje w praktyce. Dlatego teŜ

przeprowadziłem dwa testy. W pierwszym z nich stronę rocznika poddałem

przetwarzaniu z zastosowaniem zaprojektowanego systemu, w drugim dane ze strony

wprowadzałem do komputera ręcznie.

Porównanie wyników obu testów miało dać odpowiedź na pytanie czy

stosowanie systemu jest racjonalne. Wynik miał w prosty sposób określić czy

w procesie przetworzenia danych z pojedynczej strony rocznika mniej czasochłonne jest

wykorzystanie technik komputerowych czy wprowadzenie danych manualnie.

Kryterium to wraz z kryterium poprawności pozyskanych danych jest podstawowym

miernikiem uŜyteczności systemu. Wyniki przedstawiam poniŜej.

5.2. Test systemu

Wykonując test systemu przeszedłem przez proces przetwarzania pojedynczej

strony rocznika od początku do końca. Zacząłem od pracy z obrazem pliku w programie

Gimp i jego rozpoznania przy pomocy programu FineReader. Następnie wykorzystałem

zaprojektowaną aplikację Nimbi do pobrania danych. W trakcie tego procesu

wykonałem korekcję pliku wynikowego.

Test wykonałem na stronie 105 rocznika „Opady atmosferyczne 1976”.

Wybrałem ją jako reprezentatywny materiał, gdyŜ obraz tej strony jest średniej jakości

i zawiera średnią liczbę danych w porównaniu z innymi stronami rocznika.

Zmierzyłem czas, jaki zajmuje wykonanie całego zadania i poszczególnych jego

etapów. Zanotowałem dodatkowe informacje o pracy, jaką musiałem wykonać nad

zmianą szablonu rozpoznawanego obrazu w programie OCR. Zapisałem takŜe liczbę

błędów w pliku wynikowym, które wystąpiły przy kolejnych próbach pobrania danych.

Tabela 20 przedstawia kolejność wykonywanych czynności i czas, jaki minął od

rozpoczęcia wykonywania zadania do chwili ich ukończenia.

96



Tabela 20. Czas pracy nad przetwarzaniem danych z jednej strony rocznika opadowego.

Lp. Wykonywana czynno ść

Czas od

startu

[min]

1 Start 0:00

2 Obróbka pliku w programie graficznym Gimp 1:23

3 Ogólne ustalenie obszarów rozpoznawania 2:44

4 Pierwsze rozpoznanie 3:42

5 Korekcja ustawień separatorów 7:29

6 Drugie rozpoznanie 8:59

7 Zapisanie wyniku rozpoznania 9:36

8 Pierwsze poprawienie pliku z danymi 26:53

9 Drugie poprawienie pliku z danymi 34:40

10 Koniec - trzecie poprawienie pliku z danymi 41:24

Obróbki graficznej plików wykonanej jako czynność numer 2 dokonałem na

podstawie wniosków z badań przedstawionych w rozdziale 3.6. Korekcie podlegała

jasność (zmniejszona o 40 jednostek programu) i kontrast (zwiększony o 5 jednostek).

Na czynność numer 3 oprócz ustawienia obszarów rozpoznawania według schematu

opisanego w rozdziale 3.4 składa się takŜe uruchomienie programu i otwieranie pliku

z obrazem.

Poprawienie ustawienia separatorów zajęła mi 3 minuty 45 sekund. Podczas jej

wykonywania musiałem dodać w szablonie aŜ 47 separatorów poziomych. W trakcie

badań opisanych w rozdziale 3.6 liczba ta była zazwyczaj znacznie mniejsza.

Usuniętych zostało 11 separatorów poziomych. Ustawienie separatorów pionowych nie

musiało być poddane Ŝadnym korekcjom.

Po drugim rozpoznaniu i zapisaniu wyniku w pliku HTML zacząłem uŜywać

aplikacji Nimbi do pobierania danych. Pierwsze dwie próby wykazały błędy w danych,

jednak po trzeciej korekcji pliku wynikowego proces został zakończony pomyślnie.

Wykonanie wszystkich czynności zajęło mi 41 minut i 24 sekundy.

97



W tabeli 21 przedstawiam wyniki pobierania danych, które określają liczbę

poprawnie rozpoznanych wierszy przy kolejnych próbach. Liczba wszystkich wierszy

z danymi to 47. Próba numer 1 to pobranie danych z pliku pozyskanego bezpośrednio

z programu OCR, bez Ŝadnych korekcji.

Tabela 21. Liczba poprawnie rozpoznanych wierszy po kolejnych próbach pobrania danych z wykorzystaniem aplikacji Nimbi.

Próba Liczba poprawnie

rozpoznanych wierszy

1 18 na 47

2 37 na 47

3 42 na 47

5.3. Test manualnego wprowadzania danych

Test wykonałem imitując sposób, w jaki uŜytkownik musiałby wprowadzać

dane gdyby stworzony został system pobierający dane wpisywane ręcznie.

Przygotowałem plik arkusza kalkulacyjnego z ponumerowanymi kolumnami

odpowiadającymi kolejnym dniom miesiąca. Do arkusza wpisywałem dane

o wysokościach opadów, czyli dokładnie te same dane, jakie zostały pozyskane we

wcześniejszym teście.

W połowie wykonywania testu zrezygnowałem z dalszej pracy. Wyniki, jakie

uzyskałem po wprowadzeniu dokładnie połowy danych, czyli dwudziestu trzech i pół

wiersza stanowiły wystarczający zasób informacji do wyciągnięcia wniosków.

Czas, jaki zajęło mi wprowadzenie połowy danych to: 39 minut i 36 sekund.

Aby sprawdzić ich poprawność tak jak w algorytmie sprawdzającym systemu

porównywałem sumy: odczytaną ze strony rocznika i wyliczoną. Jak się okazało

w dwóch wierszach popełniłem błędy, których korekcja zajęła mi dodatkowe 2 minuty

32 sekundy.

98



Całkowity czas, jaki zajął proces wpisania połowy danych wynosi więc 42

minuty 8 sekund. MnoŜąc tę wartość przez 2 uzyskamy czas, jaki przypuszczalnie

zajęłoby ręczne wprowadzenie wszystkich danych. Wynosi on 1 godzinę 24 minuty i 16

sekund.

Czasy, jakie podaję nie uwzględniają okresów, w których odrywałem się od

pracy na krótki odpoczynek. Normalnie pracujący człowiek prawdopodobnie nie był by

w stanie przepisać wszystkich danych bez przeznaczenia chwili na odpoczynek.

Rzeczywisty czas pracy mógłby się więc dodatkowo wydłuŜyć.

5.4. Wnioski z testów

Wyniki testów, jakie przeprowadziłem w celu określenia uŜyteczności

zaprojektowanego systemu zaskoczyły mnie pozytywnie. Wynika z nich, Ŝe

wykorzystanie systemu znacząco wpływa na czas, jaki trzeba poświęcić na pobranie

danych z rocznika opadowego. Zastosowanie opracowanego systemu zwiększa

wydajność pracy o około połowę.

JeŜeli chodzi o czas, półautomatyczne przetwarzanie danych daje lepsze efekty

niŜ pozyskiwanie manualne. JeŜeli chodzi o poprawność danych, intuicyjnie moŜna

uznać ją jako zbliŜoną. System mógł źle rozpoznać liczby będące danymi i sprawdzenie

ich poprawności, na sposób opisany w rozdziale 4.4, moŜe nie wykazać tego błędu.

Jednak przy pracy manualnej moŜe zdarzyć się, Ŝe dane zostaną wpisane w złą

kolumnę, co przypisze je do nieodpowiedniego dnia miesiąca. W tym wypadku

sprawdzenie poprawności danych poprzez porównanie sum takŜe nie wykaŜe błędu.

Podsumowując: zastosowanie półautomatycznego systemu przetwarzania

danych o wysokościach opadów pozwala na skrócenie czasu pracy w stosunku do

ręcznego pozyskiwania tych samych danych.

99



6.

Podsumowanie

Rozdział ten stanowi podsumowanie całości pracy i zawiera końcowe uwagi.

100



Konwersję danych ze zbiorów drukowanych do danych zapisanych

w komputerowej bazie moŜna podzielić na dwa główne etapy:

1. Przetworzenie druku na plik z obrazem i rozpoznanie tego obrazu

w programie OCR - wynikiem tego etapu jest plik tekstowy.

2. Ekstrakcja danych z pliku tekstowego przy pomocy specjalnie stworzonej

aplikacji - dane zapisywane są w komputerowej bazy danych.

W niniejszej pracy dokonałem wyboru narzędzi i technologii, które umoŜliwiają

wykonanie obu zadań. Zagadnienie zostało opracowane na przykładzie pozyskiwania

danych ze stron rocznika opadowego zawierających wysokości dobowe opadów.

Do pierwszego etapu zaproponowałem uŜycie programu FineReader 8.0.

Wykonałem szereg badań pozwalających opracować strategię pracy z programem oraz

wyciągnąć wnioski odnośnie wpływu wstępnej, graficznej obróbki obrazów

i zastosowania funkcji douczania na skuteczność rozpoznawania. Główne wnioski

z tych badań to:

• konieczne jest dokonanie separacji procesu pozyskania danych o wysokości

i typie opadu;

• najodpowiedniejszą do zastosowania rozdzielczością obrazów ze stronami

rocznika jest 600dpi;

• zmniejszenie jasności obrazów powoduje polepszenie skuteczności procesu

rozpoznawania;

• nieznaczne zwiększenie kontrastu moŜe takŜe podnieść skuteczność;

• zastosowanie dodatkowych wzorców znaków stworzonych przez uŜytkownika w

większości przypadków nie przynosi pozytywnych skutków;

• moŜna zastosować szereg reguł zamiany znaków w wyniku rozpoznania, co

pozwoli na wykluczenie wielu błędów.

Do realizacji drugiego etapu przetwarzania zaprojektowałem własną aplikację.

UŜycie istniejących klas PHP nie przyniosło rezultatu, dlatego zaprogramowałem

własne klasy dostosowując je do specyficznego zadania jakie miały wykonywać.

Stworzona aplikacja pozwala takŜe na weryfikację wyniku rozpoznawania.

101



Zaproponowałem więc zastosowanie tej własności do przeprowadzenia bardziej

szczegółowych badań nas skutecznością rozpoznawania.

Podejmując się pracy nie wiedziałem jakie będą jej wyniki. Nie moŜna było

określić czy opracowany system będzie działał na tyle skutecznie, Ŝe jego zastosowanie

będzie racjonalne. Wyniki pierwszych badań nastawiły mnie bardzo sceptycznie.

Kontynuowałem jednak prace starając się opracować szereg działań wspomagających

proces rozpoznawania. Zaprojektowałem aplikację tak, Ŝe ułatwia uŜytkownikowi

korekcję błędów tego procesu. Ostateczna próba zastosowania stworzonego systemu

przyniosła pozytywne rezultaty.

Bazując na opracowanych przeze mnie rozwiązaniach moŜna rozwijać aplikację

zwiększając zakres jej działania. MoŜliwe jest takŜe bardziej dogłębnie zbadanie metod

na poprawę skuteczności programu OCR. Półautomatyczne pozyskiwanie danych

z roczników opadowych jest moŜliwe i zagadnienie to warte jest dalszej pracy.

102



Spis tabel

Tabela 1. Budowa strony rocznika opadowego zawierającej dane o wysokościach opadów......................................................................................................................9

Tabela 2. Symbole opadów atmosferycznych zastosowane w roczniku opadowym. ....10

Tabela 3. Przykłady błędów spowodowanych nieprawidłowym podziałem szablonu na komórki...............................................................................................24

Tabela 4. Przykłady błędów rozpoznania wynikających z nieprawidłowej rotacji obrazu......................................................................................................................34

Tabela 5. Liczba wszystkich błędów w rozpoznanych stronach zaleŜnie od rozdzielczości pliku z obrazem...............................................................................36

Tabela 6. Liczba błędów w danych opadowych rozpoznanych stron zaleŜnie od rozdzielczości pliku z obrazem...............................................................................36

Tabela 7. Wartość błędu względnego rozpoznania stron zaleŜnie od rozdzielczości pliku z obrazem.......................................................................................................36

Tabela 8. Wyniki rozpoznania kolejnych próbek strony 53 w zaleŜności od jasności i kontrastu obrazu......................................................................................41




Tabela 12. Liczba wszystkich błędów rozpoznania zaleŜnie od zastosowanych wzorców znaków. ...................................................................................................53

Tabela 13. Liczba błędów rozpoznania danych opadowych zaleŜnie od zastosowanych wzorców znaków. ..........................................................................53

Tabela 14. Wartość błędu względnego rozpoznania zaleŜnie od zastosowanych wzorców znaków. ...................................................................................................54

Tabela 15. Klasyfikacja rozpoznań próbek przy zastosowaniu róŜnych zestawów wzorców według systemu ocen. .............................................................................56

Tabela 16. Suma wszystkich błędów rozpoznania prób wykonanych na wszystkich próbkach zaleŜnie od zastosowanych wzorców...................................56

Tabela 17. Liczba zaznaczonych i niezaznaczonych błędów w wynikach rozpoznania wszystkich próbek. .............................................................................58

Tabela 18. Struktura tabeli POSTERUNKI bazy danych przechowującej dane o opadach. ..................................................................................................................88

Tabela 19. Struktura tabeli OPADY bazy danych przechowującej dane o opadach. .....88

103



Tabela 20. Czas pracy nad przetwarzaniem danych z jednej strony rocznika opadowego. .............................................................................................................96

Tabela 21. Liczba poprawnie rozpoznanych wierszy po kolejnych próbach pobrania danych z wykorzystaniem aplikacji Nimbi..............................................97

104



Spis rysunków

Rysunek 1. Schemat struktury strony rocznika opadowego zawierającej dane o wysokościach opadów. .............................................................................................8

Rysunek 2. Maska filtra maksymalnego i minimalnego stosowanego do binaryzacji obrazu [źródło: Gajer, 2008]................................................................15

Rysunek 3. Podział obrazka z pojedynczym znakiem na dwadzieścia pięć sektorów [źródło: Gajer, 2008]...............................................................................15

Rysunek 4. Zrzut ekranu środowiska pracy programu Finereader 8.0. ..........................18

Rysunek 5. Przykładowe okno ustawień formatu HTML pliku z rozpoznanym tekstem . ..................................................................................................................22

Rysunek 6. Liczba wszystkich błędów rozpoznawania w zaleŜności od rozpoznawanej strony i rozdzielczości obrazu. ......................................................37

Rysunek 7. Wartość błędu względnego rozpoznania w zaleŜności od rozpoznawanej strony i rozdzielczości obrazu. ......................................................38

Rysunek 8. Przykładowy histogram. ..............................................................................39

Rysunek 9. ZaleŜności liczby wszystkich błędów rozpoznania od średniej i odchylenia standardowego rozkładu jasności w próbkach strony 53 .....................47

Rysunek 10. ZaleŜności liczby wszystkich błędów rozpoznania od średniej i odchylenia standardowego rozkładu jasności w próbkach strony 77. ....................48

Rysunek 11. ZaleŜności liczby wszystkich błędów rozpoznania od średniej i odchylenia standardowego rozkładu jasności w próbkach strony 97. ....................48

Rysunek 12. ZaleŜności liczby wszystkich błędów rozpoznania od średniej i odchylenia standardowego rozkładu jasności w próbkach strony 128. ..................49

Rysunek 13. ZaleŜności liczby wszystkich błędów rozpoznania od ustawień jasności i kontrastu zastosowanych do otrzymania próbek strony 53. ...................50



Rysunek 16. ZaleŜności liczby wszystkich błędów rozpoznania od ustawień jasności i kontrastu zastosowanych do otrzymania próbek strony 128. .................52

Rysunek 17. Liczba wszystkich błędów rozpoznania próbek w zaleŜności od zastosowanych wzorców znaków. ..........................................................................54

Rysunek 18. Wartość błędu względnego rozpoznania próbek w zaleŜności od zastosowanych wzorców znaków. ..........................................................................55

Rysunek 19. Liczba oraz procentowy udział zaznaczonych i niezaznaczonych błędów rozpoznania danych opadowych we wszystkich próbkach........................59

105



Rysunek 20. Liczba oraz procentowy udział zaznaczonych i niezaznaczonych błędów rozpoznania nazw stacji we wszystkich próbkach.....................................59

Rysunek 21. Uproszczony schemat blokowy algorytmu pobierania danych o wysokościach opadów. ...........................................................................................74

Rysunek 22. Schemat relacyjnej bazy danych przechowującej dane o opadach............87

Rysunek 23. Zrzut ekranu aplikacji w środowisku pracy. Proces pobierania danych opadowych, część pierwsza - wybór pliku z danymi. ................................90

Rysunek 24. Zrzut ekranu aplikacji. Proces pobierania danych opadowych, część druga - wynik pobierania, wiersze błędnie rozpoznane..........................................91

Rysunek 25. Zrzut ekranu aplikacji. Proces pobierania danych opadowych, część trzecia - dane pobrane poprawnie. ..........................................................................93

106



Bibliografia

1. Bergmann Sebastian. PHP5: profesjonalne tworzenie oprogramowania. Helion, 2006.

2. Bieniecki Wojciech. Analiza wymagań dla metod przetwarzania wstępnego obrazów w automatycznym rozpoznawaniu tekstu. Automatyka, 2005, vol. 9/3.

3. Czajkowska Edyta. Cyfrowe czytanie. PC World Komputer. 2000, nr 02.

4. Dołęga Cezary. Pecet uczy się czytać. Chip. 1998, nr 11.

5. Gajer Mirosław. Systemy optycznego rozpoznawania znaków pisma. Pomiary Automatyka Robotyka, 2008, nr 04.

6. International Journal on Document Analysis and Recognition. Springer, 2007 vol. 9–10.

7. InŜynieria oprogramowania w projekcie informatycznym. Red. Górki Janusz. Mikom, 1999.

8. Opady atmosferyczne 1965. Red. Janiszewski Feliks. Wydawnictwa Komunikacji i Łączności, 1973.

9. Opady atmosferyczne 1976. Red. Stańczak Irena. Wydawnictwa Komunikacji i Łączności, 1980.

10. Orłowski Jacek. Tekst pOCRojony. Chip. 2004, nr 02.

11. PHP5, Apache i MySQL od podstaw. Naramore Elizabeth, Gerner Jason, Le Csouarnec Yann, Stolz Jeremy, Glass Michael. Helion, 2005.

12. PHP5: zaawansowane programowanie. Lecky-Thomson Ed, Eide-Goodman Heow, Nowicki Steven D., Cove Alec. Helion, 2005.

13. Śluzek Andrzej. Komputerowa analiza obrazów. Wydawnictwa Politechniki Warszawskiej, 1991.

14. Welling Luke, Thomson Laura. PHP i MySQL. Tworzenie stron WWW. Vademecum profesjonalisty. Wyd. 3. Helion, 2005.

15. Węglarczyk Stanisław. Metody statystyczne: skrypt dla studentów wyŜszych szkół technicznych. Wyd.2. Politechnika Krakowska im. Tadeusza Kościuszki, 1996.

107



Netografia

1. PHP: Podręcznik PHP – Manual [http://php.net.pl/manual/pl]

2. World Wide Web Consorcium [http://www.w3.org]

3. Free CSS templates [http://www.freecsstemplates.org]

4. Kurs HTML [http://www.kurshtml.boo.pl]

5. Dyskusje pl.lang.php [http://groups.google.com/group/pl.comp.lang.php]

6. Understanding OCR [http://www2.mustek.com/Class/ocrinfo.html]

108



Abstrakt

Nikogo nie trzeba przekonywać o zaletach gromadzenia danych w postaci

elektronicznej. Obecnie wszystkie firmy i instytucje magazynują dane przede

wszystkim przy uŜyciu systemów komputerowych. Ale co z danymi z przed lat? Co ze

zbiorami zgromadzonymi w postaci drukowanej? Jak je przetworzyć na formę

elektroniczną? Na te i inne pytania odpowiada niniejsza praca. Prezentuje ona system,

jaki został stworzony w celu półautomatycznego pozyskiwania danych z roczników

opadowych. Do optycznego rozpoznawania znaków z zeskanowanej strony rocznika

wykorzystano program OCR – FineReader 8.0. Określono jak naleŜy skonfigurować to

narzędzie oraz ustalono format pliku wyjściowego. Przeprowadzono takŜe badania

wpływu jakości obrazu i zastosowania funkcji douczania programu OCR na

efektywność procesu rozpoznawania. Wprowadzenie danych do komputerowej bazy

wymaga ich ekstrakcji z pliku otrzymanego w wyniku działania OCR’a. W tym celu

zaprojektowano autorską aplikację – Nimbi 0.4. Aplikacja, stworzona w języku PHP,

umoŜliwia wyodrębnienie danych, sprawdzenie ich poprawności i zapisanie w bazie

danych MySQL. Ostatnim elementem pracy jest weryfikacja stworzonego systemu

przez porównanie jego skuteczności ze skutecznością manualnego pozyskiwania

danych. Opracowany system moŜe być rozwijany a odpowiednio zmodyfikowany

wykorzystany do przetwarzania innego rodzaju danych.

109



Abstract in English

The advantages of assembling data in electronic form are nowadays the common

knowledge. Every company and institution stores data by means of computer systems.

But what about data from the past? What about printed sets of data? How should the

data be processed into the electronic form? The aim of the master thesis is to answer

these and other questions. It aims at presenting the system that was created for semi-

automatic data acquisition from precipitation yearbook. OCR program – FineReader 8.0

was applied for optical character recognition from scaned pages of a yearbook. It was

determined how this tool should be configurated. Data format of result file was chosen.

Investigations of influence of scan quality and usage of training mode was conducted.

Entering data into computer date base requires their extraction from the text file gained

from OCR program. For this task the author’s application – Nimbi 0.4 was created. The

application programmed in PHP enables separating data, checking their correctness and

writing into MySQL data base. The last stage of the thesis is the verification of created

system which is followed by efficacy of the system and manual data acquisition. The

designed system can be expanded and, if properly modified, applied to process other

types of data.

110



Słowa kluczowe:

pozyskiwanie danych, opady atmosferyczne, przetwarzanie danych, roczniki opadów

atmosferycznych, OCR, optyczne rozpoznawanie znaków, finereader, ekstrakcja

danych, rozpoznawanie tekstu, skuteczność rozpoznawania znaków.

Kontakt z autorem:

e-mail: [email protected]

telefon: + 48 508 901 199

Documents

Kamil Zieli ński PÓŁAUTOMATYCZNE POZYSKIWANIE DANYCH Z ...holmes.iigw.pl/~rszczepa/dyplomy/2139_Kamil_Zielinski.pdf · w aplikacji, omówienie jej składników, prezentacja jej