5.34. Podsumowanie¶
Moduł image to największe API udostępniane przez kamerę, a ten rozdział omówił tylko jego zarys: jak obraz jest reprezentowany w pamięci, jak kamera odczytuje i zapisuje pojedyncze piksele, jak rysuje w przechwyconych ramkach, jak przekształca je arytmetycznie i geometrycznie, jak progowo je klasyfikuje i filtruje, jak wyodrębnia z nich pomiary i wykrycia, jak dekoduje z nich drukowane symbole, jak porównuje jeden obraz z drugim oraz jak przenosi wyniki na kamerę i z niej.
Zestaw narzędzi jest celowo szeroki. Klasyczny potok wizji komputerowej działający na małej wbudowanej kamerze wykonuje większość pracy zanim cokolwiek dotrze do modelu uczenia maszynowego, o ile taki istnieje – progowanie czyści wejście, filtry odszumiają, obszary zawężają obszar przeszukiwania, detektory plam i linii lokalizują kandydatów, ocena podobieństwa decyduje, czy kandydat jest interesujący, a warstwa we/wy przekazuje wynik temu, co uruchamia kolejny etap. Każda strona w tym rozdziale omawiała jedną z tych operacji; właściwy potok dla danej aplikacji to ich sekwencja złożona w kolejności, jakiej wymaga problem.
5.34.1. Wzorzec potoku¶
Większość nietrywialnych aplikacji kamery podąża za tym samym zarysem. Przechwyć ramkę z sensora. Przetwórz wstępnie: przekonwertuj formaty, wyrównaj histogram, rozmyj szum. Zlokalizuj obszary lub cechy zainteresowania: wykrywanie plam, wykrywanie linii, dopasowywanie szablonów, dekodowanie kodów. Przeanalizuj to, co znaleziono: pomiary geometryczne, ocenę podobieństwa, statystyki. Zdecyduj, co zrobić na podstawie analizy: wyzwól GPIO, zgłoś ładunek, przechwyć i zaloguj, przekaż ramkę do modelu ML. Wyprowadź decyzję lub przechwycony artefakt: zapisz, zakoduj, wyślij, narysuj z powrotem w ramce na potrzeby podglądu w IDE.
Żadna pojedyncza strona rozdziału nie omawiała każdego kroku; rozdział omówił bloki konstrukcyjne, które składa potok. Wybór, których bloków użyć i w jakiej kolejności, jest zadaniem skryptu aplikacji.
5.34.2. Dokąd prowadzi ten rozdział¶
Moduł image zajmuje się obrazami jako obrazami – pikselami, obszarami, rysowaniem, wykryciami. Wiele prac na przechwyconych danych nie pasuje do tego ujęcia. Obliczanie statystyk na dowolnej tablicy liczbowej, uruchamianie zwektoryzowanej arytmetyki na surowych danych sensora, stosowanie niestandardowej transformacji macierzowej, za którą nie stoi żadna metoda modułu image, przygotowanie danych dla modelu uczenia maszynowego, który oczekuje określonego układu tensora – to wszystko są zadania dla biblioteki tablic liczbowych, a nie dla biblioteki przetwarzania obrazów.
Następny rozdział obejmuje dokładnie to. Moduł ulab.numpy dostarczany z MicroPython na kamerze jest podzbiorem NumPy, a dwa pomosty łączą go z modułem image: to_ndarray() kopiuje piksele ramki do ndarray do prac numerycznych, a konstruktor Image przyjmuje ndarray, aby zbudować nowy obraz z wyniku, gotowy do wyświetlenia, zapisania lub przekazania z powrotem do biblioteki image. Te dwa moduły się uzupełniają – każdy robi to, czego nie robi drugi, a razem pokrywają prace numeryczne i obrazowe, których potrzebuje aplikacja wizji wbudowanej.