Własny system LPR na przemysłowym SBC bez GPU: odpowiedzi na pytania

Baza: koncepcja właściciela.

• Jeden przemysłowy komputer SBC na obiekt. Analityka bez GPU, na CPU i NPU, czyli na NPU wbudowanym w SoC albo na dokładanym akceleratorze NPU. Preferowany ARM, x86 tylko jako porównanie.
• Do dwóch zwykłych kamer CCTV ze strumieniem RTSP, analityka na własnym SBC.
• Wjazd i wyjazd parkingu ze szlabanem: jeden pas na kamerę, kamera skierowana na szlaban, pojazdy do ok. 30 km/h.
• Cele: 99% skuteczności i odczyt przy dużych kątach najazdu.
• Warianty architektury:
  • A: model pojazdu, potem OCR na wybranych klatkach;
  • B: dwa substreamy;
  • C: jeden strumień 4 MP w dwóch reprezentacjach;
  • D: stały obszar zainteresowania i wyzwalacz.

Odpowiedzi na pytania właściciela

1Jakie modele mają najlepszą skuteczność?

Ograniczenie danych. Żaden otwarty model nie ma w źródłach wyniku na publicznym zbiorze polskich tablic. Najlepsze wyniki europejskie pochodzą z małego zbioru OpenALPR-EU (108 obrazów).

OCR. Najlepiej czytają modele uczone na tablicach:

• Fast-OCR: 97,2% poprawnych całych numerów; CR-NET: 96,3% F38599;
• system YOLO + CR-NET: 97,8% wobec 91,7% komercyjnego OpenALPR F43185F49325;
• gotowy fast-plate-ocr: wg autora 92,5% na tablicach z ponad 40 krajów Europy F39273;
• PARSeq douczony na tablicach przewyższa CRNN na zbiorze walidacyjnym GLPD (74 kraje): 91,88% wobec 72,24%; na teście PARSeq ma 87,93%, CRNN nie testowano F39575F48501.

Ogólne silniki OCR bez douczenia wypadają słabo. Na tablicach indonezyjskich pełne dopasowanie daje PaddleOCR 39%, EasyOCR 27%, Tesseract 17% F47760. Największy przyrost daje łączenie odczytów: fuzja ośmiu modeli podnosi średni wynik z 92,4% do 97,6% (średnia z ośmiu zbiorów z różnych krajów) F36864.

Wykrywanie tablicy. Detektory YOLOv9 z pakietu open-image-models mają wg autora mAP50 0,92–0,966 F36361F32747. Licencji fast-plate-ocr, open-image-models i PARSeq źródła nie podają.

Wykrywanie pojazdu nie ogranicza skuteczności. Czułość wynosi 99,92% F42270, więc decydują czas i licencja:

• YOLO Ultralytics (v5, v8, 11, 26) ma AGPL-3.0 dla kodu i wag F32961;
• do zamkniętego produktu bez opłat nadają się RT-DETR, RF-DETR, YOLOX i PicoDet na licencji Apache 2.0 F40446F49681F45088F40092.

Szczegóły: część 1

2Jaką architekturę wybrać: jeden model do pojazdu i drugi do OCR na wybranych klatkach czy dwa substreamy (oraz warianty C i D)?

Rekomendacja dla jednego pasa ze szlabanem: połączenie D + C ze śledzeniem i głosowaniem.

1. Sygnał z pętli przez wejście sterownika szlabanu albo z radaru otwiera okno zdarzenia F37600F37959.
2. Strumień 4 MP jest dekodowany sprzętowo.
3. Detekcja pojazdu działa na obrazie 640×360.
4. OCR dostaje wycinek tablicy z pełnej rozdzielczości, o szerokości co najmniej 100 px F38202.
5. Na pojazd przypada 10–20 wycinków F49186, a głosuje się całym ciągiem po walidacji formatu.

Wariant C jest tani przy dekoderze sprzętowym. Dwie kamery 4 MP przy 25 kl./s zajmują ok. 10–11% dekodera RK3588 przy kamerach nadających H.265 F50262; przy H.264 deklarowana przepustowość jest o połowę mniejsza F40167, więc ok. 20% (obliczenia/s02.py, s05.py). W przykładzie z kamerą 4 MP, obiektywem 12 mm i odległością 10 m tablica ma 140 px, a w tym samym kadrze zmniejszonym do 640×360 tylko 33 px, czyli tyle, ile wynosi granica odczytu 30 px F43518F45339.

Wariant B oszczędza dekodowanie, ale ma problem z synchronizacją. Pomiaru rozjazdu strumienia głównego i substreamu jednej kamery źródła nie zawierają. Najlepsza znaleziona synchronizacja programowa strumieni siedmiu różnych kamer zostawia rozjazd do 50,5 ms F33810. Taki rozjazd przy 30 km/h przesuwa pojazd o 42 cm, czyli o 81% szerokości tablicy. Wycinek trzeba poszerzyć albo ponownie wykryć tablicę w klatce głównej. Wariant B jest właściwy, gdy SoC nie dekoduje sprzętowo kodeka kamery, np. Raspberry Pi 5 z kamerą H.264 F33979.

Wariant A zostaje w postaci logiki śladu pojazdu. Głosowanie z wielu klatek wygrywa z wyborem najlepszej klatki: w WINK 92,0% wobec 79,5% F48479.

Szczegóły: część 2

3Skąd pobrać bazy do treningu dla Polski i Europy?

Darmowe polskie dane są małe.

• Jedyny opisany zbiór uczący liczy 1000 zdjęć F41384.
• Zbiór z Katowic na Kaggle nie podaje liczby zdjęć i ma licencję „Other” F35960F32420.
• Parking Database to 22 nagrania z kamer parkingowych, użyte do testu modelu dla Polski; kraju nagrań źródła nie podają F36613.

Duże polskie zbiory są płatne. Unidata ma 83 793 zdjęcia polskich tablic, a w zbiorze wielokrajowym 220 474 zdjęcia z Polski F35265F40506. Żaden darmowy polski zbiór nie ma licencji, która wprost dopuszcza zamknięty produkt komercyjny.

Europa.

• TLPD: ponad 17 tys. zdjęć z UE, bez podanej licencji F40144.
• UC3M-LP: 2547 tablic z Hiszpanii, w tym 31 dwurzędowych F32772F32774.
• GLPD: ponad 5 mln zdjęć z 74 krajów z serwisu Platesmania F36065.

Pretrening.

• CCPD: 366 789 zdjęć, licencja MIT F33922F33211.
• RodoSol-ALPR i UFPR-ALPR: tylko do badań niekomercyjnych F43802F40227.
• Jedyny zmierzony transfer dla Polski: tablice czeskie, potem polskie, dały 89,2% wobec 87,3% F45455F50494.

Dane syntetyczne dają duży zysk przy małej liczbie prawdziwych zdjęć. Na tablicach chińskich 4750 prawdziwych zdjęć z syntezą dało 99,0%, a 50 tys. samych prawdziwych 96,7% F38005F38004. Pomiaru dla tablic polskich brak.

Szczegóły: część 3

4Jakie wybrać kamery CCTV?

Wymagania. Zwykła kamera z ręczną migawką i ekspozycją:

• 100–150 px na szerokości tablicy UE F33409F33930;
• stała migawka 1/500 s na wjeździe start-stop, nocą 1/1000–4/1000 s F34377F40822;
• ograniczone wzmocnienie;
• IR 850 nm F50095.

Rozdzielczość. Kamera 2 MP z obiektywem ustawionym na pas wystarcza na 2–10 m F33415 (obliczenia/s04.py). Kamera 4 MP daje zapas pikseli na szeroki kadr i duże kąty: z obiektywem 6 mm utrzymuje co najmniej 130 px do 11 m (obliczenia/s04.py).

Konkretne kamery.

• Najlepiej udokumentowana: Bosch DINION IP starlight 6000i IR, z trybem sceny LPR, kwalifikowana przez Bosch do jednego pasa do 15 m F34386F34384. Ceny brak w źródłach.
• Z pełnymi parametrami LPR, bez ceny: Hikvision DS-2CD2043G2-I z obiektywem 6 mm: 4 MP F44281, migawka do 1/100 000 s F44277, WDR 120 dB F44283, IR 850 nm F44280. Dipolnet oznacza ją jako niedostępną F43102.
• Najtańsza z ceną: Dahua IPC-HFW1439TL1-A-IL za 93,63 € brutto T14793. Cennik pokazuje „9363 €” bez separatora; odczyt jako 93,63 € to założenie S. Kamera daje co najmniej 130 px tylko do 5 m.

Dedykowana kamera LPR Hikvision kosztuje 1286,58 € brutto F40785, czyli ok. 13,7 razy więcej (przy cenie Dahua 93,63 € S). Większość jej funkcji przejmuje SBC.

Szczegóły: część 4

5Jak osiągnąć 99%?

Definicja. Dla szlabanu liczy się tylko poprawny cały numer na przejazd, czyli wykrycie × odczyt. Brytyjski standard 98% × 95% daje 93,1% F35198F35199.

Stan systemów komercyjnych. Jedyny niezależny test przy wolnym ruchu (tablice USA) dał 70,0% i 55,3% na pojazd F38059F38060. Testu na polskim parkingu brak w źródłach.

Gdzie jest luka do 99%. Leży w odczycie znaków, nie w detekcji:

• wykrycie tablicy ma 99,51% F38915;
• dla 99% na pojazd przy wykryciu 99,5% i tablicy 7–8 znaków S błąd na znak musi być nie większy niż 0,072% (7 znaków) i 0,063% (8 znaków) (obliczenia/s06.py).

Błędy stałe. W 700 brytyjskich błędnych odczytach 72,6% powodowały śruby w obrębie znaków, a 23,0% zabrudzenia F41960. Takie błędy powtarzają się na każdej klatce i głosowanie ich nie usuwa. Jeśli 1% pojazdów ma taki stały błąd, system nie przekroczy 99%.

Zmierzone zyski technik (na tablicach spoza Polski):

• walidacja składni razem z poprawą kontrastu: +6,15 pkt proc. od 53,9%, tablice chińskie CCPD; walidacja daje większość zysku F44112F44113;
• fuzja ośmiu modeli: 92,4% → 97,6%, średnia z ośmiu zbiorów z Chin, Tajwanu, Brazylii i innych F36864;
• głosowanie z klatek: 66,7% → 81,8%, 33 nagrania z tablicami rumuńskimi F45431;
• dane z własnego obiektu: 95% → 98,6% przy 15–20 wycinkach na pojazd F41562F42840.

Najbliżej 99% jest połączenie tych technik z poprawnym ustawieniem kamery. Super-rozdzielczość przy wycinkach 80–150 px nic nie daje F42844.

Potwierdzenie. Wykazanie 99% z jednostronną ufnością 95% wymaga co najmniej 299 przejazdów bez błędu; przy 5 błędach 1049, przy 10 błędach 1693 przejazdów (obliczenia/s06.py).

Szczegóły: część 6

6Jak rozpoznawać tablice przy dużych kątach najazdu?

Deklaracje producentów. Większość deklaruje 25–35° w poziomie i 30–40° w pionie F43451F45443F45916F48779F48780. Genetec deklaruje 50° w poziomie, model Intel barrier-0001 ±45° F48781F34559. Plate Recognizer zaleca do 45°, a sam silnik ma czytać do 70° z boku i 53° w pionie F34212F34213. Niezależnych pomiarów silników komercyjnych w przedziałach kąta źródła nie zawierają; poradnik projektowy podaje orientacyjnie: 0–15° ponad 98%, 15–30° 90–98%, 30–45° 60–85%, powyżej 45° poniżej 50% F46872.

Co zawodzi. Poza granicą najpierw zawodzi OCR, nie detekcja: powyżej 45° tablica jest wykrywana, ale tekst się nie rozczytuje F46204.

Skuteczne metody:

• wykrycie czterech narożników i prostowanie homografią;
• STN: 91,5% przy kącie poziomym 20–50°, tablice chińskie F49536F49952;
• obrócone ramki (OBB): z 82,7% do 91,5% F43072;
• dane syntetyczne: +5% na ukośnych tablicach tajwańskich AOLP-RP F37553, +12,1% na tablicach malezyjskich (synteza ogólnie, nie tylko kąty) F42572.

Odczyt do ok. 45° jest realny, gdy po skróceniu perspektywicznym tablica ma co najmniej 100 px szerokości i działa programowe prostowanie (synteza z części 7). Pomiaru 99% przy kącie powyżej 30° źródła nie zawierają.

Montaż. Kamera 1,5 m od osi pasa zachowuje kąt nie większy niż 30°, gdy tablica jest czytana co najmniej 2,6 m przed kamerą S (obliczenia/s07.py).

Szczegóły: część 7

7Jaki sprzęt jest najlepszy, a jaki najrozsądniejszy cenowo?

Najlepszy ARM: przemysłowy komputer na RK3588J lub RK3588. Przykłady:

• ARMxy BL450: RK3588J, −40…85 °C, 9–36 V, watchdog F39704F39706;
• InHand EC3320: RK3588 F44349, −20…60 °C, wejścia i wyjścia cyfrowe, RS-485 F44350F44352, watchdog F44351.

NPU 6 TOPS wykonuje detekcję w 14–41 ms zależnie od modelu: YOLOX-nano 14 ms, YOLO11n 18,5 ms, YOLO26n 41,2 ms F42712F39980F35336. Przy 2 kamerach po 12 kl./s zajmuje to 34–44% czasu NPU dla dwóch pierwszych modeli i 99% dla YOLO26n (obliczenia/s05.py). Dekoder ma 5,4–21,6 razy więcej mocy, niż potrzebują dwa strumienie 4 MP F38829 (obliczenia/s05.py). Cen wersji przemysłowych RK3588J brak w źródłach.

Najrozsądniejszy cenowo ARM: RK3576. Seeed reComputer Industrial kosztuje 299 USD F46352, a Geniatech XPI-3576 pracuje w −40…85 °C F49092. NPU 6 TOPS podają producenci F36908, zmierzonych czasów brak w źródłach.

Odpadają:

• Samo CPU ARM: Pi 5 z YOLOv8s INT8 osiąga 1,1 kl./s detekcji na kamerę przy dwóch kamerach F46362; z lżejszym YOLOv8n 3,3–4,2 kl./s F36558, nadal poniżej potrzebnych 10–12 kl./s przy 30 km/h.
• Pi 5 z Hailo-8L: zapowiedź Pi 5 nie wymienia wersji przemysłowej F35972, nakładka Hailo-8L pracuje tylko w 0…50 °C F45910, a przemysłowe jednostki CM5 (np. EdgeLogix-1145, −20…60 °C) nie mają NPU F33521F33522.
• i.MX8M Plus: sprzętowo dekoduje najwyżej 1080p F43050.

x86 jako porównanie. N100 z OpenVINO (YOLOv8n INT8, 23,6 kl./s w benchmarku Intela; urządzenia ustalenie nie podaje) wystarcza tylko w trybie wyzwalanym 2×5 kl./s, przy 42% mocy F36125. Wygrywa, gdy modele mają operatory nieobsługiwane przez RKNN albo gdy wymagane jest jądro główne Linuksa bez BSP dostawcy F37242F39844.

Szczegóły: część 5

8Jaką architekturę oprogramowania zastosować i jakie modele AI do jakich zadań?

Szczegóły: część 1 i część 2

9Co może dać więcej niż zwykłe systemy LPR?

Wyróżniki uszeregowane według wartości dla klienta parkingu i wykonalności na SBC:

1. Asystent ustawienia kamery z oceną gotowości stanowiska. Wg Plate Recognizer zasady ustawienia decydują o 75% albo 98% skuteczności F36424. Przy 500 wjazdach na dobę to 125 albo 10 interwencji (obliczenia/s08.py).
2. Ciągła diagnostyka jakości obrazu i dryfu kamery z alarmem F48309F48260.
3. Głosowanie wieloklatkowe z walidacją formatu i pewnością każdego znaku. Głosowanie zmniejszyło błędy o 61%, fuzja modeli o 68% (obliczenia/s08.py).
4. Ścieżka wyjątku dla pojazdu bez odczytu: typ, kierunek, kolor w dzień i zdjęcie do szybkiej korekty F48294.
5. Uczenie na poprawkach operatora. Zwiększenie liczby etykiet z 3 tys. do 18 tys. podniosło skuteczność z 95% do 98,6% F51075. Trening odbywa się poza SBC.
6. Kierunek ruchu i typ pojazdu F48588.
7. Marka, model i kolor jako kontrola zgodności z tablicą. Kolor jest wiarygodny tylko w dzień F42873.
8. Rozpoznawanie niezależne od układu tablicy, z krajem F36554.

Model wizyjno-językowy 3B generuje na SBC 5–7 tokenów/s F43059, co daje szacunkowo 3,2–4,9 s na zapytanie, a przy wolniejszym pomiarze ok. 84 s S (obliczenia/s08.py); nadaje się tylko do asynchronicznej drugiej opinii. Super-rozdzielczość przy wycinkach 80–150 px nie daje zysku F51072.

Szczegóły: część 8

Luki w źródłach

• Brak wyniku otwartego modelu na zbiorze polskich tablic i brak niezależnego testu na polskim wjeździe parkingowym.
• Brak pomiaru 99% przy kącie powyżej 30° i brak niezależnych pomiarów kątowych silników komercyjnych.
• Brak zmierzonych czasów i strat dokładności na NPU RK3576, i.MX8M Plus i i.MX95. Brak też strat dokładności przy kompilacji Hailo i Edge TPU.
• Brak cen przemysłowych komputerów na RK3588J.
• Brak liczbowych pomiarów wyzwalaczy przy szlabanie (fałszywe i pominięte wyzwolenia).
• Brak licencji fast-plate-ocr, open-image-models i PARSeq.
• Brak zysku z syntezy i pretreningu zmierzonego na tablicach polskich.

Część 1Modele o najlepszej skuteczności dla każdego zadania

S01-Q1Które otwarte modele dają najlepszą skuteczność wykrywania tablic i rozpoznawania ich treści (OCR) na tablicach europejskich i polskich? Podaj wyniki dokładnie: zbiór danych, metrykę (dokładność całego ciągu na pojazd lub na obraz, dokładność znaków), warunki i licencję modelu.

OdpowiedźŹródła nie zawierają wyniku żadnego otwartego modelu na publicznym zbiorze polskich tablic. Najwyższe wyniki na tablicach europejskich pochodzą z małego zbioru OpenALPR-EU (108 obrazów): modele badawcze Fast-OCR i CR-NET odczytują cały ciąg poprawnie w 97,2% i 96,3% przypadków, choć nie widziały tego zbioru w treningu F38599, a system YOLO + CR-NET osiąga 97,8% wobec 91,7% komercyjnego OpenALPR F43185F49325. Gotowy do pobrania fast-plate-ocr osiąga wg autora 92,5% całego ciągu na tablicach z ponad 40 krajów Europy i 93,3% w wersji globalnej F39273F39275F36777. PARSeq na zbiorze GLPD (74 kraje) odczytuje cały ciąg w 87,93% przypadków F47011. W wykrywaniu tablic najlepiej opisane są detektory YOLOv9 z pakietu open-image-models (wg autora mAP50 0,92 przy wejściu 384 i 0,966 przy 608) F36361F32747. Licencji fast-plate-ocr, open-image-models, CR-NET, Fast-OCR i PARSeq źródła nie podają; licencje detektorów omawia s01-q3.

Dowody

• Jedyny pomiar na polskich tablicach dotyczy komercyjnego DTK ANPR SDK: najwyżej 86% na 175 zdjęciach z ruchu, kamera 6,4 m nad jezdnią, pojazdy w odległości 40–50 m F42215F42217. Dorbe i in. podają 96,7% dokładności modułu rozpoznawania znaków (VGG + LSTM) na tablicach m.in. z Polski F49508.
• Detektor potoku Intel/license-plate-recognition uczono głównie na tablicach europejskich i amerykańskich; potok ma licencję MIT, ale źródła nie podają jego dokładności F36539F36538.
• Modele z innych regionów nie przenoszą się wprost na tablice polskie: NVIDIA LPRNet ma 97,49% na tablicach USA i 99,67% na chińskim CCPD i istnieje tylko w tych dwóch wariantach F40525F40526F42020; Intel license-plate-recognition-barrier-0001 ma 88,58% na 1165 chińskich tablicach F44183.
• Wyniki z jednego zbioru zawyżają skuteczność: przy testowaniu na zbiorze pominiętym w treningu średnia 12 modeli spada z 82,4% do 74,5% F50078; po usunięciu bliskich duplikatów z CCPD średnia sześciu modeli spada z 80,3% do 77,6% F35047.
• W eksploatacji błędy powoduje sama tablica: śruba w znaku „U” dała 71,5% poprawnych odczytów (713/997), po wymianie na mniejsze śruby 99,7% (358/359) F36603F36604; mocowania odpowiadały za 72,6% z 700 błędnych odczytów F36605.
• Kąt i rozmiar tablicy: NVIDIA LPRNet uczono przy odchyleniu ±15° i przechyle ±30°, na tablicach większych niż 16×16 px F36685; barrier-0001 wymaga szerokości tablicy co najmniej 94 px i toleruje odchylenie oraz pochylenie ±45° F44183F35463. Wg testów polowych Plate Recognizer przytoczonych w artykule skuteczność wyraźnie spada powyżej 70° pochylenia, a przy 75° odczyt staje się prawie niemożliwy F36892.

Warunki i rozbieżnościOpenALPR-EU zawiera 108 obrazów z pojazdem wyśrodkowanym i dużym w kadrze F43185; jeden obraz to 0,93 pkt proc., a 97,8% daje 95-procentowy przedział ufności 93,5–99,5% (obliczenia C). Wyniki fast-plate-ocr to walidacja autora; dokładność dla poszczególnych krajów leży w plikach repozytorium, nie w ustaleniach F36780. Model europejski należy do starszej linii utrzymywanej tylko do wnioskowania F39276, a dla aktualnych modeli CCT README nie podaje dokładności w tekście F39336. Wynik bliski 99% występuje tylko w obrębie jednego chińskiego zbioru: LPRNet ma 99,64% na walidacji CCPD, ale na trudnym teście CCPD zgodność długości ciągu spada do 0,7278 F35170F35171. Zbiór ELP 1.0 zawiera polskie tablice, ale jego licencja wyklucza użycie w aplikacjach komercyjnych F41518F42162F42163; RodoSol-ALPR i UFPR-ALPR służą tylko do badań akademickich F43802F40227. Brak danych w źródłach: wynik otwartego modelu na zbiorze polskich tablic (zbiór z Katowic istnieje, ale bez wyniku modelu F40096).

S01-Q2Które podejście do OCR czyta tablice najdokładniej: modele CTC dedykowane tablicom (LPRNet, fast-plate-ocr), rozpoznawacze tekstu scenicznego (PARSeq, CRNN, SVTR), ogólne silniki OCR (PaddleOCR, EasyOCR, Tesseract) czy modele wizyjno-językowe; jak każde z nich radzi sobie z tablicami dwuwierszowymi i podobnymi znakami?

OdpowiedźNajdokładniej czytają modele uczone na tablicach: dedykowane modele wykrywające znaki (Fast-OCR, CR-NET) i rozpoznawacze tekstu scenicznego douczone na tablicach (PARSeq, ViTSTR); ogólne silniki OCR bez douczenia i modele wizyjno-językowe zostają w tyle. Na OpenALPR-EU Fast-OCR osiąga 97,2%, CR-NET 96,3%, CRNN 93,5% F38599; na GLPD PARSeq osiąga 91,88% na walidacji wobec 72,24% CRNN (na teście PARSeq 87,93%, CRNN nie testowano) F39575F48501; na brazylijskim UFPR-VeSV PARSeq-Tiny osiąga 98,0% i wyprzedza dedykowany GP-ALPR F42325F42326. Ogólne silniki wypadają słabiej: na 500 indonezyjskich tablicach pełne dopasowanie PaddleOCR wynosi 39%, EasyOCR 27%, Tesseract 17% F47760. Największy przyrost daje łączenie odczytów: fuzja kilku modeli podnosi średnią z 92,4% do 97,6% F34611. Tablice dwuwierszowe czytają modele wykrywające znaki i OCR z detektorem linii tekstu; modele bez segmentacji znaków ich nie czytają F36798F47383.

Dowody

• Pochylenie obnaża różnice: na CD-HARD CRNN spada do 31,7%, a Fast-OCR do 59,6% F38599F38600; LPRNet przy dużej zmianie kąta nie daje dobrych wyników F42579.
• PARSeq-tiny ma 94,26% całych tablic przy zmianie kamery, ale 50,76% na tablicach nieczytelnych F42067.
• Ciężkie modele są na ARM zbyt wolne: na Raspberry Pi 4 TrOCR osiąga 92,6% przy 4,98 s na wycinek, PaddleOCR potrzebuje 840 ms F46783.
• Tablice europejskie mają zmienną liczbę znaków (min. 5), więc typowe błędy to zgubiony lub dodany znak, nie dwa wiersze F36803F43189.
• OpenALPR błędnie czyta literę „I” na trzeciej pozycji polskiej tablicy przez naklejkę legalizacyjną; po jej wyretuszowaniu odczyt jest poprawny F36533F36536.
• Niezrównoważenie klas utrwala pomyłki: SSIG-SegPlate ma 746 liter „O” i 135 liter „Q” F41579, a modele OCR zapamiętują wzorce z treningu F35918. Systemy korygują podobne znaki regułami po OCR: Frigate zamienia „O” na „0” i „I” na „1” F38924, potok z PaddleOCR koryguje 0↔O i 1↔I/l i sprawdza format F42524.
• Wiele klatek poprawia odczyt: LprNet agregujący sekwencję poprawia się monotonicznie z liczbą klatek F37035 i przy szerokości tablicy 60 px osiąga prawie 80% z 10 klatek F36053; głosowanie po klatkach śledzonego pojazdu stale zwiększa dokładność znaków F47845; przy fuzji modeli najlepiej działa głosowanie na poziomie całego ciągu F34612.

Warunki i rozbieżnościfast-plate-ocr w wersji 0.2.0 nie używa CTC, tylko osobnej głowicy klasyfikacji dla każdej pozycji znaku F36779. Przegląd 21 badań, który przypisuje PaddleOCR i EasyOCR ponad 95% na ujednoliconych tablicach UE, to synteza jakościowa bez wspólnego zbioru testowego F38875F50318; 94% EasyOCR na ponad 4000 obrazach niemieckich F36512 i 27% na indonezyjskich F47760 pochodzą z różnych danych. Wyniki ze zbiorów chińskich, brazylijskich, malezyjskich i indonezyjskich nie przenoszą się wprost na tablice polskie. Brak danych w źródłach: wynik SVTR na tablicach (tylko benchmarki tekstu scenicznego F39641) i wyniki na polskich tablicach dwuwierszowych.

S01-Q3Które modele najlepiej wykrywają i śledzą pojazdy przy wjeździe na parking na CPU (warianty YOLO, RT-DETR, NanoDet, SSD-MobileNet, PicoDet, odejmowanie tła): skuteczność, opóźnienie na CPU i licencja?

OdpowiedźWykrywanie pojazdu nie ogranicza skuteczności systemu: YOLOv2 osiąga średnio 98,37% precyzji i 99,92% czułości na 8 zbiorach F42270, więc wybór modelu decyduje głównie o czasie na CPU i licencji. Najkrótsze czasy mają małe detektory jednoetapowe; jako punkt odniesienia na zintegrowanym GPU Intela (tabela Frigate podaje czasy GPU): YOLOv9-tiny 320 – 16 ms na N150, MobileNetV2 ok. 15 ms na N100 F42298F40873; na Raspberry Pi 5 (4 × Cortex-A76 2,4 GHz F41809) YOLOv8n 640 zajmuje 120–150 ms F36558. Detektory transformerowe są na CPU ARM kilkakrotnie wolniejsze: RT-DETR-R18 786,6 ms na Pi 5 F45249, a RF-DETR nie uruchamia się w OpenVINO, ORT ACL ani XNNPACK F34025. YOLOv5, YOLOv8, YOLO11 i YOLO26 Ultralytics mają AGPL-3.0 dla kodu i wag F32961, oryginalne YOLOv7 i YOLOv9 – GPL-3.0 F32962; do zamkniętego produktu bez opłat nadają się RT-DETR F40446, RF-DETR Nano–Large F49681, YOLOX F45088 i PicoDet z PaddleDetection F40092 (Apache 2.0). Do śledzenia źródła wskazują ByteTrack F45129; odejmowanie tła działa tanio i bez trenowania przy stałej kamerze F47860, ale zamienia identyfikatory bliskich pojazdów F42672.

Dowody

• RT-DETR-R18 wymaga 60 GFLOPs F45251 wobec 8,7 GFLOPs YOLOv8n F45937, czyli 6,9 razy więcej; na Pi 5 zmierzona różnica czasu wynosi 5,2–6,6 razy (obliczenia F).
• Na płytce z Rockchip RF-DETR po przeniesieniu szkieletu na NPU i kwantyzacji głowicy zajmuje 470 ms F34024; ostatecznie detekcja działa tam z 5 kl./s na płytce poniżej 100 euro F34028.
• Na Pi 5 ncnn FP32 jest średnio 2,09× szybszy od ONNX Runtime FP32 na 13 detektorach F37138, ale konwersja do ncnn obniża mAP modeli YOLOX o co najmniej 1 pkt F37141.
• Wejście 448×288 zamiast 416×416 zmniejsza zniekształcenie i przyspiesza detekcję pojazdu F39257; mniejsze warianty Fast-YOLO gubiły pojazdy częściowo zasłonięte F39253.
• SSD MobileNetV2 barrier-0123 (256×256, int8) wykrywa pojazdy i tablice dla kamer przy szlabanie, ale uczono go głównie na tablicach chińskich, gubi ciemne tablice i wymaga tablic szerokich na co najmniej 96 px F40513F40514F40518.
• ByteTrack dołącza do ścieżek także ramki o niskiej pewności F33261, ma wynik MOT-17 78,4 F45129 i działa z 35,69 kl./s wobec 15,71 kl./s BoT-SORT (pomiar na GPU) F47159; gubi obiekty zasłonięte i szybko opuszczające kadr F33310. Przy odczycie z sekwencji błędy śledzenia dominują nad błędami OCR F42101.
• Model tła musi radzić sobie m.in. ze zmianą oświetlenia, cieniami i obiektem, który się zatrzymał F45810; cienie chmur nadal zakłócają większość metod F40122.

Warunki i rozbieżnościWartości mAP pochodzą z ogólnego zbioru COCO, nie z wjazdu na parking; przewagę RF-DETR nad YOLO11 podaje producent, z czasami mierzonymi na GPU T4 F44026F43724. Społecznościowe modele YOLO11 oznaczone jako MIT F39044 i potok Intel na MIT z detektorem YOLOv8 F36538 stoją w sprzeczności z AGPL-3.0 kodu i wag Ultralytics F32961. PaddleDetection ma Apache 2.0 F40092, ale PaddleYOLO z RT-DETR i YOLOv8 – GPL-3.0 F44761. RT-DETR nie eksportuje się do RKNN, ncnn ani TFLite F36788. Wymaganie AVX i AVX2 dotyczy Frigate F33240, nie procesorów ARM ani wariantów A–D; Frigate ma osobne wydanie dla płytek z Rockchip F47306. Brak danych w źródłach: NanoDet oraz skuteczność odejmowania tła przy szlabanie.

S01-Q4Jak szybko modele wykrywania tablic i OCR działają na CPU i NPU komputerów jednopłytkowych (ARM Cortex-A76/A55, Intel serii N i Atom x7000) z ONNX Runtime, OpenVINO, ncnn lub TFLite/XNNPACK i ile skuteczności traci się przy kwantyzacji int8? Podaj ms na klatkę z dokładnym CPU, środowiskiem, rozmiarem wejścia i liczbą wątków.

OdpowiedźNa ARM najkrótsze czasy daje NPU RK3588: detektory klasy nano w INT8 zajmują 14–41 ms (yolox_nano 14 ms na 3 rdzeniach NPU w pomiarze Frigate F42712, YOLO11n 640 18,5 ms na RK3588S w niezależnym pomiarze F39980, YOLO26n 41,2 ms wg Ultralytics F35336). Na CPU Cortex-A76 (Raspberry Pi 5, 4 × 2,4 GHz F41809) YOLOv8n 640 zajmuje 120–150 ms F36558. OCR wycinka tablicy kosztuje mniej niż detekcja: LPRNet 1,3 ms na i7-6700K z OpenVINO F36919, fast-plate-ocr (model europejski) 2,9 ms na Apple M1 w ONNX Runtime CPU F36778, ale model CNN + Attention-LSTM zajmuje ok. 62,5 ms na CPU Pi 5 F44173. Cały potok LPR na Pi 5 z akceleratorem Hailo-8 zajmuje 33 ms na klatkę F41673. Na x86, jako porównanie, zintegrowane GPU Intel N150 i N100 z OpenVINO wykonują YOLOv9 320 w 16–30 ms F42298F40873 (GPU tylko jako punkt odniesienia). INT8 z kalibracją kosztuje detektory 1–2 pkt mAP (YOLOv8n 0,417 → 0,406 F46848, YOLO26n na RKNN 0,477 → 0,463 F35336), naiwna kwantyzacja 5,8 pkt F43651, a w detekcji tablic INT8 wyraźnie obniża precyzję F44170. CRNN po INT8 mieści się w ±1 pkt F46956; brak danych w źródłach o stracie INT8 dla LPRNet, fast-plate-ocr i PARSeq na tablicach.

Dowody

• Strata INT8 dla detektorów (obliczenia B): YOLOv8n w OpenVINO −0,011 mAP50-95 (−2,6% wzgl.) F46848; kwantyzacja z kontrolą dokładności −0,0138, naiwna PTQ −0,058 F43651; YOLO26n na RKNN −0,014 przy przyspieszeniu 1,42× F35335F35336; YOLOv8 na RK3588 (wykrywanie wad lin) 97,3% → 95,7% mAP@0,5 przy 32,6 → 18,5 ms F48863; YOLOv8m na Intel NPU 0,921 → 0,901 przy 31,10 → 22,43 ms, wejście 320 F47170F47172; RF-DETR Nano w ONNX Runtime −2,65 pkt przy statycznej INT8 i −9,65 pkt przy domyślnym pokryciu operatorów F44319.
• Zysk czasu z INT8 jest umiarkowany: MobileNetV2 224 na Pi 5 w TFLite 52 → 38 ms F38983, RF-DETR na CPU ok. 1,4× F44320, biblioteki mobilne na CPU ARM 0,8–3,0× F36437; procesor bez instrukcji VNNI (i7-8559U) emuluje INT8 przez AVX2 F43656.
• Kwantyzacja per-tensor modelu barrier-0123 (wersja dla ARTPEC-8) obniża ufność detekcji pojazdów średnio o ok. 0,25, a per-kanał pozostaje blisko oryginału F40516; PTQ EfficientNet-B0 spada z 77,4 do 33,9 Top-1, a trening świadomy kwantyzacji przywraca 76,8 F37169.
• OCR a INT8: PP-OCRv4 ma szkielet skwantowany do INT8 F49541; NVIDIA LPRNet eksportuje tylko FP32 i FP16 F42019; PTQ psuje się w modelach poniżej 1 mln parametrów F33631, a LPRNet ma 0,4 mln F43762.
• Na rdzeniach A76 RK3588 źródła podają tylko RF-DETR (szkielet: 950 ms ORT, 472 ms OpenVINO ARM, 367 ms na NPU) F34023 i przelicznik producenta: ResNet18 na NPU ok. 4 ms, 12× szybciej niż na A76 F46544, czyli ok. 48 ms na A76 (obliczenia A).
• Warunki pomiaru: na Pi 5 bez aktywnego chłodzenia po ok. 3 min taktowanie spada z 2,4 do 1,8 GHz, a czas rośnie z 38 do 51 ms F38986; tflite-runtime z pip nie jest zoptymalizowany pod A76, pakiet systemowy daje 15% krótszy czas F38987; na ARM Neoverse najlepszą przepustowość daje 1 proces × 4 wątki F45589.
• Obciążenie dwiema kamerami przy 2 × 5 kl./s (obliczenia G): YOLOv8n 640 na CPU Pi 5 potrzebuje 135% czasu, na NPU RK3588 15–19%, YOLO26n na NPU 41%, cały potok Pi 5 + Hailo-8 33%, YOLOv9-tiny 320 na N150 16%.
• Frigate zaleca 5 kl./s dla kamery LPR, maksymalnie 10 F40757, a czas rozpoznania powyżej 100 ms uznaje za szkodliwy F41501; to parametry Frigate, który ma też detektor RKNN dla RK3588 F42711.

Warunki i rozbieżnościLiczby IEEKER, Hailo i Ultralytics to deklaracje producentów. Tabela RKNN Model Zoo F42580F42582F42583 jest w ustaleniach odczytana jako ms, ale dałoby to 605 ms dla LPRNet (0,34 GFLOPs F42457) wobec 76 ms dla YOLOv8n (8,7 GFLOPs F45937); liczby zachowują się jak przepustowość, a ustalenia nie podają platformy dla kolumny, dlatego nie nadają się jako czasy na klatkę. Na Pi 5 TFLite INT8 F38981 wypada wolniej niż PyTorch/ONNX FP32 F36558; pomiary pochodzą z różnych źródeł i konfiguracji. Artykuł o Mini-YOLO podaje FP16 na RK3588 raz 19,4 ms F48863, raz 37,4 ms F51019. PARSeq zajmuje 14,87 ms na 1 wątku PyTorch, ale bez nazwy CPU F36840. Brak danych w źródłach: zmierzone ms na rdzeniach Cortex-A55, na NPU RK3576 (Frigate wymienia RK3576 jako obsługiwany F50409), na NPU i.MX 8M Plus (2,3 TOPS F43052) i i.MX 95 oraz na Intel Atom x7000 (praca dyplomowa VUT wybrała YOLOv8n INT8 w OpenVINO jako działający w czasie rzeczywistym, bez podania ms F41536).

Założenia S i obliczenia

• Skrypt obliczenia/s01.py, wynik obliczenia/s01.out.
• A. ms = 1000 / FPS; ResNet18 na A76: 4 ms × 12 = 48 ms (przelicznik producenta) F46544.
• B. Strata INT8 = metryka INT8 − metryka FP32/FP16; przyspieszenie = czas FP / czas INT8. Metryki pochodzą z COCO lub innych dziedzin, nie z tablic.
• C. Przedział Wilsona 95%: OpenALPR-EU 106/108 → 93,5–99,5% (liczbę trafień zaokrąglam z 97,8% × 108 S); potok YOLO + OCR 74/98 → 66,1–83,0%; tablice ze śrubą 713/997 → 68,6–74,2%; po wymianie śrub 358/359 → 98,4–100%.
• D. Różnice między protokołami (pkt proc.): −7,9 średnia cross-dataset, −2,7 CCPD bez duplikatów, +5,2 fuzja modeli, −37,6 Fast-OCR i −61,8 CRNN na CD-HARD.
• E. Głosowanie większościowe po k klatkach: P = Σ_{i>k/2} C(k,i)·p^i·(1−p)^(k−i). Zakładam niezależne błędy klatek i brak zgodnych błędnych odczytów S, więc wynik to górna granica: przy p = 92,5% (fast-plate-ocr) k = 3 daje 98,40%, k = 5 daje 99,62%; przy p = 97,2% (Fast-OCR) k = 3 daje 99,77%. Źródła potwierdzają kierunek, nie wartość, bo błędy śledzenia dominują F42101.
• F. RT-DETR-R18 / YOLOv8n = 60 / 8,7 GFLOPs = 6,9×; Pi 5: 786,6 / 120–150 ms = 5,2–6,6×.
• G. Obciążenie = 2 kamery × fps × ms / 1000 przy 5 i 10 kl./s F40757; detektor na każdej klatce, przetwarzanie szeregowe, środek przedziału, gdy źródło podaje zakres S.
• Czasy CPU z Raspberry Pi 5 to jedyne w źródłach pomiary detektorów na rdzeniach Cortex-A76; nie przenoszę ich na inne SoC z A76 S.

Część 2Architektura: który wariant wybrać

S02-Q1Wariant A: jeden model wykrywa pojazd, drugi odczytuje tablicę tylko na wybranych klatkach. Jak systemy wybierają klatki (rozmiar tablicy, ostrość, kąt, pewność, najlepsze ujęcie) i jaką skuteczność oraz obciążenie CPU podają?

OdpowiedźSystemy wybierają klatki czterema filtrami: minimalnym rozmiarem tablicy (Frigate: min_area 1000 px², ok. 32×32 px F33584; MOBOTIX: domyślny zakres szerokości 130–300 px, do dostrojenia F39963), progami pewności detekcji i odczytu z zachowaniem najpewniejszego wyniku w śladzie (Frigate: 0,7 i 0,9 F33738, F33583), interwałem przechwytywania w śladzie pojazdu (SORT, OCR na 2 z 10 klatek F41671, F41674) oraz wyborem „najlepszego momentu” przez algorytmy producenta F32996. Wybór jednej najlepszej klatki przegrywa z głosowaniem po wielu klatkach: w systemie WINK najlepszy pojedynczy wycinek daje 79,5% dokładnych odczytów, a głosowanie po 15–20 wycinkach 92,0% na 1000 tablic F48479; na zbiorze UFMG najlepsza klatka wg pewności OCR daje 53,5%, głosowanie 81,8% F51201. Ważenie klatek ostrością (Laplasjan) i rozdzielczością wycinka nie dało istotnej statystycznie poprawy ponad samo głosowanie F44574. Główną zaletą wariantu A jest koszt: śledzenie zmniejsza liczbę wywołań OCR 30-krotnie (450 → 15 wycinków dla 15 pojazdów, 22,5 s → 0,75 s OCR) F41678, a cały potok na Raspberry Pi 5 z Hailo-8 zajmuje 33 ms na klatkę F41673. Obciążenie wyznacza detektor pojazdów: YOLOv8n na samym CPU Raspberry Pi 5 (TFLite INT8) potrzebuje ok. 180 ms na klatkę F42138, na NPU RK3588 (RKNN INT8) 17,3 ms F42607.

Dowody

• Frigate zapisuje ujęcie tablicy z chwili najwyższej oceny F35322 i ostrzega, że czas wnioskowania powyżej 100 ms pogarsza wyniki, gdy tablica szybko przecina kadr F35032; zużycie zasobów rośnie proporcjonalnie do detect fps F35031. To cechy implementacji Frigate, nie ograniczenia ARM.
• Plate Recognizer (deklaracje producenta): 70 ms na odczyt na i7-8550U i 110 ms na 4 rdzeniach Xeon E5-2680 v2 F40121, F40119; Stream obsługuje 1 kamerę 1080p na Raspberry Pi 4 GB F44301 i 2 kamery na i3-4100M F45288; zużycie CPU rośnie z liczbą pojazdów F44302.
• MOBOTIX (wg producenta): min. 95% przy spełnieniu wymagań sceny, 10 kl./s przetwarzanych, 80 ms na jeden pas F37878. DTK (wg producenta): 98%, 15–40 ms na klatkę na CPU F42031. ultimateALPR (wg producenta): 12 kl./s na Raspberry Pi 4, 64 kl./s na Khadas VIM3 F42860.
• NPU RK3588: YOLO26n INT8 41,2 ms (Ultralytics, Rock 5B) F47863; dwa strumienie YOLOv5s łącznie ok. 48 kl./s (wg producenta płyty) F43563.
• DHS opisuje tryb hybrydowy: dwie kamery i programowy wybór najlepszego obrazu F33166.

Warunki i rozbieżnościWyniki UFMG, SSIG i UFPR-ALPR pochodzą z tablic brazylijskich, a potok Pi 5 + Hailo-8 z tablic indyjskich F41679; nie przenoszą się wprost na tablice polskie. Wybór klatki wg pewności jest słaby, bo modele mylą się także z wysoką pewnością F35087. IPVM stwierdził, że kamery deklarujące 99% osiągały ok. 80% F41852 (cytat na stronie producenta oprogramowania). Brak danych w źródłach: wyboru klatek wg kąta tablicy z pomiarem skuteczności.

S02-Q2Wariant B: dwa substreamy kamery, niski do detekcji ruchu i pojazdu, wysoki (strumień główny) do OCR. Jak synchronizuje się oba strumienie (znaczniki czasu RTP, przesunięcie klatek), jakie błędy powstają, gdy klatki do siebie nie pasują, i jakie obciążenie dekodowaniem i CPU daje to przy dwóch kamerach?

OdpowiedźStrumień główny i substream to dwa niezależne kodowania, więc klatki paruje się po czasie bezwzględnym: raporty RTCP Sender Report wiążą znacznik RTP z zegarem ściennym, a kamery ONVIF zawsze je wysyłają F33808; w GStreamer robi to element rtponviftimestamp (ntp-offset albo reference timestamps) F32936, F32937. Najlepszy znaleziony pomiar parowania (rtsp-streamsync, 7 kamer, 15 Hz) daje maksymalny rozjazd 50,5 ± 15 ms, mniej niż jedna klatka (66,7 ms) F33810. Błąd ma postać przesunięcia ramki: d = v·Δt, więc przy 50,5 ms pojazd przesuwa się o 14 cm przy 10 km/h i o 42 cm przy 30 km/h, czyli o 27% i 81% szerokości tablicy (38 px i 113 px w obrazie 4 MP przy 269 px/m z F43518; obliczenia/s02.py, p. 2). Ramki z substreamu nie da się więc przenieść 1:1: trzeba poszerzyć wycinek o ten margines albo ponownie wykryć tablicę w klatce głównej. Pomiaru spadku skuteczności OCR przy rozjechanych klatkach brak w źródłach. Dekodowanie substreamów jest tanie: 2×704×576 przy 25 kl./s to 20,3 Mpx/s, a 2×1280×720 to 46,1 Mpx/s wobec 204,3 Mpx/s dla dwóch strumieni 4 MP (p. 4). Oszczędność istnieje tylko wtedy, gdy strumień główny nie jest dekodowany ciągle; Motion pokazuje taki układ: detekcja na substreamie, strumień główny kopiowany bez dekodowania F33982.

Dowody

• iDS-2CD7A46G0: strumień główny 2688×1520 przy 25 kl./s, substream maks. 704×576 F44271; wersja G2: substream do 1280×720 F47969; 5 strumieni, trzeci do 1920×1080 F44974. Kamery Hikvision kodują strumień główny i substream równocześnie F45788.
• Tablica o szerokości 140 px w 4 MP ma w substreamie 704×576 ok. 37 px, a w 1280×720 ok. 67 px (p. 3); Plate Recognizer czyta do 30 px i zawodzi przy 28 px F45339. Substream 704×576 ma inną proporcję niż obraz główny (skala X 3,82, Y 2,64), więc ramki przelicza się osobno dla każdej osi.
• Kamera, rejestrator i analityka mogą liczyć czas z różnych zegarów F32623; zaleca się wiązać czas zdarzenia z klatką źródłową i ustalić tolerancję dryfu F32624, F32625.
• rtsp-streamsync kompensuje początkowy rozjazd strumieni do 28,7 s F33810, a po przekroczeniu progu początkowego przerywa pracę F33812.
• Część firmware Reolink ma błędne znaczniki czasu RTSP, co powoduje gubienie klatek F34311; domyślny limit substreamu 1 Mb/s także gubi klatki, zalecane 2–3 Mb/s F34313.
• Dekoder przetwarza każdą klatkę strumienia niezależnie od kl./s analizy; niższe kl./s ustawia się w kamerze F33984. Na Raspberry Pi 5 praktycznym limitem MotionEye są 2 kamery 2560×1920 przy 20 kl./s F33981.
• Frigate uruchamia LPR na strumieniu z rolą detect F33016, a jego dokumentacja nie opisuje synchronizacji dwóch strumieni F33891; typowy układ to detekcja na substreamie z 5 kl./s i nagrywanie strumienia głównego F34310. Użytkownik z substreamem 640×360 zgłasza słabą detekcję ludzi i aut F33066.

Warunki i rozbieżnościPomiar 50,5 ms dotyczy siedmiu różnych kamer; dwa strumienie jednej kamery mają wspólne źródło obrazu, ale pomiaru ich rozjazdu brak w źródłach. Dekodowanie strumienia głównego tylko w oknie zdarzenia zaczyna się od klatki kluczowej; danych o interwale I-klatek i opóźnieniu startu dekodowania brak w ustaleniach tej sekcji. Brak danych w źródłach: zmierzonego obciążenia CPU całego wariantu B dla dwóch kamer na SBC; dostępna jest tylko przepustowość w Mpx/s.

S02-Q3Wariant C (hipoteza właściciela): jeden strumień 4 MP i dwie reprezentacje tych samych klatek: detekcja pojazdu na obrazie zmniejszonym do 640×360, lokalizacja tablicy w wycinku oryginalnej klatki 4 MP, OCR tylko na wycinku tablicy, najlepiej z kilku kolejnych klatek. Ile kosztuje ciągłe dekodowanie 4 MP na SBC (dekoder sprzętowy vs CPU) i ile skuteczności dają idealna synchronizacja i pełna rozdzielczość?

OdpowiedźZ dekoderem sprzętowym ciągłe dekodowanie 4 MP jest tanie: dwie kamery 2688×1520 przy 25 kl./s to 204,3 Mpx/s, czyli ok. 11% zmierzonej przepustowości VPU RK3588 (8K30 HEVC dekodowane z 55,8 kl./s ≈ 1851 Mpx/s F50262), a przy 15 kl./s 6,6% (obliczenia/s02.py, p. 4). Sprzętowe transkodowanie 4K HEVC na RK3588 zajmuje 3–8% jednego rdzenia przy 306 kl./s, programowe 727% CPU przy 39 kl./s F43343, F43348; stąd górna granica dekodowania programowego 2×4 MP przy 25 kl./s to ok. 4,6 rdzenia (p. 6). Raspberry Pi 5 nie ma sprzętowego dekodera H.264 F33979, dekoduje sprzętowo tylko H.265 F42370; liniowa ekstrapolacja z 10–20% CPU przy 1080p24 i 50–60% przy 1080p60 F33980 daje 41–99% CPU dla 2×4 MP przy 25 kl./s (p. 5). Pełna rozdzielczość zmienia warunki OCR zasadniczo: tablica, która w 4 MP ma 140 px F43518, w obrazie 640×360 ma 33 px, czyli tyle, ile wynosi granica odczytu Plate Recognizer (30 px, porażka przy 28 px F45339), wobec celu projektowego 100 px F38202. Bezpośredniego porównania skuteczności OCR na tych samych tablicach europejskich dla wycinka 4 MP i 720p brak w źródłach. Idealna synchronizacja usuwa margines 14–42 cm (10–30 km/h), który wariant B musi doliczyć do wycinka (p. 2).

Dowody

• Sprzętowe dekodowanie na RK3588 przez MPP wymaga jądra BSP 5.10 lub 6.1 F43349, F49158; w jądrze mainline dekoder VDPU381 działa jednordzeniowo, obsługa obu rdzeni jest w toku F50705, F43181.
• RGA skaluje i konwertuje format sprzętowo, osobno od VPU F43347, a ffmpeg-rockchip przekazuje klatki z dekodera do RGA bez kopiowania (zero-copy DMA) F49157; zmniejszenie 4 MP do 640×360 nie musi więc obciążać CPU.
• Jellyfin wycofał V4L2 na Raspberry Pi, bo wiele operacji spadało na CPU F40065. Na Raspberry Pi 5 dwie kamery 2560×1920 przy 20 kl./s (196,6 Mpx/s, 96% zapotrzebowania wariantu C) to praktyczny limit samego MotionEye F33981.
• MediaTek Genio 720 (pomiar Collabora w Chromium): H.264 sprzętowo 433 kl./s przy 34% CPU, programowo 235 kl./s przy 57% CPU F33793; Genio 700, 4K VP9: 18% wobec 90% CPU F33789. Na x86 dekodowanie odciążają Intel Quick Sync i AMD VCN F37151, bez liczb w ustaleniach.
• Rock 5B (RK3588) obsługuje 4 strumienie 1080p we Frigate z detekcją na NPU przy CPU poniżej 40% F42368; bez aktywnego chłodzenia dławi się termicznie F42372.
• Bufor zdekodowanych klatek NV12 (stride × stride × 3/2 F48978) zajmuje 6,13 MB na klatkę 4 MP; 2 s przy 25 kl./s dla 2 kamer to 613 MB (p. 7).
• Rozdzielczość tablicy decyduje o odczycie: WINK czyta poprawnie wycinki 80–150 px F34963, a na 2000 wycinków poniżej 100 px uzyskał 0,0% dokładnych odczytów niezależnie od super-rozdzielczości F34967; na tablicach brazylijskich pojedynczy wycinek niskiej rozdzielczości dał 2,2% F38774, a najlepszy zespół ICPR 2026 osiągnął 82,13% na ścieżkach z najdalszych klatek F34169; znak 8×16 px dał 100% odczytów, poniżej 5×10 px mniej niż 36,4% (tablice chińskie i włoskie) F36256.
• Dwuetapowość wariantu C ma uzasadnienie: wykrywanie tablic wprost na całym obrazie, bez etapu pojazdu, zawodziło dla dalekich pojazdów F39654; alternatywa, kafelkowanie 3×2, kosztuje ok. 7× więcej obliczeń F33118.

Warunki i rozbieżnościLiczby dla RK3576 dotyczą VP9, nie H.264/H.265. Wymóg obsługi H.265 4K przez SoC F37621 i brak awaryjnego przejścia na CPU przy akceleracji F37623 to cechy Frigate. Detekcja pojazdu na 640×360 bywa słaba w szerokiej scenie F33066; w kadrze jednego pasa pojazd zajmuje dużą część obrazu S. Przyrostu skuteczności z samej idealnej synchronizacji nikt nie zmierzył; brak danych w źródłach.

S02-Q4Wariant D (hipoteza właściciela): jeden pas, kamera skierowana na szlaban, wolne pojazdy: stały obszar zainteresowania (ROI) i rozpoznawanie uruchamiane sygnałem czujnika (pętla indukcyjna, radar, fotokomórka, wejście ze sterownika szlabanu) albo detekcją ruchu. Który wyzwalacz działa najlepiej, ile klatek i w jakim czasie po wyzwoleniu, oraz jak obsługuje się przypadki brzegowe: pojazd zatrzymany, kolejka, cofanie, pieszy, dwa pojazdy blisko siebie?

OdpowiedźBrak danych w źródłach: odsetka fałszywych i pominiętych wyzwoleń dla pętli, radaru, fotokomórki i detekcji ruchu przy szlabanie; wybór opiera się na właściwościach. Pętla indukcyjna jest wg producenta kamer najskuteczniejszym sprzętowym wyzwalaczem przy szlabanach F33322, reaguje w 20 ms F39340 i z założenia ignoruje ludzi F37960, ale bywa, że nie wykrywa motocykli i rowerów F40139 i niszczy się od wody i pękania nawierzchni F37957. Radar widzi pojazdy stojące i pieszych, odróżnia pojazd od pojedynczego pieszego i rozpoznaje kierunek (wg producenta) F37959, F39153, F37955. Detekcja ruchu nie wymaga sprzętu, ale w nocy trzeba wyłączyć improve_contrast i podnieść contour_area do 50–90 dla obrazu 1920×1080, żeby drobne zmiany nie uruchamiały detektora F43735, F35784. Liczba klatek: n = ⌊L/(v/3,6)·fps⌋; przy 10 km/h na odcinku 4 m to 21 klatek przy 15 kl./s, przy 30 km/h 7 klatek przy 15 kl./s i 12 przy 25 kl./s, a przy 5 kl./s (domyślnie we Frigate F33881) i 30 km/h na 2 m zostaje 1 klatka (obliczenia/s02.py, p. 1). Podniesienie ramienia trwa 1,5–4 s F32827, więc OCR 10–20 wycinków (29–424 ms na CPU, p. 9) mieści się w czasie, w którym pojazd i tak czeka.

Dowody

• Pętlę wyzwalającą umieszcza się w strefie najazdu przed szlabanem, a antyzgnieceniową pod ramieniem lub za nim; łączenie obu funkcji w jednej pętli zwykle działa źle F39646, F39648.
• Płyty sterujące szlabanów mają zaciski pętli i fotokomórki F37600, a kamery LPR mają wejścia alarmowe (2 wejścia, 2 wyjścia) F41646; Avigilon uruchamia rejestrację pętlą, fotokomórką, szlabanem albo detekcją ruchu F33181. Kamera Vidar zastępuje pętlę laserami punktowymi (wg producenta) F33324.
• System wyzwalany wykonuje jedno lub kilka zdjęć w chwili sygnału F33167; Frigate w trybie dedykowanym wymaga 2 klatek inicjalizacji F33882.
• Opóźnienia: pełny cykl poniżej 100 ms (wg producenta) F39850; ok. 250 ms przy pasie F44929; otwarcie poniżej 0,5 s wobec typowych 97–98% przy ok. 1 s (wg producenta) F37453.

Warunki i rozbieżnościPętla wyzwalająca stoi przed szlabanem, więc część najlepszych klatek powstaje przed sygnałem; bufor 1–2 s przed wyzwoleniem kosztuje 153–613 MB dla 2 kamer (p. 7) S. Dane o fotokomórkach pochodzą z systemów kontroli wysokości pojazdów, nie z parkingów. Sama detekcja ruchu bez czujnika daje najmniej klatek przy nocnej konfiguracji i przy przejeździe 30 km/h z niskim kl./s.

S02-Q5Jakie połączenia tych wariantów oraz jakie śledzenie i głosowanie z wielu klatek w obrębie śladu pojazdu stosują komercyjne i otwarte systemy LPR przy szlabanach i w jakich warunkach wygrywa każdy wariant?

OdpowiedźSystemy łączą A ze śledzeniem i wieloma klatkami (Plate Recognizer Stream przetwarza wiele klatek na przejazd F34476; Frigate w trybie zwykłym najpierw wykrywa pojazd F35034) albo D ze stałą strefą i wyzwalaczem (Frigate w trybie dedykowanym uruchamia detektor tablic na całej klatce przy ruchu F33604; strefy: Detection Zone F34111, do 3 stref w MOBOTIX F39966, obszar lub linia pasa w Hikvision F48998). Głosowanie w śladzie stosują systemy z najlepszymi wynikami: WINK uzyskał 92,0% z głosowania tekstem, 79,5% z najlepszego wycinka i 77,4% z fuzji obrazów F48479, a system jako całość 98,6% (wg producenta) F49186. Przy fuzji wielu modeli na tym samym obrazie głosowanie całym ciągiem wygrywa z głosowaniem po znakach i z wyborem najpewniejszego wyniku F33591, a wybór najpewniejszego przegrywa, bo modele mylą się z wysoką pewnością F35087. Przy fuzji klatek źródła stosują głosowanie po pozycjach znaków (85,45% → 93,53% F45418) i sumę logitów (zwycięzca ICPR 2026 F37050); porównania obu reguł na klatkach jednego śladu brak w źródłach. Głosowanie ma granicę: wszystkie pozostałe błędy Geo-CTM to pozycje, w których żadna klatka śladu nie zawierała poprawnego znaku F42543, a pomiary leżą daleko pod granicą dla niezależnych klatek (79,5% i 15 wycinków: 99,50% teoretycznie, 92,0% zmierzone; obliczenia/s02.py, p. 8).

Dowody

• Plate Recognizer rozdziela Snapshot dla pojazdów stojących i Stream dla jadących F34477; eFPS = kl./s kamery / sample F44300; 4–5 eFPS poniżej 30 mph F34584.
• Frigate (licencja MIT F47249): najpewniejszy wynik w śladzie F33583, regex formatu i minimalna długość tablicy F33886, match_distance do porównania ze znanymi tablicami F48004.
• DTK przekazuje każdą klatkę osobno (PutFrame) F42033, podaje pewność dla każdego znaku i całej tablicy F42034. Milesight używa dwóch sensorów (ANPR i przegląd) oraz klatek parzystych i nieparzystych z różnym czasem ekspozycji F50849, F50851.
• UFMG grupuje klatki pojazdu filtrem Kalmana i głosuje F50933, F51201; Laroca 2018 głosuje po pozycjach znaków F47643; RoadSentinel (GPL-3.0 F48913) wybiera najczęstszą długość, potem głosuje po pozycjach F48005; system rumuński łączy głosowanie ważone pewnością z regexem formatu F45178.
• ICPR 2026 (tablice brazylijskie, niska rozdzielczość): 1. miejsce sumuje logity pięciu klatek F37050, 2. waży klatki oceną jakości F37051, 3. głosuje po znakach, remisy rozstrzyga pewnością F37047; 5 klatek zamiast 1 daje +28 pp dokładności znaków (CRNN 44,14% → 72,17%) F48012.
• Geo-CTM (MIT F44578): zmiana trackera przesuwa wynik o 1–2 pp, nieistotnie F45929; ważenie jakością i dekodowanie ograniczone formatem nie dały istotnej poprawy F44574.
• WINK podniósł skuteczność z 95% do 98,6% przez wzrost liczby etykiet z 3000 do 18 000 F34964.

Warunki i rozbieżnościPrzewaga głosowania całym ciągiem dotyczy fuzji modeli, nie klatek. Żadne źródło sekcji nie pokazuje 99% na tablicach europejskich dla otwartego systemu na SBC; 98–99,5% to deklaracje producentów F41645, F42031, F50913, a Plate Recognizer pisze, że 99% osiąga się tylko w laboratorium F43415.

Rekomendacja: jeden pas ze szlabanem

Wybór: połączenie D + C ze śledzeniem i głosowaniem; z wariantu A zostaje tylko logika śladu pojazdu.

1. Wyzwalacz: sygnał obecności z pętli przez wejście sterownika szlabanu F37600 albo radar F37959 otwiera okno zdarzenia; detekcja pojazdu w obrazie działa jako drugi kanał na wypadek motocykla lub awarii pętli F40139, F37957.
2. Dekodowanie: ciągłe, sprzętowe, strumień główny 4 MP przy 12–15 kl./s, gdy pojazdy zwalniają przed szlabanem, i 25 kl./s, gdy przejeżdżają do 30 km/h bez zatrzymania; obciążenie VPU RK3588 5,3–11% przy H.265 (p. 4) F50262.
3. Reprezentacje: RGA zmniejsza stałą strefę do 640×360 dla detekcji pojazdu na NPU F49157, tablicę lokalizuje się w wycinku 4 MP, OCR dostaje wycinek ≥100 px F38202.
4. Bufor 1–2 s klatek sprzed wyzwolenia (153–613 MB dla 2 kamer, p. 7) S.
5. Śledzenie IoU/SORT F41671 i 10–20 wycinków na pojazd: przy 30 km/h wymaga to 25 kl./s i odcinka co najmniej 4 m (12 klatek) albo 8 m (24 klatki) (p. 1); przy 4–7 wycinkach WINK uzyskał 85,1%, przy 15–20 92,0% F48480, F48479.
6. Głosowanie S: najpierw cały ciąg po walidacji formatu tablic PL/UE, przy braku większości głos po pozycjach znaków po wyrównaniu długości F48005, pewność tylko do rozstrzygania remisów F35087; OCR przyrostowo, decyzja po ostatnim wycinku.

Warunki: SoC musi dekodować sprzętowo kodek kamery na używanym jądrze (RK3588 z jądrem BSP 5.10/6.1 i MPP F43349). Bez tego (Raspberry Pi 5 z kamerą H.264, RK3576 na mainline) właściwy jest wariant B: detekcja na substreamie 1280×720, strumień główny dekodowany tylko w oknie zdarzenia, wycinek poszerzony o v·Δt (14 cm przy 10 km/h, 42 cm przy 30 km/h) i ponowna detekcja tablicy w klatce głównej. Cel 99% zależy bardziej od jakości pojedynczego wycinka i danych uczących niż od architektury: głosowanie podniosło 79,5% do 92,0% F48479, a WINK doszedł do 98,6% dopiero przez wzrost liczby etykiet F34964.

Założenia S i obliczenia

• Obliczenia: data/jobs/lpr-cpu-sbc/decyzja/obliczenia/s02.py, wynik s02.out (punkty 1–10 przywołane w tekście).
• Odcinek czytelności L = 1, 2, 4, 8 m i kl./s 5/12/15/25 to parametry, nie pomiary; wzór n = ⌊L/(v/3,6)·fps⌋.
• Skala 269 px/m pochodzi z jednego przykładu (4 MP, obiektyw 12 mm, 10 m, 140 px na tablicy 520 mm) F43518; przy innej geometrii przesunięcia w pikselach skalują się proporcjonalnie.
• Przepustowość dekoderów przeliczona liniowo na Mpx/s; dane RK3576 dotyczą VP9, a deklaracje producenta płyt RK3588 nie są pomiarem.
• CPU Raspberry Pi 5: liniowa ekstrapolacja z F33980; źródło nie mówi, czy procent dotyczy jednego rdzenia czy całego CPU.
• Górna granica ok. 4,6 rdzenia dla programowego dekodowania na RK3588 pochodzi z transkodowania, które zawiera też kodowanie 540p F43348.
• Granica głosowania: model niezależnych klatek, większość ścisła, n nieparzyste (15, 5, 29, 19); służy tylko do pokazania korelacji błędów.
• Czasy OCR pochodzą z platform innych niż docelowy SBC (Mac M1, nieokreślony CPU PaddleOCR, Hailo-8); 50 ms na wycinek w F41678 wyliczone z 22,5 s / 450 wycinków, platforma niepodana.
• Start dekodowania strumienia głównego od klatki kluczowej w wariancie B, bufor klatek przed wyzwoleniem, użycie RGA do zmniejszania strefy i reguła głosowania „ciąg, potem znaki” to wnioski projektowe analityka, nie pomiary.

Część 3Dane treningowe dla Polski i Europy

S03-Q1Które publiczne zbiory danych zawierają polskie tablice rejestracyjne i skąd je pobrać: liczba zdjęć i tablic, warunki (kąty, dzień i noc), typ adnotacji, licencja na użytek komercyjny?

OdpowiedźBezpłatne polskie dane są małe. Jedyny opisany w literaturze polski zbiór uczący liczy 1 000 zdjęć (800 do treningu, 200 do walidacji) i pochodzi z serwisu społecznościowego, który publicznie udostępnia najwyżej 1 000 zdjęć na kraj F41384F41385. Zbiór z Katowic na Kaggle nie podaje liczby zdjęć i ma licencję „Other (specified in description)” F35960F32420. Parking Database to 22 nagrania z kamer parkingowych z adnotacjami, udostępnione społeczności naukowej F36613. Duże polskie zbiory są komercyjne: Unidata sprzedaje 83 793 zdjęć polskich tablic F35265, a jej zbiór wielokrajowy zawiera 220 474 zdjęć z Polski, czyli 5,79% całości F40506. Na Hugging Face i Kaggle jest tylko podgląd, a pełny zbiór dostawca wycenia indywidualnie F32436F41628. W ustaleniach żaden bezpłatny polski zbiór nie ma licencji, która wprost dopuszcza zamknięty produkt komercyjny. Bez zakupu z publicznych źródeł da się zebrać około 1 000 opisanych zdjęć, zbiór katowicki o nieznanej liczności i 22 nagrania testowe.

Dowody

• Békési i Ekler wytrenowali model CNN-RNN na 800 polskich zdjęciach: 87,3% dokładności całej tablicy i 95,8% normED F36615. Według autorów polskiemu LPR nie poświęcono dotąd dużej analizy ilościowej F36616.
• Serwis źródłowy to platforma, na którą użytkownicy wgrywają zdjęcia tablic; według autorów nie łączy tablic z danymi właścicieli F36610.
• Twórcy zbioru katowickiego zakryli twarze czarnymi kołami F32419.
• Starsze polskie prace osiągały 60–70% rozpoznań F33092. System Kekeza, trenowany na danych wyprowadzonych z przepisów, deklaruje ponad 98% rozpoznań F33096, a ta sama praca przeglądowa podaje dla niego 88,7% dokładności znaków F42294.

Warunki i rozbieżnościLicencja UniData jest niejednoznaczna: README podaje cc-by-nd-4.0 F44068, strona zbioru nie podaje licencji F32445, a pełny zbiór wymaga zakupu F32448. CC BY-ND 4.0 pozwala rozpowszechniać materiał także komercyjnie, ale zabrania rozpowszechniania wersji zmienionej F45728F45729. Metadane podają rozmiar 100K–1M F44069, opis 83 700+ zdjęć F32432. Liczba polskich zdjęć w GLPD (ponad 5 mln zdjęć z 74 krajów) nie występuje w ustaleniach F36065.

S03-Q2Które publiczne zbiory obejmują tablice europejskie (kraje, liczba zdjęć i tablic, kąty, dzień i noc, tablice dwurzędowe, adnotacje, licencja, adres pobrania)?

OdpowiedźNajwiększe otwarte zbiory europejskie z opisanymi warunkami to TLPD i UC3M-LP. TLPD ma ponad 17 000 zdjęć i 18 000 tablic z UE, wykonanych z różnych kątów i odległości, przy różnym oświetleniu i pogodzie F40144F40145; licencji i adresu pobrania ustalenia nie podają. UC3M-LP (Hiszpania) ma 1 975 zdjęć i 2 547 tablic, z czego 362 (14,2%) sfotografowano nocą, a 31 (1,22%) to tablice dwurzędowe F32772F32775F32774. Zbiór leży na GitHubie i Zenodo bez podanej licencji F32661F38160F33340. Pozostałe otwarte zbiory mają 108–706 zdjęć F37350F40692F36072. GLPD ma ponad 5 mln zdjęć z 74 krajów z serwisu Platesmania, którego regulamin pozwala kopiować dane z obowiązkowym linkiem F36065F36066. Dane z całej Europy sprzedają Unidata (2 434 844 zdjęć) i Pangeanic F40509F38785.

Dowody

• Dwie sieci detekcji tablic trenowane na TLPD osiągnęły precyzję i czułość 93% w dzień i w nocy oraz 87% przy intensywnym śniegu F40146.
• Na zbiorach Békésiego i Eklera (po 800 zdjęć do treningu) dokładność tablicy wyniosła: HU 95,0%, CZ 89,9%, PL 87,3%, SK 84,1% F41391.
• System Laroki i in. osiągnął 97,8% na OpenALPR-EU F48576; według innej pracy wyniki na 108 zdjęciach łatwo podbić regułami F41440.
• Ramowy system wizja–język podnosi dokładność dokładnego dopasowania na UC3M-LP z 45,2% do 88,3% F33390.
• Mniejsze zbiory: LPALIC zawiera wycinki znaków z ośmiu krajów UE bez Polski F41923; belgijski zbiór na Kaggle ma ponad 400 zdjęć z plikami XML F38949; 0xnu/european-licence-plate nie ma pola kraju i jest objęty klauzulą „All Rights Reserved” F38913F38910.

Warunki i rozbieżnościTablice dwurzędowe są w otwartych zbiorach rzadkie: UC3M-LP ma ich 31 F32774, a w porównaniu ośmiu zbiorów miały je tylko zbiory z Brazylii i Chorwacji F39016. Zbiory z USA i Europy (UCSD, OpenALPR) są proste: aparat ręczny i jeden wyśrodkowany pojazd F34575. Większość publicznych zbiorów ma 2 000–5 000 zdjęć lub klatek, co utrudnia ocenę na rozmyciu ruchu F34578. Liczba zdjęć EnglishLP różni się między źródłami (509 F40692 i 500 F34621). Repozytorium podziałów GLPD nie ma opisu F43727. Dane Unidata i Pangeanic to deklaracje sprzedawców.

S03-Q3Jak generuje się syntetyczne obrazy tablic do treningu (polskie formaty i kroje, perspektywa, brud, rozmycie ruchu, nocne IR) i o ile poprawiają skuteczność w porównaniu z samymi danymi rzeczywistymi?

OdpowiedźAutorzy prac stosują cztery metody: szablon tablicy z losowym ciągiem znaków i losową perspektywą, szumem, cieniami, odcieniem, nasyceniem i jasnością F36108; permutację znaków na prawdziwych tablicach F47423; sieci GAN (CycleGAN, CycleWGAN) F35879; render 3D w Unreal Engine lub Blenderze dla skrajnych kątów i oświetlenia F35847F34148. Zysk jest duży przy małej liczbie zdjęć rzeczywistych. Na chińskim Dataset-1 sama synteza daje 42,2–64,5% F38001. Model z 4 750 prawdziwymi tablicami, augmentacją i GAN osiąga 99,0%, a model na 50 000 prawdziwych tablic 96,7% F38005F38004, czyli ma 3,3 razy mniejszy błąd (sekcja K). Dla tablic malezyjskich synteza dodana do danych rzeczywistych dała +12,1% F35254. Wyniki z Chin i Malezji nie przenoszą się wprost na tablice polskie. W ustaleniach brak pomiaru zysku z syntezy dla tablic polskich lub europejskich i z symulacji nocnego IR.

Dowody

• Polskie kroje z przepisów: na tablicach samochodowych znaki mają 80 mm wysokości, litery do 47 mm i cyfry do 43 mm szerokości, pokrycie barwne 9 mm F38418; na motocyklowych 45 mm wysokości F38419. Do 30 czerwca 2018 r. obowiązywał szerszy krój (litery do 54 mm), a tablice z nim wydawano do wyczerpania zapasów F38420F38421.
• Tablice dwurzędowe: 305 × 214 mm (samochody i przyczepy), 190 × 150 mm (motocykle), 140 × 114 mm (motorowery) F38417; w górnym rzędzie wyróżnik miejsca, w dolnym wyróżnik pojazdu, poza tablicami dyplomatycznymi F38422.
• W wyróżniku pojazdu nie występują litery B, D, I, O, Z F32516. Tło jasnozielone mają pojazdy elektryczne i wodorowe od 2020 r. F32520, zielone znaki tablice profesjonalne F32519, żółte tło tablice zabytkowe F32522, czerwone znaki tablice tymczasowe F32523.
• Krój „Tablica Rejestracyjna” powstał według Dz.U. 2014 poz. 1522; wariant „Round” naśladuje zaokrąglenie przy wytłaczaniu, a każdy znak ma wersję normalną i wąską F32820F32821F32822.
• Parametry augmentacji u Laroki i in.: jasność [0,85; 1,15], obrót ±5°, przycięcie od −2% do 8%, permutacja znaków, negatyw F44057F37348, bez odbicia poziomego F39018. Inna praca stosuje rozmycie ruchu, nierówne oświetlenie, erozję, dylatację, zmniejszanie rozdzielczości i szum gaussowski F35880.
• Békési i Ekler symulowali biblioteką Albumentations mgłę, deszcz, cień, śnieg i odblask słońca tylko na zbiorze walidacyjnym F42274F46572; polski model spadł do 73,49% w deszczu, 44,58% w śniegu i 45,78% przy odblasku F47087F48671.
• Laroca i in. (2025) porównali 16 modeli OCR na 12 zbiorach i trzy metody syntezy; masowa synteza wyraźnie poprawia wyniki w jednym zbiorze i między zbiorami F39810F39811. Liczb z tej pracy ustalenia nie podają.
• W klasycznej detekcji dodanie zdjęć przy słabym oświetleniu podniosło skuteczność do 29%, a zdjęć z deszczem, śniegiem lub mgłą nie poprawiło detekcji w tych warunkach F35056F35057.

Warunki i rozbieżnościWedług autorów GLPD sama synteza słabo uogólnia się na prawdziwe tablice F36470, a obrazy z szablonów mają inny rozkład niż zdjęcia F39817. Praca cytowana w 2202.05631 twierdzi przeciwnie: CNN trenowana na syntezie przewyższyła CNN trenowaną na zdjęciach F41821. GAN-y są podatne na mode collapse i gorzej oddają drobną strukturę znaków F35389. Metoda GSS przy dużym kącie działa nieco gorzej niż LPRNet, a trening trwa 3 h zamiast 0,75 h F39564F39566. Źródło malezyjskie nie precyzuje, czy +12,1% to punkty procentowe F35254. Tablice ze starym krojem nadal jeżdżą, więc generator powinien obejmować oba kroje S.

S03-Q4Które duże zbiory z innych regionów (UFPR-ALPR, RodoSol-ALPR, CCPD, AOLP i inne) przydają się do pretreningu i co badania mówią o stronniczości zbiorów (dataset bias) i niemal-duplikatach (near-duplicates) przy pomiarze skuteczności?

OdpowiedźDo pretreningu nadają się przede wszystkim CCPD (366 789 zdjęć, licencja MIT) i RodoSol-ALPR (20 000 zdjęć, dzień i noc, dwurzędowe tablice motocyklowe, tylko do badań niekomercyjnych) F33922F33211F40591F40594. AOLP i UFPR-ALPR mają 2 049 i 4 500 zdjęć F33919F33534. W ustaleniach brak pomiaru pretreningu na CCPD lub AOLP z dostrojeniem do tablic polskich lub europejskich. Jedyny zmierzony transfer dla Polski pochodzi z tablic sąsiednich: pretrening na tablicach czeskich dał 89,2% wobec 87,3% (+1,9 pp, błąd mniejszy o 15%) F45455F50494, a dłuższy trening tylko na polskich danych 87,2% F37842. Płytka sieć rozpoznaje zbiór źródłowy zdjęcia z dokładnością 95,2–95,9% przy losowym poziomie 25% F36210. W protokole „leave-one-dataset-out” średnia skuteczność spada z 82,4% do 74,5%, a na AOLP z 90,8% do 62,7% F44416. Po usunięciu niemal-duplikatów błąd na AOLP rośnie ponad dwukrotnie, a ranking modeli się zmienia F36638F33925. Wyniki z Chin, Tajwanu i Brazylii nie przenoszą się wprost na tablice polskie.

Dowody

• Na CCPD średnia sześciu modeli spada z 80,3% do 77,6% po usunięciu duplikatów (STAR-Net −5,20 pp, TRBA −4,35 pp) F36848; luka 1,17–5,2 pp to od ponad 1 800 do ponad 8 000 dodatkowo błędnych tablic F37123.
• Na AOLP-A błąd modelu CNNG rośnie z 1,12% do 4,37% (3,9 razy), na AOLP-B z 1,09% do 3,20% (2,9 razy) F36631F37118; obliczenia, sekcja G.
• Główną przyczyną stronniczości są kamery, drugą kompresja zapisu F36461; zbiory z kamer statycznych mają najsilniejszą sygnaturę F36211.
• Zasady przydziału tablic powodują nierównowagę znaków: w SSIG-SegPlate jest 746 liter „O” i 135 liter „Q” F34160, a model trenowany tylko na RodoSol może zawsze czytać „P” jako pierwszą literę F46482. Permutacja znaków łagodzi ten efekt F34945.
• Według autorów GLPD wiele zbiorów jest „nasyconych” powyżej 99,5% m.in. przez przecieki tych samych numerów między podziałami F36070; GLPD grupuje numery o NED ≥ 0,9 w tym samym podziale F39296.
• Duplikaty wykrywa się odległością euklidesową pikseli wyprostowanych wycinków po filtrze tekstu tablicy F39469, hashem percepcyjnym z LSH F44432 albo rozdziałem zbiorów po numerze tablicy F35819.
• Transfer CZ/HU/SK → PL obniżył błąd normED o 28–38% F46574, ale nie każdy model z transferem był lepszy od modelu polskiego w każdej symulowanej pogodzie F39925.
• Na RodoSol-ALPR żaden model ani system komercyjny nie przekroczył 70%; OpenALPR odczytał 94,3% samochodów i 1 827 z 4 000 motocykli F41288F42408.

Warunki i rozbieżnościLiczność CCPD różni się między wersjami: 250 tys. w 2018 r., ponad 300 tys. w 2019 r., 366 789 obecnie F41611; GLPD podaje 290 tys. i 350 tys. F36466F36467. AOLP ma w źródłach 2 049 albo 1 874 zdjęć F33919F36071. Część badań pominęła CCPD z powodu kompresji i błędów narożników F43433. Polskie tablice kodują w wyróżniku województwo i powiat F49699, więc zbiór z jednego obiektu zdominują lokalne wyróżniki, podobnie jak „P” w RodoSol F46482 S. Wiarygodność pomiaru 99% zależy od liczby niezależnych prób: 22 poprawne sekwencje z 22 F38502 potwierdzają z 95% pewnością tylko ≥87,3%, a wykazanie ≥99% bez błędu wymaga 299 przejazdów (sekcja E) S.

S03-Q5Jak firmy zbierają i opisują własne dane LPR z zainstalowanych kamer (automatyczne etykietowanie, aktywne uczenie, poprawki operatorów) i ile zdjęć potrzeba, by osiągnąć docelową skuteczność dla nowego kraju lub układu tablicy?

OdpowiedźProducenci opisują zamknięty obieg: błędne odczyty z instalacji trafiają do inżynierów, a nowa wersja modelu wychodzi co 3–6 tygodni. Plate Recognizer według producenta analizuje dla klientów strategicznych konkretne błędne obrazy i w 3–6 tygodni wydaje ukierunkowaną wersję beta F39744F34415. Frigate+ wymaga do dostrojenia detektora co najmniej 100 zweryfikowanych zdjęć na kamerę, w proporcji 80% trafnych i 20% fałszywych detekcji, z dni pochmurnych, słonecznych, świtu, zmierzchu i nocy F41771; dla 2 kamer to co najmniej 200 zdjęć S. Raport DHS opisuje regularny przegląd odczytów przez operatorów jako źródło danych do douczania F36794. Automatyczne etykietowanie ma dwie opisane formy: zespół półnadzorowanych detektorów z wielokrotną ręczną weryfikacją (GLPD) F39571 oraz pseudo-etykiety przyjmowane, gdy każdy znak ma pewność ≥0,90 F35393. Modele CTC i z atencją potrzebują tylko tekstu całej tablicy, bez ramek znaków F35727. W ustaleniach brak liczby zdjęć potrzebnej do 99% dla tablic polskich. Najbliższe dane: 800 polskich zdjęć daje 87,3–89,2% dokładności tablicy F45455, Laroca i in. przyjęli co najmniej 500 zdjęć na region F36081, a w Chinach 4 750 prawdziwych tablic z syntezą dało 99,0% F38005, co nie przenosi się wprost na Polskę.

Dowody

• Plate Recognizer według producenta trenuje na milionach zdjęć F39529 i dostraja silnik do kąta kamery lub oświetlenia, m.in. dla Niemiec F41555; według tego samego producenta Hikvision i Hanwha aktualizują modele co 12–18 miesięcy F39746.
• Frigate+ trenuje tylko na zdjęciach ze zweryfikowaną etykietą F41776 i obejmuje 12 treningów rocznie F41774; etykieta license_plate dotyczy detekcji, bez formatów krajowych F41775.
• Ręczne odrzucanie lub zatwierdzanie odczytów po wdrożeniu zwiększa skuteczność F36792; krótki czas przechowywania danych ogranicza ich użycie do douczania F35372.
• Laroca i in. ręcznie opisali 38 351 ramek na 6 239 zdjęciach F38115; jeden model na ośmiu zbiorach osiągnął średnio 96,9% i wyprzedził Sighthound o 9,1 pp, a OpenALPR o 6,2 pp F37097.
• LPLC opisała ręcznie jedna osoba w VIA, a wynik sprawdzono modelem PARSeq-tiny F42199; użytkownicy Platesmania wpisują tekst tablicy przy wgrywaniu zdjęcia F33482.
• PARSeq dostrojony na ok. 3 mln zdjęć z 74 krajów osiąga 87,93% dokładności całej tablicy F39575.
• NVIDIA trenowała detektor tablic na ponad 45 000 zdjęć aut z USA F37405; według producenta model wstępnie wytrenowany osiąga cel szybciej i na mniejszym zbiorze F35985.
• Na danych chińskich 300 prawdziwych tablic z augmentacją i GAN daje według autorów efekt 200 000 prawdziwych tablic F38005.
• Polski model na wideo ma 86,4% na klatkę, a głosowanie większościowe w 22 sekwencjach dało 100% F50984F38502. Przy p = 0,864 większość z 9 niezależnych klatek jest poprawna z prawdopodobieństwem 99,6% (sekcja D) S.

Warunki i rozbieżnościCykl 3–6 tygodni i „miliony zdjęć” to deklaracje producentów. Ogólne dane o automatycznym etykietowaniu, niezwiązane z LPR (pokrycie 70–85%, czas opisu krótszy o ponad 60%), pochodzą z tekstu na LinkedIn o niskiej pewności F35551F35554. W ustaleniach brak danych liczbowych o aktywnym uczeniu w LPR. Według producenta próba w lipcu może dać 99%, a ten sam system w grudniu napotyka śnieg, sól i niski kontrast F39748. Autorzy podają wynik wideo ok. 1,8% niższy niż na zdjęciach F50985; względem najlepszego wyniku na zdjęciach (89,2%) różnica wynosi 2,8 pp (sekcja C). Pomiar 99% jest wiarygodny tylko na zbiorze testowym bez tablic ze zbioru treningowego F35819F39296; na parkingu ze stałymi użytkownikami te same tablice wracają wielokrotnie S.

Założenia S i obliczenia

Skrypt data/jobs/lpr-cpu-sbc/decyzja/obliczenia/s03.py, wynik w s03.out.

• UC3M-LP: noc 362/2 547 = 14,2%, dwurzędowe 31/2 547 = 1,22% (sekcja A). Udział Polski w zbiorze Unidata: 220 474 / 3 809 704 = 5,79%; w Europie 9,05% (sekcja B).
• Zysk z transferu: Δ = acc_transfer − 87,3; zmiana błędu = (e1 − e0)/e0; CZ → PL: +1,9 pp, −15,0% (sekcja C).
• S Klatki wideo są niezależne: P(większość poprawna) = P(X ≥ ⌊n/2⌋+1), X ~ Bin(n; 0,864); n = 3 → 95,0%, n = 5 → 98,0%, n = 9 → 99,6%. Klatki z jednego przejazdu są skorelowane, więc to oszacowanie optymistyczne (sekcja D).
• S Przejazdy testowe są niezależne: dolna granica 95% przy k/k poprawnych = 0,05^(1/k), dla 22/22 → 87,3%; liczba przejazdów bez błędu dla celu q: n ≥ ln 0,05 / ln q; q = 0,99 → 299, q = 0,995 → 598 (sekcja E).
• Krotność wzrostu błędu po usunięciu duplikatów: e_fair / e_orig; dla CCPD przyjęto 157 000 zdjęć testowych F42549 (sekcje F i G).
• Rozbieżność u Laroki i in.: 257 + 341 + 174 = 772 F36081, a 257 + 347 + 178 = 782 przy deklarowanych 772 F41439 (sekcja I).
• Dataset-1: błąd 3,3% (50 000 prawdziwych) wobec 1,0% (4 750 + synteza) → 3,3 razy (sekcja K).
• S 2 kamery na obiekt z briefu; Frigate+: 2 × 100 = 200 zdjęć, 160 trafnych i 40 fałszywych (sekcja L).
• S Lokalne wyróżniki powiatowe dominują w danych z jednego obiektu (wniosek z mechanizmu opisanego dla RodoSol i SSIG, bez pomiaru dla Polski).
• S Tablice ze starszym, szerszym krojem pozostają w ruchu po 2018 r.
• S Na parkingu ze stałymi użytkownikami te same tablice wracają wielokrotnie i tworzą niemal-duplikaty we własnych danych.

Część 4Kamery CCTV do analityki na własnym SBC

S04-Q1Które parametry zwykłej kamery CCTV decydują o skuteczności LPR: liczba pikseli na szerokości tablicy lub na znak, wielkość matrycy, ogniskowa i obiektyw zmiennoogniskowy, czas migawki dla jadących pojazdów, WDR lub BLC wobec reflektorów, oświetlenie IR i długość jego fali dla tablic odblaskowych, kodek, bitrate i odstęp klatek I? Jakie wartości zalecają poradniki producentów LPR?

OdpowiedźO skuteczności decydują w tej kolejności: liczba pikseli na tablicy, czas migawki dobrany do prędkości i kąta najazdu, ręczne sterowanie ekspozycją w nocy (stała migawka, ograniczone wzmocnienie, IR przy kamerze) oraz kąt patrzenia; kodek ma znaczenie drugorzędne. Zgodny rdzeń zaleceń to 100–150 px na szerokości tablicy europejskiej (minimum fizyczne 74 px wg Axis) F33409F33930, ponad 130 px u Milesight i Axis LPV F33203F51162 oraz 20–30 px na wysokości znaku F42234F47058. Dla wjazdu start-stop Bosch i Axis zalecają stałą migawkę 1/500 s F34377F33412, a instrukcja ANPR Hikvision nocą 1/1000–4/1000 s F40822. Plate Recognizer każe wyłączyć AGC, DNR, autofokus i BLC F35678; co do WDR źródła są sprzeczne (q3). Standardem IR jest 850 nm F50095, a 740 nm to opcja Milesight dla tablic o niskim kontraście F34542. Wartości bitrate i odstępu klatek I dla LPR — brak danych w poradnikach producentów; istnieją tylko zalecenia Frigate (odstęp klatek I równy liczbie klatek na sekundę, stały bitrate) F48645.

Dowody

• Axis wyprowadza minimum 74 px z warunku dwóch pikseli na najmniejszy element znaku F34010. Commonlands zaznacza, że piksele na znak liczy się z wysokości kadru i wysokości znaku, a dzielenie szerokości tablicy przez liczbę znaków daje inną miarę F42230.
• Rozmycie powstaje tylko przy ruchu poprzecznym: pojazd jadący prosto na kamerę jedynie rośnie w kadrze, a przy kącie między osią kamery a kierunkiem jazdy zwykła migawka 1/30 s rozmywa tablicę F36628. Kryterium 14 mm dopuszczalnego rozmycia F37865 odtwarza w skrypcie tabelę Axis co do wartości (30 km/h: 19,3 ms przy 5°, 3,4 ms przy 30°).
• Migawka 1/500 s skraca zasięg IR zwykłej kamery Axis o ok. 50% względem nastaw domyślnych z maks. 1/30 s F33412; montaż pod kątem 5° zamiast 20° pozwala wydłużyć migawkę ok. 4-krotnie i podwaja zasięg IR F35114.
• Matryca i obiektyw: według Frigate większa matryca daje więcej niż wyższa rozdzielczość, zwłaszcza nocą F42302. Dedykowane kamery LPR mają matryce 1/1,8″ F36740F49210, a zwykły Hikvision DS-2CD2043G2-I matrycę 1/3″ F43099. Bosch wymaga od obiektywu wystarczającego MTF poza środkiem kadru i małej dystorsji F34381. Plate Recognizer stwierdza, że 4 MP z obiektywem 6 mm daje znacznie więcej pikseli na tablicy niż ta sama kamera z 2,8 mm, a dobór ogniskowej jest równie ważny jak rozdzielczość F41864.
• Kodek: H.265 zmniejsza bitrate o 35–50% przy tej samej jakości kosztem większej złożoności obliczeniowej F49736F49737. Po włączeniu H.265+ w kamerze Hikvision jakości obrazu i odstępu klatek I nie da się ustawić F44825. Silna kompresja i niski bitrate rozmazują znaki nocą F33511. Każdą klatkę P dekoduje się od ostatniej klatki I, więc odbiór 5 kl./s ze strumienia 20 kl./s z GOP 20 wymaga dekodowania pełnych 20 kl./s F36764. MJPEG wymusza ponowne kodowanie i znacznie obciąża CPU F48647. Frigate podaje przykład: strumień główny 15 kl./s z odstępem klatek I 30, pomocniczy 5 kl./s z odstępem 5 F47965.
• Kolor czy mono: Plate Recognizer zaleca kolor ze względu na rozpoznawanie marki i modelu F35302; cctvplanner zaleca monochromatyczną kamerę LPR z IR i osobną kolorową kamerę przeglądową F36825; matryca mono zyskuje ok. jedną przysłonę czułości F47065.

Warunki i rozbieżnościWszystkie progi pikseli to deklaracje producentów oprogramowania i kamer, nie wyniki niezależnych testów; rozrzut 74–200 px F33409F36818 wynika z różnych silników OCR. Próg 94 px modelu Intel LPRNet F32466 dotyczy tablic chińskich F33116 i nie przenosi się wprost na tablice polskie. Różnice w zaleceniach migawki (1/300–1/1000 s) wynikają z prędkości i kąta: tabela Axis pokazuje, że przy 30 km/h i kącie 30° granicą jest 1/298 s, a przy 45° — 1/421 s (obliczenia, pkt 6). Dla bitrate brak progu w źródłach; maksymalne 8 Mb/s kamery DS-2CD2043G2-I F44284 daje 0,078 bit/px przy 4 MP i 25 kl./s oraz 0,131 bit/px przy 15 kl./s (obliczenia, pkt 10).

S04-Q2Jak dobrać rozdzielczość i ogniskową dla pasa parkingowego (odległość ok. 2–10 m, szerokość tablicy UE 520 mm, kadr obejmujący jeden pas) i co w praktyce dają 2 MP, 4 MP i wyższe rozdzielczości?

OdpowiedźLiczbę pikseli na tablicy wyznacza wzór PoP = H_px × 520 mm / W, gdzie szerokość kadru W = 2·d·tan(HFOV/2) F41863. Dla celu 130 px kamera 2 MP dopuszcza kąt widzenia do 75° przy 5 m i do 42° przy 10 m, a kamera 4 MP do 94° i 57° (obliczenia, pkt 3). Axis zaleca dla jednego pasa poniżej 4 m kąt 33–44° przy 5 m i 17–23° przy 10 m F33415, czyli kadr szeroki 3–4 m; daje to 247–337 px przy 2 MP i 346–472 px przy 4 MP (obliczenia, pkt 4), a Axis uznaje 1 MP za minimum dla jednego pasa i 2 MP dla dwóch F33416. W praktyce 2 MP z obiektywem zmiennoogniskowym ustawionym na pas wystarcza w całym zakresie 2–10 m. 4 MP daje 1,4 raza więcej pikseli przy tym samym kącie, co pozwala zostawić szeroki kadr: 4 MP z obiektywem 2,8 mm (94°) utrzymuje ≥130 px do 5,0 m, a z 6 mm (52°) do 11,0 m, podczas gdy 2 MP z 2,8 mm (110°) tylko do 2,7 m (obliczenia, pkt 2). Szeroki kadr przy 4 MP ma znaczenie dla dużych kątów najazdu: przy 30° rzut tablicy kurczy się do 0,87, a przy 45° do 0,71 szerokości, więc 130 px w rzucie wymaga odpowiednio 150 i 184 px na wprost (obliczenia, pkt 5, geometria S). Rozdzielczości 6–10 MP nie poprawiają odczytu jednego pasa na 2–10 m, a zwiększają koszt dekodowania i obciążenie CPU F46774F36766.

Dowody

• Wynik wzoru zgadza się z przykładami ze źródeł: cctvplanner podaje ok. 160 px przy 5 m dla 2 MP z obiektywem 6 mm na matrycy 1/2,7″ F36819 (skrypt: 173 px przy ok. 60°), a JVSG 320 px/m dla kamery 1080p na kadrze 6 m F33953.
• Producenci kamer parkingowych dobierają te same zakresy: Dahua kamera wjazdowa 3–6 m to 4 MP, matryca 1/1,8″, obiektyw 2,7–12 mm i pas 3–4 m F49210F50541; instrukcja ANPR Hikvision przypisuje obiektyw 2,8–12 mm wjazdom na 6–18 m F40827; Nedap ANPR Lumo czyta na 2–10 m przy szerokości do 3,5 m z matrycą 1280×1024 i obiektywem 12 mm F41727; Axis LPV dla kontroli dostępu działa na 2–7 m przy montażu na 1–3,5 m F37937; Bosch kwalifikuje kamerę 1080p DINION 6000i IR do jednego pasa start-stop do 15 m F34386.
• 2 MP a 4 MP: Plate Recognizer uznaje 2 MP za odpowiednie dla garaży F39458, a 4 MP wymaga powyżej 30 ft (9 m) przy tablicach USA i celu 80 px F33285; ANPR Watch dla bram parkingowych 0–15 km/h zaleca 2 MP na jeden pas, migawkę 1/500–1/1000 s i 20–25 kl./s F46437; cctvdvrsystem uznaje 1–2 MP za zakres idealny, bo wyższa rozdzielczość zwiększa obciążenie CPU F46774.
• Zbyt blisko też szkodzi: Viewtron LPR-IP4 przy tablicy z 4 ft (40% szerokości kadru) śledził tablicę, ale nie zwrócił numeru, a z 36 ft czytał stabilnie F42781. DTK podaje minimalną odległość D = 1,7·H, gdzie H to wysokość montażu F32943.
• Kąty: Axis zaleca łączny kąt poniżej 30° F33413; DTK po 30° w pionie i poziomie F32941F32942; Plate Recognizer do 45°, a silnik czyta do 53° pochylenia i 70° kąta bocznego, przy 75° już nie F33286. Odblaskowość białej folii 3M spada ze 150 do 26 cd/lx/m² przy 30°, czyli do ok. 1/6 F37868.
• Klatki: przy 4 MP i 6 mm strefa ≥130 px ma 9 m (od 2 do 11 m), co przy 30 km/h i 15 kl./s daje 16 klatek; przy 2 MP i 2,8 mm strefa ma 0,7 m i 1 klatkę (obliczenia, pkt 8). ISS wymaga 3 klatek dla tablicy UE F38962.

Warunki i rozbieżnościTabela Plate Recognizer z 2022 r. podaje dla Europy maks. 14,1 ft (4,3 m) przy 2 MP i 19,7 ft (6,0 m) przy 4 MP, czyli mniej niż dla tablic USA F36997F37924, podczas gdy ten sam dostawca w 2025 r. podaje, że tablica UE jest 1,73 raza szersza od amerykańskiej F40853; tabela nie podaje kąta widzenia, więc nie da się jej pogodzić ze wzorem, i wiążący jest rachunek z HFOV. Kąty z kart katalogowych obiektywów szerokokątnych obejmują dystorsję, której źródła nie opisują. Wiersz 2 MP z ok. 60° pochodzi z ogólnego opisu sprzedawcy bez typu matrycy F33201. Kamery 4 MP mają 4 MP tylko w strumieniu głównym: w Hikvision iDS-2CD7A46G0 strumień pomocniczy ma maks. 704×576 F44271, w DS-2CD2043G2-I 1280×720, a trzeci strumień 1080p przy 10 kl./s F44278.

S04-Q3Jak noc i pogoda (oślepienie reflektorami, prześwietlenie odblaskowych tablic przez IR, deszcz, śnieg, nisko stojące słońce) wpływają na rozpoznawanie i które funkcje i ustawienia kamery temu przeciwdziałają (tryb LPR lub drogowy, stała migawka, sterowanie IR, podwójna ekspozycja lub HDR)?

OdpowiedźNocą tablica ginie na dwa sposoby: IR i reflektory prześwietlają odblaskową tablicę do białego prostokąta F36826, albo automatyka wydłuża ekspozycję i rozmywa obraz F39479; przy 30 km/h, migawce 1/30 s i kącie 20° rozmycie sięga 95 mm, prawie 7 razy więcej niż dopuszczalne 14 mm F37866. Przeciwdziałają temu potwierdzone w poradnikach ustawienia: stała migawka (nocą 1/1000–4/1000 s według Hikvision F40822), ograniczone wzmocnienie (9–21 dB Axis F35108, 20 Hikvision F40823), tryb sceny LPR (Bosch od firmware 6.50 ogranicza wzmocnienie i odszumianie F34384), wcześniejsze przejście w czerń i biel oraz filtr przepuszczający tylko IR. Co do WDR źródła są sprzeczne: Axis i Hikvision każą go wyłączyć F35408F40824, ANPR Watch zaleca True WDR ≥120 dB z HLC F46434; wieloekspozycyjny HDR daje podwójne krawędzie znaków i duchy pojazdów F39771 oraz obniża liczbę klatek do 1/2–1/3 F39774. Podwójną ekspozycję (Frame Parity Flashing) mają kamery dedykowane, np. Milesight F34541 i Adaptive Recognition Vidar F43877. Deszcz i śnieg zmniejszają odblaskowość tablicy i odbijają IR w pobliżu obiektywu, a zasypana tablica jest nieczytelna dla każdego silnika F36856. Na niskie słońce działa pochylenie kamery w dół i osłona F34601F33732. Testy terenowe autorów pracy z University of Hertfordshire pokazały, że źle ustawione kamery osiągały 5–60% przechwyceń, najgorzej w ciemne październikowe godziny szczytu F50622.

Dowody

• Bosch: w trybie LPR przy zalecanej migawce cały obraz poza tablicą i reflektorami jest ciemny i jest to zamierzone F36649; zakres wzmocnienia jest ograniczony w firmware, a wzmocnienie i moc IR ustawia się do uzyskania czytelnej tablicy F36650; przy utrzymującym się oślepieniu Bosch zaleca wyższy montaż, niższe wzmocnienie lub mocniejsze IR F38958.
• Praktyk z forum IPVM: AGC wyłączone, migawka 1/800–1/1000 s przy dobrych naświetlaczach IR, wzmocnienie 20–30 zamiast maksimum fabrycznego F36307; jeśli kamera przy migawce 1/500–1/1000 s nie przejdzie w czerń i biel lub zrobi to za późno, LPR nie działa F36310. Digital Watchdog: kamery LPR pracują stale w trybie nocnym z włączonym IR F40896.
• Przypadek z praktyki: integrator ustawił kopułki Dahua 3 MP na maks. 8 ms, wzmocnienie 1 i WDR w trybie Strong; przy 7 ms tablice były czytelne do 45 mph bez rozmycia F40469F40470; była to ocena wzrokowa, bez oprogramowania LPR F40476.
• HDR: jednoekspozycyjny HDR z podwójnym wzmocnieniem (DCG) zachowuje pełną liczbę klatek F39772F39774; wieloekspozycyjny HDR wystarcza dla scen statycznych i wolnych, ale słabiej radzi sobie z ruchomymi tablicami nocą F39778. Źródło dotyczy kamer samochodowych, nie CCTV.
• Długość fali IR: Milesight zaleca 850 nm dla tablic standardowych o wysokim kontraście lub nieodblaskowych, a 740 nm dla odblaskowych o niskim kontraście F34542. Badania tablic brytyjskich pokazują spadek odblaskowości tła ok. 850 nm F50601, rozbieżności między tablicami powyżej 850 nm F50123 i malejący kontrast znak/tło w bliskiej podczerwieni F51171, przy czym kontrast przy 850 nm pozostaje dobry dla wielu tablic przednich F50600; śruby i zaślepki mocujące odpowiadały za 72,6% z 700 błędnych odczytów F50313. 940 nm jest mniej widoczne F36619, ale Avigilon podaje dla 940 nm zasięg 15 m wobec 30 m dla 850 nm F49730F49728.
• Pogoda: norma dopuszcza utratę odblaskowości do 20% na sucho i do 28% na mokro F32742F32743; Plate Recognizer czyta przy zamieci, dopóki śnieg nie zasypie tablicy F36858. Dostawca usług deklaruje spadek z 98% do 90–95% w intensywnych opadach F39718.

Warunki i rozbieżnościSpór o WDR rozstrzyga się podziałem ról: zalecenie „wyłącz” dotyczy kamery tablicowej ze stałą migawką i IR F35408F34128, zalecenie „włącz ≥120 dB” dotyczy kamer pracujących bez stałego IR F46434; przy wieloekspozycyjnym WDR liczba klatek spada F39774, a źródła nie podają, od jakiej prędkości duchy psują odczyt przy ≤30 km/h. Pomiary długości fali dotyczą tablic brytyjskich z osłoną akrylową F50598 i nie przenoszą się wprost na tablice polskie; dla tablic polskich brak danych w źródłach. Teza, że 740 nm daje jaśniejszy obraz tablic europejskich niż 850 nm, nie ma pokrycia w zmierzonych wartościach: praca z Hertfordshire nie podaje odblaskowości przy 740 nm F51172. Spadek 98% → 90–95% w opadach to deklaracja firmy instalacyjnej, nie test F39718.

S04-Q4Które zwykłe kamery CCTV (RTSP i ONVIF, ręczna migawka, strumienie pomocnicze, IR) są zalecane lub sprawdzone do LPR z zewnętrzną analityką, ile kosztują i która jest najlepsza, a która najrozsądniejsza cenowo? Porównanie z dedykowanymi kamerami LPR tych samych producentów: różnica ceny i co dodają.

OdpowiedźNajlepiej udokumentowaną zwykłą kamerą do zewnętrznej analityki jest Bosch DINION IP starlight 6000i IR (NBE-6502-AL, 1080p): Bosch w swoim poradniku ANPR kwalifikuje ją do jednego pasa start-stop do 15 m F34386, ma tryb sceny LPR ograniczający wzmocnienie F34384, a kamery Bosch nie odczytują tablic i wymagają zewnętrznego oprogramowania F34385 — dokładnie układ z SBC; ceny brak w źródłach. Najrozsądniejsza cenowo z ceną jest Dahua IPC-HFW1439TL1-A-IL (4 MP, 2,8 mm, 94°, IR 30 m) za 93,63 € brutto T14793T14794S: daje ≥130 px do 5,0 m i ≥100 px do 6,5 m (obliczenia, pkt 2), więc wymaga montażu 2–5 m od tablicy; źródła nie potwierdzają dla niej ręcznej migawki ani WDR. Z potwierdzonymi parametrami LPR, ale bez ceny, wyróżnia się Hikvision DS-2CD2043G2-I(U) z obiektywem 6 mm: 4 MP, 52°, migawka 1/3–1/100 000 s, IR 850 nm do 40 m, WDR 120 dB, ONVIF S/G, RTSP, strumień pomocniczy 1280×720 F44277F44280F42920F43096F44278, ≥130 px do 11 m (obliczenia); Dipolnet oznacza ją jako niedostępną F43102. Dedykowana kamera tego samego producenta kosztuje kilkanaście razy więcej: Hikvision iDS-2CD7A46G0/P-IZHSY(C) 1 286,58 € brutto po 15% rabacie F40785, czyli dla dwóch kamer o 2 385,90 € więcej niż dwie Dahua IPC-HFW1439TL1 (×13,7; obliczenia, pkt 11). Dodaje głównie analitykę w kamerze, większą matrycę, motorowy obiektyw, mocniejsze IR i wyjścia do szlabanu, czyli funkcje, które w architekturze właściciela przejmuje SBC.

Zwykłe kamery w źródłach:

Porównanie z dedykowanymi kamerami LPR:

Dowody

• Pasma cen: zwykłe kamery 100–500 USD, kamery LPR 1 500–5 000 USD F37851; Plate Recognizer: kamery LPR średnio 900–1 500 USD, kamery IP „po kilkaset dolarów” F37254; tania kamera LPR to kilkaset dolarów F36938. Starsze ceny zwykłych kamer: Dahua IPC-HDW4231EM-AS 127,30 USD (2018) F38977, Dahua IPC-HFW4300S 120 USD (2014) F37014.
• Sprawdzenie w praktyce zwykłych kamer: kopułki Dahua 3 MP z migawką 7–8 ms F40469F40470; Frigate poleca Dahua, Hikvision i Amcrest w tej kolejności F42302; Plate Recognizer ma klientów korzystających z istniejących kamer CCTV F33830 i twierdzi, że tania kamera IP działa tak dobrze jak droga, jeśli jest dobrze ustawiona F40753 — to deklaracja dostawcy oprogramowania konkurującego z kamerami LPR.
• Kamery dedykowane też wysyłają strumień RTSP H.264/H.265 (Tattile F43530, JideTech z ONVIF i RTSP F37325, Hikvision iDS z ONVIF S/G/T F42945), więc mogą zasilać SBC jak zwykła kamera z lepszą optyką i IR. Ich strumienie pomocnicze są małe: Milesight TS4466 640×480 lub 640×360 F37439, Hikvision iDS 704×576 F44271.
• Wiarygodność deklaracji: Plate Recognizer powołuje się na IPVM, według którego kamery reklamowane jako 99% osiągały ok. 80% F36940; modele AI w kamerach Hikvision i Hanwha aktualizuje się rzadko, co 12–18 miesięcy F39602. Oba twierdzenia pochodzą od konkurenta producentów kamer.

Warunki i rozbieżnościCeny pochodzą z różnych rynków, lat i walut (cennik UE z VAT, Alibaba, cennik edukacyjny USA, oferty z montażem), więc różnice są orientacyjne. Dla zwykłych kamer z obiektywem zmiennoogniskowym i potwierdzoną ręczną migawką źródła nie podają aktualnej ceny w Europie. Dahua IPC-HFW1439TL1 wymaga montażu 2–5 m od tablicy przy celu 130 px; na 6–10 m potrzebny jest obiektyw ok. 6 mm (4 MP, 52°) lub zmiennoogniskowy. Wskaźniki ≥95–99% kamer dedykowanych to deklaracje producentów „w zalecanych warunkach montażu i oświetlenia” F41645F50430, nie wyniki niezależnych testów.

Założenia S i obliczenia

• Obliczenia: data/jobs/lpr-cpu-sbc/decyzja/obliczenia/s04.py, wynik w s04.out. Wzory: PoP = H_px × 520 / (2·d·tan(HFOV/2)); maks. HFOV = 2·atan(H_px × 520 / (PoP·2·d)); t_max = 14 mm / (v·sin θ); rozmycie w px = v·sin θ·t × PoP / 520.
• S Kąty widzenia obiektywów pochodzą wyłącznie z kart katalogowych przywołanych w tabelach; wiersze „ok. 6 mm (ok. 60°)” i „ok. 12 mm (ok. 30°)” opierają się na ogólnym opisie sprzedawcy bez typu matrycy F33200F33201.
• S W tabeli porównawczej 1b skryptu ten sam kąt widzenia przyjęto dla 2 MP i 4 MP.
• S Skrót perspektywiczny tablicy liczony jako cos θ (czysta geometria).
• S Strefa odczytu liczona od 2 m przy najeździe wzdłuż osi kamery i stałej prędkości.
• S Kryterium 14 mm dopuszczalnego rozmycia pochodzi z cctvplanner F37865; skrypt odtwarza nim tabelę Axis F36627.
• S Ceny Dahua z cennika norteh.com zapisane w źródle jako „7093 €” i „9363 €” odczytano jako 70,93 € i 93,63 € brutto (cennik nie pokazuje separatora; sprawdzone 16.10.2026).
• [T…] oznacza zweryfikowany wpis z tabela_wartosci.json (identyfikator wiersza), dla którego nie ma ustalenia F w plikach sekcji.
• Część ustaleń pochodzi z innych sekcji (ceny i parametry kamer dedykowanych: s01, s02, s06, s08), np. F40785, F46385, F49577, F45975, F51162.
• S Porównanie Dahua dedykowana/zwykła łączy pasmo cen w USD z ceną w € bez przeliczenia kursu.

Część 5Przemysłowy SBC: najlepszy i najrozsądniejszy cenowo

S05-Q1Który przemysłowy SBC jest najlepszy, a który najrozsądniejszy cenowo do analityki LPR na CPU lub NPU (bez GPU) przy maksymalnie dwóch kamerach (np. Rockchip RK3588 lub RK3576, Intel serii N, Atom x7000, NXP i.MX8M Plus, jednostki przemysłowe na Raspberry Pi 5 lub CM5): CPU, RAM, zakres temperatur, zasilanie, wejścia i wyjścia dla czujników i szlabanu, cena?

OdpowiedźNajmocniejszą platformą ARM w ustaleniach jest RK3588: 4× Cortex-A76 do 2,4 GHz i 4× Cortex-A55 do 1,8 GHz oraz trzyrdzeniowe NPU 6 TOPS INT8 F36319F47676. Jego wersja przemysłowa RK3588J pracuje w zakresie −40…85 °C kosztem niższych taktów: A76 1,6 GHz (2,0 GHz w trybie overdrive), A55 1,3 GHz (1,7 GHz) F39707F39704. Najrozsądniejszy cenowo jest RK3576 (4× Cortex-A72 2,2 GHz i 4× Cortex-A53 1,8 GHz, NPU 6 TOPS) w gotowej obudowie przemysłowej za 299 USD (4 GB/32 GB) lub 339 USD (8 GB/64 GB) F47539F48425F46352F46353. i.MX8M Plus ma tylko 4× Cortex-A53, NPU 2,3 TOPS i sprzętowe dekodowanie do 1080p60 F46145F46146F43050. Raspberry Pi 5 nie ma NPU, a zapowiedź producenta nie wymienia wersji przemysłowej ani rozszerzonego zakresu temperatur F35972; zakres −20…60 °C dają dopiero urządzenia firm trzecich z CM5 F33521. Po stronie x86 Intel N100 (4 rdzenie Gracemont, 3,4 GHz, TDP 6 W, bez NPU) kosztuje jako kompletny mini PC 130–180 USD F39606F35944F42348, a jego bezwentylatorowe wersje mają zwykle zakres 0…60 °C F46231. Dla Atom x7000 (x7425E) brak danych w źródłach o wydajności LPR, cenie i wersjach przemysłowych; procesor występuje tylko na liście platform testowanych przez OpenVINO F36130.

Dowody

• Płytki RK3588 zasilane są zwykle 5 V/4 A przez USB-C, a płytki N100 pobierają 15–25 W z zasilacza 12 V lub 19 V F38510F38511; Rock 5B pobiera maksymalnie 13,3 W F38651, moduł Forlinx RK3588 6,98 W w teście obciążeniowym F49278.
• Ceny płytek RK3588 (nie przemysłowych): Rock 5B+ 75–149 USD F37127, przedział 149–250 USD w połowie 2026 r. F43249; kompletny zestaw Rock 5B 16 GB z dyskiem, zasilaczem i obudową kosztował w 2023 r. 297 USD wobec 183,50 USD za mini PC N100 16 GB z dyskiem NVMe (133,50 USD bez dysku) F46347.
• Raspberry Pi 5 16 GB kosztuje 305 USD w kwietniu 2026 r. po trzech podwyżkach od października 2025 r. F43915; CM5 kosztuje od 45 USD F41890.
• RK3588 zużywa wyraźnie mniej energii niż N100; w teście FFmpeg mini PC potrzebowały ok. 100% więcej energii F46345F38654.
• W UnixBench 4-rdzeniowy N100 ma wyższy łączny indeks niż 8-rdzeniowy RK3588, ale RK3588 wygrywa w Dhrystone i Whetstone F48609F48610; Geekbench: N100 1226/3345 pkt, Pi 5 777/1496 pkt F47561.
• Inna znaleziona platforma: Amlogic A311D (Khadas VIM3) z 4× A73 2,2 GHz, 4× A53 1,8 GHz i NPU 5 TOPS F37112; brak danych o wersji przemysłowej i pomiarach LPR.

Warunki i rozbieżnościKonfiguracja rdzeni jest spójna w kartach katalogowych: RK3588 to 4× A76 + 4× A55 F38830, a artykuł w „Scientific Reports” podaje błędnie „sześciordzeniowy CPU” F41116F50695. Takt A76 zależy od płytki: 2,4 GHz nominalnie F36319, 2,1–2,256 GHz w części płytek F36674F38935F43081. Dla RK3576 jedna instrukcja podaje A72 do 2,2 GHz, a inna jej część do 2,4 GHz F48423F48424. Jedno ustalenie przypisuje i.MX8M Plus rdzeń Cortex-A72 F49031; karty NXP, Kontron, SECO i Ezurio podają wyłącznie 4× A53 + M7 F44443F46911F47459. Formaty NPU RK3588: karta 2023 wymienia INT4/INT8/INT16/FP16 F38833, strona Rockchip dodaje BF16/TF32 F39495. Dla BeagleBone AI-64 jeden artykuł podaje błędnie SoC AM625 i 4× A53 F46583F47278. N100: Intel podaje maks. 16 GB RAM F44599, użytkownik działa na 32 GB F47559; N100 nie ma opcji „embedded” F44600, mają ją N200 i N250 F44650F45530. Giada IM1-707 z RK3588J osiąga −20…70 °C tylko przy przepływie 0,7 m/s, a odmiana RK3588 tylko 0…60 °C F42911; RK3588 bez litery J w module BL450 ma zakres 0…80 °C F39704. Brak danych w źródłach o cenach przemysłowych odmian RK3588J, i.MX8M Plus i i.MX95. Wszystkie parametry w tabeli to deklaracje producentów.

S05-Q2Ile klatek na sekundę na kamerę potrzebuje wolny ruch parkingowy do pewnego odczytu i czy modele detekcji i OCR z sekcji s01 osiągają tę wartość na CPU tych SBC przy dwóch kamerach jednocześnie (ms na klatkę, kl./s, wątki)?

OdpowiedźŹródła podają 4–5 kl./s dla pojazdów poniżej 30 mph F34338, 5 kl./s, najwyżej 10, w Frigate F32604, 12 kl./s dla wolno jadących F32877 i ok. 15 kl./s dla bram i parkingów F41228. Obliczenie (klatki = strefa / prędkość × kl./s) daje przy 10 km/h i strefie czytelności 3 m S 5,4 klatki przy 5 kl./s, a przy 30 km/h wymaga 10,4–13,9 kl./s, aby w strefie 3–4 m znalazło się 5 klatek. Cel dla dwóch kamer to więc 5 kl./s, gdy pojazd zwalnia przed szlabanem, i 10–12 kl./s, gdy przejeżdża strefę z prędkością do 30 km/h. CPU ARM w ustaleniach tego nie osiąga: Pi 5 (4× A76) wykonuje YOLOv8s INT8 w 457 ms, czyli 1,1 kl./s na kamerę przy dwóch kamerach F46362. Dla CPU RK3588 brak bezpośredniego pomiaru detektora tablic; ResNet18 trwa na A76 ok. 48 ms (4 ms na NPU razy 12, wg producenta) F46544. N100 z OpenVINO przetwarza 23,6 kl./s YOLOv8n INT8 F36125, co zajmuje 42% jego mocy przy 2×5 kl./s i 102% przy 2×12 kl./s; N100 wystarcza więc tylko w trybie wyzwalanym (benchmark OpenVINO; urządzenia, CPU czy iGPU, ustalenie nie podaje) z 5 kl./s. NPU RK3588 wykonuje detekcję w 14–18,5 ms F42712F46635F43794, co przy 2×12 kl./s zajmuje 34–44% czasu jednego toru NPU.

Dowody

• Frigate ostrzega, że czas inferencji powyżej 100 ms pogarsza odczyt F34295; użytkownik z kamerą LPR gubił tablice przy 8 kl./s, a przy 12 kl./s odczytywał je poprawnie F44793. Luxriot: przy 7 kl./s i obecności tablicy przez 300–400 ms rozpoznawanie dostaje 2–3 klatki i wynik jest niedokładny F41316.
• Głosowanie po klatkach podniosło odczyt tablic z 29% (1 klatka) do 69% (35 klatek) kosztem 18% przepustowości przy przejściu z 1 do 20 klatek; wynik dotyczy tablic saudyjskich i nie przenosi się wprost na tablice europejskie F42008F47298.
• RK3588 wg producenta przetwarza dwa strumienie YOLOv5s łącznie z prędkością 48 kl./s, czyli 24 kl./s na kamerę F37234. Podział wyjścia modelu na trzy rdzenie NPU podniósł wykorzystanie NPU z 60% do 90% F45885, a optimum dało 12 pul wątków (18,5 ms; 10 pul: 20,1 ms) F51016.
• OCR: CNN + Attention-LSTM osiąga na Pi 5 ok. 16 kl./s, czyli 62,5 ms na wycinek, a model z dekoderem Transformer ok. 5 kl./s F47002F42184; dokładność znaków 99,10% dotyczy koreańskiego zbioru AI-HUB i nie przenosi się wprost na tablice polskie F42183. PP-OCRv4_mobile_rec rozpoznaje wycinek w 17,48 ms, ale na serwerowym Xeon Gold 6271C z 8 wątkami F40612F47695F41291; PaddleOCR na Raspberry Pi 4 potrzebował 840 ms F43796.
• Obliczenie OCR: przy 2×12 kl./s i OCR na każdej klatce z tablicą potrzeba 1,5 s czasu CPU A76 na sekundę; przy OCR tylko na 5 najlepszych wycinkach pojazdu S i pojeździe co 10 s na pas S obciążenie spada do ok. 6%, a odczyt jednego pojazdu trwa ok. 312 ms.
• Wątki: detektor CPU Frigate używa domyślnie 3 wątków, po jednym detektorze na kamerę F41918F42771. Na RK3588 przejście z 4 do 8 wątków dodaje tylko 37,9%, bo rdzeń A55 daje ok. jednej trzeciej wydajności A76 F39451; YOLO26n na Apple M4 działa najszybciej na 4 wątkach, po jednym na rdzeń wydajnościowy F49366. Detekcję i OCR warto więc przypiąć do czterech rdzeni A76 (na Orange Pi 5 to CPU 4–7 F43639).

Warunki i rozbieżnościPomiary NPU RK3588 różnią się nawet u jednego producenta: YOLOv5s INT8 trwa 18,5 ms F46635 albo ok. 45 ms przy wejściu 640×640 F37233; YOLOv8n trwa 15,2 ms F46635, ok. 40 ms F50114 albo osiąga do 100 kl./s w demonstracji F39502. YOLO26n w RKNN potrzebuje 41,2 ms, bo RKNN nie obsługuje głowicy bez NMS i wymaga osobnego NMS F35336F47147. Dla Pi 5 wpis na LinkedIn podaje YOLOv8n INT8 w 16 ms (60 kl./s), ale z analizą tylko obszaru ROI F35861F35863; sprzedawca podaje 0,45 kl./s dla YOLOv8 na CPU F33753. fast-plate-ocr i FastALPR nie publikują pomiarów na CPU ARM ani N100 F32869F32989. Brak danych w źródłach: czasu NPU dla RK3576, i.MX8M Plus i i.MX95, czasu OCR na NPU RK3588 (przykład LPRNet istnieje w rknn_model_zoo F46068) oraz pomiarów na Atom x7000.

S05-Q3Czy te SBC dekodują sprzętowo dwa strumienie 4 MP H.264 lub H.265 (rkmpp, V4L2, Quick Sync, VPU), ile kosztuje dekodowanie programowe na CPU i czym różni się obciążenie dekodowaniem w wariantach architektury B, C i D?

OdpowiedźRK3588 dekoduje dwa strumienie 4 MP sprzętowo z dużym zapasem. Deklarowane 8K60 H.265 i 8K30 H.264 to ok. 1991 i 995 Mpx/s wobec 92–184 Mpx/s dla 2×4 MP przy 12,5–25 kl./s, czyli zapas od ×5,4 do ×21,6 F38829F40167. Dekoder ma dwa rdzenie VDPU381 F40435; transkodowanie 4K HEVC Main10 do 540p przez rkmpp osiągnęło 306 kl./s przy 3–8% CPU F39845. RK3576 ma dekoder 8K30 (ok. 995 Mpx/s) i ok. połowę wydajności transkodowania RK3588 F48131F43615; i.MX95 deklaruje 4Kp60 H.264/H.265, czyli zapas ×2,7–5,4 F47877F48741. Raspberry Pi 5 ma jeden dekoder 4Kp60 HEVC, a H.264 dekoduje programowo F35969F43912, więc kamery muszą nadawać H.265. i.MX8M Plus dekoduje sprzętowo najwyżej 1080p60 F43050F48579; w teście użytkownika H.265 przestało działać powyżej 1280×960 F36004, więc strumień 4 MP dekoduje tylko programowo, a sprzętowo wyłącznie substream. N100 przez Quick Sync transkoduje cztery strumienie 4K HEVC do 1080p przy 15 W F41816. Transkodowanie programowe 4K HEVC na RK3588 zajęło 727% CPU przy 39 kl./s F39847, co daje górne oszacowanie ok. 83 ms czasu rdzenia na klatkę 4 MP i 2,1–4,1 rdzenia (z 8) dla 2×4 MP przy 12,5–25 kl./s.

Dowody

• Rockchip deklaruje „wielokanałowy dekoder równolegle dla mniejszych rozdzielczości” F38829, Geniatech do 32 kanałów 1080p30 na RK3588 F43146; przewodnik Rockchip notuje, że 4K60 może się zacinać z powodu przepustowości DDR, a pomaga AFBC F39223.
• rkmpp działa tylko na jądrze BSP Rockchip 5.10 lub 6.1 F39844F44046; obsługę VDPU381/VDPU383 (RK3588/RK3576) włączono do jądra głównego w 2026 r. F40437, ale obsługa wielu rdzeni dekodera jest dopiero w pracach F40439; ścieżka V4L2 bez kopiowania wymaga puli CMA co najmniej 512 MB F38764.
• Frigate nie ma awaryjnego przejścia na CPU, gdy akceleracja sprzętowa zawiedzie F36667; NPU ani Coral nie dekodują wideo F42695F34999.
• Na N100 Quick Sync obniża zużycie CPU przez ffmpeg z ponad 70% do poniżej 25% przy czterech substreamach 1080p F47409; programowe transkodowanie 1080p zajmuje ok. 95% CPU N100 i obsługuje jeden strumień F44259.

Warunki i rozbieżnościEdgeAIStack podaje dla RK3588 „modelowy pułap” 1× 4K H.264 F43247; przy założeniu 4K30 S zapas dla 2×4 MP spada do ×1,4–2,7, wobec ×5,4–10,8 z deklaracji 8K30 H.264. Dla iGPU klasy UHD 730 podano 1–2 równoczesne pełne transkodowania 4K HEVC F43592, dla N100 cztery F41816; pomiary dotyczą innych układów i obciążeń. Geniatech przypisuje APC880 Mini „dekodowanie 4K” F46217, a karta APC880 podaje 1080p60 F48684. Koszt dekodowania programowego wyprowadzono z transkodowania, które obejmuje też kodowanie 540p, więc jest to górne oszacowanie. Brak danych w źródłach: pomiaru jednoczesnego dekodowania 2×4 MP na którymkolwiek SBC oraz kosztu programowego dekodowania H.264 4 MP na Pi 5 i N100.

S05-Q4Które NPU dają najlepszą dokładność, szybkość i koszt dla LPR z maksymalnie dwiema kamerami: NPU wbudowane w SoC (Rockchip RK3588 lub RK3576, NXP i.MX8M Plus, Intel Core Ultra i inne) oraz dokładane akceleratory (Hailo-8 lub Hailo-8L, Google Coral); ile dokładności traci się przy kwantyzacji i konwersji modelu (RKNN-Toolkit, kompilator Hailo, kompilator Edge TPU), których operatorów modeli detekcji i OCR NPU nie obsługuje i w jakich warunkach wygrywa projekt tylko na CPU? GPU (Jetson, iGPU) wyłącznie jako punkt odniesienia.

OdpowiedźNajlepszy stosunek kosztu do szybkości ma NPU wbudowane w RK3588: 6 TOPS bez dopłaty, detekcja w 14–30 ms (YOLOX-nano, YOLO-NAS s) F42712F41731F47358 i strata mAP50-95 1,4 pkt przy INT8 względem FP16 dla YOLO26n (0,463 wobec 0,477) F35335F35336. Najszybszy dokładany akcelerator w danych to Hailo-8 (26 TOPS, 2,5 W, YOLOv6n w ok. 7 ms) F40568F47356; Hailo-8L (13 TOPS) kosztuje 70 USD i wykonuje YOLOv6n w ok. 11 ms F45825F47356. Coral (4 TOPS, 60–95 USD) obsługuje tylko modele INT8 TFLite, a Frigate nie zaleca go do nowych instalacji F34852F34857F34856F47355. Dla NPU i.MX8M Plus (2,3 TOPS), i.MX95 (2 TOPS) i RK3576 brak danych w źródłach o zmierzonej szybkości i stracie dokładności. NPU Intel Core Ultra 7 155H wykonuje YOLOv8n z prędkością 142 kl./s F38055, a detektor tablic YOLOv8m po kwantyzacji PTQ traci 0,020 mAP@0.5 i 0,067 mAP@0.5:0.95; kwantyzacja z douczaniem (QAT) zmniejsza stratę mAP@0.5 do 0,015 i podnosi mAP@0.5:0.95 o 0,011 F47189F47190. Dla kompilatorów Hailo i Edge TPU brak danych w źródłach o stracie dokładności. CPU wygrywa, gdy rozpoznawanie jest wyzwalane i wystarcza 2×5 kl./s (N100: 42% mocy), gdy model zawiera operatory nieobsługiwane przez NPU (attention, transformery) lub gdy koszt konwersji i walidacji przewyższa zysk F36125F39503F37242.

Dowody

• INT8 skraca czas na NPU RK3588 o 42–51% dla YOLOv8n/s/m F34659; FP16 na RK3588 był wolniejszy od FP32 (37,4 wobec 32,6 ms) i obniżył dokładność o 3,2 pkt (89,4% → 86,2%) F47436.
• Kalibracja na małym zbiorze bez przykładów negatywnych obniżyła dokładność ResNet50 INT8 na RK3588 do 73%; 500 obrazów kalibracyjnych i kwantyzacja mieszana (FP16 w ostatnich warstwach) przywróciły 88,9% przy 28 ms (deklaracja) F46636.
• Nieobsługiwane operatory: warstwa z niestandardową aktywacją przechodzi z NPU RK3588 na CPU i wydłuża czas o 500% lub więcej (deklaracja) F46637; RKNN-Toolkit2 1.6.0 nie obsługiwał części operatorów attention na RK3588 (dodano je w 2.0.0b12) F39503; NPU Arm Ethos-N nie przyspiesza Softmax, Sigmoid i Exp w głowicy detekcji, więc głowicę liczy CPU F47325F47326; TIDL przenosi nieobsługiwane warstwy na C7x lub A72, a akceleratory tej klasy osiągają 20–40% wartości szczytowej F47489F47490.
• Eksport INT8 do RKNN w Ultralytics obsługuje tylko modele detekcji F35345; Frigate dla RKNN zapewnia post-processing tylko dla dostarczonych modeli F44268; sukces eksportu nie gwarantuje zgodności wyników z FP32 F47149.
• Ogólne straty INT8: 0,1–2% dla detektorów CNN, 1–5% bez starannej kalibracji F42682; YOLOv8s traci 0,45 pkt mAP na COCO F46364; CRNN zmienia dokładność o −0,35 do +1,00 pkt F46956; kilka modeli YOLOv12 do detekcji tablic wyraźnie straciło precyzję F40888.
• Demonstracja ALPR Hailo-8 z hostem i.MX8 działa z prędkością 60 kl./s przy dokładności 99,86% (deklaracja); LPRNet trenowano na syntetycznych tablicach izraelskich z samymi cyframi, więc wynik nie przenosi się na tablice europejskie F34229F34232F34239. Dekodowanie, śledzenie i ocena jakości wycinka działają na CPU hosta F35592F35593.
• Konwersja YOLOv5/YOLOv8 do RKNN zajmuje wg producenta 1–3 dni pracy inżyniera F39519.

Warunki i rozbieżnościSprzedawca twierdzi, że Hailo-8L działa tylko z kamerami Raspberry Pi, a nie z kamerami IP F33755; Frigate, system NVR dla kamer IP, obsługuje Hailo-8L na Pi 5 F49813F41498. W 2023 r. społeczność zarzucała Rockchip zamknięte oprogramowanie NPU F36973, a sterownik jądra RKNPU jest otwarty F36023 i powstał sterownik Mesa „Rocket” w jądrze głównym F38570. Liczba TOPS nie przekłada się wprost na szybkość F35945; różnica RK3588 vs Jetson Orin Nano jest w praktyce mniejsza niż stosunek TOPS (deklaracja) F36911. Na Pi 5 jądra FP32 bywają szybsze od INT8 dla małych modeli F46986. Test NPU Core Ultra użył zbioru Kaggle „Car Plate Detection” (433 obrazy) i wejścia 320×320 F47171F47172, więc nie przenosi się wprost na tablice polskie. Frigate deklaruje, że modele LPR są na tyle lekkie, że działają na większości CPU F35177; to opis Frigate, nie pomiar na ARM.

S05-Q5Które przemysłowe SBC i komputery bezwentylatorowe mają potwierdzoną niezawodność w szafkach zewnętrznych (zakres temperatur, chłodzenie bez wentylatora, zużycie eMMC lub SSD, watchdog, zachowanie po zaniku zasilania) i w jakiej cenie?

OdpowiedźBrak danych w źródłach o niezależnie potwierdzonej, wieloletniej niezawodności (MTBF, statystyki awarii) któregokolwiek z tych urządzeń; dostępne są deklaracje producentów i krótkie testy cieplne. Z deklaracji najlepiej do szafki pasują: ARMxy BL450 z RK3588J (−40…85 °C, 9–36 V, sprzętowy watchdog, DIN) F39704F39706, Geniatech XPI-3576 (−40…85 °C, watchdog, 7,08 W) F49092F49094 oraz Geniatech APC880 z i.MX8M Plus (−40…85 °C, bez wentylatora) F46322; żaden z nich nie ma ceny w danych. InHand EC3320 (RK3588) ma −20…60 °C, obudowę bez wentylatora IP40 i watchdog F44350F44351, a CM5 w EdgeLogix-1145 −20…60 °C przy cenie 249–299 USD F33521F33522. W opisanym przez producenta wdrożeniu RK3588 bez wentylatora w szczelnej skrzynce IP65 przy 42 °C otoczenia obniżał takt CPU po 2–3 godzinach F38811. Pamięć eMMC 16 GB zużyła się po 23 TiB zapisu F36726; z obliczeń ciągłe nagrywanie 2×4 Mbit/s S wyczerpuje ją po ok. 279 dobach, a zapis samych zdjęć 2 MB × 2000 pojazdów na dobę S po ok. 17 latach.

Dowody

• Testy cieplne RK3588: z pasywnym radiatorem 68–74 °C w stanie ustalonym, dławienie powyżej ok. 80 °C F36314; A76 utrzymują 2,2–2,3 GHz przez 25 minut pełnego obciążenia F36320; NanoPC-T6N osiągnął 56,4 °C po 2 minutach bez dławienia F39445.
• Raspberry Pi 5 dławi się przy 82 °C, samoprzylepne radiatory nie pomagają (85,6 °C), a producent zaleca aktywne chłodzenie F36157F36158F40001. Pi 4 na zewnątrz przy 22–36 °C traci bez wentylatora 19,3–27,7% przepustowości F47515.
• N100 bez wentylatora jest stabilny, ale gorący; dysk NVMe osiągnął 85–90 °C w słońcu na parapecie F47554F47558.
• Pamięć: kart SD należy unikać w produkcji F33760; blok eMMC MLC wytrzymuje 3000–10 000 cykli kasowania F36292; tryb pSLC wydłuża życie ponad dwukrotnie kosztem połowy pojemności F36293, wg Flexxon nawet 20× względem TLC F41100; eMMC przemysłowa pracuje w −40…85 °C lub do 105 °C i ma ochronę przed zanikiem zasilania (PLP) F41098F41099; raport zdrowia eMMC sygnalizuje 80% i 90% zużycia bloków zapasowych F38671.
• Zanik zasilania: system plików root tylko do odczytu przez overlayfs zapobiega uszkodzeniu plików F33965; RTC z baterią CR1220 utrzymuje czas po wyłączeniu F48951; Rock 5B z niektórymi zasilaczami PD wpada w pętlę restartów, Radxa zaleca zasilacz 12 V DC F40134F40136.
• Watchdog: RK3588 ma pięć watchdogów F42949, RK3576 trzy F48429, BCM2711/BCM2712 sprzętowy watchdog F33964.
• Dostępność: i.MX95 15 lat F50151, Verdin iMX8M Plus do 2036 r. i dalej F45173, Geniatech DB3588V2 ponad 10 lat F43150, XPI-3576 7–10 lat F47392, Advantech 7–15 lat F39304.
• Szafa zewnętrzna klasy IP55 ma zakres −40…+55 °C i opcje wentylatora, wymiennika ciepła lub klimatyzatora F35998.
• Ryzyka programowe: NanoPC-T6N fabrycznie startował z karty microSD, choć miał 64 GB eMMC F39448; NPU i dekoder RK3588 działają tylko z jądrem dostawcy F36953; Rock 5B zgłaszał błędy pamięci po dłuższej pracy jako serwer F35722.

Warunki i rozbieżnościTen sam producent (ieeker) deklaruje utrzymanie pełnej wydajności RK3588 bez wentylatora do 60 °C F46638 i w szczelnej obudowie DIN do 55 °C F37239, a w opisanym wdrożeniu notuje dławienie przy 42 °C po 2–3 godzinach F38811; EdgeAIStack zaleca aktywne chłodzenie przy ciągłym obciążeniu NPU F43248. Geniatech APC880 jest bezwentylatorowy F46322, a APC880 Mini ma wentylator F47549. Dane do obliczenia zużycia eMMC pochodzą z badania z 2019 r. na jednym układzie 16 GB F36726; większa pojemność i tryb pSLC wydłużają czas życia. Brak danych w źródłach o cenach przemysłowych komputerów z RK3588J, i.MX8M Plus, i.MX95 oraz N100.

Wskazanie

• Najlepszy ARM: przemysłowy komputer na RK3588J lub RK3588, np. ARMxy BL450 (RK3588J, −40…85 °C, 9–36 V, watchdog) F39704F39706 albo InHand EC3320 (RK3588, −20…60 °C, 4 DI/4 DO, RS-485, watchdog) F44350F44352. NPU wykonuje detekcję w 14–18,5 ms, co przy 2×12 kl./s zajmuje 34–44% czasu jednego toru NPU, dekoder ma zapas ×5,4–21,6 dla 2×4 MP, a cztery rdzenie A76 obsługują OCR na wybranych wycinkach (ok. 6% czasu przy 5 wycinkach na pojazd S). Warunek: jądro BSP Rockchip dla rkmpp i NPU F39844F36953 oraz niższe takty RK3588J F39707.
• Najrozsądniejszy cenowo ARM: RK3576 w obudowie przemysłowej, np. Seeed reComputer Industrial za 299 USD (4 GB/32 GB) F46352 lub Geniatech XPI-3576 (−40…85 °C, watchdog, 7,08 W) F49092F49094. Ma NPU 6 TOPS wg producentów F36908 i dekoder 8K30 z zapasem ×5,4–10,8 dla 2×4 MP F48131, ale słabsze rdzenie A72/A53 i brak w danych zmierzonych czasów NPU. Tańszy zestaw Pi 5 + Hailo-8L (150 USD przy cenach z 2023–2024 r.) F39935F45825 nie ma wersji przemysłowej (HAT 0…50 °C, wymagane aktywne chłodzenie) i nie dekoduje H.264 sprzętowo F45910F40001F43912; EdgeLogix-1145 na CM5 (249 USD) ma przemysłowe I/O, ale nie ma NPU, a CPU Pi 5 daje 1,1 kl./s detekcji na kamerę F33522F46362.
• Kiedy x86 nadal wygrywa: gdy zespół chce uruchamiać modele bez konwersji do RKNN (OpenVINO wykonuje ten sam model na CPU, iGPU i NPU F46171; N100 iGPU: YOLOv9-s 320 w 30 ms F40873); gdy OCR lub detektor używa operatorów attention lub transformerów, których RKNN nie przyspiesza F37242F39503; gdy wymagane jest jądro główne Linuksa i długie utrzymanie bez BSP dostawcy F39844; gdy wystarcza tryb wyzwalany 2×5 kl./s (42% mocy N100 F36125) i liczy się niska cena konsumenckiego mini PC (183,50 USD z dyskiem NVMe wobec 297 USD za zestaw Rock 5B w 2023 r. F46347); gdy potrzebny jest większy detektor na NPU Core Ultra (YOLOv8m-320 w 22,4 ms F47189). Wymóg AVX2 dla LPR dotyczy oprogramowania Frigate F32603, nie platformy ARM; Frigate ma osobny obraz dla Rockchip z RKNN F44049.

Założenia S i obliczenia

• Skrypt: data/jobs/lpr-cpu-sbc/decyzja/obliczenia/s05.py, wynik: s05.out.
• S Głębokość strefy czytelności tablicy: 2–4 m (w tekście 3–4 m); prędkości 5–30 km/h; cel: co najmniej 5 klatek w strefie.
• S Obciążenie detekcją liczone szeregowo na jednej jednostce: obciążenie = 2 × kl./s × ms / 1000; maks. kl./s na kamerę = 1000 / (2 × ms). Dla N100 CPU czas = 1000 / 23,6 kl./s przepustowości.
• S OCR na A76 RK3588 przyjęty jak na Pi 5 (62,5 ms na wycinek F47002, ten sam rdzeń 2,4 GHz) i jako czas całego CPU; OCR na N100 przeskalowany wynikiem Geekbench 1-rdzeń 777/1226 F47561 (39,6 ms).
• S OCR tylko na 5 najlepszych wycinkach na pojazd, najwyżej 1 pojazd na 10 s na pas.
• S 4 MP = 2560×1440 (3,69 Mpx); kamery nadają 12,5 lub 25 kl./s; substream w wariancie B 640×360.
• S Przepustowość dekodera = rozdzielczość × kl./s z deklaracji; „1× 4K H.264” EdgeAIStack przyjęte jako 4K30.
• S Koszt programowego dekodowania na RK3588 wyprowadzony z transkodowania 4K HEVC Main10 → 540p (727% CPU, 39 kl./s) proporcjonalnie do liczby pikseli; obejmuje kodowanie, więc jest górnym oszacowaniem.
• S W wariancie D dekoder pracuje ciągle, bo wyzwolenie nie skraca dekodowania strumienia.
• S Zużycie eMMC: ciągłe nagrywanie 2 × 4 Mbit/s (84,4 GiB/dobę) albo tylko zdjęcia 2 MB × 2000 pojazdów/dobę (3,91 GiB/dobę) wobec 23 TiB do końca życia eMMC 16 GB.
• Ceny podano w walutach i latach źródeł, bez przeliczeń kursowych; zestaw Pi 5 8 GB + AI Kit = 80 + 70 = 150 USD.

Część 6Jak osiągnąć 99% skuteczności

S06-Q1Jak producenci systemów LPR i niezależne testy definiują i mierzą skuteczność (capture rate, read rate, poprawny cały numer na pojazd, dokładność na znak, wynik na klatkę czy na pojazd, błędny odczyt a brak odczytu, wielkość próby) i co systemy komercyjne faktycznie osiągają w niezależnych testach na wjazdach parkingowych?

Odpowiedź„Skuteczność” w materiałach producentów i w badaniach oznacza co najmniej pięć różnych miar o różnych mianownikach: odsetek wykrytych pojazdów (capture rate), odsetek poprawnych odczytów wśród wykrytych (read rate), odczyt „skorygowany”, w którym tablica z jednym błędnym znakiem liczy się jako dobra, dokładność na znak oraz poprawny cały numer na obraz albo na przejazd F34565F38058F38192F37021. Dla szlabanu liczy się tylko poprawny cały numer na przejazd, czyli iloczyn wykrycia i odczytu: brytyjski standard policyjny (98% wykrycia × 95% odczytu) daje 93,1% na pojazd F35198F35199. Jedyny w źródłach niezależny pomiar systemów komercyjnych przy wolnym ruchu w pasach wjazdowych (terminale promowe NCDOT, tablice USA) dał 70,0% (ARV-LPR, 1064 z 1520 pojazdów) i 55,3% (Hik-LPR, 2035 z 3677) poprawnych numerów na pojazd; po zaliczeniu tablic z jednym błędnym znakiem odczyt wynosił 95% i 91% F38059F38060. Niezależnego testu na wjeździe parkingowym z tablicami polskimi lub unijnymi brak w źródłach. Deklaracje producentów mieszczą się w przedziale 95–99% i zwykle nie podają warunków ani próby F50503F44613F38196. Wiarygodne potwierdzenie 99% wymaga liczenia pojazdów, nie klatek, i próby rzędu 1000–3000 przejazdów (obliczenia H).

Dowody

• Błędny odczyt i brak odczytu to osobne kategorie: badanie brytyjskie rozdziela „misread” i „missed read” F41959, a raport powinien mieć trzy wyniki z własnymi mianownikami: pojazdy nieuchwycone, uchwycone bez wyniku i uchwycone błędnie F35203. Norma NASP zapisuje brak odczytu jako „QQQQQQQ” F39423. Na parkingu błędny odczyt oznacza utraconą opłatę albo obciążenie niewłaściwego pojazdu F36521; w punktacji kursu NHL Stenden poprawny odczyt daje +1, brak odczytu 0, błędny −10 F43709.
• AutoOCR wymienia cztery spotykane definicje: dokładne dopasowanie, wynik użyteczny po walidacji, poprawny odczyt w co najmniej jednej klatce sekwencji, poprawny odczyt w limicie czasu F34324.
• Wyniki systemów komercyjnych w testach niezależnych (żaden zbiór nie zawiera tablic polskich; wyniki z Brazylii i USA nie przenoszą się wprost na tablice europejskie):

• Deklaracje producentów i integratorów: Dahua ≥99% wykrycia i ≥95% rozpoznania „w zależności od kraju i warunków” F50502F50503; CatchCAM 2MP do 98% wykrycia i 99% odczytu F44613; Placa.ai 92–97% na wjeździe parkingowym przy 5–20 mph i ponad 97% przy ≤10 mph F49650F49651; AirGarage: 95–99% w materiałach marketingowych, 70–90% w realnych garażach F36518; Plate Recognizer: od 75% do 98% zależnie od ustawienia kamery F35276; TRUETECH: 87% → 99% po przebudowie wjazdów terminalu logistycznego (ok. 900 pojazdów na zmianę) F40986. Flock deklaruje >98% wykrycia, >96% na znak i >97% stanu tablicy, a w sporze sądowym podał 93 poprawne tablice na 100 F38192F38196.
• Wyniki badań są zawyżane przez podział danych: w AOLP-B 67,6% obrazów testowych ma niemal duplikat w zbiorze uczącym F41932, a po usunięciu duplikatów odsetek błędów rośnie ponad dwukrotnie F46689; przy testowaniu na zbiorze nieużytym w uczeniu średnia spada z 82,4% do 74,5%, dla AOLP z 90,8% do 62,7% F47128F49275. Zbiory testowe bywają bardzo małe: OpenALPR-EU ma 108 obrazów F47993, Caltech Cars 46 obrazów testowych F38869.
• Przedział ufności dla zaobserwowanych 99% (Clopper-Pearson, 95%, obliczenia H1): 100 pojazdów → 94,55–99,97%; 500 → 97,68–99,67%; 1000 → 98,17–99,52%; 2000 → 98,46–99,39%; 5000 → 98,68–99,26%. Połowa szerokości ±0,5 pkt proc. wymaga ok. 1521 pojazdów, ±0,25 pkt proc. ok. 6085 (wzór n = 1,96² · p(1−p) / d², H2).
• Aby jednostronna 95-procentowa dolna granica wynosiła co najmniej 99%, potrzeba: 299 pojazdów bez błędu (reguła trzech daje 300 F43041), 473 przy 1 błędzie, 1049 przy 5, 1693 przy 10, 2902 przy 20 (H3). System o rzeczywistej skuteczności 99,5% przechodzi taki odbiór z prawdopodobieństwem 44% przy 1000 pojazdach, 79% przy 2000 i 92% przy 3000 (H4). Odbiór NASP na 50 kolejnych pojazdach F39424 przy wyniku 50/50 potwierdza tylko ≥94,2% (H5); wynik fuzji 99,1% na OpenALPR-EU F36865 (≈107/108) ma przedział 94,9–100% (H7).

Warunki i rozbieżnościLiczby producentów to deklaracje bez metodyki; Flock nie podaje próby ani warunków poza „optymalnymi warunkami wdrożenia” F38196, a deklaracje 99,9% pomijają tablice niestandardowe, które według komentatora branżowego stanowią kilka procent ruchu F45332. Test NCDOT dotyczy tablic USA i terminali promowych, nie parkingów w Polsce. Przedziały ufności zakładają niezależne pojazdy S; kolejne rejestracje tego samego auta nie są niezależne: wynik 358/359 w badaniu brytyjskim pochodzi z 5 samochodów F45374, więc jego przedział 98,5–100% (H7) jest zbyt wąski.

S06-Q2Które źródła błędów tworzą lukę do 99% (pominięta detekcja, mała tablica, rozmycie ruchu, kąt, odblaski, brud, tablice dwurzędowe, podobne znaki, takie jak O i 0 albo B i 8, tablice zagraniczne, polskie tablice specjalne) i jaki jest udział każdego z nich w opublikowanych badaniach lub danych z eksploatacji?

OdpowiedźDetekcja nie jest główną luką: na ośmiu zbiorach wykrycie pojazdu ma 99,92% czułości, a wykrycie tablicy 99,51% F38914F38915, YOLOv4 przekracza 99,5% F47127, a autorzy kilku prac wskazują rozpoznanie znaków jako wąskie gardło F45115F47622. Jedyny w źródłach rozkład przyczyn błędnych odczytów rzeczywistych tablic europejskich (Wielka Brytania, 700 błędów) to: śruby i zaślepki śrub w obrębie znaków 72,6%, zabrudzenia i ślady 23,0%, zasłonięcie 1,8%, uszkodzenie 1,8%, niedozwolona czcionka 0,9% F41960. Pozostałe źródła podają spadek skuteczności w danym warunku, a nie udział w błędach: noc przy świetle reflektorów 55,7% wobec 95,3% w dzień, kąt powyżej 45° −42,8 pkt proc., ulewa −33,3 pkt proc. (tablice nepalskie) F49635F45313F45312, odblask 50% (tablice marokańskie) F45214, rozmycie 52,0–68,4% wobec 98,8% (CCPD, Chiny) F38105F38999. Udziałów dla tablic dwurzędowych, zagranicznych i polskich tablic specjalnych źródła nie podają. Budżet błędu dla 99% na tablicy 7- i 8-znakowej wynosi 0,143% i 0,126% na znak, a przy 99,5% wykrycia 0,072% i 0,063% (obliczenia A).

Dowody

• Śruby: 63% z 1238 brytyjskich pojazdów ma widoczne śruby w obrębie znaków F45965; pozycje 2 i 5 dają razem 50% błędów od śrub F41966; dziesięć znaków odpowiada za 55,6% błędnych odczytów F45378; zaślepki wyglądają inaczej w świetle widzialnym i w podczerwieni (żółta jako „L”, czarna jako „O”) F47657.
• Mylone pary: B/8, G/6, I/1 F36979; E/F i B/8 F39830; w Roseville (USA) 71% z 1427 alarmów Flock wynikało z błędnego odczytu, m.in. 9→8, 3→2, 1→4 F38195; Sighthound odczytywał 6 znaków zamiast 7 F39824. Nierównowaga klas wzmacnia pomyłki: w SSIG-SegPlate litera O występuje 746 razy, Q 135 razy F35486.
• Część błędów jest stała dla pojazdu: tablice błędnie odczytane prawie w każdej klatce (np. 5 i S) F45432; po fuzji wielu klatek wszystkie pozostałe błędy dotyczyły pozycji, dla których detektor znaków nie zaproponował poprawnej klasy w żadnej klatce F43867.
• Tablice zagraniczne: czcionki, składnia, symbole i odstępy tablic z państw Schengen sprawiają kłopot OCR w Wielkiej Brytanii F43037; przy testach na nowych zbiorach większość błędów wynika z innej czcionki i elementów takich jak herb między znakami F47129; ukraińskie tablice używają cyrylicy podobnej do łaciny i kolidują z prefiksami bułgarskimi i hiszpańskimi F37995F37996.
• Polskie tablice: w części wyróżnika pojazdu (po odstępie) nie występują litery B, D, I, O, Z, z wyjątkiem tablic indywidualnych F38590; wiodące zero jest częścią numeru F38592; tablice profesjonalne mają format X12 34P56 z literą P na drugiej pozycji F38593; czarne tablice sprzed 2001 r. pozostają ważne F38591. Zbiór z Katowic obejmuje zimę, błoto, śnieg, odblaski i różne kąty, ale bez wyników skuteczności F37317.
• Zima: śnieg zakrywający tablicę uniemożliwia odczyt F37611; IACP wskazuje brudne lub wygięte tablice, przeszkody i nietypowy wzór tablicy jako główne problemy F37610.

Warunki i rozbieżnościWyniki z Nepalu, Maroka, Chin i Brazylii nie przenoszą się wprost na tablice polskie. Rozkład brytyjski dotyczy błędnych odczytów, nie braków odczytu, i tablic z typowym brytyjskim mocowaniem. Źródła różnią się co do detekcji: w danych nepalskich noc obniża samo wykrycie do 78,2% F45311, podczas gdy w zbiorach publicznych wykrycie przekracza 99% F38915. Brak danych w źródłach o udziale tablic dwurzędowych, zagranicznych i polskich tablic specjalnych w błędach.

S06-Q3Które techniki podnoszą skuteczność całego ciągu do 99% i wyżej: głosowanie z wielu klatek, walidacja składni formatów polskich i unijnych, klasyfikacja kraju, zespoły i fuzja modeli, progi pewności z drugim odczytem, super-rozdzielczość, obsługa mylonych znaków? Podaj zmierzone zyski.

OdpowiedźNajbliżej 99% na pojazd są wdrożenia łączące głosowanie z wielu wycinków, dane z własnego obiektu i poprawne ustawienie kamery: 98,6% przy 15–20 wycinkach na pojazd, gdzie wzrost danych z 3 tys. do 18 tys. etykiet dał 95% → 98,6% (test operatora WINK, jedna kamera bramowa osiedla) F41562F42840F42846, oraz 99% po przebudowie wjazdów (deklaracja TRUETECH) F40986. Największe zmierzone zyski pojedynczych technik: głosowanie czasowe 66,7% → 81,8% (błąd mniejszy o 45%, tablice rumuńskie) F45431, fuzja ośmiu modeli 92,4% → 97,6% na znanych rozkładach F35496F51001, ale tylko 87,6% → ponad 90% na nowych zbiorach F49178, walidacja składni +6,15 pkt proc. (95% CI 4,97–7,44), główny składnik poprawy F44112F44113. Super-rozdzielczość nie poprawia odczytu przy wycinkach 80–150 px typowych dla bram F42844, a próg pewności działa tylko po kalibracji na lokalnych tablicach F35208F36869. Głosowanie ma sufit: błąd stały we wszystkich klatkach (śruba, brud, czcionka) dotyczący odsetka s pojazdów ogranicza wynik do 1 − s, więc 1% takich pojazdów zatrzymuje system na 99% (obliczenia C3). Dla klasyfikacji kraju brak danych w źródłach o zmierzonym zysku.

Dowody

• Głosowanie, teoria (błędy niezależne S, obliczenia C): przy 90% poprawnych klatek ścisła większość z 5 klatek daje 99,14%, z 9 klatek 99,91%; głosowanie na znak przy 99% na znak i 3 klatkach daje 99,79% dla 7 znaków. Pomiary są niższe, bo błędy się powtarzają: po głosowaniu zostają tablice mylone prawie w każdej klatce F45432. Bez poprawnego modelu ruchu fuzja spada poniżej pojedynczej klatki (15,1% na nagraniach z ruchomej kamery w Wietnamie), a model geometryczny podnosi ją do 26,7% F42831F42832F43873F44959. Autorzy jednej z prac proponują uznawać za pewne trzy kolejne zgodne odczyty tej samej tablicy F47617. W konkursie ICPR 2026 na odczyt tablic w niskiej rozdzielczości trzecie miejsce (80,17%) osiągnięto samym głosowaniem znaków z wielu klatek, bez super-rozdzielczości F41564. Przy 30 km/h i strefie 4 m pojazd daje 7,2 klatki przy 15 kl./s i 2,4 przy 5 kl./s; przy 10 km/h 21,6 klatki przy 15 kl./s (obliczenia D).
• Składnia: reguła polska wyklucza B, D, I, O, Z w części wyróżnika pojazdu F38590, co pozwala zamieniać tam O→0, B→8, I→1, Z→2 S; tablice indywidualne są wyjątkiem F38590. Reguły zawodzą dla pojazdów z innych krajów i tablic indywidualnych F47996F49855; dla tablic europejskich jedyną regułą w badaniu wieloregionowym była długość 5–8 znaków F38919. System rumuński przyjmuje wynik dopiero po trzech odczytach z pewnością >0,4 zgodnych z wyrażeniem regularnym formatu F44435. Dokumentacja anpr-ocr nie podaje zmierzonego spadku błędów F45537.
• Klasyfikacja kraju i układu: tablica europejska o kolorach i liczbie znaków jak chińska została zaklasyfikowana jako chińska F38916; wyłączenie augmentacji kolorów usunęło ponad połowę błędów klasyfikacji układu F38917. Plate Recognizer zaleca ustawienie regionu, aby ograniczyć pomyłki O/0, bez liczb F36381; fast-plate-ocr ma opcjonalne rozpoznanie regionu F33230.
• Fuzja: wybór odczytu o najwyższej pewności daje gorsze wyniki niż głosowanie, bo modele mylą się z wysoką pewnością F36869F36870; fuzja trzech najszybszych modeli (91,1%) jest gorsza od najlepszego pojedynczego (92,4%) F49691; autorzy zalecają 4–6 modeli F34606. Na zbiorze silnie pochylonych tablic fuzja daje 65,4% F37676.
• Progi pewności i drugi odczyt: przy pewności poniżej progu kadr trafia do kolejki weryfikacji, a szlaban działa według reguły; takich zdarzeń jest „ułamek procenta zamiast kilku procent” (deklaracja TRUETECH) F40990. Frigate ma domyślne progi 0,7 (wykrycie) i 0,9 (rozpoznanie) F37942. Pewność silników OCR nie jest skalibrowana: tekst z 52,9% CER otrzymał ok. 95% pewności F46674, a wynik 95 nie oznacza 95% poprawnych odczytów bez kalibracji na lokalnych tablicach F35208.
• Super-rozdzielczość: może obniżyć OCR o 9% na czytelnych obrazach (praca Nguyen i in. cytowana przez WINK) F42856; poniżej 35 px długości tablicy nie pomaga, poniżej 50 px pomaga F37986F37987; GAN podnosi odczyt wycinków 16×16 px z 0,02% do 66,59% F44404; specjalizowane modele dają 3–5% na wycinkach poniżej 60 px F44235. Nawet po rekonstrukcji wynik (39,0% i 72,0%) jest daleko od wyniku na oryginałach (96,6% i 99,4%) F48187F44367, a model tworzy fałszywe znaki (3→J, Z→2) F46612.
• Mylone znaki: wspólna klasa 0/O z regułami kraju działa, ale „załamuje się” dla tablic zagranicznych i indywidualnych F49855; ukierunkowana augmentacja słabo rozpoznawanych znaków (sztuczny cień, barwa światła słonecznego, rozmycie) F47626; Frigate pozwala dopuścić warianty, np. [S5]LL 1234, i odległość edycyjną 1 przy dopasowaniu do listy znanych tablic F35365F35364. Sposób liczenia O i 0 zmienia wynik o 1,4 pkt proc. (96,4% wobec 95,0%) F45222.
• Warunki pracy, w których źródła podają wysoką skuteczność:

Warunki i rozbieżnościWyniki fuzji pochodzą z GPU i ze zbiorów brazylijskich, chińskich, tajwańskich i amerykańskich; czas 10,8 ms nie dotyczy CPU ani NPU. Wynik walidacji składni zmierzono na tablicach chińskich przy niskim punkcie wyjścia (53,9%), a filtr pewności na tablicach nepalskich; nie przenoszą się wprost na tablice polskie. WINK i TRUETECH to dane operatora i integratora bez niezależnej weryfikacji. Dla dużych kątów żadne źródło nie pokazuje 99%: najwyższe wartości to 87,5% dla szerokiego zakresu kątów po odtworzeniu perspektywy F47042 i 84,5% czułości dla 0–60° F47074, a zalecenia producentów dotyczą kątów do 30–45° F49653F33906. Wartość ±5° Hikvision dotyczy obrotu tablicy w obrazie, a kąty Plate Recognizer kąta patrzenia kamery, więc nie są ze sobą sprzeczne. Brak danych w źródłach o zmierzonym zysku z klasyfikacji kraju i z walidacji składni polskich tablic.

Założenia S i obliczenia

Skrypt: data/jobs/lpr-cpu-sbc/decyzja/obliczenia/s06.py, wynik: s06.out.

• Błędy znaków są niezależne S; skuteczność tablicy = p_znak^N (A). Polska tablica ma 7–8 znaków S.
• W budżecie przyjęto 99,5% skuteczności wykrycia pojazdu i tablicy S (A, B).
• Błędy kolejnych klatek są niezależne S (C1, C2); wariant optymistyczny zakłada, że błędne odczyty nigdy się nie powtarzają. Model błędów skorelowanych: odsetek s pojazdów ma błąd stały we wszystkich klatkach (C3).
• Zamiana liter na cyfry w części wyróżnika pojazdu zakłada, że tablica nie jest indywidualna S.
• Długość strefy odczytu 3, 4 i 6 m oraz prędkości 10, 20 i 30 km/h S (D).
• Gęstość pikseli liczona dla całej szerokości obrazu, bez obrotu tablicy S (F).
• Kryterium odbioru: jednostronna 95-procentowa dolna granica Clopper-Pearsona ≥99%; pojazdy w próbie są niezależne S (H).
• Przykład testu McNemara (1000 pojazdów, 15 i 8 błędów, 11 rozbieżnych) S jest ilustracją metody porównania dwóch konfiguracji na tych samych przejazdach: przy takich liczbach p = 0,065, czyli różnica nie jest istotna (H6).

Część 7Duże kąty najazdu

S07-Q1Do jakich kątów poziomych i pionowych komercyjne kamery i silniki LPR niezawodnie odczytują tablice (maksymalne kąty deklarowane przez producentów) i jak szybko w testach spada skuteczność poza tymi granicami?

OdpowiedźWiększość producentów deklaruje granicę 25–35° w poziomie i 30–40° w pionie: Hikvision 30°/30° F45443, Adaptive Recognition CARMEN 30° F45916, ISS 30°/40° F48779, Streaming Networks 35°/35° F48780, Vaxtor yaw poniżej 25° i pitch poniżej 30° F43451. Szerzej deklarują Genetec (50° w poziomie, 30° w pionie) F48781, model Intel license-plate-recognition-barrier-0001 (±45° w obu osiach) F34559 i Plate Recognizer, który wg producenta zaleca do 45° w obu osiach, a sam silnik ma czytać do 70° z boku i 53° w pionie, bez odczytu przy 75° F34212F34213. Niezależnych pomiarów skuteczności komercyjnych silników w przedziałach kąta źródła nie zawierają. Najbliższe takim pomiarom są tabela poradnika projektowego (0–15°: ponad 98%, 15–30°: 90–98%, 30–45°: 60–85%, powyżej 45°: poniżej 50%) F46872 oraz testy terenowe Plate Recognizer cytowane w pracy naukowej: wyraźny spadek powyżej 70° i odczyt „prawie niemożliwy” przy 75° F46446. Poza granicą deklarowaną najpierw zawodzi OCR, a nie detekcja: tablica jest wykrywana, ale tekst się nie rozczytuje F46204, co pokazuje poradnik ENS Security: powyżej 45° tablica jest wykrywana, ale tekst się nie rozczytuje F46204. Wyniki CCPD-Tilt nie dowodzą tej tezy: system bazowy SSD512+HC odczytuje tablice pochylone (52,04) lepiej niż średnio na całym zbiorze (43,42) F48533.

Dowody

• Bosch zbiera w dodatku B swojego opracowania maksymalne kąty dostawców oprogramowania F46593 i zaznacza, że poza nimi ANPR „nie działa niezawodnie”, a kąt poziomy ma być jak najmniejszy F46589F48779F48780F48781.
• Plate Recognizer w teście na własnej stronie odczytał tablicę poprawnie do 53° obrotu obrazu wykonanego funkcją Rotate Image w programie Paint.net F45484. To obrót całego zdjęcia w płaszczyźnie, a nie widok ukośny, więc liczba 53° nie mierzy skrócenia perspektywicznego.
• Wg producenta stosowanie zasad montażu Plate Recognizer zmienia skuteczność z 75% na 98% F35684. ENS Security pisze, że wartości z kart katalogowych (w górnej części przedziału 90–100%) pochodzą z kontrolowanego pasa testowego, a zły kąt lub wysokość na obiekcie obniża je „wyraźnie poniżej 90%” F46208.
• Poradniki instalacyjne podają spójnie: poniżej 25–30° odczyt jest niezawodny, powyżej 45° skuteczność gwałtownie spada F46203; typowa granica silników to 30–35° F46297; powyżej 30° kąta najazdu zniekształcenie i odblaski „gwałtownie” obniżają odczyt F46871.
• Praca z 2026 r. na syntetycznej siatce kątów [0°, 89°]² wykazała, że 90–92% siatki daje się odczytać po rekonstrukcji, a skuteczność spada gwałtownie dopiero powyżej ok. 80° w obu osiach. Obrót boczny jest trudniejszy niż pionowy F47944F47945.
• W niezależnym teście z 2018 r. OpenALPR osiągnął 93,0%, a Sighthound 89,8% na zbiorze SSIG. Przy ruchomej kamerze i ruchomym pojeździe oba systemy spadły poniżej 70% F44166F44167. Test nie podaje kątów.

Warunki i rozbieżnościDeklaracje dotyczą osi osobno; kąt łączny przy jednoczesnym przesunięciu bocznym i wysokości jest większy (obliczenia w s07-q4). Wartości 70° i 53° Plate Recognizer to granica silnika wg producenta, a nie poziom 99%. Firma sama zaleca 45° F42504. Tabela ENS Security podaje „kąt poziomy 45–110°” przy odczycie powyżej 98% F47175F47176, ale nie definiuje osi odniesienia, a tekst tej samej strony zaleca poniżej 30° F46209. Loyalty-Secu deklaruje 97–99,8% przy „dużym kącie” bez podania kąta F41108. Tabela 0–15°/15–30°/30–45° F46872 to typowe wartości z poradnika bez opisanej metody pomiaru. Brak danych w źródłach: niezależnych testów silników komercyjnych w przedziałach kąta poziomego i pionowego na tablicach europejskich.

S07-Q2Jakie metody rozpoznają tablice przy dużych kątach: wykrywanie narożników lub punktów charakterystycznych z prostowaniem perspektywy, sieci transformacji przestrzennej (STN), detekcja obróconych ramek, trening na ukośnych tablicach z augmentacji i danych syntetycznych, kilka widoków? Podaj zmierzone wyniki.

OdpowiedźNajwięcej zmierzonych wyników ma wykrywanie czterech narożników i prostowanie homografią: bez prostowania WPOD-NET osiąga 57,69% na zbiorze CD-HARD F37548, homografia z 2012 r. daje po korekcji 97% rozpoznań aut F42147, a rekonstrukcja widoku z 2026 r. podnosi dokładność przy ekstremalnych kątach o 15–38 punktów F47948. STN przed LPRNet daje 91,5% na CCPD2019 (+8,38 pkt) przy kącie poziomym 20–50° F49536F49952 i koryguje pochylenia w zakresie ok. ±35° F47207. Detekcja obróconych ramek (OBB) z regresją kąta podnosi dokładność tablic z 82,7% do 91,5% F43072, ale wycinek i tak jest prostowany przed OCR F42223. Dane syntetyczne dają +5% F37553 do +12,1% F42572. Głosowanie wielu modeli OCR podnosi średni wynik z 92,4% do 97,6% F35217, a głosowanie po wielu wycinkach tej samej tablicy daje 98,6% skuteczności systemu przy bramie F43498. Pomiarów dla układu dwóch kamer źródła nie zawierają. Większość wyników pochodzi ze zbiorów chińskich i brazylijskich i nie przenosi się wprost na tablice polskie.

Dowody

• Prostowanie po narożnikach przed OCR to w literaturze częsty krok, który „znacznie” zwiększa odporność na widok ukośny F37814F39442. Mocno pochylona tablica jest dowolnym czworokątem, nie równoległobokiem, więc wystarczają dopiero cztery narożniki i homografia F34390F44845. STN-OCR z przekształceniem afinicznym obsługuje przesunięcie, obrót i pochylenie, ale nie perspektywę F35778.
• Prostowanie nie zastąpi słabego OCR: WPOD-NET wykrył tablice ukośne z dokładnością 0,90, a OCR na MobileNets odczytał tylko 0,31 F44252F44253. Sieci prostujące mogą też psuć proste obrazy, co pokazały badania tekstu w scenach F50958F50995.
• Ulepszony LPRNet (GSS) zyskał średnio 5,86 pkt na CCPD, ale przy dużej zmianie kąta ani on, ani bazowy LPRNet nie dały dobrych wyników F42566F42565.
• Prace nad STN zauważają, że metody STN łączą kilka modeli i wymagają dużych zbiorów treningowych F34392. STN uczy się bez nadzoru geometrycznego, tylko od straty rozpoznawania F47209.
• Dane syntetyczne: ECCV 2018 zyskało ≈5% na AOLP-RP F37553; Laroca i in. (2025) porównali generowanie z szablonów, permutację znaków i GAN i opisali „znaczny” wzrost w testach w obrębie zbioru i między zbiorami F42716; BLPR trenował detektor na scenach z Blendera z ekstremalną perspektywą i osiągnął 89,6% poprawności znaków na rzeczywistych tablicach boliwijskich F35468F35467. Część prac celowo wyłącza zniekształcenie perspektywy z augmentacji F42804.
• Wiele klatek: WINK osiąga 98,6% skuteczności systemu (CTC-CRNN, 1,1 M parametrów) z głosowaniem po wielu wycinkach, mierzone na 314 979 wycinkach z jednej kamery przy bramie osiedla F43498. Przy testach między zbiorami największą różnicę wyników strategii głosowania autorzy obserwują na CD-HARD z mocno pochylonymi tablicami, gdzie pojedynczy CRNN osiąga 31,7% F37392F37390.
• Koszt obliczeń na CPU i NPU: Intel barrier-0001 potrzebuje 0,328 GFLOPs F34564, LPTR-AFLNet poniżej 1 GFLOP F35081, a zoptymalizowany układ OBB z Transformerem wg ustalenia działa z szybkością 9,8 kl./s na Raspberry Pi 4 z Coral TPU (ARM z NPU) F43075.

Warunki i rozbieżnościWyniki z CCPD, CRPD i LSV dotyczą tablic chińskich, a z RodoSol-ALPR tablic brazylijskich. Po zmianie zbioru STN+LPRNet traci od 2,2 do 6,7 pkt (91,45→89,27 i 92,0→85,31) F48156. Wyniki prostowania homografią (97,16%) mierzą poprawność geometrii, nie odczytu. Ustalenie o 9,8 kl./s na Raspberry Pi 4 z Coral cytuje w dowodzie tylko wynik 42,3 kl./s na RTX 3090 F43075. Ustalenia nie podają liczby dla WPOD-NET z prostowaniem na CD-HARD. Źródła nie zawierają pomiaru 99% dla kąta powyżej 30°: najwyższe zmierzone wartości dla zakresów ukośnych to 91,5% na tablicach chińskich F49536F43072, a 98,6% z głosowaniem po klatkach dotyczy kamery przy bramie bez podanego kąta F43498. Brak danych w źródłach: zmierzonej skuteczności układu dwóch kamer na tym samym pasie przy dużych kątach; producenci zalecają drugą kamerę lub zoom motorowy, gdy tablica ma mniej niż 130–150 px F40848, ale nie podają wyników.

S07-Q3Które zbiory danych i benchmarki zawierają tablice widziane pod dużymi kątami i jak modele na nich trenowane radzą sobie z widokami ukośnymi?

OdpowiedźSpośród zbiorów rzeczywistych jawnie wydzielone podzbiory kątowe ma w źródłach tylko CCPD (Chiny, licencja MIT, ponad 300 tys. obrazów): Rotate i Tilt z adnotacją kąta poziomego i pionowego oraz czterech narożników F34889F34887F37815. Detektory bazowe z 2018 r. osiągają tam 88,19–91,86 AP, a system SSD512+HC 52,04 (Tilt) i 52,82 (Rotate) pełnego odczytu, czyli więcej niż jego średnia 43,42 na całym zbiorze testowym F36413F35395F48533. Nowe modele z prostowaniem dochodzą do 91,5% na podzbiorze z kątem poziomym 20–50° F49536F49952. Ukośne widoki zawierają też AOLP-RP (Tajwan) F37551, CD-HARD (102 obrazy, głównie ukośne) F37552, RodoSol-ALPR (Brazylia, narożniki we wszystkich obrazach) F40911 i syntetyczna siatka kątów 0–89° z 2026 r. F47944. Wyniki z tych zbiorów nie przenoszą się wprost na tablice polskie. Zbiory europejskie ze źródeł (UC3M-LP, polski zbiór z Katowic) nie mają opublikowanych wyników dla widoków ukośnych F40760F40494.

Dowody

• CCPD ocenia odczyt jako poprawny tylko przy wszystkich znakach poprawnych, a detekcję przy IoU powyżej 0,7 F36414F36416. Autorzy sami nazywają swój model RPnet „przestarzałym” F35735.
• Ulepszone modele na CCPD: GSS-LPRNet +5,86 pkt średnio F42566, STN+LPRNet 91,5% F49536, LPTR-AFLNet lepszy od LPRNet także na podzbiorze tilt F35079. Na wideo LSV LPTR-AFLNet osiąga 74,10% (6 znaków) i 71,50% (7 znaków) F35078.
• Uogólnianie między zbiorami jest słabe: średnia 12 modeli spada z 82,4% do 74,5% po wyłączeniu zbioru z treningu F49838. Prosta sieć rozpoznaje zbiór źródłowy po samym wycinku tablicy w ponad 95% przypadków F33892. Żaden model nie wygrał na wszystkich zbiorach F49377.
• Nakładanie się zbiorów: 19,1% obrazów testowych CCPD ma bliskie duplikaty w treningu F39878, a uczciwy podział obniża średnią z 80,3% do 77,6% F39444. W AOLP-B 67,6% obrazów testowych ma duplikaty F35740. Narożniki w CCPD są niedokładne, a obrazy mocno skompresowane F39879F36988.
• Jako jedyne spośród ośmiu badanych zbiorów CCPD i RodoSol-ALPR mają narożniki we wszystkich tablicach; pozostałe trzeba oznaczać ręcznie przed prostowaniem F36003.

Warunki i rozbieżnościŹródła różnie opisują CCPD: zdjęcia z ręcznych aparatów pracowników firmy parkingowej na ulicach F35746 albo kamery monitoringu przy wjazdach na parkingi w Hefei F49955. Podają też różną wielkość zbioru: ponad 250 tys. F49955, ponad 300 tys. F34889 i ponad 350 tys. F36002. Wyniki na CCPD, AOLP, CRPD i RodoSol-ALPR dotyczą tablic chińskich, tajwańskich i brazylijskich o innym formacie i kroju niż tablice polskie. Brak danych w źródłach: europejskiego zbioru z adnotacją kąta i opublikowanymi wynikami dla widoków ukośnych.

S07-Q4Jak położenie, wysokość i odległość kamery przy pasie ze szlabanem zmieniają kąt i jakie zasady montażu podają producenci, gdy geometria pasa wymusza widok z boku?

OdpowiedźKąt poziomy zależy od przesunięcia bocznego o i odległości punktu odczytu d: θ = atan(o/d). Przy kamerze na słupku 1,5 m od osi pasa kąt nie przekracza 30°, gdy tablica jest odczytywana co najmniej 2,6 m przed kamerą, a 45° od 1,5 m. Przy przesunięciu 2,5 m (widok z boku, np. z wysepki) potrzeba 4,3 m dla 30° S[obliczenia]. Kąt pionowy rośnie z wysokością: kamera na 2,5 m widzi tablicę z odległości 4 m pod kątem 27°, a z 2 m pod kątem 45° S. Producenci zalecają oddalanie punktu odczytu i dłuższą ogniskową, by zmniejszyć kąt F44896, prowadzenie pojazdu w zakresie ±15° od osi obiektywu F45602, jedną kamerę na pas F46205 i drugą kamerę lub zoom motorowy, gdy tablica ma mniej niż 130–150 px F40848. Widok z boku mieści się w deklaracjach większości silników do 30° w każdej osi F45443F45916F48779, a w deklaracjach Plate Recognizer, Genetec i Intel do 45–50° F34212F48781F34559, jeśli po skróceniu tablica ma co najmniej 100–150 px szerokości F34215F45444. Dla 2 MP oznacza to pole widzenia w punkcie odczytu nie szersze niż 7,1 m przy 45° i 5,0 m przy 60° (T3 w obliczeniach).

Kamera na słupku obok pasa: przesunięcie 1,5 m, wysokość 1,5 m, tablica na 0,5 m, matryca 1/2,8″ S; obliczenia/s07.py, tabela T7.

Dowody

• Przykład Dipol dla Hikvision: kąt pionowy 30° i odległość pozioma 5,2 m dają montaż na 3 m i odległość skośną 6 m; matryca 1/3″, 1920×1080 i obiektyw 6 mm dają przy 6 m pole 4,8 m i 208 px szerokości tablicy UE F45446F45445. Obliczenie kontrolne atan(3,0/5,2) daje 30,0° [obliczenia].
• ENS Security podaje pochylenie w dół 15–30°, wysokość kamer pasowych 3–10 stóp, odległość odczytu równą ok. dwóm wysokościom montażu F46206F46207, a w tabeli wysokość 2,1–3,0 m i odległość 2–10 m F47177. Reguła d = 2h daje kąt pionowy 26,6° [obliczenia].
• Vaxtor dla szlabanów zaleca obiektyw zmiennoogniskowy 2–8 mm przy odległości 2–6 m, rozdzielczość co najmniej 800×600 F43454F43455, a przy ostrym kącie zaleca przestawić kamerę, by tablice były bardziej poziome F45016.
• JB Tecknologies: optimum 15–30° od kierunku jazdy i 15–30° w pionie F46298. Kamera prostopadła do osi pasa „prawie nigdy” nie odczyta tablicy F46302, a kamera nad pasem zbyt stromo patrzy na tablicę F46303.
• Plate Recognizer: kadrowanie samego wjazdu zamiast szerokiego widoku parkingu F42509, kamera skierowana w dół, nie pod słońce F37501, ustawiona pod kątem do reflektorów F34217. Zbyt wysoki lub zbyt odległy montaż zmniejsza liczbę pikseli i zniekształca tablicę F42491. Powyżej ok. 9 m potrzebna jest kamera 4 MP F42506, a 4 MP z obiektywem 6 mm daje „znacznie” więcej pikseli niż z 2,8 mm F40846.
• Bosch zaleca montaż powyżej wysokości tablicy przeciw olśnieniu F47690. Arecont Vision pokazuje, że niski montaż na wprost zwraca najwięcej światła IR, a wysoki i stromy odbija je w bok F43644F43645. Większa wysokość zmniejsza zasłanianie przez inne pojazdy, ale zwiększa pochylenie tablicy F42979.
• Kamera dwuprzetwornikowa LTS CMIP7C44WLPR-32R łączy przetwornik 4 MP z zoomem motorowym do tablic i przetwornik 4 MP z obiektywem 4 mm do widoku sceny. Producent kieruje ją do szlabanów i wjazdów na parkingi F42189F42190.
• Dla ruchu do 40 km/h Digital Watchdog dopuszcza kąt pionowy do 30° F44705.
• CCTVplanner zaleca dla sterowania szlabanem 300–400 px/m i 30% zapasu na pochylenie i spadek ostrości na brzegach kadru F45605F45604.
• Praca z 2026 r. wskazuje, że zakres odczytywalnych kątów wyznacza głównie geometria obrazowania, a architektura sieci wpływa na wydajność i stabilność F47946.

Warunki i rozbieżnościZalecenia montażowe są rozbieżne: od 15° (CCTV Camera World, PlakaNet) F40721F45081 przez 30° (Hikvision, Adaptive Recognition) F45443F45916 do 45° (Plate Recognizer) F34212. Wartości wysokości 5–7 m i odległości 10–25 m z poradnika F46873 dotyczą dróg, nie szlabanów. Producenci podają granice dla osi osobno, a przy kamerze z boku i z góry kąt łączny jest większy od każdego z kątów składowych (31° łącznie przy 27° poziomo i 18° pionowo w T7). Brak danych w źródłach: zmierzonej skuteczności przy konkretnej geometrii pasa ze szlabanem oraz zasad producentów dla układu dwóch kamer na jednym pasie.

Założenia S i obliczenia

• Skrypt data/jobs/lpr-cpu-sbc/decyzja/obliczenia/s07.py, wynik w s07.out.
• Wzory: szerokość pozorna = W·cos θ_poz; wysokość pozorna = H·cos θ_pion; px/m = rozdzielczość pozioma / szerokość pola widzenia w punkcie odczytu; pole widzenia = R·szerokość matrycy / ogniskowa (wzór f = D·a′/A F35908); px na tablicy = px/m · W · cos θ (wzór Plate Recognizer F40849 uzupełniony o cos θ); kąt poziomy = atan(o/d); kąt pionowy = atan((h_kamery − h_tablicy)/d). Przybliżenie ortograficzne, bez dystorsji obiektywu, ostry i dobrze naświetlony obraz.
• S Tablica UE 520×110 mm F44218; wysokość znaku 70 mm według przykładu Commonlands F41016; 2 MP = 1920×1080 F45445, 4 MP = 2560×1440 F43815; ta sama matryca 1/2,8″ o szerokości 5,4 mm dla 2 i 4 MP F45609; tablica na wysokości 0,5 m; w przykładzie T7 przesunięcie kamery 1,5 m od osi pasa i wysokość 1,5 m.
• Skrócenie szerokości (T1): cos 30° = 0,866, cos 45° = 0,707, cos 60° = 0,500, cos 70° = 0,342. Proporcja tablicy 4,73 spada do 3,34 przy 45° i 2,36 przy 60°.
• Piksele na szerokości tablicy (T1) przy polu widzenia 3 m (kamera wykadrowana na pas): 2 MP 333/288/235/166/114 px, 4 MP 444/384/314/222/152 px dla 0/30/45/60/70°. Przy polu 6 m: 2 MP 166/144/118/83/57 px, 4 MP 222/192/157/111/76 px.
• Maksymalne pole widzenia w punkcie odczytu dla ≥100 px (cel Plate Recognizer F34215) (T3): 2 MP 9,98/8,65/7,06/4,99 m, 4 MP 13,31/11,53/9,41/6,66 m dla 0/30/45/60°. Dla ≥150 px (dolna granica optimum Hikvision F45444): 2 MP 6,66/5,76/4,71/3,33 m, 4 MP 8,87/7,69/6,28/4,44 m.
• Maksymalna odległość kamera–tablica dla ≥100 px (T4): 4 mm 2 MP 7,4/6,4/5,2/3,7 m, 4 MP 9,9/8,5/7,0/4,9 m; 2,8 mm 2 MP 5,2/4,5/3,7/2,6 m; 6 mm 4 MP 14,8/12,8/10,5/7,4 m (0/30/45/60°).
• Wysokość znaku 70 mm (T2): przy polu 6 m i 2 MP 22,4 px na wprost i 19,4 px przy 30° w pionie, czyli na dolnej granicy 20–30 px Vaxtor dla tablic UE F43452; przy polu 3 m 44,8 i 38,8 px.
• Wniosek z obliczeń: przy 60° kamera 2 MP wymaga pola widzenia nie szerszego niż 5 m w punkcie odczytu, a 4 MP nie szerszego niż 6,7 m, by utrzymać 100 px. Przy 45° granice wynoszą 7,1 m i 9,4 m.

Część 8Wyróżniki: co może dać więcej niż zwykłe systemy LPR

S08-Q1Jakie funkcje poza odczytem tablicy oferują czołowe produkty LPR (marka, model i kolor, kraj, typ pojazdu, kierunek jazdy, dopasowanie pojazdów bez czytelnej tablicy, wykrywanie brudnych, zasłoniętych lub fałszywych tablic) i które z nich działają na brzegu na CPU?

OdpowiedźCzołowe produkty oferują wszystkie wymienione funkcje, ale nierówno: marka, model i kolor (MMC) oraz typ pojazdu są standardem kamer i silników klasy premium, kraj i kierunek należą do funkcji podstawowych, a alarm o sklonowanej tablicy deklaruje tylko część dostawców, np. Neural Labs F34465. Na brzegu na samym CPU działają: Plate Recognizer Stream z MMC (wg producenta Raspberry Pi 4 GB obsługuje 1 kamerę 1080p z MMC przy dużym ruchu) F48397, F48395, silnik Carmen w kamerze Vidar na czterordzeniowym CPU 4×1,4 GHz z MMR w standardzie F50904, F51211 oraz Eyedea ANPR na CPU AArch64 F44772. ultimateALPR SDK ma osobno włączane moduły koloru, marki i modelu, typu nadwozia i kraju oraz przyspieszenie na NPU Amlogic i NXP F42895, F42897; Hailo wskazuje MMCR jako zastosowanie swoich akceleratorów F34080. Pojazdy bez tablicy zgłaszają Plate Recognizer (typ, marka, model, kierunek, kolor) F48294 i ultimateALPR (opcja car_noplate_detect_enabled, domyślnie wyłączona) F42896; produktu parkingowego, który dopasowuje pojazd bez tablicy przez ReID, ustalenia nie opisują. Część funkcji działa tylko w chmurze, np. rozpoznawanie akcesoriów pojazdu w Plate Recognizer (70 USD miesięcznie za kamerę, wersja lokalna „wkrótce”) F49962, F49964.

Dowody

• PR Stream działa bez GPU na ARMv8 (Raspberry Pi 4, Banana Pi M4, Orange Pi) i x86 F48395; MMC i orientacja to włączane funkcje zwiększające zużycie RAM F48396; na Jetson Orin Stream i Snapshot pracują na samym CPU F40454; Intel Core i3-4100M (PassMark 2440) wystarcza na 2 kamery z MMC przy dużym ruchu F48400 — wszystko wg producenta.
• ultimateALPR: każdy z modułów VCR, VMMR, VBSR i LPCI dodaje opóźnienie i jest domyślnie wyłączony F42895; rozpoznawanie zwraca pewność 0–1 dla każdego znaku F42894.
• NPU RK3588: YOLOv8n 640×640 daje 46 kl./s przy 1080p, a CPU pozostaje wolne; 137–152 MB RSS na strumień F47116, F47117. To miejsce na detektor pojazdu i klasyfikator typu poza CPU.
• Badania (GPU, punkt odniesienia): potok detekcja pojazdu, kolor, marka i podmodel, OCR trwa 42–58 ms na klatkę na GTX 2070; marka i podmodel ≈0,92, kolor macro-F1 0,88 F49803, F51228 — tylko 6 podmodeli popularnych w Meksyku F50378. VLM PaliGemma 3B bez douczania: marka i model 72,0% wobec 79,8% wyspecjalizowanego EfficientNet F42555.
• Weryfikacja tablicy atrybutami pojazdu (UFPR-VeSV, Brazylia): zgodność „LPR + typ” 96,2% przy 3,8% konfliktów; najsurowsza kombinacja (LPR, kolor, marka, model, typ) 81,1% walidacji i 68,4% odzysku błędnych odczytów F45043; zestawienie atrybutów z rejestrem tablic wskazuje błędy ALPR F40381.

Warunki i rozbieżnościLiczby skuteczności MMC i kierunku to deklaracje producentów; niezależnych testów MMC na pojazdach europejskich w ustaleniach brak. W zbiorze UFPR-VeSV obrazy nocne IR stanowiły 21,5%, a dały 53,4% błędów marki F45044, czyli błąd marki na IR występował ok. 4,2 razy częściej niż w dzień (obliczenia/s08.out, p. 4); zbiór brazylijski nie przenosi się wprost na Polskę. Kolor nocą jest niewiarygodny F42873, więc przy wjeździe z oświetlaczem IR zostają marka i typ. Materiały PR podają sprzeczne wymagania: pełny przód lub tył pojazdu F42874 wobec 40% widocznego pojazdu F37223. Brak danych w źródłach o skuteczności wykrywania klonów oraz brudnych i zasłoniętych tablic.

S08-Q2Na co skarżą się użytkownicy, instalatorzy i operatorzy parkingów w obecnych systemach LPR przy wjazdach i jakie funkcje rozwiązałyby te problemy?

OdpowiedźNajczęstsze skargi dotyczą błędnych odczytów i pominiętych pojazdów, a główna przyczyna leży w ustawieniu kamery, nie w modelu F43471. W Roseville 71% z 1427 alertów Flock z lat 2023–2024 wynikało z błędnych odczytów: pomylone znaki (9 czytane jako 8), rozmyte obrazy, pominięte pojazdy F46622, F46623; producent przypisał to kamerom zamontowanym wyżej i dalej niż zaleca F46625. W brytyjskich parkingach brak odczytu wyjazdu lub wjazdu („double dipping”) wynika zwykle ze źle zamontowanych kamer F44310. Wg Plate Recognizer stosowanie zasad ustawienia kamery decyduje o skuteczności 75% albo 98% F36424 (wersja strony w języku hindi: 75% → 98–99% F44689); przy 500 wjazdach na dobę to 125 albo 10 interwencji dziennie (obliczenia/s08.out, p. 1). Dalsze skargi: noc i odblaski F34373, pogarszanie się skuteczności przez kurz na obiektywie i dryf kalibracji F48309, F48260, rzadkie aktualizacje silników F36421, zawyżane deklaracje skuteczności F48920 i koszt ręcznej obsługi każdego błędu F34491, F43477. Rozwiązują je: asystent ustawienia kamery z pomiarem na żywo, ciągła diagnostyka jakości i dryfu, głosowanie wieloklatkowe z walidacją formatu, obsługa pojazdów bez odczytu oraz uczenie na poprawkach operatora.

Dowody

• Przy 2000 wjazdów na dobę różnica między 97% a 99% to 60 wobec 20 interwencji dziennie (obliczenia/s08.out, p. 1); przykład z F43477 sprawdza się rachunkiem: 0,92 × 0,951 = 0,875 → 250 interwencji.
• Na lotnisku w Exeter szlaban nie podniesie się bez poprawnej tablicy w rezerwacji, a kierowca musi pobrać bilet i może ponieść dodatkowe koszty F46597.
• Integracje działające w demonstracji mają w eksploatacji problemy z opóźnieniem i niezawodnością F34493; gęsta sieć ANPR bez centralnego systemu prowadzi do „zmęczenia alarmami” F48307.
• Modele LPR trenowane na jednym zbiorze słabo działają na innych F34076; część systemów ma kłopot z tablicami o czerwonawym tle, wytłaczanymi znakami i tablicami z innych stanów F48301.
• PR deklaruje kąt pochylenia do 53° i kąt boczny do 70°, bez odczytu przy 75° F34371; śnieg i mgła zasłaniające tablicę uniemożliwiły odczyt F37707.

Warunki i rozbieżnościDane z Roseville dotyczą policyjnych alertów w USA, nie parkingu, a wyjaśnienie o montażu pochodzi od producenta F46625. Wypowiedź o double dipping opiera się na źródłach magazynu Which?, nie na pomiarze F44310. Para 75%/98% to deklaracja producenta bez niezależnego testu F36424. Brak danych w źródłach: ankiety lub statystyki skarg operatorów parkingów w Polsce.

S08-Q3Które najnowsze kierunki badań i produkty zagraniczne (modele wizyjno-językowe do tablic, super-rozdzielczość tablic niskiej jakości, rozpoznawanie niezależne od układu tablicy, samouczenie z poprawek operatora, automatyczny asystent ustawienia kamery, diagnostyka jakości obrazu) mogłyby wyróżnić brzegowy system LPR na CPU i które są wykonalne na CPU komputera SBC?

OdpowiedźNa CPU SBC wykonalne i wartościowe są: asystent ustawienia kamery, diagnostyka jakości i dryfu, głosowanie wieloklatkowe i fuzja z walidacją formatu, rozpoznawanie niezależne od układu tablicy na lekkich modelach oraz zbieranie poprawek operatora z treningiem poza SBC. VLM jako czytnik podstawowy wymaga GPU F43928; model 3B na SBC generuje 5–7 tokenów/s F43059, F41903, co daje 3,2–4,9 s na zapytanie bez kosztu enkodera obrazu albo ok. 84 s przy wolniejszym pomiarze prefill (obliczenia/s08.out, p. 5), więc nadaje się tylko na asynchroniczną drugą opinię. Super-rozdzielczość nie pomaga przy kamerach bramowych z wycinkami 80–150 px F51072 i może pogorszyć OCR na czytelnych obrazach o do 9% F50421; pomaga przy wycinkach 20–50 px F51073.

Dowody

• VLM: modele ogólne mają lukę domenową wobec obrazów z kamer drogowych i wymagają douczenia F41162; w korekcie tekstu na zdjęciach GPT-4o poprawił 16 z 50 błędów (32%), ludzie 41 z 50 (82%) F47396; małe VLM (QwenVL-3B, InternVL-2B) tracą w trybie OCR + korekta F47397.
• LLM na SBC: Phi-3.5 Mini na Raspberry Pi 5 ≤7,1 tokena/s F39839; Phi-3 na NPU RK3588 (RKLLM) 6 tokenów/s, konwersja modelu na osobnym x86 F41907; prefill na Pi 4: 1000 tokenów w 3–5 s F40738, ale w tabeli tego samego źródła ~7 tokenów/s F40736.
• Super-rozdzielczość ma sens, gdy OCR jest zamknięty i nie da się go douczyć F38646; WINK uczy OCR na wycinkach losowo zmniejszanych do 40–100% rozmiaru i dzięki temu czyta słabe obrazy bez SR F38645. Koszt SR na przejazd: LCDNet 0,93 s dla 15 wycinków, Real-ESRGAN 1,89 s (obliczenia/s08.out, p. 7).
• Zasłonięcia: wielowidokowy WTEF osiąga 84% pełnych odczytów na prawdziwych zasłoniętych tablicach wobec 19–21% modeli jednoklatkowych (LPRNet, RPNet, EuLPR) i 66% CLIP F44482; adaptacyjne zatrzymanie zmniejsza liczbę użytych widoków o do 56% F42826.
• Redukcja błędów: głosowanie WINK −61%, fuzja modeli −68%, więcej etykiet −72% (obliczenia/s08.out, p. 3).
• Dane do douczenia: zbiór UniDataPro z 83 700+ zdjęciami polskich tablic i plikami CSV z tekstem F37533.
• Samouczenie na jednym obiekcie: 2000 poprawek zbiera się 400 dni przy 500 wjazdach i 1% poprawek, 33 dni przy 2000 wjazdach i 3% (obliczenia/s08.out, p. 6).
• Monitoring VMS dotyczy stanu urządzeń i serwerów, np. status serwera LPR w XProtect F43372 i monitor wydajności kamer F44683; polecenie camera-status w BoringBot nie ma metryki jakości obrazu, ostrości ani ekspozycji F39759.

Warunki i rozbieżnościNeural Sentinel nie podaje sprzętu przy 152 ms F44787, ale stwierdza, że model 3B wymaga GPU F43928; dane pochodzą z bramek autostradowych, nie z parkingu F41163. Wyniki SR dotyczą zbiorów brazylijskich i chińskich i nie przenoszą się wprost na tablice polskie. TransLPRNet obsługuje tylko tablice chińskie F50752; zbiór CBLPRD-330k do zasłonięć jest syntetyczny, bez rozmycia ruchu i pogody F44486. Prefill na Pi 4 różni się w jednym źródle o rząd wielkości F40736, F40738. Licencja zbioru UniDataPro: brak danych w źródłach. Koszt CPU metryk BRISQUE i CLIP-IQA: brak danych w źródłach.

Wyróżniki uszeregowane według wartości dla klienta parkingu i wykonalności na SBC

1. Asystent ustawienia kamery z oceną gotowości stanowiska. Usuwa główną przyczynę błędów F43471, F44310; różnica 75% wobec 98% F36424 to 125 wobec 10 interwencji na dobę przy 500 wjazdach (obliczenia/s08.out, p. 1). Mierzy szerokość tablicy, wysokość znaku, kąt i czas w kadrze z wyjścia detektora i porównuje z progami F34372, F45572, F43473, F45573, F37288. Zwykłe kamery CCTV nie mają czujnika orientacji jak Axis F37522, więc kąt trzeba szacować z geometrii tablicy S.
2. Ciągła diagnostyka jakości i dryfu z alarmem. Odpowiada na kurz i przesunięcia kamery F48309, F48260 oraz pominięte pojazdy F46624; wskaźnik zweryfikowanych trafień wskazuje problemy z ustawieniem kamery F43544. Wykonalność wysoka: statystyki odczytów, pewności i pikseli tablicy S.
3. Głosowanie wieloklatkowe, walidacja formatu PL/UE i pewność każdego znaku. Ogranicza mylenie znaków F46623; głosowanie zmniejszyło błędy o 61%, fuzja modeli o 68% (obliczenia/s08.out, p. 3); przy wjeździe jest ok. 15 wycinków na przejazd F38278, F37288.
4. Ścieżka wyjątku dla pojazdu bez odczytu. Zdarzenie z typem, kierunkiem, kolorem w dzień i zdjęciem do szybkiej korekty zastępuje bilet awaryjny F45166 i skraca ręczną obsługę F43477, F41271. PR uruchamia MMC na Raspberry Pi 4 F48397, a NPU RK3588 obsługuje detektor przy wolnym CPU F47116, F47117.
5. Uczenie na poprawkach operatora. Wzrost z 3000 do 18 000 zweryfikowanych etykiet podniósł skuteczność z 95% do 98,6% F51075. SBC zbiera etykiety, trening odbywa się poza nim F43062; na jednym obiekcie próg 2000 poprawek wymaga 33–400 dni, więc etykiety trzeba łączyć z wielu obiektów S.
6. Kierunek ruchu i typ pojazdu. Rozdziela wjazd i wyjazd na jednej kamerze i wspiera wykrywanie jazdy „na zderzaku” F38414; Hikvision deklaruje ≥98% trafności kierunku F48588. Wykonalność wysoka.
7. MMC jako kontrola zgodności z tablicą. Utrudnia podmianę tablic i wykrywa błędne odczyty F37463, F45043; ograniczenia: kolor tylko w dzień F42873, błędy marki na IR ok. 4,2 razy częstsze F45044, 1 kamera z MMC na Raspberry Pi 4 F48397. Wykonalność średnia.
8. Rozpoznawanie niezależne od układu tablicy, z krajem. Nowy układ wymaga tylko douczenia detektora F36554; lekkie modele z regionem działają na CPU F34771. Wartość zależy od udziału tablic zagranicznych na obiekcie (brak danych w źródłach).
9. Wykrywanie fałszywych i sklonowanych tablic. Skuteczności w źródłach brak; na SBC wykonalne jako porównanie MMC z wcześniejszymi przejazdami tej samej tablicy F40381, S.
10. VLM jako asynchroniczna druga opinia lub opis pojazdu. Sekundy na zapytanie na CPU SBC (obliczenia/s08.out, p. 5) i ryzyko halucynacji F43932; wartość tylko dla rzadkich przypadków o niskiej pewności.
11. Super-rozdzielczość. Przy wycinkach 80–150 px bez korzyści F51072, z ryzykiem pogorszenia OCR F50421; głosowanie wieloklatkowe daje porównywalny efekt F51074.

Założenia S i obliczenia

• Skrypt: data/jobs/lpr-cpu-sbc/decyzja/obliczenia/s08.py, wynik: s08.out (p. 1–7).
• S Odczyt tablicy przez VLM to ok. 10 tokenów wyjścia; koszt enkodera obrazu ViT-L/14 pominięto z braku danych, więc 3,2–4,9 s to dolna granica.
• S Prędkość prefill modelu tekstowego 3B na Pi 4 przeniesiono na 576 tokenów obrazu PaliGemma F42561.
• S Odsetek odczytów wymagających poprawki: 1% (cel 99%) i 3% (97% z F34491).
• S Asystent ustawienia i diagnostyka korzystają z wyjść detektora pojazdów i tablic działającego w potoku, bez osobnego modelu; na kamerze CCTV bez czujnika orientacji kąt wynika z geometrii tablicy.
• S Trening OCR i LoRA odbywa się poza SBC; SBC zbiera zweryfikowane etykiety i przyjmuje nowy model.
• S Kontrola klonów wymaga własnej bazy MMC dla tablic z wcześniejszych przejazdów.
• S Modele rzędu 200 GFLOPs uznano za zbyt ciężkie na CPU SBC przy kilku wycinkach na przejazd.
• S Kolejność wyróżników: najpierw liczba interwencji obsługi i skarg u klienta parkingu, potem wykonalność na SBC bez GPU.