OpenMV MicroPython 4.16. Podgląd obrazu#
Pula buforów ramek to miejsce, z którego aplikacja odczytuje swoje ramki. Podczas gdy aplikacja pracuje nad tymi ramkami, cokolwiek jest podłączone do kamery w celu ich podglądu, również potrzebuje kopii każdej ramki. Kamera ma do tego celu drugi, dedykowany bufor oraz jedną regułę dotyczącą jego wypełniania: za każdym razem, gdy aplikacja wywołuje snapshot(), poprzednia przechwycona ramka jest kopiowana do bufora podglądu przed zwróceniem nowej ramki.
Aplikacja i podglądarka nigdy nie rywalizują o tę samą pamięć. Aplikacja odczytuje swoją ramkę z puli; podglądarka odczytuje swoją ramkę z bufora podglądu. Oba procesy zachodzą równolegle.
4.16.1. Bufor ramki strumienia#
Bufor podglądu – bufor ramki strumienia – to pojedynczy obszar pamięci RAM o stałym rozmiarze, oddzielony od puli buforów ramek. Jego rozmiar jest ustalany podczas kompilacji oprogramowania układowego i nie zmienia się wraz z framesize() ani pixformat(). Na nowszych OpenMV Cam typowo jest to około megabajta – wystarczająco dużo, aby pomieścić podgląd o umiarkowanej rozdzielczości, znacznie mniej niż ramka w pełnej rozdzielczości przy największych rozmiarach sensora.
Kod aplikacji nie odczytuje ani nie zapisuje tego bufora bezpośrednio; sterownik kamery wypełnia go jako efekt uboczny snapshot().
4.16.2. Co snapshot robi dla podglądu#
Przy każdym wywołaniu snapshot(), zanim sterownik zwolni poprzedni bufor ramki aplikacji z powrotem do puli i przekaże nowy, kopiuje poprzednią ramkę do bufora podglądu – wraz ze wszystkim, co aplikacja narysowała na niej podczas przetwarzania, wciąż obecnym na obrazie. Możliwe są dwie ścieżki. To, która z nich zostanie wykonana, jest wybierane przez podglądarkę, a nie przez kamerę: konsument, który otworzył podgląd, informuje sterownik, czy chce surowy obraz, czy JPEG, oraz jaki rozmiar surowego okna może zaakceptować.
Surowa kopia pomniejszona. Gdy podglądarka poprosiła o surowe ramki, sterownik kopiuje poprzednią ramkę w jej natywnym formacie pikseli (RGB565, skala szarości itp.). Jeśli ramka jest większa niż surowe okno, o które poprosiła podglądarka, sterownik pomniejsza ją z filtrowaniem dwuliniowym, aż się zmieści; w przeciwnym razie piksele przechodzą bez zmian. Brak artefaktów kompresji; podglądarka widzi te same piksele, nad którymi pracowała aplikacja.
Kompresja JPEG. Gdy podglądarka poprosiła o JPEG – lub gdy surowa kopia w ogóle nie zmieściłaby się w buforze strumienia – sterownik kompresuje poprzednią ramkę do formatu JPEG w jej pełnej rozdzielczości do bufora strumienia. Jakość jest dostosowywana adaptacyjnie dla każdej ramki, tak aby skompresowane dane wyjściowe mieściły się w pojemności bufora strumienia. Gdy ramka się mieści, sterownik stopniowo podnosi jakość o jeden krok w kierunku górnego pułapu zależnego od rozmiaru pikseli przechwyconej ramki (mniejsze ramki mogą mieć wyższą jakość; większe ramki są ograniczane niżej, aby nie mogły się przepełnić przy niewielkiej zmianie treści). Gdy ramka nie mieści się, sterownik zmniejsza bieżącą jakość o połowę, utrzymuje ją na obniżonym poziomie przez kolejne kilkadziesiąt ramek, aby nowe ustawienie miało czas się ustabilizować, i usuwa przepełnioną ramkę z podglądu. Pętla aplikacji działa dalej bez zakłóceń; tylko podglądarka traci odrzuconą ramkę.
Ramki, które kamera produkuje w formacie już skompresowanym (format pikseli JPEG na sensorach emitujących JPEG bezpośrednio), pomijają obie ścieżki: zakodowany strumień bitów jest kopiowany bezpośrednio do bufora podglądu bez zmian.
Podglądarka odpytuje według własnego harmonogramu, zwykle znacznie wolniej niż kamera przechwytuje, więc próbkuje podrzędnie surową częstotliwość przechwytywania: pokazywane są tylko te zrzuty obrazu, które zdąży odczytać w odpowiednim czasie. Jeśli świeży snapshot() dotrze do bufora podglądu, zanim podglądarka odczyta poprzednią ramkę, bufor jest wciąż zablokowany przez podglądarkę i nowa aktualizacja podglądu zostaje pominięta – ten zrzut zostaje utracony ze strumienia podglądu. Własna pula buforów ramek aplikacji pozostaje nienaruszona; przechwycona ramka nadal trafia do aplikacji normalnie.
4.16.3. Ręczne wypchnięcie ostatniej ramki#
Ponieważ podgląd jest aktualizowany jako efekt uboczny snapshot(), skrypt, który kończy działanie bez ponownego wywołania snapshot, pozostawia to, co ostatnio wysłał do podglądu, na podglądarce w nieskończoność – co w przypadku skryptu wykonującego swoją pracę przed pierwszym zrzutem obrazu, a następnie kończącego działanie, oznacza pusty podgląd. image.Image.flush() (lub równoważne flush() na obiekcie CSI) kopiuje bieżącą zawartość bufora ramki aplikacji do bufora strumienia na żądanie, bez przechwytywania nowej ramki:
img = csi0.snapshot()
# process the image and draw on it
img.flush() # previewer sees the annotated frame
To samo wywołanie jest również przydatne, gdy pomiędzy zrzutami obrazu wykonywana jest długotrwała operacja, a podglądarka w przeciwnym razie pokazywałaby przez cały ten czas nieaktualny podgląd.
Informacja
Aplikacja podglądu musi odczytać ramkę z bufora strumienia, zanim skrypt zakończy działanie. Wywołanie flush na końcu krótkiego skryptu jedynie przygotowuje ramkę; jeśli skrypt następnie zwróci kontrolę kamerze, zanim podglądarka zdąży odpytać, bufor zostanie ponownie użyty przy następnym uruchomieniu, a ta ostatnia ramka zostanie utracona. W przypadku podglądów na końcu skryptu daj podglądarce chwilę na pobranie ramki (krótki sleep po flush lub po prostu nie kończ działania natychmiast) przed zakończeniem skryptu.