Twój tool projektowy CCTV kłamie o zasięgu kamery o 251%. Dowód matematyczny

CCTVplanner napisał:

Większość CCTV design toolów liczy zasięg Identify wyłącznie z PPM (rozdzielczość przez piksele na metr), ignorując że kamera nachylona w dół fizycznie nie sięga wzrokiem za pewien dystans. Klasyczny ...

Krótko: kierunek jest słuszny, a liczby z przykładów się zgadzają

Aleksandrze, sama idea liczenia Identify jako przecięcia dwóch ograniczeń:

1. PPM cap – czy w danym miejscu jest wystarczająca liczba pikseli na metr,
2. rzeczywisty wycinek widzenia wynikający z wysokości i pochylenia kamery,

jest poprawna i w praktyce bardzo potrzebna. Samo PPM bez geometrii pochylenia kamery rzeczywiście potrafi dać absurdalnie optymistyczny wynik, szczególnie przy kamerach nad wejściami, na elewacjach i pod stropami.

Twoje obliczenia dla kamery:

- 1/2.8", szerokość sensora ok. 5,4 mm,
- obiektyw 4 mm,
- 2560×1440,
- stream 16:9,

dają poprawne wartości:



Scenariusz B, czyli

h = 3 m

,

β = 75°

, też jest policzony poprawnie:



Czyli tak: kamera fizycznie nie obejmuje ziemi na 4 m przed sobą, niezależnie od tego, że czysto „pikselowo” kalkulator PPM pokazuje 7,59 m.

---

Największy plus Twojego podejścia

Najważniejsze, że rozdzielasz dwie rzeczy, które wiele prostych kalkulatorów miesza:



oraz



To są dwa niezależne warunki. Rzeczywisty zakres Identify powinien być:



A nie samo:



W Twoim przykładzie z wejściem:



I to jest bardzo dobry przykład praktyczny, bo instalatorzy często zawieszają kamerę wysoko, mocno ją pochylają, a potem dziwią się, że kamera „4 MP, ładny obraz”, ale twarzy lub tablicy dalej od drzwi nie ma z czego odczytać.

---

Istotna uwaga: dla twarzy i tablicy nie wystarczy liczyć przecięcia z ziemią

Tu moim zdaniem warto dopisać w dokumentacji jedną rzecz, bo może to być ważniejszy niuans niż samo PPM.

Twoje

d_near

i

d_far

liczą przecięcie pola widzenia z płaszczyzną ziemi, czyli z poziomem

Z = 0

.

To jest dobre dla pytania:



Ale Identify zwykle dotyczy nie ziemi, tylko obiektu znajdującego się wyżej:

- twarz: około 1,5–1,8 m nad ziemią,
- tablica rejestracyjna: około 0,4–0,9 m nad ziemią,
- sylwetka człowieka: bryła 3D, a nie punkt na podłodze.

Dla obiektu na wysokości

z_target

należałoby w prostym przybliżeniu użyć:



i wtedy:



Przykład dla Twojego scenariusza B:



Dla ziemi:



Dla twarzy na wysokości 1,6 m:



Czyli kamera może widzieć ziemię do około 2,16 m, ale twarz człowieka stojącego dalej może już wypaść ponad górną krawędź kadru. To jest klasyczny problem kamer nad drzwiami: widać czapkę, kaptur, ramiona, ale nie twarz.

Dla tablicy na wysokości np. 0,6 m:



To dodatkowo wzmacnia Twój argument: samo liczenie footprintu na ziemi jest już lepsze niż samo PPM, ale dla Identify warto iść jeszcze krok dalej i liczyć widoczność konkretnego celu na konkretnej wysokości.

---

Druga ważna uwaga: PPM powinno zależeć od orientacji celu

Wzór:



jest poprawnym uproszczeniem dla płaszczyzny ustawionej w sposób „ładny” względem kamery, zwykle prostopadle do osi widzenia albo przynajmniej bez dużego skrótu perspektywicznego.

W praktyce:

- twarz jest mniej więcej pionową powierzchnią,
- tablica rejestracyjna też jest mniej więcej pionowa, ale bywa pochylona,
- pojazd może być pod kątem do kamery,
- człowiek może iść bokiem,
- kamera może patrzeć bardzo stromo z góry.

Dlatego przy dużym downtilcie nominalne 250 px/m nie zawsze oznacza realne 250 px/m użyteczne dla identyfikacji.

Najbardziej poprawny model byłby taki:

1. Definiujesz typ celu:
- twarz,
- sylwetka,
- tablica,
- pojazd,
- obiekt niestandardowy.

2. Nadajesz mu:
- wysokość nad ziemią,
- szerokość,
- wysokość,
- orientację w przestrzeni,
- dopuszczalny kąt obserwacji.

3. Rzutujesz jego narożniki do obrazu kamery.

4. Liczysz rzeczywistą liczbę pikseli na:
- szerokość celu,
- wysokość celu,
- ewentualnie mniejszą z tych dwóch wartości.

To jest bardziej odporne niż samo PPM po ziemi.

W praktyce wystarczyłby tryb:



I wtedy narzędzie pokazywałoby nie tylko „gdzie kamera widzi podłogę”, ale również „gdzie da się realnie zidentyfikować twarz/tablicę”.

---

Przypadki brzegowe, które warto jawnie obsłużyć

1. Gdy górna krawędź FOV idzie ponad horyzont

Jeżeli:



to górna krawędź kadru nie przecina ziemi w skończonej odległości.

Wtedy:



albo praktycznie:



To trzeba obsłużyć w kodzie, żeby uniknąć dzielenia przez zero lub fałszywych wyników.

---

2. Gdy dolna krawędź przechodzi za pion w dół

Jeżeli:



to dolna część kadru patrzy pod kamerę albo nawet „za” punkt montażu.

Wtedy ustawianie:



jest rozsądne, ale trzeba pamiętać, że przy bardzo szerokim kącie i dużym tilcie footprint nie jest już prostym wycinkiem przed kamerą. Dokładniej jest to przecięcie ostrosłupa widzenia z płaszczyzną ziemi.

---

3. Dokładny footprint to nie idealny sektor koła

Określenie „pie-slice” jest czytelne marketingowo i użytkowo, ale matematycznie dla kamery rektilinearnej dokładny rzut FOV na ziemię to przecięcie ostrosłupa/frustum kamery z płaszczyzną ziemi.

Najbardziej odporna metoda implementacyjna:



Wtedy automatycznie rozwiązujesz:

- duży tilt,
- kamerę patrzącą częściowo w horyzont,
- widzenie pod sobą,
- roll kamery,
- nietypowe proporcje streamu,
- target na wysokości innej niż ziemia.

---

Sensor i FOV: Twoje podejście jest dobre, ale warto dodać zastrzeżenie

Zgadzam się, że używanie realnej szerokości sensora i ogniskowej jest lepsze niż ślepa wiara w marketingowe HFOV z datasheetu.

Natomiast trzeba uważać na kilka rzeczy:

1. „1/2.8 cala” nie zawsze oznacza identyczny aktywny obszar

Format optyczny jest historycznie umowny. Typowe 1/2.8" ma około 5,4 mm szerokości, ale konkretne sensory mogą mieć minimalnie inne aktywne wymiary.

Różnice kilku procent są normalne.

2. Tryb streamu może używać innego cropu

Dobrze, że bierzesz

aspect_HW

ze streamu, a nie z fizycznego sensora. Ale oprócz samego aspect ratio dochodzą jeszcze:

- tryb 16:9 z sensora 4:3,
- tryb 4:3 z sensora 16:9,
- digital zoom,
- EIS/stabilizacja elektroniczna,
- WDR z niestandardowym odczytem,
- różne tryby fps z częściowym odczytem matrycy.

W katalogu kamer dobrze byłoby mieć nie tylko:



ale docelowo także:



albo przynajmniej flagę:



To zwiększy zaufanie do wyników.

---

Fisheye: equidistant jako domyślne założenie jest OK, ale nie zawsze prawdziwe

Dla fisheye zwykły model rektilinearny rzeczywiście się wykłada. Projekcja:



czyli equidistant, jest sensownym domyślnym modelem.

Ale producenci stosują też inne projekcje:



Warto więc w dokumentacji napisać, że equidistant jest używane, jeżeli brak dokładniejszej informacji o optyce. Przy kamerach 180°/360° różnice na brzegach kadru mogą być zauważalne.

---

DORI a realne odczytywanie tablic

Tu byłbym ostrożny z komunikatem „Identify = plate readable”.

Normowe 250 px/m jest dobrym punktem odniesienia, ale w praktyce odczyt tablic zależy jeszcze od:

- kąta obserwacji tablicy,
- czasu ekspozycji,
- prędkości pojazdu,
- motion blur,
- kompresji H.264/H.265,
- poziomu wyostrzania,
- WDR,
- IR i prześwietlenia odblaskowej tablicy,
- brudu/deszczu/śniegu,
- kraju i rozmiaru znaków na tablicy,
- sposobu montażu tablicy,
- wysokości kamery.

Dla LPR/ANPR przydałby się osobny profil, np.:



I osobne ostrzeżenie, jeżeli kamera jest zbyt wysoko lub zbyt stromo pochylona.

---

Bardzo dobry pomysł: ostrzeżenie o złym kącie identyfikacji twarzy

Dodałbym wprost alert typu:



Przykładowe kryteria:

- kamera widzi cel głównie z góry,
- twarz znajduje się blisko górnej granicy kadru lub poza nią,
- kąt depresji do twarzy przekracza zadany próg,
- identyfikacja będzie formalnie miała PPM, ale praktycznie pokaże czubek głowy.

To byłoby bardzo użyteczne dla kamer nad drzwiami, recepcjami, bramkami i korytarzami.

---

Z-occlusion i multi-floor: bardzo dobra funkcja, ale liczyć warto bryły, nie tylko podłogę

To, że liczysz przeszkody z wysokością Z, jest dużym plusem.

W praktyce warto rozważyć trzy poziomy dokładności:

Poziom 1: przeszkody 2.5D

Czyli rzut na planie + wysokość:



Poziom 2: target height

Czyli sprawdzanie, czy widoczna jest:



Poziom 3: częściowe zasłonięcie

Np. twarz widoczna, ale dolna część sylwetki zasłonięta ladą. Albo tablica zasłonięta przez słupek.

Nie trzeba od razu robić pełnego 3D walkthrough, ale już samo rzutowanie kilku wysokości celu dałoby dużo lepszą informację projektową niż klasyczny FOV na podłodze.

---

Funkcje, które z punktu widzenia praktyka byłyby bardzo wartościowe

1. PoE budget i spadki napięć

Skoro liczysz trasy kablowe, naturalnym krokiem jest:



Bardzo częsty błąd: system działa w dzień, a w nocy po włączeniu IR zaczynają się restarty kamer.

---

2. Storage/bandwidth calculator

Przydatne minimum:



To jest często wymagane już na etapie oferty.

---

3. Tryb offline/on-premise

PWA offline po pierwszym załadowaniu jest wygodne, ale dla części obiektów to może nie wystarczyć:

- infrastruktura krytyczna,
- przemysł,
- wojsko,
- energetyka,
- zakłady produkcyjne,
- obiekty z zakazem wynoszenia planów do chmury.

Rozważyłbym nie tylko „desktop offline”, ale też wariant:



Dla większych klientów to może być ważniejsze niż cena miesięczna.

---

Podsumowanie

Moim zdaniem główna teza jest poprawna: PPM bez geometrii nachylenia kamery potrafi znacząco przeszacować zasięg Identify. Twoje dwa przykłady są matematycznie spójne i dobrze pokazują problem.

Najważniejsze sugestie do dopracowania:

1. Dodać tryb liczenia dla celu na wysokości, nie tylko dla ziemi.
Szczególnie: twarz, tablica, sylwetka.

2. Nie traktować 250 px/m jako gwarancji odczytu tablicy.
Dla LPR/ANPR warto zrobić osobny profil.

3. Docelowo liczyć PPM przez rzutowanie rzeczywistego celu 3D do obrazu.
To rozwiąże problem kąta, skrótu perspektywicznego i wysokości celu.

4. W dokumentacji jawnie opisać edge case:


5. Przy fisheye dopisać, że equidistant jest modelem domyślnym, ale nie zawsze jedynym.

6. W katalogu kamer warto rozróżniać dane:


Ogólnie: bardzo dobry kierunek. Jeżeli narzędzie faktycznie pokazuje przecięcie FOV wynikającego z tiltu, PPM/DORI oraz przeszkód Z, to jest to znacznie bliższe realnemu projektowaniu niż typowy płaski kalkulator „ile metrów z PPM”. Największą wartość dodałoby teraz przejście z „DORI na ziemi” do „DORI dla konkretnego celu 3D”.