Nowoczesne biblioteki do przetwarzania obrazu w kontroli jakości produkcji

Rzeczywiste wymagania kontroli jakości w produkcji a wybór bibliotek

Jak wygląda typowy proces kontroli jakości na hali produkcyjnej

System wizyjny w kontroli jakości produkcji nie pracuje w sterylnym laboratorium, tylko kilka metrów od taśmy, prasy czy wtryskarki. Kamera musi „nadążyć” za tempem linii, algorytm podjąć decyzję w ułamku sekundy, a sterowanie odrzutnikiem lub sygnalizacją błędu musi działać powtarzalnie. Dlatego dobór bibliotek do przetwarzania obrazu trzeba zaczynać od zrozumienia, jak fizycznie wygląda proces inspekcji.

Najprostszy scenariusz to punkt kontrolny: element pojawia się w polu widzenia kamery, następuje trigger (np. z czujnika indukcyjnego), kamera wykonuje zdjęcie, algorytm ocenia wynik, sterownik PLC podejmuje decyzję (OK/NOK, zatrzymanie, odrzut, sygnał alarmowy). Cały proces ma zwykle 50–300 ms, rzadziej więcej. W tym czasie trzeba nie tylko przetworzyć obraz, ale też przesłać go, zdekodować i wykonać wszystkie niezbędne kroki w kodzie.

W bardziej złożonych liniach oprócz decyzji binarnej dochodzą dodatkowe funkcje: pomiar wymiarów, odczyt kodu 2D, zapis zdjęć NOK do archiwum, statystyki jakości (PPM, trendy defektów), a często także komunikacja z systemem MES lub ERP. Tym samym biblioteka przetwarzania obrazu jest tylko jednym z klocków; równie ważne jest to, jak łatwo można ją zintegrować z resztą infrastruktury.

W praktyce kontrola jakości rzadko jest jednorodna. Jedna linia może mieć prosty punkt sprawdzania obecności nakrętki i równocześnie złożony system wizyjny 3D do pomiaru profilu. Dobór bibliotek musi obejmować najsłabsze ogniwo: jeśli jedna krytyczna stacja wymaga bardzo zaawansowanych narzędzi kalibracji 3D, cały stos technologiczny powinien to uwzględniać.

Co system wizyjny naprawdę musi umieć, a co jest dodatkiem

Marketing producentów oprogramowania wizyjnego skupia się na hasłach typu „AI ready”, „deep learning inside”, „no-code inspection”. Tymczasem podstawowe wymagania na hali są dużo bardziej przyziemne. System wizyjny musi przede wszystkim:

• działać stabilnie 24/7 bez zawieszania się i „przecieków” pamięci,
• utrzymywać stały czas cyklu, przewidywalny w każdych warunkach,
• radzić sobie z typowymi zmianami w oświetleniu i położeniu detali,
• udostępniać wyniki w prosty sposób dla PLC i systemów nadrzędnych,
• pozwalać na łatwą korektę progów i parametrów przez technologa, bez rekompilacji kodu.

Funkcje „miłe, ale niekonieczne” to np. wbudowane uczenie aktywne, piękne dashboardy webowe, automatyczna dokumentacja, setki egzotycznych filtrów, których nikt nie użyje. W projekcie pilotażowym wszystko może wyglądać imponująco, lecz utrzymanie nadmiernie skomplikowanego systemu przez lata często wymyka się spod kontroli.

Rozsądny filtr oceny bibliotek jest prosty: jeśli dana funkcja nie wspiera wprost kluczowego wskaźnika (redukcja błędów, skrócenie cyklu, większa powtarzalność, łatwiejsza zmiana asortymentu), to jest kosmetyką. W systemach przemysłowych kosmetyka zwykle przegrywa z niezawodnością, zwłaszcza po pierwszych kilku awariach w nocy, gdy dyspozytor nie ma pod ręką programisty.

Zakres zadań wizyjnych: od detekcji defektów po weryfikację kompletności

Biblioteki do przetwarzania obrazu w kontroli jakości powinny być dobierane pod konkretne typy zadań, a nie pod modne technologie. Typowy zakres obejmuje cztery główne klasy problemów:

• Detekcja defektów powierzchni – rysy, wtrącenia, przebarwienia, pęknięcia. Może być realizowana klasyczną filtracją i progowaniem lub metodami deep learning (segmentacja, anomaly detection).
• Pomiary wymiarowe – sprawdzenie długości, szerokości, kątów, promieni, położeń otworów. Tu liczy się precyzyjna kalibracja kamery, dobre narzędzia detekcji krawędzi i geometria.
• Identyfikacja i śledzenie – odczyt kodów 1D/2D, OCR na etykietach, rozpoznawanie typu detalu, przypisywanie numeru seryjnego do obrazu.
• Weryfikacja kompletności – sprawdzenie, czy wszystkie elementy są obecne (np. śruby, naklejki, plomby, korki), poprawnie ułożone i nieuszkodzone.

Większość projektów nie wychodzi poza ten zestaw. Jeżeli biblioteka dobrze rozwiązuje te cztery obszary, często okazuje się wystarczająca na lata. Gdy dostawca skupia się na „spektakularnych” przykładach – np. rozpoznawanie twarzy, autonomiczne roboty – a w dokumentacji brakuje porządnych narzędzi do prostej metrologii czy kodów kreskowych, jest to sygnał ostrzegawczy dla zastosowań przemysłowych.

Prototyp na laptopie a system pracujący 24/7 na linii

Różnica między POC uruchomionym w Pythonie na laptopie a systemem wizyjnym działającym 24/7 jest większa, niż zwykle się zakłada. Na etapie prototypu wystarczy, że skrypt zadziała na kilkudziesięciu przykładach. W prawdziwym systemie potrzebne są:

• mechanizmy watchdog i restartu komponentów,
• logowanie wszystkich błędów i podejrzanych sytuacji (np. brak obrazu z kamery, zbyt długi czas przetwarzania),
• monitoring czasu cyklu i zasobów (CPU, pamięć, użycie GPU),
• backup i wersjonowanie konfiguracji, modeli i parametrów progowych,
• procedury aktualizacji bez zatrzymywania linii lub z minimalnym postojem.

Biblioteki przetwarzania obrazu zwykle nie rozwiązują tego za nas. OpenCV czy PyTorch dostarczają funkcje obliczeniowe, ale nie narzędzia eksploatacyjne. Komercyjne frameworki wizyjne czasem dodają warstwę środowiska wykonawczego (runtime z narzędziami diagnostycznymi), lecz i tu nie wszystko jest gotowe „z pudełka”.

Jeżeli projekt ma przejść z fazy R&D do produkcji, w ocenie bibliotek trzeba uwzględnić nie tylko ich możliwości algorytmiczne, ale też to, na ile dają się włączyć w ekosystem: system operacyjny, sterowniki kamer, biblioteki do komunikacji z PLC, narzędzia do konteneryzacji (Docker), CI/CD dla modeli i aplikacji wizyjnych.

Środowisko przemysłowe: wibracje, brud, oświetlenie i tempo taśmy

Algorytm, który na próbkach z idealnie ustawioną kamerą działa znakomicie, może radykalnie stracić skuteczność po przeniesieniu na halę. Źródła problemów są zwykle prozaiczne:

• mikrowibracje konstrukcji powodujące rozmycie obrazu,
• zmiany temperatury wpływające na ostrość i położenie ogniska,
• pył, tłuszcz lub wilgoć na optyce,
• zmienny poziom oświetlenia (otwarte drzwi, inne operacje na sąsiednich stanowiskach),
• losowe położenie detali na taśmie, odbicia światła od metalicznych powierzchni.

W takich warunkach biblioteka musi oferować solidne narzędzia do:

• normalizacji jasności i kontrastu,
• kompensacji przesunięć (rejestracja obrazów, wyszukiwanie wzorca),
• filtrowania szumu i artefaktów,
• robustnej segmentacji przy zmiennych warunkach.

Część tych problemów rozwiązuje się sprzętowo (odpowiednie uchwyty, optyka, oświetlacze), lecz z reguły nie uda się wyeliminować wszystkiego. Dlatego wybierając bibliotekę, trzeba patrzeć nie tylko na to, jak radzi sobie z „ładnymi” obrazami, lecz jakie ma narzędzia na wypadek pogorszenia ich jakości. W systemie przemysłowym jakość obrazu „idealna” jest wyjątkiem, a nie normą.

Kryteria biznesowe i kiedy wystarczy prosty system kamerowy

Nie każde zadanie na linii wymaga zaawansowanych bibliotek do przetwarzania obrazu. Jeżeli celem jest jedynie obecność/nieobecność elementu o wysokim kontraście (np. czy jest korek w butelce z przeźroczystym tłem), czasem tańszym i stabilniejszym rozwiązaniem będzie czujnik wizyjny z gotowym zestawem funkcji: prostym interfejsem, jednym wyjściem binarnym i ograniczoną, ale przewidywalną konfiguracją.

Zaawansowane biblioteki sensownie wykorzystuje się, gdy:

• koszt pojedynczego błędu (fałszywie dobry lub fałszywie zły produkt) jest wysoki,
• inspekcja wymaga złożonej logiki: wiele cech, wiele wariantów produktu, korelacja wielu obrazów,
• ważna jest skalowalność – docelowo dziesiątki stanowisk, integracja z MES, raportowanie jakości,
• system ma być rozwijany przez lata (dodawanie nowych typów defektów, modeli DL, funkcji metrologicznych).

Z kolei przy niskim tempie linii i prostych przypadkach nadużyciem jest wdrażanie pełnego stosu „OpenCV + PyTorch + MLOps + orkiestracja kontenerów”. Im więcej warstw, tym większa podatność na awarie, a zespół utrzymania musi mieć odpowiednie kompetencje. Czasem rozsądna decyzja to ograniczenie się do stabilnego, choć mniej elastycznego systemu z gotowego kontrolera wizyjnego.

Klasyczne biblioteki do przetwarzania obrazu – fundamenty, których nie warto pomijać

OpenCV – fakty, mity i typowe nadużycia

OpenCV jest de facto standardem w wielu zastosowaniach wizyjnych. Udostępnia ogromny zestaw algorytmów: od prostych operacji na pikselach, przez morfologię, po złożoną geometrię i kalibrację. Jednak sam fakt, że „da się coś zrobić w OpenCV”, nie oznacza automatycznie, że jest to najlepsze rozwiązanie dla produkcji.

Najczęstsze mity wokół OpenCV w kontekście przemysłowym:

• „OpenCV to gotowy system wizyjny” – w rzeczywistości to biblioteka algorytmów. Brakuje GUI, narzędzi do zarządzania konfiguracją, komunikacji z PLC. Te elementy trzeba dopisać lub zintegrować samodzielnie.
• „OpenCV jest za wolne” – większość funkcji jest mocno zoptymalizowana w C++ i wykorzystuje instrukcje SSE/AVX, a także biblioteki matematyczne. Często wąskim gardłem jest nie biblioteka, lecz błędna architektura aplikacji lub nieefektywne kopiowanie danych.
• „OpenCV rozwiąże każdy problem” – są klasy zadań (np. subtelna detekcja defektów tekstury), gdzie klasyczna CV jest niewystarczająca i lepiej sięgnąć po deep learning.

OpenCV sprawdza się tam, gdzie potrzebna jest dobra kontrola nad pipeline’em przetwarzania i gdzie zespół ma kompetencje programistyczne. W połączeniu z C++ pozwala zbudować bardzo szybkie aplikacje. W wariancie Pythonowym jest świetne do prototypowania, ale w aplikacjach 24/7 częściej wybiera się C++ lub mieszaną architekturę (krytyczny fragment w C++, orkiestracja w Pythonie lub innym języku wysokiego poziomu).

Inne otwarte biblioteki: scikit-image, Pillow, SimpleCV

Poza OpenCV istnieje szereg bibliotek, które mogą uzupełnić stos lub posłużyć do mniej krytycznych fragmentów systemu:

• scikit-image – biblioteka Pythonowa oparta na NumPy/SciPy, oferująca szeroki zestaw algorytmów do segmentacji, filtracji, operacji morfologicznych. Bardzo wygodna do eksperymentów i prototypów, lecz trudniej z niej zbudować wydajny system w C++.
• Pillow – następca PIL, typowo używana do prostych operacji na obrazach (wczytywanie, zapis, zmiana rozdzielczości, konwersje formatów). W systemach przemysłowych bywa przydatna głównie w warstwie pomocniczej, nie jako „silnik” inspekcji.
• SimpleCV – framework abstrakcyjny nad OpenCV i innymi bibliotekami. Ułatwia szybkie prototypowanie, ale w poważnych projektach często ogranicza elastyczność i trudniej kontrolować wydajność.

W zastosowaniach przemysłowych dominującą rolę odgrywa jednak nadal OpenCV – głównie dzięki dojrzałości, wsparciu dla C++ i integracji z wieloma innymi ekosystemami (np. GStreamer, ROS). Inne biblioteki dobrze nadają się do analiz offline, przygotowania danych, narzędzi diagnostycznych czy aplikacji webowych do przeglądania zdjęć NOK.

Co klasyczne biblioteki robią dobrze: filtracja, segmentacja, geometria

Nowoczesne modele głębokiego uczenia przyciągają uwagę, ale w wielu zadaniach klasyczne algorytmy CV są niezastąpione lub przynajmniej stanowią solidną pierwszą warstwę pipeline’u. Do zadań, w których biblioteki takie jak OpenCV są bardzo skuteczne, należą:

• Filtracja i redukcja szumu – mediany, filtry Gaussa, bilateralne, a także zaawansowane metody odszumiania. Pomagają ustabilizować obraz, zanim trafi do detektora krawędzi czy segmentatora.
• Segmentacja – progowanie globalne i adaptacyjne, metody Otsu, Watershed, detekcja regionów o określonych cechach (jasność, kolor, tekstura).

Metrologia, kalibracja i precyzyjna geometria

Przy kontroli jakości bardzo często nie chodzi o samą detekcję defektu, ale o dokładny pomiar: średnicy otworu, odległości między krawędziami, kąta pochylenia, bicia promieniowego. Klasyczne biblioteki radzą sobie tu zwykle lepiej niż „gołe” modele deep learning, pod warunkiem poprawnej kalibracji i geometrii.

Minimalny zestaw funkcji, którego wypada oczekiwać od biblioteki metrologicznej:

• kalibracja kamery (parametry wewnętrzne, zniekształcenia soczewki),
• transformacje perspektywiczne i odwzorowanie piksel–świat (mm, µm),
• detektory krawędzi subpikselowych,
• dopasowanie prymitywów geometrycznych (prosta, okrąg, łuk, elipsa) metodami odpornymi na outliery,
• funkcje do tworzenia profili intensywności, pomiarów szerokości szczelin, grubości warstw powłoki.

W praktyce metrologia pada ofiarą dwóch uproszczeń. Pierwsze: „jak policzę piksele, to przeskaluję na milimetry i będzie dobrze” – bez kalibracji i kompensacji zniekształceń błąd rośnie ku krawędziom pola widzenia. Drugie: „wystarczy zwykły Canny i Hough” – dla części zadań to działa, ale tam, gdzie tolerancje są rzędu dziesiątych części piksela, potrzebne są dokładniejsze metody, zwykle dostępne już tylko w wyspecjalizowanych bibliotekach lub komercyjnych frameworkach.

Wyszukiwanie wzorców i dopasowanie kształtu

W systemach wizyjnych stabilne odnajdywanie położenia detalu jest kluczowe dla wszystkich dalszych kroków. Klasyczne biblioteki oferują kilka podejść, od banalnej korelacji szablonu, po odporne na skalę i obrót metody feature-based.

Przy wyborze implementacji wyszukiwania wzorca dobrze sprawdza się chłodne podejście:

• korelacja szablonu (template matching) – szybka i prosta, ale mało odporna na zmiany oświetlenia i deformacje; bywa wystarczająca przy dobrze ustabilizowanej optyce i oświetleniu,
• metryki podobieństwa z normalizacją jasności – rozsądny kompromis tam, gdzie oświetlenie „pływa”, ale geometria pozostaje stała,
• opis cech (SIFT, SURF, ORB, BRISK i ich warianty) – bardziej złożone, dają większą odporność na obrót, skalę, częściowe zasłonięcia; koszt to wyższe zużycie czasu CPU i konieczność sensownej parametryzacji.

Zdarza się, że zespół próbuje „uleczyć” niestabilne wyszukiwanie wzorca w OpenCV, zamiast przyjrzeć się przyczynom: ruch elementów poza dozwolonym obszarem, zbyt małe pole widzenia, brak mechanicznego pozycjonowania. Biblioteka nie uratuje sytuacji, w której obraz wejściowy jest kompletnie niespójny z założeniami algorytmu – w takich przypadkach zwykle wygrywa kombinacja drobnej modyfikacji hardware’u i prostszego algorytmu, a nie coraz bardziej wyszukane metody dopasowania.

Komercyjne frameworki wizyjne – kiedy mają sens

Co tak naprawdę kupuje się w licencji Halcon, Cognex, Matrox, NI Vision

Popularne platformy komercyjne są często postrzegane jako „droższe OpenCV z graficznym interfejsem”. W praktyce płaci się za coś innego:

• rozbudowane środowisko projektowe (edytor przepływu, podgląd na żywo, narzędzia do strojenia progów),
• gotowe, dobrze przetestowane narzędzia metrologiczne i do wyszukiwania wzorców,
• integrację ze sprzętem (kamery przemysłowe, frame grabbery, oświetlacze, I/O),
• mechanizmy deploymentu i licencjonowania (runtime na liniach, serwery kluczy),
• wsparcie techniczne i aktualizacje (w tym łatki bezpieczeństwa i nowe sterowniki).

Dla producenta, który ma kilka linii i ograniczony dział utrzymania, zakup gotowego frameworka bywa tańszy w horyzoncie kilku lat niż budowa całego stosu od zera. Zwłaszcza jeśli w firmie nie ma zespołu programistów C++ z doświadczeniem w systemach czasu zbliżonego do rzeczywistego.

Typowe przypadki, w których komercyjny framework się opłaca

Nie każdy projekt uzasadnia inwestycję w licencje. Są jednak scenariusze, gdzie bilans zwykle wychodzi na korzyść płatnych narzędzi:

• złożona metrologia 2D/3D z wysokimi wymaganiami dokładności,
• wiele typów produktu na tej samej stacji z często zmieniającymi się recepturami,
• brak wewnętrznych kompetencji programistycznych – konfiguracją ma się zająć inżynier procesu, nie zespół dev,
• wymóg szybkiego uruchomienia (np. kilka miesięcy) i ograniczona możliwość „dokręcania śrub” w kodzie.

Przykładowo, linia montażu elektroniki z wieloma wariantami płytek i krótkimi seriami częściej kończy z Cognexem lub Halconem, ponieważ narzędzia do dopasowania obwiedni elementów, czytania kodów i weryfikacji obecności są gotowe i łatwo parametryzowalne. Tworzenie tego samego zestawu na OpenCV wymagałoby odrębnego projektu softwarowego, testów, dokumentacji – i zwykle kilku iteracji poprawek po uruchomieniu.

Gdzie komercyjny framework jest przerostem formy nad treścią

Ten sam pakiet narzędzi, który ratuje projekt złożonej linii, może być nadmiarem przy prostych zadaniach. Typowe sytuacje, gdy zakup licencji nie ma większego sensu:

• pojedyncze, powtarzalne zadanie oparte na prostym progowaniu lub detekcji konturu,
• brak planów skalowania – jedna stacja, jedna kamera, jeden produkt,
• silny dział IT/OT i gotowa infrastruktura, w której łatwo utrzymywać autorskie aplikacje.

Program „do wszystkiego” kusi rozbudowanymi funkcjami, ale w małych zastosowaniach generuje koszty utrzymania: aktualizacje, kompatybilność licencji na nowe maszyny, szkolenia dla personelu. Dla prostych zadań rozsądniejszy jest czujnik wizyjny albo cienka aplikacja na OpenCV z minimalną liczbą zależności.

Pułapki „drag and drop”: kiedy blokowy edytor przestaje wystarczać

Środowiska typu drag-and-drop z gotowymi blokami są wygodne, ale w pewnym momencie stają się ograniczeniem. Problemy zaczynają się, gdy:

• logika inspekcji wymaga złożonych warunków, pętli, zarządzania stanem,
• ten sam pipeline trzeba odtworzyć w wielu odmianach z drobnymi różnicami,
• potrzebna jest integracja z niestandardowym systemem (własne protokoły, REST API, chmura).

Komercyjne frameworki zwykle umożliwiają dopisywanie własnych modułów (np. w C++ lub .NET). To jednak oznacza powrót do typowych problemów developerskich: wersjonowanie, testy jednostkowe, dystrybucja bibliotek, debugowanie na obiekcie. Jeżeli projekt ma „urośnąć” w taki sposób, lepiej z wyprzedzeniem założyć, że część logiki będzie w normalnym kodzie, a środowisko blokowe potraktować jako interfejs konfiguracyjny dla użytkownika końcowego.

Biblioteki głębokiego uczenia dla wizji i ich miejsce w kontroli jakości

PyTorch, TensorFlow, ONNX – różnice praktyczne, nie marketingowe

W zastosowaniach przemysłowych ważniejsze od sporów „PyTorch vs TensorFlow” są kwestie rzeczowe: wsparcie sprzętowe, stabilność API, dostęp do narzędzi inference i integracja z istniejącym stosem.

• PyTorch – elastyczny i popularny w R&D; świetny do szybkiego eksperymentowania z modelami, transfer learningu, prototypów. Do produkcji zwykle używa się TorchScript, ONNX lub rozwiązań typu Triton Inference Server.
• TensorFlow / Keras – lepsze wsparcie dla niektórych scenariuszy produkcyjnych, zwłaszcza w ekosystemie Google; jednak w ostatnich latach część zespołów odchodzi od „czystego” TF na rzecz ONNX Runtime lub bezpośrednich bibliotek dostawców sprzętu.
• ONNX + ONNX Runtime – format wymiany modeli; kluczowy, gdy R&D używa różnych frameworków, a na linii potrzebne jest neutralne środowisko inference (CPU, GPU, czasem FPGA/ASIC).

W projektach, gdzie model ma być wdrożony na wielu platformach (PC przemysłowe, edge z Jetsonem, serwer GPU w serwerowni), stabilny pipeline eksportu do ONNX i uruchamiania w ONNX Runtime czy TensorRT bywa ważniejszy niż to, czy model trenowano w PyTorch, czy w TensorFlow.

Typowe zadania DL w kontroli jakości

Głębokie uczenie w systemach wizyjnych rozwiązuje nieco inne problemy niż klasyczne biblioteki. Używa się go tam, gdzie reguły są trudne do zapisania ręcznie lub obraz jest zbyt „bogaty”, aby progi i filtry wystarczyły.

Najczęstsze scenariusze:

• detekcja defektów powierzchni (rysy, wtrącenia, przebarwienia, pęknięcia) na tworzywach, metalach, szkle,
• klasyfikacja produktu – wariant, typ, obecność nadruków, mieszanie detali z różnych partii,
• segmentacja semantyczna/instancyjna – oddzielenie tła od produktu, wydzielenie obszarów uszkodzonych, wykrywanie elementów w złożonych scenach,
• anomaly detection – gdy defektów jest mało lub są bardzo zróżnicowane, a łatwiej zebrać przykłady dobrych produktów.

Modele DL dobrze radzą sobie z subtelnymi zmianami tekstury czy niejednoznacznymi uszkodzeniami, ale wymagają dobrze przygotowanych danych. Jeżeli baza zdjęć jest niespójna (różne oświetlenie, inne kadrowanie, brak etykietowania), każda biblioteka – niezależnie od tego, jak nowoczesna – będzie generować losowe zachowania na granicy tolerancji.

Inference na krawędzi vs w serwerowni

Przy wdrażaniu modeli DL w przemyśle kluczowa jest decyzja, gdzie uruchamia się inferencję. Istnieją dwa podstawowe scenariusze:

• edge (PC przemysłowe, Jetson, embedded GPU) – krótka ścieżka sygnału do PLC, brak zależności od sieci; ograniczenia to moc obliczeniowa, chłodzenie, miejsce w szafie sterowniczej,
• serwerownia / chmura prywatna – wygodniejszy dostęp do zasobów GPU, centralne zarządzanie aktualizacjami; problemem są opóźnienia, przepustowość sieci i wymagania deterministyczności czasów odpowiedzi.

W praktyce systemy kontroli jakości z krótkim taktem taśmy (setki ms) zwykle kończą na inferencji edge, z ewentualną repliką modelu w serwerowni do zadań analitycznych i re-treningu. Biblioteki takie jak TensorRT, OpenVINO czy własne runtime’y dostawców kamer inteligentnych umożliwiają istotne przyspieszenie modeli, ale kosztem dodatkowej złożoności procesu deploymentu (konwersje, profile kalibracji, osobne pipeline’y CI/CD).

Szkolenie modeli vs utrzymanie na linii – dwa różne światy

R&D często skupia się na „dociśnięciu” kilku punktów procentowych dokładności, natomiast utrzymanie produkcji boleśnie odczuwa każdy niestabilny deployment. Dlatego w ocenie bibliotek do DL trzeba oddzielić dwa aspekty:

• narzędzia do trenowania – augmentacje, biblioteki datasetów, optymalizatory, wizualizacja metryk,
• narzędzia do wdrażania i monitoringu – stabilny runtime, obsługa błędów, możliwość rollbacku wersji modelu, logowanie próbek NOK do dalszej analizy.

Sam PyTorch czy TensorFlow nie dostarczają mechanizmów MLOps. Trzeba je budować z klocków: system kontroli wersji modeli (np. MLflow, DVC), rejestry artefaktów, orchestrację kontenerów (Kubernetes, Nomad, czasem prostsze rozwiązania oparte na usługach systemowych). W środowisku przemysłowym z ograniczonym wsparciem IT takie rozwiązania mogą okazać się przesadnie ciężkie; wtedy lepszym kompromisem bywa prosty, własny system wersjonowania modeli w plikach i jasno opisana procedura aktualizacji.

AutoML i „no-code DL”: gdzie kończy się magia

Na rynku pojawiło się wiele narzędzi obiecujących automatyczny dobór architektury, hiperparametrów i augmentacji, często z interfejsem webowym lub integracją z komercyjnymi frameworkami wizyjnymi. W kontekście przemysłowym te rozwiązania bywają użyteczne, ale trzeba mieć świadomość ich granic:

• działają dobrze dla standardowych zadań (klasyfikacja, segmentacja defektów),
• słabo radzą sobie z niestandardową metryką jakości lub nietypowym zbiorem danych,
• utrudniają późniejszą modyfikację modelu poza dostarczonym ekosystemem (problem „vendor lock-in”).

Jeżeli projekt ma żyć kilka lat, a firma chce budować własne kompetencje w DL, sensowniejsze jest użycie AutoML jako narzędzia pomocniczego do wstępnej eksploracji architektur, a nie jako „czarnej skrzynki”, której nikt w zespole nie rozumie. W przeciwnym razie korekta modelu przy nowych typach defektów kończy się zamówieniem kolejnego projektu u dostawcy narzędzia, zamiast modyfikacją w istniejącym pipeline’ie.

Optymalizacja modeli pod produkcję: prędkość, deterministyczność, serwis

Model, który działa świetnie w laboratorium, potrafi kompletnie się „rozsypać” po przeniesieniu na linię. Problemem rzadko bywa sama architektura sieci – częściej cała otoczka: sposób ładowania modelu, kolejki żądań, obróbka wstępna obrazu, priorytety w systemie operacyjnym.

Przed wyborem biblioteki lub runtime’u DL trzeba ustalić realne wymagania:

• czas odpowiedzi – nie tylko średni, ale i maksymalny w warunkach obciążenia (przypadkowe lagi co kilkadziesiąt obrazów są trudniejsze do zaakceptowania niż stabilnie wyższy czas inference),
• deterministyczność – czy można zaakceptować okazjonalne spowolnienia z powodu alokacji pamięci, JIT kompilacji, zbierania śmieci,
• tryb pracy – pojedyncze zapytania synchronicznie wyzwalane z PLC vs przetwarzanie strumieniowe wielu kamer równolegle.

To determinuje wybór narzędzi: lekkie runtime’y (ONNX Runtime, TensorRT, NCNN) były projektowane z myślą o małych opóźnieniach i niskim narzucie, podczas gdy „pełne” frameworki (PyTorch, TensorFlow) nadają się raczej do backendów serwerowych lub etapów przygotowawczych. Uproszczenie architektury modelu z 5% spadkiem dokładności, ale dwukrotnym przyspieszeniem inference bywa w przemyśle znacznie korzystniejsze niż walka o „rekord” na benchmarku.

Przenoszenie pipeline’u z klasycznego CV na DL i odwrotnie

Częstym błędem jest traktowanie głębokiego uczenia jako całkowitego zastępstwa dla klasycznych bibliotek – albo odwrotnie, kurczowe trzymanie się filtrów i progowania tam, gdzie model DL rozwiązałby problem z mniejszą liczbą wyjątków. Zrównoważone podejście zwykle oznacza hybrydę.

Typowy, sensowny schemat:

• CLassic CV (OpenCV / HALCON / Cognex) zajmuje się przygotowaniem sceny – stabilizacją, korekcją perspektywy, wyrównaniem oświetlenia, znalezieniem regionów zainteresowania,
• model DL obsługuje trudny fragment decyzyjny – np. ocenę jakości powierzchni w konkretnym wycinku obrazu.

Odwrotna sytuacja – gdy istniejący system DL zaczyna być „rozdmuchany” – też się zdarza. Jeżeli kilka prostych reguł geometrycznych pozwala odfiltrować oczywiste przypadki NOK/OK, nie ma sensu przepuszczać wszystkiego przez sieć; klasyczne operacje morfologiczne lub Hougha potrafią odciążyć GPU bardziej niż wymiana modelu na „lżejszy”.

Diagnostyka jakości modeli na produkcji: logi, próbki graniczne, dryf danych

Bez sensownego logowania i archiwizacji próbek granicznych nawet najlepsze biblioteki deep learningowe stają się czarną skrzynką. Problem z jakością rzadko ujawnia się spektakularnie; częściej pojawia się powolny dryf – coraz więcej „dziwnych” odrzuceń albo przepuszczonych defektów.

Praktyczne nawyki, które znacząco ułatwiają życie:

• logowanie metryk modelu w czasie (udział NOK, liczba przypadków manualnego nadpisania decyzji, zmiany w rozkładzie pewności predykcji),
• archiwizowanie próbek spornych – wszystkie przypadki, gdzie model jest „blisko progu” lub gdzie operator skorygował decyzję,
• oznaczanie w metadanych wersji modelu i parametrów preprocessing’u – bez tego analiza regresji jakości po aktualizacji staje się zgadywanką.

Wielu producentów zaczyna od prostego logu CSV i katalogu „anomalie” na dysku sieciowym. To nie jest eleganckie, ale w praktyce znacznie lepsze niż brak jakiejkolwiek historii. Rozbudowane platformy MLOps mają sens dopiero wtedy, gdy liczba modeli i linii produkcyjnych przekracza możliwości ręcznego ogarnięcia wersji.

Specjalistyczne biblioteki i narzędzia dla systemów wizyjnych w przemyśle

Biblioteki do obsługi kamer, framegrabberów i standardów wizyjnych

Nowoczesny system wizyjny rzadko komunikuje się z kamerą „wprost” przez prosty sterownik. Standardy typu GigE Vision, USB3 Vision czy Camera Link mają swoje wymagania, a producenci sprzętu oferują dedykowane SDK. Ich jakość bywa skrajnie różna – od dopracowanych, wieloplatformowych bibliotek po pęki nagłówków i przykładów sprzed dekady.

Na tym poziomie sens mają głównie trzy podejścia:

• korzystanie z oficjalnych SDK producenta kamery/framegrabbera (Basler pylon, Allied Vision Vimba, Teledyne DALSA Sapera itp.) – zwykle najlepsze wsparcie dla specyficznych funkcji, ale mocniejsze powiązanie z jednym dostawcą,
• używanie neutralnych bibliotek opartych na GenICam/GenTL (np. Aravis w świecie Linux) – większa szansa migracji między kamerami, ale czasem ograniczony dostęp do nietypowych funkcji (specjalne tryby wyzwalania, niestandardowe buforowanie),
• pełna integracja przez framework wizyjny (HALCON, Cognex VisionPro), który chowa detale komunikacji, ale zamyka projekt w konkretnym ekosystemie.

Przy większych instalacjach dobrze jest od początku oddzielić logikę komunikacji z kamerami od logiki inspekcji. Nawet jeśli korzysta się z SDK producenta, nie ma sensu „wplatać” go bezpośrednio w algorytmy. Osobna warstwa abstrakcji na poziomie aplikacji pozwala w razie potrzeby wymienić kamerę lub framegrabbera bez przepisywania całego pipeline’u.

Biblioteki do kalibracji, metrologii i robotyki

Kontrola jakości coraz częściej łączy się z pomiarem 3D, robotami współpracującymi lub systemami śledzenia pozycji. Tutaj klasyczne OpenCV często bywa punktem startowym, ale w zastosowaniach produkcyjnych potrzebne są narzędzia gwarantujące powtarzalność i lepszą kontrolę nad błędami kalibracji.

Typowe kategorie rozwiązań:

• kalibracja kamer 2D/3D – biblioteki wspierające precyzyjne modele obiektywów (w tym obiektywy telecentryczne), kalibrację kilku kamer jednocześnie, powiązanie z układem współrzędnych robota,
• metrologia wizyjna – specjalistyczne funkcje do pomiarów subpikselowych, kompensacji dystorsji, analizy niepewności pomiaru; często wbudowane w komercyjne frameworki (HALCON, Matrox Imaging Library),
• integracja z robotami – biblioteki i moduły do hand-eye calibration (kamera na ramieniu robota albo nad stanowiskiem), generowania trajektorii na podstawie wyników inspekcji, korekcji uchwytów na podstawie danych wizyjnych.

Przy metrologii najczęstszym nadużyciem jest założenie, że „jak raz się skalibruje, to będzie działać”. W praktyce każda zmiana obiektywu, skręcenie głowicy kamery czy ingerencja serwisu wymaga weryfikacji. Biblioteka powinna nie tylko oferować funkcje kalibracyjne, ale też wspierać procedury ponownej walidacji i raportowania niepewności. Bez tego wyniki pomiarów mogą formalnie spełniać tolerancje na wykresie, a realnie przegrywać z analogową suwmiarką na hali.

Biblioteki i narzędzia do wizji 3D: chmury punktów, profilometry, tomografia

Systemy 3D (skanery laserowe, kamery strukturalne, profilometry liniowe, tomografy przemysłowe) wprowadzają dodatkową warstwę komplikacji. Dane przestają być prostym obrazem 2D – pojawiają się chmury punktów, siatki trójkątów, mapy wysokości. Klasyczne biblioteki typu OpenCV mają tu ograniczone zastosowanie.

Najczęściej wykorzystywane są:

• PCL (Point Cloud Library) – otwartoźródłowa biblioteka do obróbki chmur punktów: filtracja, rejestracja, segmentacja, dopasowanie kształtów. Bardzo elastyczna, ale dość „niskopoziomowa” i wymagająca dobrej znajomości geometrii 3D.
• Open3D – nowocześniejsze API, wsparcie dla wizualizacji, integracja z Pythonem; przydatne w prototypowaniu, choć w systemach z twardymi ograniczeniami czasowymi często i tak kończy się na implementacji krytycznych fragmentów w C++.
• moduły 3D w komercyjnych frameworkach (HALCON 3D, Cognex 3D-Locate, Matrox MIL 3D) – mniej elastyczne niż czyste biblioteki, ale szybsze do wdrożenia, jeżeli zakres zadań mieści się w przewidzianych scenariuszach.

Przy wizji 3D kluczowe są kwestie wydajności I/O i pamięci. Surowa chmura punktów z liniowego profilometru generuje setki tysięcy, a czasem miliony punktów na detal. Niewłaściwie dobrana biblioteka albo brak przemyślanej redukcji danych (downsampling, ROI, filtracja wstępna) kończy się zawieszaniem aplikacji przy najmniejszym szczycie produkcyjnym.

Systemy wizyjne w środowiskach czasu rzeczywistego

Nie każdy system kontroli jakości wymaga ścisłego „real-time”, ale w niektórych branżach (farmacja, motoryzacja, linie o bardzo krótkim takcie) opóźnienia i jitter mają krytyczne znaczenie. Wtedy wybór bibliotek nie może opierać się tylko na wygodzie API.

Elementy, które często są pomijane na etapie ofertowania, a wracają w trakcie uruchomienia:

• deterministyczność alokacji pamięci – bibliotegi, które agresywnie alokują/zwalniają bufory, wprowadzają losowe skoki czasu obliczeń,
• obsługa priorytetów wątków i integracja z RTOS lub jądrami czasu rzeczywistego (np. PREEMPT_RT, QNX),
• stabilne API w długim horyzoncie – aktualizacja biblioteki, która zmienia wewnętrzny model wielowątkowości, bywa niemożliwa do przeprowadzenia bez przestojów.

Jeżeli przewidziane są wymagania „prawie real-time”, lepiej od razu zakładać buforowanie obrazów, mechanizmy degradacji (np. spadek liczby analizowanych klatek przy chwilowym przeciążeniu) i jasne granice odpowiedzialności: co dzieje się, gdy vision nie odpowie w zadanym czasie. Biblioteka nigdy nie rozwiąże za projektanta kwestii logiki awaryjnej.

Narzędzia do anotacji, zarządzania danymi i wersjonowania datasetów

Nowoczesne systemy wizyjne, zwłaszcza te z DL, są tak dobre, jak zbiory danych, na których powstają. Sam wybór biblioteki do trenowania modeli to połowa układanki; druga to praktyczne narzędzia do pracy z obrazami.

W praktyce pojawiają się trzy klasy narzędzi:

• edytory anotacji (CVAT, Label Studio, LabelMe, komercyjne rozwiązania vendorów) – oznaczanie defektów, rysowanie masek, klasyfikacja; ważna jest nie tyle ilość funkcji, co ergonomia przy dziesiątkach tysięcy zdjęć,
• systemy zarządzania danymi (DVC, MLflow, własne repozytoria plików z metadanymi) – śledzenie wersji datasetów, historii modyfikacji, powiązań z wersjami modeli,
• pipeline’y ETL dla obrazów – skrypty lub usługi, które okresowo zrzucają obrazy z linii, czyszczą je, anonimizują (jeżeli trzeba), przypisują do odpowiednich zbiorów treningowych/testowych.

Najczęstszy błąd to tworzenie datasetu „na raz”, tylko pod pierwszą wersję modelu. Gdy po roku zmienia się produkt, oświetlenie lub kamera, nagle okazuje się, że brakuje infrastruktury do ciągłego zbierania i selekcji danych. Wtedy nawet najlepsze biblioteki DL nie pomogą – model nie ma z czego nauczyć się nowych wzorców.

Monitorowanie i testowanie bibliotek w długim cyklu życia projektu

Większość projektów wizyjnych nie kończy się wraz z pierwszym uruchomieniem. System działa latami, a w tym czasie:

• pojawiają się nowe wersje bibliotek (OpenCV, HALCON, ONNX Runtime, CUDA),
• zmieniają się systemy operacyjne i sterowniki,
• producent sprzętu wycofuje stare modele kamer albo kart akwizycji.

Bez automatycznego testowania kluczowych funkcji każda aktualizacja staje się loterią. Rozsądne minimum to zestaw testów regresyjnych uruchamianych na reprezentatywnej próbce obrazów – zarówno tych uważanych za poprawne, jak i typowych defektów. Dobrze, jeżeli testy mierzą nie tylko zgodność wyniku (OK/NOK), ale także czas przetwarzania.

Nie ma jednej „złotej” strategii aktualizacji bibliotek. Niektóre firmy zamrażają wersje na lata i aktualizują całość jednorazowo przy większym remoncie linii. Inne stosują podejście iteracyjne – małe, częste aktualizacje, ale zawsze z odtwarzalnym procesem testowym. Niezależnie od wybranej drogi, brak świadomej polityki aktualizacji kończy się tym, że pierwsza poważniejsza awaria wymusza paniczne łatanie kilku poziomów zależności na raz.

Najczęściej zadawane pytania (FAQ)

Jaką bibliotekę do przetwarzania obrazu wybrać do kontroli jakości na linii produkcyjnej?

Dobór biblioteki powinien wychodzić od realnego procesu na hali: czasu cyklu, sposobu wyzwalania kamery, komunikacji z PLC oraz wymaganego typu inspekcji (defekty, pomiary, kody, kompletność). Narzędzia „efektowne” (deep learning, ładne dashboardy) są drugorzędne wobec stabilnego działania 24/7, przewidywalnego czasu przetwarzania i łatwej integracji z resztą systemu.

W praktyce zestawia się zazwyczaj 2–3 krótkie listy: wymagane funkcje wizyjne, wymagania integracyjne (system operacyjny, sterowniki kamer, PLC, MES/ERP) oraz ograniczenia czasowe. Biblioteka, która nie obsłuży choćby jednego krytycznego punktu (np. precyzyjnych pomiarów lub niezawodnego odczytu kodów 2D), będzie wąskim gardłem, nawet jeśli „reszta” wygląda atrakcyjnie marketingowo.

Kiedy wystarczy prosty czujnik wizyjny zamiast zaawansowanej biblioteki?

Prosty czujnik wizyjny zwykle wystarcza, gdy zadanie jest binarne i ma wysoki kontrast: obecność/nieobecność elementu, prosty pomiar położenia, weryfikacja jednej etykiety. Typowy przykład to sprawdzenie, czy na butelce jest korek albo czy na produkcie jest naklejka w przybliżonym miejscu.

Rozbudowane biblioteki mają sens dopiero wtedy, gdy:

• koszt pojedynczego błędu jest istotny (drogie części, ryzyko reklamacji lub zatrzymania linii klienta),
• trzeba łączyć wiele zadań (pomiar, defekty, OCR, kody 2D) w jednym systemie,
• warunki są zmienne (oświetlenie, położenie, kilka wariantów produktu na tej samej stacji).

Jeśli konfiguracja czujnika zamyka temat bez skomplikowanego serwisu, wysilone „AI” zwykle tylko zwiększa ryzyko awarii.

Czym różni się prototyp systemu wizyjnego w Pythonie od rozwiązania 24/7 na linii?

Prototyp na laptopie ma zwykle jedno kryterium: „działa na przykładowych obrazach”. System produkcyjny musi dodatkowo zapewnić:

• mechanizmy watchdog i automatyczny restart modułów w razie zawieszenia,
• logowanie błędów i incydentów (brak obrazu, przekroczenie czasu cyklu, błędne dane z kamery),
• monitoring zasobów (CPU, pamięć, GPU) oraz czasu przetwarzania każdej klatki.

Te elementy rzadko „wbudowane” są w biblioteki typu OpenCV czy PyTorch, więc trzeba je świadomie zaprojektować.

Dochodzi jeszcze zarządzanie konfiguracją: wersjonowanie modeli, progów, receptur produktowych i bezpieczne aktualizacje bez niepotrzebnego postoju linii. To zwykle wywraca do góry nogami entuzjazm po pierwszym udanym POC, gdy okazuje się, że „skrypt z demo” nie nadaje się do utrzymania przez kilka lat.

Jakie zadania wizyjne najczęściej realizuje się w kontroli jakości produkcji?

W zdecydowanej większości projektów powtarza się ten sam zestaw zadań:

• detekcja defektów powierzchni (rysy, wtrącenia, przebarwienia, pęknięcia),
• pomiary wymiarowe i geometryczne (długości, szerokości, kąty, promienie, położenia otworów),
• identyfikacja i śledzenie (kody 1D/2D, OCR, przypisanie numeru seryjnego do obrazu),
• weryfikacja kompletności (czy wszystkie elementy są, są poprawnie zamontowane i nieuszkodzone).

Biblioteka, która dobrze pokrywa te cztery klasy problemów i da się ją stabilnie zintegrować z linią, zwykle wystarcza na wiele lat.

Jeżeli dostawca eksponuje głównie „showcase’y” typu rozpoznawanie twarzy, autonomiczne roboty czy analitykę retail, ale w dokumentacji brakuje porządnych narzędzi do metrologii czy kodów kreskowych, to jest sygnał ostrzegawczy dla zastosowań przemysłowych.

Jak uwzględnić warunki na hali (wibracje, brud, oświetlenie) przy wyborze biblioteki?

Środowisko produkcyjne generuje typowe problemy: mikrowibracje powodujące rozmycie, zmiany temperatury wpływające na ostrość, pył i tłuszcz na optyce, zmienne światło i losowe położenie detali. W takich realiach biblioteka powinna mieć:

• narzędzia normalizacji jasności i kontrastu,
• funkcje rejestracji obrazu i wyszukiwania wzorca (kompensacja przesunięć, obrotów),
• solidne filtry szumu i artefaktów,
• algorytmy segmentacji odporne na zmiany oświetlenia.

Bez tego system będzie działał „idealnie” tylko w dniu kalibracji.

Część problemów rozwiązuje się sprzętowo (stabilne mocowanie kamer, odpowiednia optyka, oświetlacze, osłony), ale nigdy nie da się wyeliminować wszystkiego. Dlatego testy biblioteki na „ładnych” obrazach z laboratorium są konieczne, lecz niewystarczające – kluczowe jest sprawdzenie, jak zachowuje się przy gorszych próbkach z realnej linii.

Czy w kontroli jakości w produkcji zawsze potrzebna jest sztuczna inteligencja / deep learning?

Nie. W wielu prostych i średnio złożonych zadaniach klasyczne metody (progowanie, filtrowanie, dopasowanie wzorca, pomiary geometryczne) działają stabilniej, są łatwiejsze do wyjaśnienia i prostsze w utrzymaniu. Deep learning ma przewagę głównie wtedy, gdy defekty są złożone, zmienne lub trudno je opisać prostymi regułami (np. nieregularne przebarwienia, „subiektywne” wady wizualne).

Wdrożenie sieci neuronowych oznacza dodatkowe koszty: przygotowanie i utrzymanie zbioru danych, trenowanie modeli, proces walidacji i regularne ponowne uczenie przy zmianie produktu czy procesu. Jeżeli kluczowe KPI (błędy OK/NOK, czas cyklu, łatwość przezbrojenia) są osiągalne klasycznymi metodami, „AI ready” bywa tylko drogą ciekawostką na slajdach.

Jak upewnić się, że wybrana biblioteka dobrze zintegruje się z PLC i systemami MES/ERP?

Pierwszy krok to sprawdzenie obsługiwanych protokołów i środowisk wykonawczych: dostępne API (C/C++, .NET, Python), wsparcie dla popularnych systemów operacyjnych w przemyśle (Windows, Linux RT) oraz możliwość pracy w kontenerach (Docker) lub jako usługa sieciowa. Biblioteka sama w sobie nie musi „rozmawiać” z PLC, ale powinna pozwalać bez problemu zintegrować się z modułem komunikacyjnym.

Warto zweryfikować:

• czy dostawca ma gotowe przykłady integracji z PLC (np. przez OPC UA, Modbus, TCP/IP),
• jak wygląda obsługa wielu kamer i kilku równoległych stacji,

Kluczowe Wnioski

• Wybór biblioteki wizyjnej trzeba zaczynać od realiów linii produkcyjnej: czasu cyklu rzędu 50–300 ms, sposobu wyzwalania kamer, wymogów PLC/MES/ERP oraz najsłabszej, najbardziej wymagającej stacji, a nie od „laboratoryjnych” warunków testowych.
• Kluczowe cechy systemu wizyjnego to stabilna praca 24/7, przewidywalny czas przetwarzania, odporność na typowe zmiany warunków oraz łatwa regulacja parametrów przez technologów; efektowne dodatki (AI-ready, dashboardy, dziesiątki filtrów) mają znaczenie drugorzędne, jeśli nie wpływają wprost na jakość lub takt linii.
• Zakres zadań wizyjnych w przemyśle jest stosunkowo powtarzalny: detekcja defektów, pomiary wymiarowe, identyfikacja/śledzenie oraz weryfikacja kompletności – biblioteka, która solidnie pokrywa te cztery obszary, zwykle daje większą wartość niż platforma nastawiona na „spektakularne” zastosowania spoza produkcji.
• Marketing producentów oprogramowania często promuje modne technologie (deep learning, no-code), ale w praktyce to narzędzia do kalibracji, metrologii 2D/3D, odczytu kodów i integracji z PLC decydują, czy system realnie zadziała na linii – brak tych podstaw to sygnał ostrzegawczy.
• Prototyp w Pythonie na laptopie i system działający 24/7 to dwa różne światy; biblioteki obliczeniowe (np. OpenCV, PyTorch) nie zapewniają watchdogów, logowania incydentów, monitoringu zasobów ani procedur aktualizacji, więc te elementy trzeba świadomie zaplanować poza samą biblioteką wizyjną.