\chapter{Eksperyment na podstawie danych Newspaper Navigator}\hypertarget{chap:4}{}
W niniejszym rozdziale opisane zostało autorskie podejście do uprzednio opisywanego problemu. Na jego kolejnych stronach przedstawiona zostanie całość procesu budowania opartej na sztucznych sieciach neuronowych aplikacji, pozwalającej na wyszukanie dowolnych treści wizualnych znajdujących się w omawianym zbiorze danych poprzez obsługę tekstowych zapytań użytkownika. Proces działania całej aplikacji opisuje schemat przedstawiony na rysunku \ref{schemat_aplikacji}.
\item pozyskiwanie obrazów o wysokiej rozdzielczości przy użyciu robota internetowego (\emph{z ang. web scraper}),
\item przetworzenie obrazów wraz z ich adnotacjami do użytecznej postaci,
\item zbudowanie modelu detekcji treści wizualnych pojawiających się w gazetach z wykorzystaniem metod głębokiego uczenia maszynowego,
\item ladrowanie wykrytych obiektów z testowego zestawu oryginalnych obrazów, zastosowanie na nich systemu OCR, wyodrębnienie słów kluczowych oraz zapisanie wyników w bazie danych,
\item implementacja silnika wyszukiwania pełnotekstowego,
\item zaprojektowanie graficznego interfejsu użytkownika, który wyświetla wybrane treści wizualne zgodne z zapytaniem tekstowym użytkownika.
Całość prac związanych z przygotowaniem rozwiązania wykonana została przy użyciu języka programowania Python oraz korzystając z dostępnych rozszerzeń jego funkcjonalności w postaci różnorodnych bibliotek programistycznych. Repozytorium kodu jest ogólnodostępne i znajduje się pod następującym adresem internetowym: \url{https://github.com/yngalxx/Master_degree}. Cały kod, jaki został napisany na potrzeby opisywanego rozwiązania liczy, 23 skrypty co w przybliżeniu daje około 2,8 tysiąca linijek kodu. Najważniejsze foldery wchodzących w skład repozytorium przedstawione zostały poniżej:
\item[$\bullet$]\textbf{cropped\_visual\_content} -- wykadrowane treści wizualne.
\item[$\bullet$]\textbf{model\_config} -- folder ten zawiera zapisany model, statystyki ewaluacyjne z ostatniej epoki treningu, a także parametry konfiguracyjne modelu.
\item[$\bullet$]\textbf{data} -- na folder data składają się 3 inne foldery o takiej samej strukturze (2 plik tekstowe, jeden z nazwami obrazów wchodzących w skład zbioru, a drugi z odpowiadajacymi im adnotacjami), każdy z nich odnosi się do innego zbioru danych (uczącego, walidacyjnego lub testowego).
\item[$\bullet$]\textbf{logs} -- zbiór plików odpowiadające konkretnym skryptom z folderu src\textbackslash runners, które zbierają chronologiczne zapisy zdarzeń i statystyki (logi), służące do późniejszej analizy działania aplikacji.
\item[$\bullet$]\textbf{ocr\_database} -- baza danych zawierająca wyniki otrzymane z systemu OCR.
\item[$\bullet$]\textbf{scraped\_photos} -- pozyskane za pomocą robota internetowego obrazy.
\item[$\bullet$]\textbf{source\_annotations} -- oryginalne adnotacje do obrazów pobrane z repozytorium Newspaper Navigator.
\item[$\bullet$]\textbf{src} -- rdzeń aplikacji i całe jej zaplecze techniczne.
\item[$\bullet$]\textbf{runners} -- zestaw skryptów wywoływanych z wiersza poleceń uruchamiających odpowiednie fragmenty kodu zgromadzonego w folderze lib.
\item[$\bullet$]\textbf{lib} -- zbiór skryptów zawierających skategoryzowane w odpowiednie pliki, klasy i funkcje, wywoływane następnie przez skrypty z folderu runners.
Repozytorium wzbogacono o CI/CD z pomocą rozszerzenia oferowanego przez używany system kontroli wersji, tj. GitHub Actions \cite{BibEntry2022Sep_GH_actions}. W tym przypadku CI/CD odpowiedzialne było za automatyczne formatowanie kodu z wykorzystaniem narzędzia jakim jest Black \cite{BibEntry2022Sep_black}, w trosce o przejrzystość i jakość kodu samego rozwiązania, a także jego zgodność z przyjętym kanonem dobrych praktyk programowania.
Z oryginalnego repozytorium projektu Newspaper Navigator pobrane zostały pliki zawierające przygotowane adnotacje do zdjęć w formacie JSON. 80\% wszystkich adnotacji przypadło na jeden z plików, kolejne 20\% zaś na drugi, stanowiły one odpowiednio zbiór uczący (treningowy) i testowy. Ważnym było zachowanie tej samej struktury testowego zbioru danych, aby mieć możliwość porównania ich z wynikami pierwowzoru. Dodatkowo, ze zbioru uczącego wyodrębniony został zestaw danych walidacyjnych, którego przeznaczeniem jest możliwość ewaluacji wyników jeszcze podczas trwania samego treningu modelu, po każdej kolejnej epoce. W trosce o stabilność rozwiązania i pewność, aby to zawsze dokładnie ten sam wycinek oryginalnego zbioru danych stawał się zbiorem walidacyjnym, do jego wyboru została wykorzystana funkcja skrótu lub inaczej funkcja haszująca (\emph{z ang. hash function}). Nazwy plików zostały poddane działaniu funkcji haszującej, a następnie przetransformowane do reprezentacji numerycznej, dzięki czemu możliwym było wyekstrahowanie podzbioru zdjęć, który na późniejszym etapie posłuży jako zbiór walidacyjny. Na potrzeby tego zbioru poświęcone zostało około 8\% zdjęć należących do pierwotnego zbioru treningowego. Z oryginalnych adnotacji pozyskane zostały współrzędne ramki ograniczającej daną treść wizualną, jej kategorie, a także adres URL do zdjęcia danej strony gazety o wysokiej rozdzielczości. Wyodrębnione jedynie użyteczne elementy oryginalnych adnotacji zostały zapisane w formacie tekstowym, gdzie jeden wiersz odpowiada jednemu zdjęciu gazety. Adnotacje dla poszczególnych treści wizualnych oddzielone są separatorem. Przetworzone adnotacje przechowywane są w folderze 'data', który dodatkowo rozbity jest na 3 foldery reprezentujące konkretne zbiory danych (uczący, walidacyjny lub testowy). Twórcy projektu Newspaper Navigator umieścili zebrane obrazy na internetowym nośniku danych Amazon S3, do ich pobrania zbudowany został robot internetowy przy użyciu biblioteki Requests. W sumie pobrano stamtąd 3\,559 zdjęć o wysokiej rozdzielczości. Liczba zdjęć przypadająca na każdy ze zbiorów danych przedstawia tabela \ref{liczebnosc_moja}.
Porównując tabele przedstawione powyżej z tabelami odnoszącymi się do klas występujących w projekcie Newspaper Navigator, które przedstawione zostały w poprzednim rozdziale, zauważyć można brak jednej klasy, a mianowicie klasy ,,Karykatura''. W rzeczywistości treści wizualne należące do tej klasy były bardzo podobne do tych należących do klasy ,,Komiksy'', dlatego też podjęta została decyzja o połączeniu tych dwóch klas. Obserwacje, które wcześniej były dość kłopotliwe dla modelu, po tej zamianie przestały sprawiać trudności na etapie klasyfikacji. Decyzja ta pozytywnie wpłynęła na ogólną wydajność modelu. Praktycznie wszystkie obserwacje dla etykiety ,,Karykatura'' przedstawione były i tak w formie komiksu, o czym też informuje nas dość dobitnie angielska nazwa tej etykiety: ,,editorial cartoon''.
Jeśli chodzi o samą liczebność adnotacji zbiór Newspaper Navigator oraz ten użyty na potrzeby tego eksperymentu jest identyczny, co warto podkreślić, ponieważ pozwoli to swobodnie porównywać wyniki między projektami. Adnotacje, które zostały pobrane z repozytorium Newspaper Navigator, odpowiadały przeskalowanym już na potrzeby projektu zdjęciom, dlatego też pojawiła się potrzeba dostosowania ich do pozyskanych zdjęć o wyższej rozdzielczości. Oryginalne adnotacje zawierały również rozmiar zdjęcia, któremu odpowiadają, dlatego też nie było większych problemów ze stworzeniem algorytmu do skalowania. Niektóre adnotacje znajdowały się poza granicami pozyskanych obrazów, co musiało być efektem błędów powstałych w trakcie tworzenia adnotacji. Wszystkie tego rodzaju obserwacje zostały poprawione w taki sposób, że zostały nałożone na nie odpowiednie ograniczenia. Statystyki dotyczące tej procedury przedstawia tabela \ref{tab_problem}.
Kolejno na rysunkach \ref{1png}, \ref{2png}, \ref{3png} i \ref{4png} przedstawione zostały przykładowe zdjęcia wraz z adnotacjami już po etapie wstępnego przetwarzania danych.
Jak nietrudno zauważyć, większość treści wizualnych została zaznaczona na zdjęciach gazet, choć niestety zazwyczaj nie są to wszystkie treści, jakie mogłyby zostać oznaczone. Praktycznie na każdym zdjęciu gazety da się znaleźć brakujące elementy. Jest to zdecydowanie czynnik, który pogarsza otrzymywane później wyniki. Model dostaje wówczas sprzeczne informacje, ponieważ raz obiekt wejściowy dla modelu ma być interpretowany jako mapa, a raz bardzo podobna treść jako tło (brak adnotacji). Im lepszej jakości danymi dysponujemy tym lepszych rezultatów możemy się spodziewać. Na tej podstawie sformułować można tezę, że w kolejnych krokach należałoby się skupić na poprawię jakości danych w znacznie większym stopni, aniżeli na poprawianiu działania samego modelu detekcji.
Model detekcji treści wizualnych stworzony na potrzeby tej pracy został napisany korzystając z języka programowania Python, a dokładniej przy użyciu biblioteki programistycznej PyTorch, która pozwala na tworzenie i korzystanie z modeli opartych o sztuczne sieci neuronowe. Wśród konkurencyjnych narzędzi wyróżnia go przede wszystkim używanie dynamicznych grafów obliczeniowych, co ułatwia dostosowywanie i badanie przebiegu tworzonego modelu na bieżąco, kontrolując wykonywany kod linia po linii. Dodatkowo twórcy zadbali o odpowiedni styl kodowania, który wykorzystuje unikalne cechy języka Python, dzięki czemu jest on łatwy do interpretacji i przyjazny do nauki \cite{Paszke2019Dec}.
\newline
Finalne podejście do modelowania opisywanego zagadnienia korzysta z konkretnej architektury głębokich sieci neuronowych, a mianowicie Faster R-CNN z wykorzystaniem wstępnie przetrenowanej sieci ResNet-50 jako szkieletu rozwiązania. Wybór finalnego podejścia nie był zagadnieniem trywialnym, wymagał bowiem przetestowania wielu różnych algorytmów oraz technik modelowania i zajął większość czasu poświęconego na pisanie kodu całego programu. Skrót R-CNN oznacza Region-based Convolutional Neural Network co w tłumaczeniu na język polski oznacza konwolucyjną sieć neuronową opartą na regionach. Przedrostek Faster oznacza zaś jej kolejne ulepszenie. Pierwsza implementacja tej architektury nosiła nazwę R-CNN \cite{Girshick2013Nov}, następna Fast R-CNN \cite{Girshick2015Apr}, zaś aktualnie najnowsza nosi nazwę właśnie Faster R-CNN \cite{Bharati2019Aug}.
Architektura Faster R-CNN zaczyna się od konwolucyjnej sieci neuronowej używanej do proponowania regionów (\emph{z ang. Region Proposal Network - RPN}), które następnie poddawane są klasyfikacji. W przypadku tego podejścia, jak już zostało to wcześniej wspomniane, użyta została w tym celu ResNet-50. Sposób, w jaki został stworzony ResNet, pozwala na trenowanie bardzo głębokich sieci neuronowych (w tym wypadku jest to, jak wskazuje już sama nazwa, 50 warstw) z pominięciem towarzyszących zazwyczaj temu problemów, jakimi są zjawiska zanikającego gradientu (\emph{z ang. vanishing gradient}) oraz eksplodującego gradientu (\emph{z ang. exploding gradient}). Pierwsze z nich dotyczy niewielkich zmian wag sieci podczas procesu uczenia, co w najgorszym przypadku praktycznie stopuje trening całej sieci, drugi zaś jest zjawiskiem przeciwnym, co z kolei powoduje ogromne zmiany wag przez co osiągany poziom błędu drastycznie wzrasta. Jak nietrudno zauważyć, oba te zjawiska są wysoce niepożądane. ResNet pozwolił na rozwiązywanie jeszcze bardziej skomplikowanych problemów z dziedziny komputerowej wizji (\emph{z ang. computer vision}) niż było to możliwe wcześniej. W teorii im głębsza jest sieć (im więcej warstw posiada), tym lepiej i łatwiej uczy się ona trudniejszych, bardziej zaawansowanych wzorców, a gdy do tego wyeliminujemy towarzyszące temu problemy takie jak eksplodujący i zanikający gradient, wówczas otrzymamy niezwykle potężne narzędzie, jakim właśnie jest ResNet. Główna koncepcja tego podejścia skupia się wokół tego, że każda warstwa jest podawana nie tylko do warstwy następnej sieci, ale także bezpośrednio do kolejnych warstw pomijając kilka warstw pomiędzy nimi, jest to tzw. połączenie rezydualne (\emph{z ang. residual connection}) \cite{He2015Dec}. Mechanizm ten został zaprezentowany na rysunku \ref{resnt}.
RPN wyposażona jest zarówno w klasyfikator jak i regresor. Klasyfikator ma za zadanie określić prawdopodobieństwo, czy w zaproponowanym regionie znajduje się szukany obiekt docelowy, zaś regresor określa współrzędne tego regionu. Po mapie cech przesuwa się prostokątne okno o rozmiarze n x n. Dla każdego okna generowanych jest K propozycji regionów o różnych kształtach tzw. kotwic (\emph{z ang. anchors}). W celu wytrenowania RPN każdej propozycji regionu przypisywana jest przez binarny klasyfikator etykieta, czy na danym obszarze znajduje się obiekt, czy tło. Ta etykieta przypisywana jest na podstawie, wcześniej omawianej już, metryki IoU (zobacz rozdział \hyperlink{chap:2}{2}). Etykietę obiektu otrzymują propozycje regionów, dla których wartość tej metryki jest większa niż 0,7 albo między 0,5 i 0,7 włącznie, ale jedynie wtedy, kiedy dla danego okna nie ma kotwicy z wynikiem większym niż 0,7. Następnie na finalnych propozycjach regionów przeprowadzany jest pooling, którego cel jest dokładnie taki sam jak zostało to omówione w rozdziale drugim przy okazji opisu konwolucyjnych sieci neuronowych \cite{Ren2015Jun}.
Tak jak zostało wspomniane to już wcześniej użyta architektura składa się z wstępnie przetrenowanej sieci ResNet-50, co oznacza że początkowe wagi nie zostały wybrane losowo, a były wagami wyjściowymi tego modelu wytrenowanego na konkretnych danych. W tym przypadku był to znany zbiór danych ImageNet \cite{deng2009imagenet}. Jednakże Wszystkie warstwy tej sieci zostały dodatkowo przetrenowane również na posiadanym zbiorze danych. Detektor Faster R-CNN został całkowicie wymieniony i również wytrenowany specjalnie dla omawianego zbioru danych. Cały trening finalnej wersji modelu składający się z 35 epok zajmuje w przybliżeniu 3,5 godziny. Podany czas dotyczy wykonywania przeliczeń na karcie graficznej Nvidia GeForce RTX z 24 GB pamięci VRAM.
Wejściem modelu są zdjęcia gazet w skali szarości przeskalowane do rozmiaru 1024 x 1024 podzielone na 20-elementowe partie (\emph{z ang. batches}). Rozmiar zdjęć do którego były one skalowane, podobnie zresztą jak pozostałe parametry, wybrany został metodą prób i błędów.
\newline
Długość kroku (zobacz rozdział \hyperlink{chap:2}{2}) wynosiła 0,00035, dodatkowo była ona dwukrotnie zmniejszana co każde 7 epok wykorzystując do tego planistę tempa uczenia (\emph{z ang. learning rate scheduler}), aby uniknąć zbyt dużego kroku w późniejszych etapach uczenia powodującego pomijanie minimów optymalizowanej funkcji straty. Podane wartości parametrów zapewniły najlepsze wyniki podczas przeprowadzania eksperymentów treningowych. Do optymalizacji parametrów procesu uczenia się użyty został jeden z najpopularniejszych i najwydajniejszych aktualnie dostępnych optymalizatorów, Adam \cite{Kingma2014Dec}. Swoją popularność zawdzięcza on przede wszystkim szybkości i małej złożoności obliczeniowej, ponadto jest to algorytm adaptacyjny co oznacza, że oblicza on indywidualne tempo uczenia dla różnych parametrów.
\subsection{Analiza predykcji i wyników}
\subsubsection{Wyniki modelu}
Wyniki omówionej wcześniej już metryki mAP wyliczonej na postawie predykcji modelu na dokładnie tym samym zbiorze testowym używanym do demonstracji wyników projektu Newspaper Navigator prezentuje tabela \ref{table_my_map}. Porównując otrzymane wyniki z rezultatami osiągniętymi przez naukowców pracujących nad projektem Newspaper Navigator, zauważyć można, iż dla każdej klasy wytworzony w ramach tej pracy magisterskiej model spisuje się znacznie lepiej. Świadczy o tym również średni wynik metryki, który wynosi $\approx0,72$. Dla porównania w Newspaper Navigator wynik ten wynosił zaledwie $\approx0,63$. Najgorsze wyniki dotyczą klasy 'Ilustracja' i wynoszą jedynie $\approx0,35$, co ciekawe nie jest to najrzadsza klasa w zbiorze, ponieważ takową są mapy. Najlepiej zaś model radzi sobie z etykietą 'Tytuły', co nie może zaskakiwać, ponieważ jest to najliczniejsza i chyba też najbardziej charakterystyczna klasa występująca w tym zbiorze. Zawiera ona jedynie tekst, najczęściej znacznie większy niż inne litery znajdujące się w gazecie, a także zawierający dużo wolnej przestrzeni wokół tekstu. Dlatego też jest to zrozumiałe, iż właśnie ta klasa wypada najlepiej. Ich liczebność jest pięciokrotnie mniejsza niż ilustracji, a wyniki zaś są aż ponad dwukrotnie lepsze.
Na następnej stronie przedstawiona została przykładowa predykcja dla każdej klasy w opisywanym zbiorze danych, tj. reklamy, mapy, ilustracji, tytułu, fotografii, czy komiksu. Na pierwszym obrazie, tj. obrazie \ref{adv2}, przedstawiona została bardzo typowa dla tego zbioru reklama, a mianowicie reklama odzienia wierzchniego. Rysunek \ref{map3} przedstawia zaś mapę obrazującą zjawisko głodu w Europie. Następnie na rycinie \ref{ilustration4} widzimy gęś, a obok niej na kolejnym już obrazie \ref{head}, znajduje się tytuł sekcji. W tytule tym zawarto apel do, jak to nazwano obywateli patriotów, aby wspierali pobór wojenny oraz kupowali wojenne obligacje. Ostatni rysunek w tym rzędzie, czyli rysunek \ref{photo} przedstawia fotografie. Na samym dole, na rycinie \ref{cart}, ostatnią klasę, czyli komiks, reprezentuje rysunkowa historyjka o łowieniu ryb w domowym akwarium.
Jeśli chodzi o błędy jakie popełnia model to analizując wyniki, zauważyć można, że często problematyczne staje się odróżnienie przez niego ilustracji od fotografii i na odwrót. Nie jest to jednak zaskakujące, ponieważ nawet człowiek może mieć z tym zadaniem problem w omawianym zbiorze. Opisane zjawisko przedstawiają predykcje przedstawione na poniższych obrazach.
Kolejny przykładowy zaobserwowany problem to nierównomierność niektórych wyników, pomimo bardzo dużego podobieństwa między treściami wizualnymi które zostały wykryte i tymi które nie zostały, model zdaje się niektóre z nich pomijać. Przykłady o których mowa zlokalizowane są na następnej stronie, kolejno na obrazach \ref{err} oraz \ref{err1}. Na drugim z nich pomimo opisywanego w tym akapicie problemu, dodatkowo jesteśmy świadkami także problemu opisanego w akapicie wyżej.
Na tej i następnych stronach przedstawione zostały przykłady zdjęć gazet, dla których wszystkie możliwe wizualne treści, jakie znajdowały się na obrazach, zostały przez model wykryte, a także poprawnie przypisane do odpowiednich klas. Niestety taki przykładów jest względnie mało, prawie zawsze przynajmniej jednej treści brakuje.
\caption{Cała wizualna treść poprawnie wykryta i zaklasyfikowana, przykład 3}
\end{figure}
Poniżej zaś przygotowane zostało zestawienie predykcji (obrazki po lewej stronie) z oczekiwanymi rezultatami (obrazki po prawej stronie). Na porównaniu tym widzimy, że model nie tylko spełnia oczekiwane rezultaty, ale także ma tendencje do zaznaczania nowych treści, które nie były wcześniej oznaczone w adnotacjach do zbioru.
Dla zaspokojenia ciekawości model został również przetestowany na względnie nowej, oczywiście w odniesieniu do posiadanego zbioru, gazecie. Dodatkowo nie była to gazeta pochodząca ze Stanów Zjednoczonych, a wydawany na terenie naszego kraju ,,Głos Wielkopolski''. Niestety, jak zresztą można było się tego spodziewać, wyniki predykcji prezentują się dość słabo. Na zdjęciu \ref{nowa1} tylko 4 z 12 predykcji można uznać jako trafione, są to kolejno idąc od góry tytuł ,,Przez Wielkopolskę przejdzie 26. Blues Express!'', tytuł ,,W środę w stan spoczynku ma przejść kilkunastu sędziów i prezes SN'', reklama Lotto, a także fotografia policjanta w radiowozie. Pozostałe predykcje, nie mają większego sensu. Ciekawe jednak są dolne predykcje, ponieważ dziwić może fakt, iż nie zostały one sklasyfikowane jako tytuł, lecz jako reklama. Na pierwszy rzut oka wydawać się może, że ich struktura znacznie bardziej pasuje właśnie do etykiety 'Tytuł'.
Przykład drugi wygląda zaś nieco lepiej, ponieważ aż 5 z 6 predykcji jest w miarę sensowna, jedyną nietrafioną klasyfikacją jest reklama na samym dole. Pominięta została jednak spora część treści wizualnych zgromadzonych na zdjęciu.
Jak widać na obrazie \ref{nowa2}, stworzone rozwiązanie nie jest dość uniwersalne, jeśli chodzi o samo ponowne użycie tego konkretnego modelu. Jednakże, cała aplikacja przygotowana została tak, aby móc przetworzyć przez nią dowolny zbiór danych o tej samej strukturze i na tej podstawie swobodnie wytrenować własny model, a jego wyniki poddać kolejnym etapom programu.
\section{Wyszukiwarka obrazów na bazie wyników z OCR}
Dokładnie tak jak obrazował to przedstawiony na początku tego rozdziału diagram, następnym krokiem całego procesu jest kadrowanie treści wizualnych z oryginalnych zdjęć gazet składających się na testowy zbiór danych. Wszystkie wycięte obrazki zapisywane są w odpowiednim folderze i w kolejnym kroku posłużą jako wejście do systemu OCR.
\subsection{Transformacja obrazów oraz system OCR}
Zanim jednak tekst znajdujący się na wykadrowanych treściach wizualnych zostanie wyekstrahowany, zdjęcia muszą zostać poddane odpowiedniemu przetworzeniu. W przypadku, kiedy obrazy były poddawane działaniu OCR bez stosownego przystosowania wyniki były dramatycznie gorsze. Elektroniczne obrazy będące efektem skanowania rzeczywistych dokumentów często posiadają nierównomierne tło, miejscami może być ono ciemniejsze, a miejscami jaśniejsze w zależności od stanu i ułożenia strony skanowanego dokumentu. Aby wyekstrahować tekst należy przede wszystkim zadbać o jak największy kontrast między tłem, a potencjalnymi znakami, aby system łatwiej mógł dopasować je do znanych mu wzorców, nie zważając na zniekształcenia oryginalnego zdjęcia. Proces transformacji treści wizualnych zostanie przedstawiony na poniższym przykładzie. Pierwszym krokiem, jaki musi zostać podjęty, jest zatem upewnienie się, czy dany obraz na pewno jest przedstawiony w skali szarości.
Następnie obraz zostaje poddany operacji matematycznej zwanej dylatacją (\emph{z ang. dilatation}), w przypadku obrazów polega ona na tym, że wartość piksela wyjściowego jest maksymalną wartością wszystkich pikseli w jego sąsiedztwie. Na obrazie binarnym piksel ustawiony jest na 1, wówczas gdy którykolwiek z sąsiednich pikseli ma wartość 1 \cite{BibEntry2022Sep}. jest to pierwszy krok, aby pozbyć się tekstu, a pozostawić tylko tło.
Drugi krok to zastosowanie filtra o nazwie rozmycie medianą (\emph{z ang. median blur}). Filtr ten oblicza medianę z wartości sąsiadujących ze sobą pikseli, bardzo mocno wygładzając obraz, praktycznie pozbywając się z niego pierwotnego tekstu \cite{BibEntry2022Sep2}.
Po tej operacji należy obliczyć różnicę między oryginalnym obrazem a nowo utworzonym tłem. Piksele, które są identyczne będą czarne (różnica $\approx0$), tekst będzie zaś biały (duża różnica).
Ostatnim krokiem jest normalizacja, służy ona do zwiększenia kontrastu, co pomaga w procesie ekstrakcji treści z obrazu, a także do usunięcia z obrazu szumu \cite{ContributorstoWikimediaprojects2022Apr2}.
Tak przygotowane obrazy przepuszczane są przez system OCR. Na potrzeby przygotowywanej pracy magisterskiej do tego zadania użyty został Tesseract OCR. Narzędzie to zostało opracowane przez firmę Google \cite{10.5555/1288165.1288167}. Silnik Tesseract dostępny jest na licencji Open Source, dzięki czemu można swobodnie używać go do własnych celów. W języku programowania Python dostępna jest biblioteka, która pozwala korzystać z tego silnika z poziomu kodu aplikacji, po jego uprzednim zainstalowaniu \cite{madmaze2022Sep}. Tekst będący wynikiem działania OCR jest następnie czyszczony i umieszczany w bazie danych SQLite, a z jego treści ekstrahowane są słowa kluczowe. Do pozyskania słów kluczowych wykorzystany został przetrenowany oparty na sztucznych sieciach neuronowych model KeyBERT \cite{grootendorst2020keybert}.
Finalnym produktem niniejszej pracy magisterskiej jest interfejs użytkownika, który pozwala na konstruowanie zapytań do bazy danych i wyświetlanie rezultatów, z możliwością podejrzenia szczegółów każdego z nich. Do obsługi zapytań użytkownika wykorzystana zostało narzędzie o nazwie Whoosh zaimplementowane w języku programowania Python. Pozwala ono na indeksowanie i wyszukiwanie pełnotekstowe \cite{BibEntry2022Sep3}. Założeniem wyszukiwania pełnotekstowego jest możliwość sprawnego i wydajnego przeszukiwania zbiorów danych. Dzieje się to według określonych kryteriów uwzględniających odmianę wyrazów, błędy ortograficzne oraz synonimy. Dokumenty zwracane są na podstawie z góry określonej oceny ich dopasowania \cite{Daniel2019Nov}. Ten element całej aplikacji w nawiązaniu do pierwowzoru nazwany został News Finder, co w tłumaczeniu na język polski oznacza Poszukiwacz Wiadomości. Działanie interfejsu graficznego przedstawione zostało przedstawione na poniższych zrzutach ekranu.
Obraz \ref{gui1} przedstawia ekran startowy aplikacji, na którym użytkownikowi wyświetla się wiadomość powitalna oraz prośba o cierpliwość, ponieważ komponenty aplikacji są aktualnie przygotowywane. W międzyczasie, kiedy użytkownik czeka, przygotowywane są dane, aby po chwili możliwe było obsługiwanie jego zapytań. Proces ten nie jest długi, trwa około 10 sekund, a po tym czasie program jest gotowy do pełnego użytku. Z kolei na obrazie \ref{gui2} prezentowany jest już widok głównego ekranu aplikacji. Na samej górze znajduje się nazwa oraz logo programu, a tuż pod nim miejsce na wpisywanie zapytań. Wyszukiwanie rozpoczyna się po kliknięciu w przycisk 'Search'.
Po wpisaniu dowolnej frazy lub też kilku fraz zostaną zwrócone nam ikony treści wizualnych pasujące do danego zapytania. Na powyższym zrzucie ekranu (obrazek \ref{gui3}) zwrócone zostały wyniki dla przykładowego zapytania 'sausage', co w języku polskim oznacza kiełbasę. Dzięki zaimplementowanemu w rozwiązaniu narzędziu do logowania wiadome jest, że zostało wyświetlone 10 treści wizualnych dla tego zapytania, jego obsługa z perspektywy znalezienia odpowiednich indeksów trwała jedynie 0,0005 sekundy. Czas zaś potrzebny, żeby wyświetlić wszystkie 10 obrazków, to około 0,5 sekundy.
\newline
Na samej górze, na pasku aplikacji, pokazuje się treść aktualnie obsługiwanego zapytania. Aby kontynuować przeszukiwanie bazy danych, można od razu zacząć wpisywać kolejne frazy zatwierdzając je przyciskiem 'Search' lub też najpierw nacisnąć przycisk 'Clear results', aby wymazać prezentowane rezultaty i powrócić do widoku głównego aplikacji. Treść aktualnego zapytania będzie pokazywała się na pasku, aż do momentu wybrania jednej z tych dwóch opcji. Jeżeli istnieje potrzeba, aby dowiedzieć się więcej szczegółów na temat jednego z prezentowanych wyników wystarczy w niego kliknąć, wówczas oczom użytkownika, pokaże się widok jak na rysunku \ref{gui4}.
Szczegółowy widok przedstawia nam powiększoną wersje danej treści wizualnej, a także pola: słowa kluczowe (Keywords), etykieta przekazana przez model (Label), tekst pochodzący z OCR (OCR text) oraz nazwę oryginalnego zdjęcia gazety z której pochodzi dany wynik (Origin file). Dodatkowo na górnym pasku aplikacji znajduje się poza treścią zapytania, również nazwa pliku przedstawiającego zaznaczoną treść wizualną.
Przedstawione w niniejszym rozdziale podejście, począwszy od przygotowania danych, aż do końcowej warstwy wizualnej zostało zrealizowane zgodnie z oczekiwaniami, a nawet można by rzecz że znacząco przewyższyło postawione cele. Początkowo praca miała skupić się w zasadzie tylko na modelu, natomiast kolejne etapy potraktować jako najmniej ważne, tzn. miała zawierać jedynie prosty skrypt do wizualizacji wyników. Również same wyniki predykcji miały tylko jak najbardziej zbliżyć się do pierwowzoru, a jak zostało tu już pokazane, wyniki Newspaper Navigator zostały znacząco poprawione. W toku prac podejście mocno ewoluowało i ostatecznie stworzone zostało w pełni funkcjonalne narzędzie do pełnotekstowego przeszukiwania dużych zbiorów zdigitalizowanych starych gazet, uprzednio wytrenowawszy na nich model detekcji oparty na głębokim uczeniu maszynowym. Co bardzo ważne, dysponując dowolnym zbiorem danych o takiej samej strukturze jak prezentowany w ramach tej pracy zbiór danych Newspaper Navigator, będzie można bez większych problemów stworzyć identyczną aplikację, zawierającą jednak zupełnie inne dane początkowe. Jest to możliwe dzięki położeniu dużego nacisku od samego początku pracy na generalizację rozwiązania. Jeśli chodzi o elementy całościowego podejścia, które mogłyby zostać poprawione przy kolejnych aktualizacjach oprogramowania, to z pewnością byłyby to kwestie optymalizacyjne. Ze względu na fakt, że jest to praca magisterska, największy nacisk nałożony został na działającą wersję oprogramowania. Kwestie optymalizacyjne zostały zepchnięte na dalszy plan, co jednocześnie nie oznacza, że nie były w ogóle brane pod uwagę, czy że szybkość działania aplikacji jest nieakceptowalna. Jest to jedynie wskazówka, że niektóre procesy można by było zoptymalizować, aby zapewnić przyszłym użytkownikom aplikacji jeszcze lepsze doznania.
