OpenCV: Computer Vision Deep Dive

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 1 z 20. Większość programistów myśli o obrazie jako o skompresowanym pliku siedzącym na dysku twardym. Ale w momencie, gdy przekazujesz ten plik do biblioteki computer vision, pozbywa się on swojego formatu pliku i staje się ogromną siatką liczb czekających na operacje na macierzach. Zrozumienie, jak dokładnie te liczby są ustrukturyzowane, to The Soul of OpenCV: Pixels as Matrices. Kiedy ładujesz obraz używając OpenCV, funkcja read wyciąga plik z dysku i natychmiast konwertuje go na wielowymiarowy array NumPy. To jest ta część, która ma znaczenie. OpenCV w Pythonie nie używa własnego obiektu image. Opiera się całkowicie na NumPy. Ponieważ obraz to po prostu standardowy array, każdą operację matematyczną, którą możesz zastosować na arrayu, możesz zastosować bezpośrednio na swoim obrazie. Przyjrzyjmy się strukturze tego arraya. Jeśli załadujesz standardowy kolorowy obraz, otrzymasz trójwymiarową macierz. Pierwszy wymiar to wysokość, która reprezentuje liczbę wierszy. Drugi wymiar to szerokość, reprezentująca liczbę kolumn. Trzeci wymiar przechowuje kanały kolorów. Jeśli masz obraz, który ma osiemset pikseli szerokości i sześćset pikseli wysokości, shape twojego arraya to będzie sześćset wierszy, osiemset kolumn i trzy kanały. Każde przecięcie wiersza i kolumny przechowuje piksel. A w przypadku standardowych obrazów, każdy kanał koloru wewnątrz tego piksela przechowuje wartość typu integer od zera do dwustu pięćdziesięciu pięciu, reprezentującą intensywność tego koloru. Kryje się tu bardzo częsta pułapka. Większość programów graficznych i przeglądarek internetowych reprezentuje kolory w formacie Red, Green, Blue, znanym jako RGB. OpenCV tego nie robi. Z powodów historycznych, sięgających wczesnego hardware'u kamer, OpenCV przechowuje kanały kolorów w odwrotnej kolejności: Blue, Green, Red, czyli BGR. Jeśli spróbujesz wyświetlić obraz z OpenCV w innej bibliotece bez zamiany tych kanałów, twój czerwony będzie wyglądał jak niebieski, a niebieski jak czerwony. To nie jest bug w twoim kodzie. Po prostu pamiętaj, że wartość pod indeksem kanału zero to niebieski, pod indeksem jeden to zielony, a pod indeksem dwa to czerwony. Ponieważ obrazy to po prostu arraye w NumPy, manipulowanie nimi opiera się na standardowej składni Pythona. Nie potrzebujesz specjalistycznych funkcji OpenCV, żeby wykadrować obraz. Po prostu robisz slice na arrayu. Załóżmy, że masz feed z kamery monitoringu w wysokiej rozdzielczości i interesuje cię tylko region o wymiarach sto na sto pikseli, w którym znajdują się drzwi. Wyodrębniasz Region of Interest, czyli ROI, używając standardowego slicingu arraya. Określasz wiersz początkowy i wiersz końcowy, a następnie kolumnę początkową i kolumnę końcową. W ujęciu matematycznym, najpierw robisz slice na osi Y, a potem na osi X. To natychmiast zwraca mniejszy array w NumPy, zawierający tylko dane pikseli z drzwi. Kiedy już zrobisz slice swojego arraya lub zmodyfikujesz jego piksele, zazwyczaj chcesz zapisać wynik. OpenCV obsługuje to za pomocą prostej funkcji write. Podajesz docelową ścieżkę do pliku i przekazujesz swój array NumPy. OpenCV odczytuje rozszerzenie pliku, o które prosiłeś, na przykład kropka JPG, i automatycznie obsługuje złożoną kompresję wymaganą do przekształcenia tej macierzy liczb z powrotem w standardowy plik obrazu. Najbardziej użyteczną rzeczą, jaką możesz zrobić, ucząc się computer vision, jest przestanie myśleć o obrazach jako o wizualnych płótnach, a zaczęcie traktować je jako układy współrzędnych wypełnione surowymi danymi liczbowymi. Jeśli podobają ci się te deep dive'y, możesz wesprzeć program, wyszukując DevStoriesEU na Patreon. To wszystko w tym odcinku. Dzięki za wysłuchanie i koduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 2 z 20. Nałożenie filtra blur na zdjęcie wydaje się skomplikowanym efektem wizualnym, ale od strony obliczeniowej to po prostu zastąpienie każdego piksela średnią matematyczną jego bezpośrednich sąsiadów. Mechanizm, który za tym stoi, to temat naszego dzisiejszego odcinka: Convolution Kernels, czyli filtrowanie i edge detection. Słysząc słowo convolution, możesz od razu pomyśleć o Convolutional Neural Networks. Musimy od razu rozdzielić te dwa pojęcia. W sieciach deep learningowych model sam dobiera wartości w swoich filtrach podczas potężnego procesu trenowania. Dzisiaj mówimy o klasycznym, dwuwymiarowym convolution. Te kernele to stałe, zahardcodowane macierze matematyczne, które istnieją od dekad. One się nie uczą. One po prostu liczą. Kernel to po prostu malutka siatka liczb. Popularny rozmiar to kwadrat trzy na trzy. Convolution to proces, w którym bierzesz tę małą siatkę i przesuwasz ją po całym obrazie, piksel po pikselu. Na każdym kroku zrównujesz środek kernela z konkretnym pikselem na obrazie. Następnie mnożysz każdą liczbę w kernelu przez wartość piksela, który znajduje się dokładnie pod nią. Dodajesz do siebie wszystkie dziewięć wyników, a ta końcowa suma staje się nową wartością dla środkowego piksela na obrazku wyjściowym. Robisz to dla każdego piksela. Liczby, które wrzucisz do tej małej siatki, dokładnie dyktują, co stanie się z całym obrazem. Jeśli wypełnisz kernel ułamkami, które sumują się do jedynki, otrzymasz blur. Gaussian blur to specyficzny typ kernela, w którym środkowa wartość ma największą wagę, a wartości maleją w miarę zbliżania się do krawędzi siatki. Tworzy to lokalną średnią ważoną. I to jest kluczowa sprawa. Nie nakładamy blura na obrazy, żeby wyglądały artystycznie. Robimy to, żeby zniszczyć noise. Sensor kamery rejestruje drobne, losowe fluktuacje światła. Jeśli spróbujesz analizować sztywną strukturę obrazu z obecnym tam noisem, twoje algorytmy polegną. Gaussian blur wygładza ten chaotyczny noise, zachowując jednocześnie ogólne kształty. Kiedy pozbędziesz się noise'u, zazwyczaj chcesz znaleźć konkretne obiekty w kadrze. Wyobraź sobie system kamer zaprojektowany do odczytywania tablic rejestracyjnych. Zanim będziesz w stanie odczytać znaki, musisz wyizolować prostokątną tablicę na tle zderzaka samochodu. Dla komputera krawędź to po prostu nagłe przejście od ciemnych pikseli do jasnych, albo na odwrót. Żeby znaleźć te ostre przejścia, podmieniamy macierz blura na macierz do edge detection, taką jak Sobel kernel. Pionowy Sobel kernel jest zaprojektowany specjalnie do wyszukiwania pionowych krawędzi. To siatka trzy na trzy, która zawiera kolumnę liczb ujemnych po lewej, kolumnę zer na środku i kolumnę liczb dodatnich po prawej. Kiedy ten kernel przesuwa się po obszarze o jednolitym kolorze, na przykład po gładkim, szarym zderzaku, liczby ujemne i dodatnie mnożą się przez tę samą wartość szarości. Znoszą się nawzajem. Suma wynosi zero, co przekłada się na czarny piksel na obrazku wyjściowym. Jednolite obszary znikają. Ale kiedy kernel wyląduje dokładnie na pionowej granicy między tym ciemnym zderzakiem a jasnobiałą tablicą rejestracyjną, matematyka się zmienia. Liczby ujemne mnożą się przez ciemne piksele, dając małą wartość. Liczby dodatnie mnożą się przez jasnobiałe piksele, dając ogromną wartość. Już się nie znoszą. Końcowa suma to bardzo wysoka liczba dodatnia, która tworzy jasnobiały piksel na twoim obrazku wyjściowym dokładnie tam, gdzie znajduje się krawędź. Wykonując tę operację na całym obrazie, zderzak znika w czerni, pozostawiając po sobie wyraźny, biały kontur tablicy rejestracyjnej. Właśnie zamieniłeś surowe dane o kolorze w strukturalną geometrię. Główny wniosek jest taki, że klasyczny convolution kernel to nic innego jak lokalna reguła matematyczna aplikowana globalnie, która dyktuje, jak każdy pojedynczy piksel powinien reagować na swoich bezpośrednich sąsiadów. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 3 z 20. Potrzebujesz dokładnego obrysu obiektu na taśmie produkcyjnej. Twoim pierwszym odruchem może być odpalenie potężnej sieci neuronowej do segmentacji semantycznej. Ale obliczenie tego obrysu za pomocą standardowej geometrii jest o rzędy wielkości szybsze, tańsze obliczeniowo i nie wymaga GPU. I to właśnie pozwala ci zrobić Drawing Boundaries: Contours and Geometry. Częstym błędem jest traktowanie krawędzi i konturów jako tego samego. To fundamentalnie różne struktury danych. Detektor krawędzi daje ci binarną mapę nieuporządkowanych, niepołączonych białych pikseli w miejscach, gdzie zmienia się intensywność. Kontur to ciągła krzywa matematyczna łącząca wszystkie kolejne punkty wzdłuż granicy o tym samym kolorze lub intensywności. Krawędzie to po prostu pojedyncze kropki na ekranie. Kontury tworzą zamknięte, mierzalne kształty. Wyobraź sobie fabryczny system kontroli jakości, który sprawdza metalowe koło zębate. Przekonwertowałeś już obraz z kamery na czarno-biały obraz binarny. Koło zębate jest jednolicie białe na czarnym tle. Aby uzyskać matematyczną granicę tego koła zębatego, przekazujesz ten obraz do funkcji szukającej konturów. OpenCV robi to, skanując obraz wiersz po wierszu. Gdy algorytm natrafi na granicę między czarnymi i białymi pikselami, śledzi tę granicę, zapisując współrzędne do arraya. Aby oszczędzić pamięć, kompresuje output, zapisując tylko punkty początkowe i końcowe prostych odcinków zamiast każdego pojedynczego piksela. Ten proces wychwytuje również relacje przestrzenne. Koło zębate ma zewnętrzną krawędź, ale ma też otwór w środku na oś. Algorytm konturów buduje hierarchię. Zapisuje zewnętrzną granicę jako parent contour, a wewnętrzny otwór jako child contour. Pozwala ci to selektywnie analizować lub ignorować wewnętrzne kształty w zależności od twoich potrzeb. Teraz, gdy masz już koło zębate jako połączoną granicę, możesz wyciągnąć jego geometrię. Możesz obliczyć pole konturu. To matematyczne wyliczenie całkowitej powierzchni pikseli wewnątrz zamkniętej krzywej. Idealnie wyprodukowane koło zębate będzie miało konkretną, znaną powierzchnię. Jeśli koło zębate ma wyłamany ząb, pole jego konturu spada poniżej twojego akceptowalnego progu. Od razu oflagowujesz ten defekt. Czasami musisz zrozumieć ogólny kształt obiektu, ignorując jego skomplikowane detale. I tu robi się ciekawie. Możesz obliczyć convex hull konturu. Pomyśl o convex hull jak o gumce recepturce naciągniętej ciasno wokół twojego obiektu. W przypadku koła zębatego, standardowy kontur idealnie śledzi każdy pojedynczy ząb i zagłębienie. Convex hull ignoruje zagłębienia. Rozciąga się w linii prostej od czubka jednego zęba do czubka następnego. Porównując oryginalny kontur z convex hull, identyfikujesz strukturalne anomalie. Puste przestrzenie między gumką a rzeczywistym konturem koła zębatego to tak zwane convexity defects. Zmierzenie tych defektów mówi ci dokładnie, jak głębokie są zęby koła i czy któreś z nich są zużyte, a to wszystko za pomocą czystych obliczeń geometrycznych. Kontury wypełniają lukę między niskopoziomowym przetwarzaniem obrazu a wysokopoziomową analizą obiektów, zamieniając siatkę głupich pikseli w ustrukturyzowane kształty geometryczne, które możesz ściśle zwalidować. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórz dalej!

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 4 z 20. Najbardziej niezawodne visual trackery nie zapamiętują wyglądu całego obiektu. Zamiast tego, namierzają matematycznie unikalne narożniki i gradienty o wysokim kontraście, które pozostają niezmienne niezależnie od oświetlenia. Zrobienie tego dobrze to domena Feature Detectorów: Keypointów i Neural Matchingu. Zanim przyjrzymy się mechanice, musimy oddzielić to od object detection. Object detection stosuje szerokie kategorie semantyczne. Rysuje bounding box i mówi ci, że w kadrze znajduje się budynek. Feature matching jest ściśle strukturalny. Nie wie, czym jest budynek. Znajduje konkretne, identyczne przecięcie dwóch cegieł na dwóch różnych obrazach. Pomyśl o budowaniu aplikacji do panorama stitching. Masz dwa nakładające się na siebie zdjęcia ceglanej ściany, zrobione pod nieco różnymi kątami. Aby je płynnie złączyć, oprogramowanie musi matematycznie wyrównać overlap. Robi to, znajdując unikalne lokalne feature'y na pierwszym obrazie, znajdując te same feature'y na drugim obrazie i parując je ze sobą. Pierwszym krokiem jest detekcja. System skanuje obraz w poszukiwaniu keypointów. Keypoint to konkretna lokalizacja piksela, która wyróżnia się z otoczenia. Płaskie obszary, takie jak czyste niebo czy pusta biała ściana, są bezużyteczne, ponieważ każdy piksel wygląda dokładnie tak samo. Algorytm poluje na wyraźne tekstury, ostre narożniki i przecinające się linie. Tradycyjnie algorytmy opierały się na ręcznie tworzonych formułach matematycznych, aby znaleźć te krawędzie. Nowoczesne podejścia wykorzystują konwolucyjne sieci neuronowe. Wrzucasz obraz do sieci, a ona zwraca probability map, wskazującą, jak bardzo prawdopodobne jest, że dany piksel to stabilny keypoint. Kiedy sieć zidentyfikuje punkt, na przykład róg konkretnej ramy okiennej, potrzebuje sposobu na jego opisanie. To jest descriptor. Sieć neuronowa generuje wielowymiarowy wektor, embedding, który przechwytuje wizualny wzorzec pikseli bezpośrednio otaczających ten keypoint. Solidny descriptor pozostaje matematycznie podobny, nawet jeśli drugie zdjęcie zostało zrobione w innej skali, obrócone lub w innych warunkach oświetleniowych. Oto najważniejsza rzecz. Posiadanie listy punktów i ich opisów to tylko połowa układanki. Nadal musisz zmatchować punkty z pierwszego obrazu z punktami na drugim obrazie. Historycznie, po prostu obliczałeś odległość między wektorami i wybierałeś ten najbliższy. Ale powtarzające się wzorce, jak setki identycznych cegieł na ścianie, powodują poważne błędy mismatchingu. Właśnie tutaj wkraczają modele neural matching. Zamiast oceniać jeden keypoint w izolacji, neural matcher analizuje relacje przestrzenne między wszystkimi keypointami jednocześnie. Zasadniczo uczy się, że konkretny narożnik może wyglądać jak pięćdziesiąt innych narożników cegieł, ale jako jedyny znajduje się dokładnie między ramą okna a konkretnym cieniem. Przepuszczając descriptory i ich pozycje geometryczne przez warstwy self-attention, system odrzuca false positives i zwraca wysoce dokładne pary matchujące. W typowym pipeline'ie, najpierw przepuszczasz oba obrazy przez sieć do feature extraction. To zwraca dwa zestawy keypointów i dwa zestawy descriptorów. Następnie przekazujesz oba zestawy danych do matching network. Matching network oblicza podobieństwa kontekstowe i zwraca listę prawidłowych par, wyrzucając keypointy, które nie występują w obu klatkach. Następnie używasz tych zmatchowanych par współrzędnych do obliczenia transformacji geometrycznej potrzebnej do idealnego zwarpowania i złączenia obu zdjęć. Przejście od ręcznie tworzonych formuł do neural embeddings oznacza, że feature matching może teraz radzić sobie z ekstremalnymi zmianami oświetlenia i ekstremalnymi punktami widzenia, które kiedyś całkowicie wysypywały starsze algorytmy. Dzięki za wysłuchanie, happy coding wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 5 z 20. Mobilne aplikacje do skanowania dokumentów wydają się być skomplikowaną magią AI. Kierujesz telefon na kartkę papieru, a ona natychmiast spłaszcza się, tworząc idealny cyfrowy dokument. Ale głównym silnikiem, który za tym stoi, wcale nie jest sieć neuronowa przewidująca brakujące detale. Całość opiera się na piętnastoletnim matematycznym triku wykorzystującym macierz transformacji trzy na trzy. W tym odcinku bierzemy na warsztat geometrię w prawdziwym świecie: budowanie skanera dokumentów. Wyobraź sobie pognieciony paragon leżący na stole w restauracji. Robisz mu zdjęcie pod kątem. Przez perspektywę paragon wygląda jak przekrzywiony trapez, otoczony teksturą stołu. Aby wyodrębnić dokument, pierwszym krokiem jest odizolowanie go od tła. Konwertujesz obraz do grayscale i nakładasz lekki blur. To zmiękcza zaszumione detale, takie jak zagięcia papieru czy słoje drewna na stole, jednocześnie zachowując główne granice nienaruszone. Następnie odpalasz Canny edge detection. To podkreśla ostre zmiany intensywności, zostawiając ci jasny kontur paragonu na ciemnym tle. Następnie musisz zamienić te luźne krawędzie w konkretny kształt. Szukasz konturów na edge mapie. Obraz będzie zawierał wiele konturów, a większość z nich to bezużyteczne, małe artefakty. Sortujesz je po wielkości, zostawiając tylko te największe. Następnie iterujesz po tych dużych konturach i aproksymujesz ich kształt do wielokąta. Szukasz konkretnej wskazówki strukturalnej. Jeśli znajdziesz kształt, który da się opisać dokładnie czterema punktami, to znaczy, że znalazłeś granice swojego paragonu. Te cztery punkty definiują rogi twojego dokumentu na oryginalnym, zrobionym pod kątem zdjęciu. Teraz dochodzimy do kluczowego etapu spłaszczania dokumentu. Powszechnym mitem jest to, że ten proces wykorzystuje AI do zgadywania lub halucynowania brakujących danych. Wcale tak nie jest. Perspective transform to czysto matematyczne warpowanie współrzędnych pikseli z jednej płaszczyzny na drugą. Aby to zrobić, potrzebujesz dwóch zestawów po cztery punkty. Pierwszy zestaw to cztery rogi, które właśnie znalazłeś na paragonie. Drugi zestaw reprezentuje miejsce, w którym te rogi powinny się znaleźć na docelowym, idealnym obrazku. Aby uzyskać drugi zestaw, obliczasz maksymalną szerokość i wysokość przekrzywionego paragonu, używając wzoru na odległość między oryginalnymi punktami. Następnie definiujesz nowy, idealny prostokąt, zaczynając od współrzędnych zero-zero i rozciągając go do tej konkretnej szerokości i wysokości. Mając te dwa zestawy punktów, obliczasz perspective transformation matrix. Ta macierz dokładnie definiuje, o ile każdy piksel musi się przesunąć, rozciągnąć lub skompresować, aby przejść z kształtu pochylonego trapezu do płaskiego prostokąta. Na koniec aplikujesz tę macierz na oryginalny obraz w wysokiej rozdzielczości. Matematyka dosłownie wyciąga cztery rogi na zewnątrz i wyrównuje je do kątów prostych, warpując razem z nimi wszystkie piksele wewnątrz. W efekcie otrzymujesz idealny, dwuwymiarowy obraz twojego paragonu widziany z góry, gotowy do przetwarzania. I to jest kluczowy wniosek. Nie potrzebujesz deep learningu, żeby poprawić perspektywę. Dopóki potrafisz wyizolować cztery rogi, prosta operacja na macierzy idealnie zremapuje geometrię dowolnej płaskiej powierzchni. Dzięki, że wpadłeś. Mam nadzieję, że dowiedziałeś się czegoś nowego.

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 6 z 20. Zanim nowy algorytm śledzący stanie się standardową funkcją w głównej bibliotece OpenCV, często spędza lata na testach bojowych u badaczy w oddzielnej, równoległej przestrzeni. Jeśli trzymasz się tylko domyślnych release'ów, omijają cię najnowsze techniki w tej dziedzinie. Tą równoległą przestrzenią jest repozytorium opencv_contrib. Wielu developerów widzi słowo „contrib” i zakłada, że kod jest zepsuty, nieprzetestowany, albo że to po prostu soft w wersji beta. To nieporozumienie. Kod w tym repozytorium jest często mocno zoptymalizowany i aktywnie używany w wymagających środowiskach. Różnica polega wyłącznie na stabilności API, a nie na jakości kodu. Core'owa biblioteka OpenCV narzuca ścisłe, długoterminowe gwarancje backward compatibility. Jeśli funkcja trafi do głównego release'u, jej inputy, outputy i zachowanie muszą pozostać stabilne przez lata. Ale badania nad computer vision posuwają się do przodu agresywnie szybko. Badacze potrzebują miejsca, żeby publikować nowe algorytmy, zmieniać nazwy parametrów i modyfikować struktury danych na podstawie realnego feedbacku. Repozytorium opencv_contrib zapewnia dokładnie takie środowisko. Działa jak inkubator. Maintainerzy tych dodatkowych modułów mogą łamać API między release'ami. Mogą zmieniać nazwy funkcji albo to, jak algorytm się inicjalizuje, bez łamania surowych zasad core'owej biblioteki. Z czasem moduł może okazać się uniwersalnie przydatny. Jego API się stabilizuje, edge case'y są obsłużone, a społeczność zaczyna na nim mocno polegać. Kiedy to nastąpi, maintainerzy OpenCV migrują kod. Fizycznie przenoszą moduł z repozytorium opencv_contrib i mergują go bezpośrednio do głównego repozytorium OpenCV. Ten proces graduacji gwarantuje, że core'owa biblioteka wchłania tylko sprawdzoną, stabilną technologię. Weźmy pod uwagę konkretny scenariusz. Budujesz projekt augmented reality i chcesz użyć modułu śledzącego ArUco do wykrywania kwadratowych markerów referencyjnych w feedzie na żywo z kamery. Ten moduł zawiera mocno wyspecjalizowane, najnowocześniejsze funkcje. Żeby go użyć, budujesz swoje środowisko OpenCV ze źródeł. Klonujesz główne repozytorium na swoją lokalną maszynę, a potem klonujesz repozytorium opencv_contrib tuż obok. Kiedy konfigurujesz swój build tool, przekazujesz konkretną zmienną ścieżki, która wskazuje na folder modules wewnątrz repozytorium contrib. Build system odczytuje tę flagę i kompiluje core'ową bibliotekę, ale sięga też do folderu contrib, kompiluje moduł ArUco i linkuje go bezpośrednio do twoich finalnych binarek. Nie kończysz z dwiema osobnymi bibliotekami. Dostajesz jedną, zunifikowaną instalację OpenCV, która zawiera zarówno solidną jak skała bazę, jak i wybrane przez ciebie eksperymentalne moduły. Jeśli podoba ci się podcast i chcesz wesprzeć program, możesz wyszukać DevStoriesEU na Patreonie — zawsze to doceniamy. Prawdziwa siła tej architektury leży w zrozumieniu jej podwójnej natury: główne repozytorium chroni twoje produkcyjne pipeline'y przed breaking changes, podczas gdy repozytorium contrib daje ci jutrzejszy research z zakresu computer vision już dziś. To tyle w tym odcinku. Do usłyszenia następnym razem!

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 7 z 20. Możesz wyrwać mózg z potężnego serwera treningowego PyTorch, wyeksportować go jako pojedynczy plik i odpalić niesamowicie szybko w czystym C++ bez instalowania PyTorcha. Kiedy przechodzisz od trenowania modelu do jego deployu w prawdziwym świecie, twoje priorytety zmieniają się z elastyczności na czystą szybkość. Właśnie w tym momencie do akcji wkracza Inference Engine, czyli moduł DNN z OpenCV. Częstą pułapką, w którą wpadają inżynierowie, jest założenie, że jeśli model został wytrenowany w TensorFlow, to docelowa maszyna do deployu też musi mieć ciężką instalację TensorFlow, żeby go odpalić. To nieprawda. OpenCV wykonuje inference całkowicie natywnie. Moduł DNN to dedykowany, mocno zoptymalizowany inference engine typu forward-pass. Nie robi backpropagation. Nie liczy gradientów. Nie trenuje modeli. Jego jedynym zadaniem jest wzięcie wytrenowanej sieci, przyjęcie obrazu i zwrócenie odpowiedzi tak szybko, jak tylko pozwala na to sprzęt. OpenCV dostarcza natywne loadery dla standardowych formatów modeli. Możesz ładować modele Caffe, protocol buffers z TensorFlow, konfiguracje Darknetu i pliki ONNX bezpośrednio do swojej aplikacji. I tu jest kluczowa sprawa. Kiedy wywołujesz funkcję taką jak readNet, OpenCV parsuje zewnętrzny format pliku i rekonstruuje graf sieci neuronowej, używając swoich własnych, wewnętrznych implementacji warstw w C++. Zewnętrzne zależności znikają całkowicie. Twoja aplikacja linkuje się tylko z OpenCV. Wyobraź sobie smart kamerę embedded w C++, zaprojektowaną do wykrywania pieszych na ulicy. Nie chcesz, żeby potężny runtime Pythona zżerał twoją ograniczoną pamięć, i na pewno nie chcesz, żeby gigabajty bibliotek do deep learningu zajmowały miejsce na urządzeniu edge. Zamiast tego trenujesz swój detektor pieszych na potężnym klastrze GPU i eksportujesz końcowe wagi do pliku ONNX. Wrzucasz ten jeden plik do pamięci kamery. W swojej aplikacji w C++ używasz modułu DNN, żeby załadować plik ONNX. Następnie przechwytujesz klatkę z sensora kamery. Sieci neuronowe nie potrafią przetwarzać surowych obrazów bezpośrednio. Musisz przekonwertować tę klatkę na ustrukturyzowaną, czterowymiarową tablicę, powszechnie nazywaną blobem. OpenCV dostarcza dedykowaną funkcję do zbudowania tego bloba, która ogarnia resizing obrazu, zamianę kanałów kolorów i aplikowanie konkretnego mean subtraction lub scalingu, którego wymaga oryginalny model. Przekazujesz ten przygotowany blob do warstwy wejściowej sieci. Następnie wywołujesz funkcję forward. Moduł DNN przejmuje stery, przepychając dane przez każdą warstwę konwolucyjną, funkcję aktywacji i warstwę pooling. Ponieważ w tym momencie OpenCV ma na własność cały execution graph, może agresywnie optymalizować matematykę. Łączy sąsiednie warstwy tam, gdzie to możliwe, żeby zmniejszyć zużycie memory bandwidth, i automatycznie targetuje natywną akcelerację sprzętową. Funkcja forward kończy działanie i zwraca końcową tablicę zawierającą współrzędne bounding boxów i confidence scores dla znalezionych pieszych. Zostaw swoje ciężkie frameworki w laboratorium do trenowania, a do lekkiego, wolnego od zależności deployu na produkcji używaj modułu DNN z OpenCV. Dzięki za spędzony czas. Mam nadzieję, że dowiedziałeś się czegoś nowego.

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 8 z 20. Zanim pojawiły się nowoczesne systemy, detektory obiektów musiały skanować pojedynczy obraz dziesiątki razy w różnych skalach, aby znaleźć cel. Było to strasznie wolne i obciążające obliczeniowo. Aż w końcu nowa architektura zrewolucjonizowała tę dziedzinę, robiąc to wszystko w jednym, niesamowicie szybkim matematycznym przebiegu. Dzisiaj przyjrzymy się rodzinie YOLO: Fast Object Detection. Żeby zrozumieć, dlaczego You Only Look Once, czyli YOLO, zmieniło wszystko, spójrz na to, jak wyglądał poprzedni standard. Starsze, wieloetapowe pipeline'y opierały się na region proposals. Generowały setki zgadywanek, gdzie może znajdować się obiekt, robiły cropy tych obszarów, a następnie odpalały image classifier na każdym pojedynczym, wyizolowanym fragmencie. Odpalałeś skomplikowane sieci w pętli. Było to pofragmentowane, trudne do zoptymalizowania i po prostu wolne. Niektórzy developerzy mylą YOLO ze standardowym image classification, które po prostu przypisuje labelkę do całego obrazka. YOLO robi znacznie więcej. Zwraca precyzyjne, przestrzenne bounding boxy wraz z class probabilities. Mówi ci, czym jest dany obiekt i gdzie dokładnie znajduje się w fizycznej przestrzeni. YOLO osiągnęło to, całkowicie zmieniając podejście do object detection. Zamiast wieloetapowego pipeline'u, zamieniło detekcję w pojedynczy problem regresji. Logika przechodzi bezpośrednio od surowych pikseli obrazu do współrzędnych bounding boxów i class probabilities w jednym, ciągłym kroku. Oto kluczowy pomysł. YOLO bierze obraz wejściowy i dzieli go na jednolity grid. Jeśli środek obiektu wpadnie do konkretnej komórki grida, to właśnie ta komórka staje się odpowiedzialna za wykrycie tego obiektu. Każda komórka grida jednocześnie przewiduje stałą liczbę bounding boxów. Dla każdego boxa zwraca współrzędne środka, szerokość i wysokość. Zwraca również confidence score, który mówi systemowi, jak bardzo jest pewny, że dany box faktycznie zawiera obiekt. Jednocześnie komórka przewiduje class probabilities. Oblicza, czy obiekt to samochód, ciężarówka, czy człowiek. Następnie sieć mnoży box confidence przez class probability. Ta pojedyncza operacja matematyczna odfiltrowuje wszystkie słabe strzały na całym gridzie, zostawiając tylko bardzo dokładne bounding boxy. Wyobraź sobie kamerę na bramce autostradowej. Samochody jadą z prędkością osiemdziesięciu mil na godzinę. Potrzebujesz sieci typu single-pass, żeby narysować bounding boxy wokół tablic rejestracyjnych, zanim samochód opuści kadr. Wieloetapowy detektor miałby laga, robiąc cropy i analizując wyizolowane fragmenty asfaltu, podczas gdy samochód by odjechał. YOLO przetwarza całą klatkę naraz. Nakłada grid, przewiduje geometrię i oblicza prawdopodobieństwa w jednym forward passie sieci neuronowej. Ponieważ YOLO przetwarza cały obraz w jednym przebiegu, z natury rozumie globalny kontekst sceny. Starsze modele często myliły fragmenty tła z obiektami, ponieważ widziały tylko wyizolowane cropy. Traktując detekcję jako pojedynczy problem regresji na gridzie, YOLO zmusza sieć do uczenia się uogólnionych reprezentacji obiektów w ich pełnym kontekście. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 9 z 20. Przez dekadę największym wąskim gardłem w detekcji obiektów w czasie rzeczywistym nie była sama sieć neuronowa. Był nim toporny, ręcznie napisany algorytm używany do czyszczenia jej chaotycznych, nakładających się na siebie predykcji. Rozwiązaniem tego problemu jest YOLOv26, a konkretnie jego architektura detekcji end-to-end NMS-free. Żeby zrozumieć tę zmianę, musisz przyjrzeć się, jak tradycyjne detektory kończą swoją pracę. Opierają się one na Non-Maximum Suppression, czyli NMS. NMS to powolny etap post-processingu. Kiedy standardowy model patrzy na obiekt, nie zwraca tylko jednego bounding boxa. Zwraca dziesiątki nakładających się na siebie boxów wokół tego samego obiektu. Wtedy wkracza NMS, żeby ocenić te boxy, obliczyć ich overlap, usunąć duplikaty i zostawić tylko jednego, najlepiej dopasowanego boxa. Ten proces czyszczenia jest z natury sekwencyjny i prawie zawsze działa na CPU. Wyobraź sobie deploy modelu wizyjnego na NVIDIA Jetson Orin dla robota sortującego w magazynie. Musisz wykrywać setki szybko poruszających się paczek w 60 klatkach na sekundę. GPU błyskawicznie przelatuje przez warstwy sieci neuronowej. A potem pipeline się zatrzymuje. CPU dławi się, próbując odpalić NMS na tysiącach surowych, nakładających się na siebie współrzędnych boxów. Twój frame rate drastycznie spada z powodu czyszczenia, a nie inferencji. YOLOv26 całkowicie eliminuje to wąskie gardło, zapewniając natywną inferencję NMS-free. Wrzucasz obraz do sieci, a sieć zwraca dokładnie jeden box na obiekt. Skrypt post-processingu znika. Żeby to było możliwe, architektura YOLOv26 pozbywa się komponentu o nazwie Distribution Focal Loss, czyli DFL. W poprzednich iteracjach DFL był używany do modelowania krawędzi bounding boxa jako ciągłego rozkładu statystycznego. Pomagał modelowi odgadnąć, gdzie mogą znajdować się rozmyte lub zasłonięte krawędzie, ale w naturalny sposób zachęcał sieć do generowania wielu nakładających się na siebie predykcji. Usunięcie DFL fundamentalnie zmienia zachowanie sieci. Bez niego model jest mocno karany podczas treningu za predykcję więcej niż jednego boxa na obiekt. To zmusza sieć do bycia absolutnie zdecydowaną. Jednak usunięcie DFL stwarza nowy problem. Zmuszenie sieci do zwracania dokładnie jednej, sztywnej granicy sprawia, że proces treningu staje się bardzo niestabilny. Loss landscape staje się ostry i chaotyczny. Żeby to naprawić, YOLOv26 integruje optimizer MuSGD ze swoim pipelinem treningowym. MuSGD stabilizuje proces uczenia, dynamicznie dostosowując momentum w oparciu o wariancję gradientów. Kiedy trening trafia na stromą, chaotyczną część loss landscape'u, MuSGD tłumi aktualizacje wag, żeby model się nie wykoleił. Gdy ścieżka gradientu jest stabilna, przyspiesza. To właśnie ten konkretny optimizer pozwala architekturze skonwergować do pojedynczej, ścisłej predykcji bez kolapsu. Rezultat podczas deployu jest ogromny. Kiedy eksportujesz model YOLOv26 do TensorRT dla tego robota magazynowego, cały pipeline zostaje na GPU. Sieć przetwarza klatkę i bezpośrednio zwraca końcowe współrzędne paczki. CPU jest całkowicie zwolnione do innych zadań związanych ze sterowaniem robotem. Oto kluczowy wniosek. Najszybszy kod to ten, który nigdy się nie odpala. Przenosząc ciężar deduplikacji ze skryptu post-processingu w runtime z powrotem do fazy optymalizacji podczas treningu, YOLOv26 odblokowuje wydajność sprzętową, która wcześniej była niemożliwa. To wszystko w tym odcinku. Dzięki za wysłuchanie i budujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 10 z 20. Tradycyjne detektory obiektów cierpią na poważną formę widzenia tunelowego. Potrafią doskonale śledzić samochody, ludzi i rowery, ale poproś je o znalezienie rozlanej kawy, a stają się całkowicie ślepe, ograniczone do garstki klas, na których zostały jawnie wytrenowane w laboratorium. Aby to naprawić, nie musisz labelować tysięcy rozlanych kubków. Potrzebujesz YOLO-World i Open-Vocabulary Zero-Shot Detection. Wyobraź sobie konkretny scenariusz. Zarządzasz systemem bezpieczeństwa w sklepie. Musisz przeszukać strumienie wideo na żywo w poszukiwaniu niebieskiej butelki hydroflask lub zaginionego golden retrievera. Ze standardowym detektorem typu fixed-vocabulary, musiałbyś zatrzymać system, zebrać zdjęcia golden retrieverów w swoim sklepie, ręcznie narysować wokół nich bounding boxy, przetrenować model i zrobić redeploy. Z YOLO-World po prostu wpisujesz text prompt do systemu. Znajduje obiekt natychmiast, zero-shot. To nie jest model generatywny text-to-image. On nie tworzy obrazków. Znacznie różni się też od zwykłego dodania nowej klasy do istniejącego datasetu. Detekcja open-vocabulary opiera się na głębokim, semantycznym zrozumieniu języka. Bezpośrednio mapuje lingwistyczne text prompty na wizualne bounding boxy. System przyjmuje dwa inputy: obraz i zestaw text promptów. Używa vision backbone do wyciągnięcia cech wizualnych z obrazu. Jednocześnie używa text encodera, aby przetłumaczyć twoje text prompty na wektory matematyczne, zwane embeddingami. I tu robi się ciekawie. Te dwa odrębne strumienie danych muszą zostać połączone. YOLO-World radzi sobie z tym za pomocą struktury o nazwie RepVL-PAN. To skrót od Reparameterizable Vision-Language Path Aggregation Network. Akronim jest skomplikowany, ale jego funkcja jest prosta. RepVL-PAN łączy cechy obrazu i tekstu. Wstrzykuje semantyczne znaczenie twojego text promptu bezpośrednio do visual feature mapy w wielu skalach. Podczas gdy sieć przetwarza piksele, jest aktywnie kierowana przez text embedding. Model uczy się tego podczas początkowej fazy treningu poprzez mechanizm zwany region-text contrastive loss. Model generuje bounding boxy i wyciąga cechy wizualne z tych regionów. Następnie porównuje te cechy wizualne z text embeddingami. Contrastive loss mocno karze model, jeśli cechy wizualne boxa nie pokrywają się z właściwym text embeddingiem. I nagradza model, gdy do siebie pasują. To wymusza na sieci precyzyjne dopasowanie swojej reprezentacji wizualnej do pojęć lingwistycznych na ogromnych datasetach par obraz-tekst. Uczy się, co oznaczają słowa „niebieski”, „hydroflask” i „butelka” jako ogólne pojęcia, zamiast zapamiętywać pojedynczą, sztywną kategorię. Kiedy uruchamiasz model na produkcji, workflow jest niezwykle przejrzysty. Najpierw definiujesz customową listę słownictwa zawierającą twoje obiekty docelowe. Przepuszczasz tę listę przez text encoder jeden raz, aby wygenerować swoje text embeddingi. Następnie przekazujesz klatki wideo na żywo do visual backbone. Architektura RepVL-PAN łączy przychodzące dane wizualne z twoimi wcześniej obliczonymi text embeddingami. Na koniec model zwraca bounding boxy i confidence scores na podstawie tego, jak bardzo obszary wizualne pasują do twoich słów. Prawdziwą siłą YOLO-World jest oddzielenie detektora od sztywnego datasetu, co pozwala ci na użycie języka naturalnego jako wykonywalnego w czasie rzeczywistym zapytania do fizycznego świata. Dzięki za wysłuchanie. Do usłyszenia następnym razem!

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 11 z 20. Dla współczesnego AI twoja tożsamość nie jest definiowana przez kształt nosa czy odległość między oczami. Zamiast tego, twoją tożsamość definiuje dokładna pozycja w 128-wymiarowej przestrzeni geometrycznej. Classic to Deep: Facial Recognition Evolution wyjaśnia, jak doszliśmy do tego modelu. Najpierw musimy rozdzielić dwa pojęcia, które często się ze sobą mylą. Face detection polega na znalezieniu miejsca, w którym twarz znajduje się na obrazie. Rysuje bounding box wokół pikseli, które wyglądają jak ludzka głowa. Z kolei face recognition to identyfikacja, czyja twarz znajduje się wewnątrz tego boxa. Ten odcinek skupia się wyłącznie na recognition. Przez dekady standardowe podejście było statystyczne. Jeśli budowałeś system na początku lat dwutysięcznych, prawdopodobnie używałeś techniki o nazwie Eigenfaces. Eigenfaces opierają się na algorytmie Principal Component Analysis, czyli PCA. Zaczynasz od datasetu obrazów twarzy i spłaszczasz każdy obraz do ogromnego, jednowymiarowego arraya surowych intensywności pikseli. Następnie PCA analizuje cały ten dataset, aby znaleźć kierunki maksymalnej wariancji. Znajduje ukryte matematyczne wzorce, które odróżniają jedną twarz od drugiej. Kiedy zwizualizujesz te główne składowe, wyglądają jak upiorne, rozmyte twarze. Aby rozpoznać nową osobę za pomocą Eigenfaces, system rzutuje nowy, surowy obraz na tę podprzestrzeń głównych składowych i oblicza dystans do znanych twarzy w bazie danych. To działa w ściśle kontrolowanych środowiskach, ale wysypuje się w prawdziwym świecie. Cień na policzku albo lekkie pochylenie głowy całkowicie zmieniają surowe wartości pikseli. Algorytm widzi inny wzór światła i cię nie rozpoznaje. I tu pojawia się kluczowy wniosek. Deep learning całkowicie odrzucił pomysł porównywania wariancji surowych pikseli. Nowoczesne systemy używają Convolutional Neural Networks do generowania embeddingów. Embedding to gęsty wektor liczb reprezentujący wysokopoziomowe cechy twarzy. Te sieci są trenowane na milionach obrazów z użyciem zaawansowanych matematycznych kar, takich jak ArcFace loss. Podczas treningu sieć jest zmuszana do przybliżania do siebie wektorów embeddingów tej samej osoby w przestrzeni geometrycznej, jednocześnie odpychając od siebie wektory różnych osób. Wyobraź sobie bezpieczny zamek w drzwiach biura wyposażony w kamerę. Kiedy zbliża się gość, system wykrywa i kadruje twarz, a następnie przepuszcza ten wykadrowany obraz przez sieć neuronową. Sieć zwraca na wyjściu pojedynczy array 128 liczb zmiennoprzecinkowych. To jest właśnie wektor embeddingu. Następnie system oblicza prosty dystans euklidesowy między tym wektorem gościa a bazą danych wektorów autoryzowanych pracowników. Nie porównuje pikseli ani oświetlenia. Mierzy po prostu odległość w linii prostej między dwoma punktami w 128-wymiarowej przestrzeni. Jeśli dystans do wektora pracownika jest poniżej zdefiniowanego progu, drzwi się odblokowują. System jest solidny, ponieważ podczas treningu sieć nauczyła się ignorować cienie, okulary i lekkie obroty głowy. Ewolucja od Eigenfaces do deep embeddingów to przejście od analizowania tego, jak światło pada na twarz, do mapowania koncepcyjnej tożsamości osoby w mierzalnym układzie współrzędnych. Jeśli chcesz pomóc w utrzymaniu stałego dopływu kawy i wesprzeć podcast, możesz wyszukać DevStoriesEU na Patreon. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 12 z 20. Uruchamianie ciężkiej sieci neuronowej na każdej pojedynczej klatce wideo o wysokiej rozdzielczości jest bardzo kosztowne obliczeniowo. Inteligentne systemy wykrywają obiekt raz, a następnie wykorzystują błyskawiczne równania fizyczne, aby przewidzieć jego dalszy ruch. To domena Persistent Perception: Object Tracking Algorithms. Wyobraź sobie system monitorowania ruchu w inteligentnym mieście. Musisz policzyć unikalne pojazdy przejeżdżające przez ruchliwe skrzyżowanie. Model object detection analizuje pojedynczy, zamrożony moment w czasie. Jeśli uruchomisz samą detekcję na wideo z prędkością trzydziestu klatek na sekundę, samochód zatrzymany na czerwonym świetle przez dziesięć sekund wygeneruje trzysta oddzielnych, niepowiązanych bounding boxów. Bez logiki trackingu twój system policzy trzysta samochodów. Detekcja znajduje obiekt. Tracking matematycznie wiąże ten obiekt z jego wcześniejszym stanem w czasie. Aby rozwiązać problem z kamerą drogową, potrzebujesz multi-object trackera, który utrzyma stałe ID dla każdego pojazdu. Nowoczesne trackery, takie jak te zaimplementowane przy użyciu Roboflow i OpenCV, dzielą ten problem na dwie odrębne fazy matematyczne. Pierwsza faza to predykcja, a druga to asocjacja. Gdy samochód pojawia się na feedzie z kamery, początkowy detektor rysuje bounding box. Tracker wyciąga współrzędne środka, szerokość i wysokość tego boxa, i przypisuje mu unikalnego integera, na przykład ID 42. Gdy pojawia się kolejna klatka wideo, tracker nie skanuje od razu obrazu. Zamiast tego wykorzystuje model matematyczny, zazwyczaj Kalman Filter, do wykonania state estimation. Analizując, jak ID 42 poruszał się na poprzednich klatkach, filtr oblicza prędkość pojazdu. Następnie projektuje te właściwości fizyczne w przód, aby dokładnie przewidzieć, gdzie w nowej klatce powinien znajdować się bounding box dla ID 42. Masz teraz dwa zestawy danych dla bieżącej klatki. Masz przewidywane boxy wygenerowane przez state estimator oraz rzeczywiste boxy właśnie znalezione przez detektor. I tu pojawia się kluczowa kwestia. Tracker musi pogodzić te dwa zestawy, aby zachować spójność ID bez ponownego analizowania samych pikseli. Buduje macierz porównującą każdy przewidywany box z każdym nowo wykrytym boxem. Podstawową metryką używaną do tego porównania jest Intersection over Union, czyli IoU. Mierzy ona, w jakim stopniu przewidywany obszar geometryczny pokrywa się z wykrytym obszarem geometrycznym. Jeśli przewidywana lokalizacja dla ID 42 w znacznym stopniu pokrywa się z nowo wykrytym bounding boxem, system uznaje, że to ten sam pojazd. Metoda optymalizacji, zazwyczaj Hungarian algorithm, rozwiązuje tę macierz, aby znaleźć najbardziej logiczne pary jeden do jednego na całym skrzyżowaniu. Nowa detekcja dziedziczy ID 42, a tracker aktualizuje swój model prędkości o nowe, potwierdzone współrzędne. Ta pętla predykcji i asocjacji naturalnie radzi sobie z tymczasowymi przeszkodami wizualnymi. Jeśli autobus zasłoni nasz samochód na kilka klatek, detektor nie jest w stanie go znaleźć. Jednak state estimator nadal przewiduje ruch samochodu za autobusem na podstawie jego ostatniej znanej trajektorii. ID jest utrzymywane przy życiu w stanie pending. Gdy samochód się wyłoni, a detektor zaznaczy bounding box, który pokrywa się z trwającą, ślepą predykcją trackera, ID zostaje natychmiast ponownie przypisane. Wypełniając lukę między niezależnymi klatkami, multi-object tracking przekształca strumień statycznych obrazów w spójną mapę poruszających się obiektów. Tracking pozwala twojej aplikacji przestać pytać o to, co znajduje się na klatce, i zacząć rozumieć, jak obiekty zachowują się w czasie. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórz dalej!

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 13 z 20. Spędziliśmy lata trenując AI do rysowania bounding boxów wokół obiektów, ale te boxy są nieporęczne i pełne szumu z tła. Prawdziwym celem jest poproszenie systemu w prostym angielskim o narysowanie pixel-perfect sylwetki wokół dokładnych konturów obiektu, nawet jeśli nigdy wcześniej nie był na nim bezpośrednio trenowany. To prowadzi nas do Vision-Language Models do segmentacji. Tradycyjne modele segmentacji obrazu są sztywne. Mapują piksele na stałą, zamkniętą listę kategorii, takich jak samochód, osoba czy drzewo. Jeśli chcesz wysegmentować coś spoza tej listy, musisz zebrać ogromny dataset i wytrenować zupełnie nowy model. Vision-Language Models, czyli VLM-y, przełamują to ograniczenie, łącząc duże modele językowe z visual encoderami, aby wykonywać open-world segmentation. Podajesz na wejściu obraz i dowolny string tekstowy, a model zwraca gęstą maskę na poziomie pikseli tego, co opisałeś. Wyobraź sobie zautomatyzowanego drona rolniczego latającego nad winnicą. Rolnik nie chce zwykłych boxów wokół roślin. Potrzebuje precyzyjnej mapy infekcji. Wysyła do drona prompt ze stringiem diseased grape leaves. VLM przetwarza visual feed i text prompt jednocześnie. Rozumie semantyczne znaczenie słów diseased i grape leaves na podstawie swojego treningu językowego, dopasowuje to znaczenie do visual features obrazu i zwraca maskę na wyjściu. Ta maska izoluje tylko zainfekowane liście z dokładnością do pojedynczego piksela, całkowicie ignorując zdrowe liście, glebę i cienie. To prowadzi nas do tego, jak model właściwie wykonuje tę logikę. Podejściem bazowym jest text prompting typu zero-prediction, często nazywany zero-shot. W tym trybie model polega całkowicie na ogromnym datasecie, na którym został pierwotnie wytrenowany. Text prompt przechodzi przez text encoder, zmieniając się w matematyczną reprezentację twojego zapytania. Jednocześnie obraz przechodzi przez vision encoder, który dzieli go na siatkę visual features. Następnie model oblicza podobieństwo między twoją reprezentacją tekstową a każdym pojedynczym visual feature w tej siatce. Wysokie wyniki podobieństwa stają się twoją maską. Kluczowe jest tutaj to, że wagi modelu pozostają całkowicie zamrożone. Wyciągasz złożoną maskę pikselową, używając tylko siły language alignment. Oto kluczowy wniosek. Zero-prediction jest potężne, ale opiera się na szerokim treningu general-purpose. Czasami domena wizualna jest po prostu zbyt wyspecjalizowana. Jeśli konkretna choroba liści winogron wygląda identycznie jak nieszkodliwy niedobór składników odżywczych, zamrożony VLM może mieć problem z odróżnieniem ich wyłącznie na podstawie opisu tekstowego. Wtedy właśnie przechodzisz na visual fine-tuning. Zamiast tylko zmieniać text prompt, aktualizujesz rzeczywiste wagi komponentów wizualnych modelu, używając małego datasetu bardzo specyficznych, ręcznie zamaskowanych obrazów. W ten sposób bezpośrednio uczysz vision encoder niuansów wizualnej tekstury choroby, zamiast polegać tylko na szerokim, konceptualnym zrozumieniu słowa choroba przez model językowy. Zero-prediction traktuje VLM jako silnik wnioskowania out-of-the-box, sterowany całkowicie przez słowa, podczas gdy visual fine-tuning traktuje go jako potężny fundament, który trwale modyfikujesz, aby opanować konkretną domenę wizualną. Prawdziwa siła nowoczesnej segmentacji nie polega już na zbieraniu milionów oznaczonych pikseli; chodzi o to, by wiedzieć, kiedy sterować zamrożonym modelem za pomocą sprytnego text promptu, a kiedy poświęcić compute na zmianę jego wag wizualnych. To wszystko w tym odcinku. Dzięki za wysłuchanie i budujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 14 z 20. Chociaż ludzie postrzegają kolor jako mieszankę czerwonego, zielonego i niebieskiego, próba zaprogramowania komputera do śledzenia obiektu za pomocą RGB to koszmar, gdy tylko chmura zasłoni słońce. Rozwiązanie tkwi w tym, jak matematycznie reprezentujemy i łączymy piksele. Dzisiaj bierzemy na warsztat Pixel Alchemy: Alpha Blending i Color Spaces. Głównym problemem z przestrzenią barw RGB jest to, że łączy informacje o kolorze bezpośrednio z luminancją. Jeśli cień padnie na jasnozielony obiekt, wartości jego pikseli dla kanałów Red, Green i Blue znacznie się zmienią. Dla standardowego algorytmu thresholdingu, zacieniony zielony obiekt wygląda zupełnie inaczej niż ten oświetlony. Aby to naprawić, transformujesz obraz z RGB do przestrzeni HSV. HSV to skrót od Hue, Saturation i Value. Hue reprezentuje sam kolor bazowy jako kąt na walcu kolorów. Saturation reprezentuje intensywność tego koloru, a Value jego jasność. Dzięki wyizolowaniu informacji o czystym kolorze w pojedynczym kanale Hue, twój pipeline computer vision staje się wysoce odporny na zmiany oświetlenia. Możesz skonfigurować swoją logikę tak, aby szukała konkretnego odcienia zieleni, a ona znajdzie go niezależnie od tego, czy pokój jest jasno oświetlony, czy ciemny. Ta odporność jest kluczowa, gdy budujesz coś w rodzaju zautomatyzowanego systemu green-screen do transmisji. Chcesz płynnie zblendować dynamiczną mapę pogody za prezenterem wiadomości. Najpierw bierzesz feed z kamery i konwertujesz go do HSV. Następnie definiujesz zakres dla Hue zieleni, odpowiadający fizycznemu tłu. Dla każdego piksela, który mieści się w tym zakresie zielonego Hue, zwracasz zero. Dla całej reszty, jak prezenter, zwracasz jedynkę. To tworzy binarną maskę. Ta maska działa jako twój kanał alpha. I tu jest kluczowa sprawa. Słuchacze często mówią o alpha, jakby to był kolor, prawie jak przezroczysty barwnik. A tak nie jest. Alpha to czysto liczbowa waga, wartość skalarna między zerem a jeden, która dyktuje opacity w równaniu interpolacji liniowej. Blending obrazów to po prostu arytmetyka piksel po pikselu. Aby połączyć prezentera na pierwszym planie i mapę pogody w tle, używasz konkretnego równania. Dla każdego piksela, końcowy kolor na wyjściu równa się pikselowi pierwszego planu pomnożonemu przez wartość alpha, plus piksel tła pomnożony przez jeden minus wartość alpha. Przemyśl matematykę tego scenariusza z green-screenem. Tam, gdzie stoi prezenter, alpha wynosi jeden. Piksel pierwszego planu jest mnożony przez jeden, co idealnie zachowuje prezentera. Piksel mapy pogody z tła jest mnożony przez jeden minus jeden, czyli zero. Mapa pogody znika dokładnie w tym miejscu. Z kolei tam, gdzie znajduje się green-screen, alpha wynosi zero. Zielony piksel pierwszego planu mnoży się przez zero, całkowicie wymazując fizyczny ekran. Piksel mapy pogody z tła mnoży się przez jeden minus zero, czyli jeden, dzięki czemu mapa pogody jest w pełni widoczna. Jeśli chcesz uzyskać gładką krawędź z antyaliasingiem wokół prezentera, używasz ułamkowych wartości alpha, takich jak zero przecinek pięć wzdłuż granicy. To uśrednia piksele pierwszego planu i tła, aby uniknąć ostrych, poszarpanych konturów. Najbardziej przydatną rzeczą do zapamiętania jest to, że obrazy w pamięci to po prostu macierze, a manipulacja pikselami to po prostu arytmetyka na macierzach; wybór odpowiedniego układu współrzędnych, takiego jak HSV, sprawia, że ta arytmetyka jest odporna i przewidywalna, a nie krucha. Dzięki za spędzenie ze mną tych kilku minut. Do następnego razu, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 15 z 20. Każde zdjęcie, które kiedykolwiek zrobiłeś, jest subtelnym kłamstwem, zniekształconym przez zakrzywione szkło obiektywu. W robotyce to lekkie zniekształcenie to różnica między złapaniem piłki a całkowitym spudłowaniem. Rozwiązanie tego problemu wymaga Kalibracji Kamery: Radzenia sobie ze Zniekształceniem Obiektywu. Montujesz na ramieniu robota tanią kamerkę internetową typu fisheye, która mocno zniekształca obraz. System musi obliczyć odległość co do milimetra, aby bezpiecznie chwycić delikatny kubek z kawą. Jeśli będziesz bezpośrednio przetwarzać surowy feed wideo, twoja geometria będzie całkowicie błędna. Obiektyw zakrzywia wpadające światło, co oznacza, że piksel blisko krawędzi kadru reprezentuje drastycznie inną rzeczywistą odległość niż piksel w samym środku. Jeśli robot zaufa tym surowym pikselom, po prostu zmiażdży kubek. Musimy skorygować dwa główne rodzaje zniekształceń obiektywu. Pierwszy to zniekształcenie radialne. Światło zakrzywia się mocniej na krawędziach obiektywu niż w jego środku. Przez to proste linie wydają się zakrzywione, często wybrzuszając się na zewnątrz jak beczka lub zapadając do środka. Drugi rodzaj to zniekształcenie styczne. Powstaje ono podczas produkcji, gdy obiektyw nie jest zamontowany idealnie równolegle do sensora obrazu, przez co niektóre obszary wydają się znajdować bliżej niż inne. Aby to naprawić, potrzebujemy znanego geometrycznego punktu odniesienia. Standardem w branży jest prosty, płaski wzór szachownicy wydrukowany na sztywnej planszy. Szachownica daje ostre, wysoce kontrastowe, przecinające się linie, co niezwykle ułatwia algorytmowi detekcji precyzyjne namierzenie wewnętrznych narożników. Co ważniejsze, ponieważ sami ją wydrukowaliśmy, znamy dokładne fizyczne wymiary kwadratów. Developerzy często mylą parametry intrinsic i extrinsic, gdy mają do czynienia z danymi kalibracyjnymi. Łatwo wrzucić je do jednego worka jako po prostu ustawienia kamery. Oto kluczowa kwestia. Parametry extrinsic w ogóle nie opisują hardware'u kamery. Definiują one fizyczną lokalizację i rotację kamery w świecie 3D względem sceny. Z kolei parametry intrinsic definiują wewnętrzne właściwości fizyczne obiektywu i sensora. Zawierają w sobie ogniskową i środek optyczny. Macierz intrinsic jest unikalna dla tej konkretnej fizycznej kamery i pozostaje stała, niezależnie od tego, gdzie poruszy się ramię robota. Proces kalibracji polega na mapowaniu znanych punktów 3D na obserwowane piksele 2D. Najpierw robisz kilkanaście lub więcej zdjęć szachownicy pod różnymi kątami i z różnych odległości za pomocą swojej kamerki. Następnie odpalasz na tych obrazach funkcję detekcji narożników. Tworzysz listę miejsc, w których te współrzędne pikseli 2D lądują na obrazach, i parujesz je z arrayem rzeczywistych współrzędnych 3D tych samych narożników. Współrzędne 3D to po prostu płaska siatka oparta na znanym rozmiarze kwadratu, z osią Z ustawioną na zero. Przekazujesz oba zestawy współrzędnych do funkcji kalibracji kamery. Algorytm oblicza matematyczną transformację wymaganą do zmapowania punktów 3D na twoje obrazy 2D. Zwraca on twoją macierz intrinsic kamery, wektory rotacji i translacji extrinsic dla każdego obrazu oraz zestaw współczynników zniekształceń. Te współczynniki obsługują zarówno zniekształcenie radialne, jak i styczne. Kiedy masz już te współczynniki i macierz intrinsic, przekazujesz je do funkcji undistortion. Każda nowa klatka, którą widzi twój robot, jest matematycznie rozciągana i przywracana do prawdziwej projekcji rektilinearnej. Proste linie znów stają się proste. Twoje ramię robota może teraz mierzyć dokładne milimetry, wyciągnąć się i bezpiecznie chwycić kubek. Macierz intrinsic to fundamentalna warstwa geometrii computer vision, przekształcająca zniekształcony array pikseli w matematycznie wiarygodny układ współrzędnych. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 16 z 20. Wykorzystując dokładnie ten sam biologiczny trik, którego używają nasze ludzkie oczy do postrzegania trójwymiarowej przestrzeni, komputer może błyskawicznie obliczyć odległość do obiektu, używając tylko podstawowej geometrii. To jest Stereo Vision: Finding Depth with Two Cameras. Pojedyncza kamera samochodowa rejestruje płaską, dwuwymiarową projekcję świata. Całkowicie traci przy tym informacje o głębi. Bez kontekstu nie jest w stanie wiarygodnie określić, czy samochód z przodu jest mały i blisko, czy duży i daleko. Żeby zbudować Advanced Driver Assistance System, czyli ADAS, który faktycznie zapobiegnie kolizji z hamującym samochodem, potrzebujesz rzeczywistej fizycznej odległości. Możesz to osiągnąć, montując dwie idealnie wyrównane kamery samochodowe. Fizyczna odległość między ich obiektywami to tak zwany baseline. Żeby określić odległość do samochodu z przodu, system musi znaleźć dokładnie ten sam punkt na tym samochodzie zarówno na obrazie z lewej, jak i z prawej kamery. Przeszukiwanie całego prawego obrazu w poszukiwaniu punktu z lewego obrazu jest zdecydowanie zbyt wolne, żeby działało w czasie rzeczywistym podczas jazdy. I tu do gry wchodzi epipolar geometry. Poprzez matematyczną transformację, czyli tak zwaną rectification obu obrazów, tak aby ich obiektywy były wirtualnie wyrównane w dokładnie tej samej płaszczyźnie, upraszczasz to wyszukiwanie. Konkretne tylne światło znalezione w dwusetnym wierszu na lewym obrazie będzie teraz zawsze znajdować się tylko w dwusetnym wierszu na prawym obrazie. Ta pozioma ścieżka wyszukiwania to tak zwana epipolar line. System musi tylko skanować w lewo i w prawo wzdłuż jednego wiersza. Kiedy system znajdzie pasujący piksel wzdłuż tej linii, mierzy różnicę w ich poziomym położeniu. Ta różnica to tak zwane disparity. Ludzie często mylą disparity z głębią, ale są one odwrotnie proporcjonalne. Obiekty, które drastycznie zmieniają pozycję między widokami z dwóch kamer, są fizycznie bliżej obiektywów. Jeśli hamujący samochód z przodu przeskakuje o czterdzieści pikseli między lewym a prawym widokiem, to znaczy, że jest bardzo blisko. Jeśli góra na horyzoncie przesuwa się tylko o jeden piksel, jest daleko. Wysokie disparity oznacza małą głębię. I tu jest kluczowa sprawa. Nie potrzebujesz tylko odległości do jednego tylnego światła. Potrzebujesz gęstej disparity map, czyli wartości głębi dla prawie każdego piksela w kadrze. OpenCV radzi sobie z tym używając block matching, a konkretnie algorytmu o nazwie Semi Global Block Matching. Zamiast próbować dopasować pojedynczy, niejednoznaczny piksel, bierze mały blok pikseli z lewego obrazu. Następnie przesuwa ten blok wzdłuż poziomej epipolar line na prawym obrazie, porównując intensywność pikseli, aż znajdzie najlepsze matematyczne dopasowanie. Robi to dla całego obrazu, nakładając kary za nagłe skoki disparity, żeby wynikowa mapa była gładka i fizycznie realistyczna. Kiedy masz już disparity map, konwersja na rzeczywistą głębię to tylko jedno obliczenie. Mnożysz ogniskową kamer przez fizyczny baseline między nimi i dzielisz ten wynik przez wartość disparity piksela. Matematyka jest tu niepodważalna. Nie zgadujesz na podstawie cieni czy rozmiaru obiektu. Dopóki twoje kamery pozostają sztywno skalibrowane i wyrównane, to geometryczne obliczenie daje ci precyzyjną odległość do pojazdu z przodu w milisekundach. Piękno skalibrowanego stereo rig polega na tym, że omija on potrzebę identyfikacji tego, czym jest obiekt, zanim dowiemy się, gdzie on jest. To wszystko w tym odcinku. Dzięki za wysłuchanie i keep building!

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 17 z 20. Przez dekady inżynierowie computer vision uważali, że do obliczenia rzeczywistej odległości potrzebujesz dwóch kamer. Potrzebowałeś widzenia stereoskopowego, żeby triangulować punkty w przestrzeni. Dziś modele AI potrafią ocenić fizyczną odległość na podstawie pojedynczego, płaskiego obrazu, interpretując cienie, teksturę i skalę dokładnie tak, jak robi to malarz. Ten przełom nazywa się Deep Monocular Metric Depth. Ludzie często mylą głębię względną z głębią metryczną. Głębia względna to po prostu wiedza, że sofa stoi przed ścianą. To sortowanie warstw wizualnych. Głębia metryczna oznacza wiedzę, że sofa znajduje się dokładnie dwa przecinek cztery metra od obiektywu aparatu. Do niedawna wyciągnięcie absolutnych pomiarów metrycznych z jednego zdjęcia uważano za matematycznie niemożliwe. Pojedynczy, dwuwymiarowy obraz traci całą swoją rzeczywistą skalę. Obiekt może być mały i blisko obiektywu, albo wielki i bardzo daleko. Modele deep learning całkowicie omijają problem klasycznej geometrii. Zamiast triangulować punkty między dwoma obiektywami, sieci takie jak DepthPro uczą się na ogromnych datasetach, zawierających miliony obrazów sparowanych z mapami głębi 3D typu ground-truth. Kiedy karmisz sieć pojedynczym, standardowym obrazem, nie szuka ona dysparycji stereo. Ocenia wskazówki monokularne. Analizuje gradienty tekstury, zauważając, że powierzchnie wydają się gładsze, im dalej się znajdują. Przetwarza oświetlenie kontekstowe, okluzję i znaną fizyczną skalę rozpoznawalnych obiektów. Następnie model buduje gęstą, tworzoną piksel po pikselu predykcję absolutnej odległości. I tu pojawia się kluczowa sprawa. Nowoczesne architektury osiągają to bez znajomości twoich camera intrinsics. Nie musisz podawać sieci ogniskowej, pola widzenia ani rozmiaru matrycy aparatu, którym zrobiono zdjęcie. Sieć wnioskuje ogniskową bezpośrednio z wizualnej zawartości samego obrazu. To tworzy rozwiązanie zero-shot. Dajesz modelowi zdjęcie zrobione dowolnym, nieskalibrowanym obiektywem, a on zwraca precyzyjną, absolutną mapę głębi. Pomyśl o aplikacji AR na standardowym smartfonie. Użytkownik chce sprawdzić, czy nowy stół do jadalni zmieści się w jego domu. Staje w pustym pokoju i kieruje swój pojedynczy, tylny aparat na podłogę. Klasyczne AR wymaga od ciebie poruszania telefonem, żeby wygenerować paralaksę i powoli zbudować mapę przestrzenną. Dzięki Deep Monocular Metric Depth, aplikacja natychmiast przetwarza pojedynczą, statyczną klatkę. Sieć neuronowa w ciągu milisekund oblicza dokładną objętość i wymiary przestrzeni na podłodze. Następnie aplikacja renderuje wirtualny stół na podglądzie z kamery, idealnie wyskalowany do rzeczywistego świata i osadzony na podłodze na dokładnie odpowiedniej głębi. Pod maską, osiągnięcie tego wymaga ogromnych receptive fields w architekturze sieci neuronowej. Model wykorzystuje Vision Transformers do uchwycenia globalnego kontekstu. Patrzy na cały obraz naraz, żeby zrozumieć ogólną geometrię pomieszczenia. Następnie łączy ten szeroki widok z lokalnym przetwarzaniem w wysokiej rozdzielczości. To podwójne podejście pozwala modelowi na generowanie ostrych granic głębi wokół złożonych krawędzi, takich jak cienkie nogi krzesła czy liście rośliny doniczkowej. Całkowicie unika artefaktów rozmywających krawędzie, które były plagą wcześniejszych modeli depth estimation. Fundamentalną zmianą jest możliwość wyciągnięcia absolutnych pomiarów przestrzennych z pojedynczej, całkowicie nieskalibrowanej klatki obrazu. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 18 z 20. Najbardziej imponujące współczesne deploye sztucznej inteligencji nie działają w ogromnych, klimatyzowanych farmach serwerów. Działają na dwudolarowych krzemowych chipach, zasilanych baterią od zegarka, gdzieś na odludziu. Przeniesienie złożonych sieci neuronowych na te maleńkie urządzenia wymaga zupełnie innego podejścia, co prowadzi nas do AI on the Edge: deployu na mikrokontrolery. Mikrokontrolery są niezwykle ograniczone. Mówimy o urządzeniach z kilobajtami pamięci RAM, kilkoma megabajtami pamięci flash i restrykcyjnymi limitami zasilania. Standardowe modele computer vision używają 32-bitowych floatów dla swoich wag i aktywacji. Typowy model potrzebuje setek megabajtów, żeby tylko załadować się do pamięci. Jeśli spróbujesz odpalić to na podstawowym mikrokontrolerze, od razu zcrashuje z powodu braku pamięci. Wyobraź sobie zasilaną z baterii, ładowaną solarnie fotopułapkę zdeployowaną głęboko w lesie. Jej zadaniem jest wypatrzenie zagrożonego wyginięciem irbisa śnieżnego. Jeśli kamera będzie wybudzać swój nadajnik radiowy, żeby wysyłać każde zdjęcie wyzwolone ruchem do chmury do analizy, bateria padnie w jeden dzień. Urządzenie musi odpalać object detector lokalnie. Musi przetwarzać video feed bezpośrednio na krzemie i wybudzać prądożerny nadajnik, żeby wysłać alert tylko wtedy, gdy konkretnie zidentyfikuje irbisa. Aby zmieścić model computer vision na tak małym chipie, musisz go agresywnie odchudzić. Robisz to głównie za pomocą dwóch technik: pruning i quantization. Pruning to dokładnie to, na co wskazuje nazwa. Analizujesz wytrenowaną sieć neuronową i usuwasz połączenia, które mają najmniejszy wpływ na końcową predykcję. W zasadzie wycinasz martwe drewno z architektury sieci, żeby na każdą klatkę przypadało mniej obliczeń. Druga technika, quantization, to moment, w którym następuje prawdziwa redukcja rozmiaru. To jest ta najważniejsza część. Quantization zmniejsza precyzję numeryczną modelu. Zamiast przechowywać każdą wagę jako 32-bitowy float, mapujesz te wartości na 8-bitowy integer, co powszechnie nazywa się konwersją do INT8. Główny trade-off jest tutaj prosty. Celowo pozbywasz się precyzji numerycznej. Żeby zrobić to poprawnie, przepuszczasz calibration dataset przez model, aby śledzić minimalne i maksymalne wartości wag. Następnie skalujesz ten zakres floatów, żeby dokładnie zmieścił się w 256 możliwych wartościach 8-bitowego integera. W ten sposób poświęcasz ułamek dokładności modelu w zamian za ogromną redukcję memory footprintu i czasu wykonywania. Model INT8 zajmuje dokładnie jedną czwartą miejsca modelu 32-bitowego. Co więcej, mikrokontrolery radzą sobie z matematyką na integerach znacznie szybciej i przy znacznie mniejszym zużyciu energii niż w przypadku floatów. Wiele energooszczędnych mikrokontrolerów w ogóle nie ma dedykowanego sprzętu do operacji na floatach. To oznacza, że matematyka na floatach musi być emulowana w software, co jest niesamowicie wolne i drenuje baterię. Z modelem INT8 po agresywnym quantization, kiedy fotopułapka rejestruje obraz, sieć neuronowa mnoży i dodaje małe integery w pojedynczych cyklach zegara sprzętowego. Mikrokontroler może przeanalizować obraz w milisekundy, potwierdzić brak irbisa śnieżnego i natychmiast wrócić do stanu deep sleep, żeby oszczędzać energię. Sam proces deployu zaczyna się na zwykłym desktopie. Trenujesz swój model na standardowym datasecie. Po wytrenowaniu odpalasz skrypt konwertera, który aplikuje pruning i quantization do INT8. Output to zazwyczaj płaski byte array wyeksportowany jako blok kodu w nagłówku C, zawierający skompresowane wagi. Kompilujesz to bezpośrednio do firmware'u swojego mikrokontrolera razem ze sterownikami kamery. Nie ma tu systemu operacyjnego ani systemu plików, z których można by ładować modele w runtime. To czysta skompilowana logika wykonywana bezpośrednio na bare metal. To ostateczne ograniczenie w tym środowisku zmienia sposób, w jaki oceniasz sukces. Na mikrokontrolerze twoją główną metryką nie jest już szczytowa precyzja, ale liczba dokładnych inferencji, które możesz wykonać na milidżul energii z baterii. Jeśli chcesz pomóc nam utrzymać ten podcast, możesz nas wesprzeć, wyszukując DevStoriesEU na Patreonie. To wszystko na dzisiaj. Dzięki za wysłuchanie i keep building!

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 19 z 20. Tradycyjne gry wideo renderują światy, rysując miliony maleńkich, płaskich trójkątów. Najnowsza rewolucja w computer vision całkowicie rezygnuje z trójkątów, renderując rzeczywistość jako gęstą chmurę milionów nakładających się na siebie, świecących, matematycznych blobów. To Radiance Fields: 3D Gaussian Splatting. Agent nieruchomości spaceruje po domu, nagrywając standardowe wideo smartfonem. Musisz przetworzyć ten surowy materiał na w pełni nawigowalny, fotorealistyczny wirtualny spacer 3D z dynamicznymi odbiciami i oświetleniem. Przez kilka lat standardowym podejściem były Neural Radiance Fields, czyli NeRF-y. NeRF mapuje przestrzeń używając implicit neural network. Aby wygenerować obraz, wypuszcza matematyczny ray przez scenę i odpytuje neural network w setkach punktów wzdłuż tego raya, żeby sprawdzić, jaki jest tam kolor i gęstość. Daje to piękne rezultaty, ale odpytywanie deep neural network dla milionów pikseli jest strasznie wolne. 3D Gaussian Splatting rezygnuje z implicit neural network. Zamiast tego wykorzystuje explicit strukturę przypominającą point cloud. Pipeline zaczyna się od standardowego algorytmu structure-from-motion, który analizuje wideo ze smartfona, żeby wyśledzić pozycję kamery i zbudować rzadki 3D point cloud tego domu. Następnie algorytm zastępuje każdy pojedynczy punkt w tym point cloudzie 3D Gaussianem. Możesz myśleć o 3D Gaussianie jako o półprzezroczystej, kolorowej elipsoidzie. Każdy Gaussian przechowuje konkretny zestaw parametrów. Ma współrzędną środka w przestrzeni 3D. Ma macierz kowariancji, która dyktuje jego skalę i rotację, rozciągając go w płaski dysk albo długie cygaro, w zależności od geometrii, którą reprezentuje. Ma wartość opacity. I wreszcie, przechowuje dane o kolorze używając Spherical Harmonics. I tu jest kluczowa sprawa. Spherical Harmonics to funkcje matematyczne, które kodują kolor kierunkowo. Kiedy patrzysz na Gaussiana pod jednym kątem, może on odbijać jasne okno. Z innego kąta pokazuje ciemną teksturę deski podłogowej. To właśnie nadaje finalnemu wirtualnemu spacerowi fotorealistyczne, zależne od widoku oświetlenie. Początkowy point cloud jest chaotyczny, więc system wchodzi w pętlę optymalizacji. Rzutuje, czyli splatuje, te 3D Gaussiany na widok kamery 2D, żeby wyrenderować obraz. Odejmuje ten wyrenderowany obraz od rzeczywistego zdjęcia zrobionego przez agenta nieruchomości, żeby obliczyć błąd. Następnie algorytm używa tego błędu do zaktualizowania parametrów Gaussianów. Podczas tej optymalizacji system aktywnie zarządza populacją Gaussianów. Jeśli blob staje się zbyt duży i pokrywa zbyt wiele detali, algorytm dzieli go na mniejsze kawałki. Jeśli obszar o złożonych teksturach potrzebuje większej rozdzielczości, algorytm klonuje istniejące Gaussiany, żeby zwiększyć gęstość. Jeśli blob staje się całkowicie przezroczysty albo nieistotny, system go usuwa. Ponieważ finalna scena składa się w całości z explicit data points, jej renderowanie jest wyjątkowo szybkie. Sprzęt graficzny po prostu sortuje elipsoidy od tyłu do przodu i blenduje ich kolory, tworząc finalny obraz. Przełom w 3D Gaussian Splatting polega na udowodnieniu, że chaotyczna chmura explicit matematycznych blobów potrafi uchwycić złożone światło i geometrię znacznie szybciej niż gęsta neural network. Dzięki za wysłuchanie. Trzymajcie się wszyscy.

Cześć, tu Alex z DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, odcinek 20 z 20. Przez dekady algorytmy computer vision były całkowicie pasywne. Mogły narysować bounding box wokół kubka na stole, ale na tym się kończyło. Dzisiaj system nie tylko widzi kubek — wykorzystuje te dane wizualne, aby po niego sięgnąć i go chwycić. Mostem między widzeniem a działaniem jest pętla Vision-Action, napędzana przez Agentic AI. Zanim przejdziemy do mechaniki, musimy wyraźnie rozgraniczyć dwie technologie, które brzmią podobnie, ale wykonują zupełnie różne zadania. Standardowy Vision-Language Model, czyli VLM, ma charakter opisowy. Wrzucasz mu screenshot, a on zwraca tekst, który mówi ci, co jest na ekranie. Z kolei Vision-Language-Action model, czyli VLA, ma charakter wykonawczy. Podajesz VLA screenshot i cel, a on generuje wykonywalne komendy. Nie tylko opisuje interfejs użytkownika, ale aktywnie wchodzi z nim w interakcję. Agentic AI przekształca vision pipeline w narząd zmysłów dla silnika decyzyjnego. Działa to w ciągłym cyklu postrzegania, wnioskowania i działania. Najpierw system pobiera wizualną obserwację swojego obecnego otoczenia. Może to być feed z kamery robota albo zrzut pulpitu komputera w czasie rzeczywistym. Następnie agent przetwarza ten stan wizualny wraz z konkretnym promptem lub celem. Analizuje relacje przestrzenne, odczytuje tekst i identyfikuje interaktywne elementy. Kiedy model zidentyfikuje element, mapuje semantyczne zrozumienie – wiedząc, że konkretny zielony prostokąt to przycisk submit – na geometryczną przestrzeń współrzędnych. Na koniec, zamiast zwracać opis, model generuje action payload. Często jest to ustrukturyzowana komenda zawierająca dokładne współrzędne ekranu, regulację silnika sprzętowego lub API call. Po wykonaniu akcji środowisko ulega zmianie. Agent pobiera nową wizualną obserwację, sprawdza, czy poprzednia akcja się powiodła, i oblicza kolejny krok. Oto kluczowy wniosek. Dane wizualne nie są już ślepą uliczką; stanowią grounding mechanism dla autonomicznego korzystania z narzędzi. Przeanalizujmy konkretny scenariusz zautomatyzowanego cyfrowego asystenta księgowego. Celem jest autoryzacja płatności. Agent zaczyna od przechwycenia ekranu. Vision model przetwarza zeskanowaną fakturę PDF, wyciągając nazwę dostawcy i całkowitą kwotę. Reasoning engine wie, że musi zalogować te dane. Generuje akcję najechania myszką na ikonę oprogramowania księgowego na pasku zadań i kliknięcia jej. Ekran się aktualizuje. Agent pobiera kolejną wizualną obserwację, aby zweryfikować, czy aplikacja jest otwarta. Skanuje nowy interfejs, lokalizuje pole autoryzacji płatności, mapuje wizualną lokalizację na współrzędne ekranu, wpisuje kwotę i klika przycisk submit. Vision pipeline stale przekazuje aktualizacje stanu z powrotem do agenta, dzięki czemu wie on dokładnie, kiedy wykonać kolejną akcję, a co ważniejsze, kiedy się zatrzymać. Computer vision ewoluowało z samodzielnego narzędzia analitycznego w warstwę sensoryczną dla systemów autonomicznych. Jeśli twój pipeline tylko analizuje obraz i się zatrzymuje, wykorzystujesz zaledwie połowę tej technologii. Ponieważ to nasz ostatni odcinek, zachęcam cię do zapoznania się z oficjalną dokumentacją modeli VLA, spróbowania samodzielnego zbudowania prostego feedback loopa, lub odwiedzenia devstories dot eu, aby zasugerować tematy do naszej kolejnej serii. To wszystko w tym odcinku. Dzięki za wysłuchanie i keep building!