פיתוח מערכת למעקב אחר אובייקטים בווידאו (Object Tracking) כפתרון מלא

המצלמות באתר כבר קיימות, אך את המתרחש בצילומים מנתחים ידנית — ובדרך כלל רק לאחר האירוע. אנו מפתחים מערכות למעקב אחר אובייקטים כפתרון מלא: מגדירים זיהוי וכללי אזורים בהתאם לתהליך שלכם, ומצמצמים את הצפייה הידנית בארכיון באופן ניכר. התוצאה — אירועים בזמן אמת ודוחות ברורים.

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

מדוע מעקב אחר אובייקטים נשבר על וידאו אמיתי

בסרטון הדגמה הליווי נראה ללא רבב: האובייקט חוצה את הפריים, המלבן מחזיק יציב, המזהה לא משתנה. בזרם מבצעי אותה מודל מתפרק בתוך דקות. הסיבה היא שהגלאי מעריך כל פריים בנפרד, ואילו מעקב אחר אובייקטים בווידאו הוא בעיה של קשרים בין פריימים — והקשרים הם בדיוק מה שנקרע ראשון.

שגיאות הליווי חוזרות מסצנה לסצנה. האובייקט נעלם מאחורי עמוד, מרכב או רכב אחר — ולאחר היציאה מהחסימה מקבל מזהה חדש, והמזהה הקודם ממשיך "לתלות" על הצל. בשינוי זווית המלבן נסחף על הרקע ותופס אובייקט שכן, כך ששני מסלולים נדבקים לאחד.

בלילה הפעלות שווא של הגלאי על הבזקים, השתקפויות ופנסים יוצרות עשרות מסלולים קצרים במקום שבו עבר אובייקט אחד.

סיפור נפרד הוא אובדן האובייקט בפריים: הוא כמעט אף פעם לא חופף לרגע ההיעלמות. הליווי נשבר שניות לפני כן, כשהאובייקט מאט, משנה כיוון או מתמזג עם הרקע. לפי מערכי נתונים ענפיים כמו MOT Challenge רואים עד כמה איכות מעבדתית רחוקה מהמבצעית: הפער בשיעור המזהים הנכונים נמדד בעשרות אחוזים.

זה נמדד לא לפי תמונה אלא לפי אירועים. מסלול קרוע הופך או להפעלה מיותרת, או מאבד את האירוע כולו — וההחלטה מתקבלת לפי תמונה חלקית. בהמשך נפרק איך זה נסגר: מבחירת מודל לסצנה מסוימת ועד לוגיקת ההתאמה ובדיקת המסלולים.

מה נותנת מערכת אנליטיקת וידאו: אפקטים מדידים

את האפקט בודקים במדדים שנלקחים באתר שלכם לפני ואחרי ההפעלה: שיעור הפספוסים, קרעים במסלולים, זמן התגובה של המשמרת התורנית, נפח הצפייה הידנית בארכיון. הדגמה על וידאו של מישהו אחר לא מוכיחה דבר — אנחנו מחשבים על ההקלטות שלכם, כולל משמרות לילה.

פחות פספוסים של אובייקטים

שיעור הפספוסים מחושב על מדגם מתויג מההקלטות שלכם, תוך פירוק לפי תרחישים: זרם צפוף, אובייקטים בודדים, שולי הפריים. ספי הביטחון של הגלאי והמעקב מכווננים לסצנה — עבור זרם צפוף ואובייקטים קטנים ונדירים הם שונים. בפלט מתקבלים מזהי מסלול יציבים: רואים כמה אובייקטים עברו דרך האזור.

עמידות לחפיפות

המסלול לא נקרע כשהאובייקט נעלם מאחורי עמוד או אל תוך קהל: ההתאמה מתבצעת לפי מראה חיצוני ולפי חיזוי המסלול, ולא רק לפי מיקום בפריים. קרעים במסלולים נמדדים כמדד נפרד — כל קרע הופך לספירה כפולה של אירועים ולהפעלות מיותרות של המשמרת התורנית.

תאורה חלשה ומשמרות לילה

בלילה חלק מהפריים הולך לאיבוד בגלל רעש וסנוור, ולכן אנחנו מכווננים עיבוד מקדים של הפריים ומצב תאורה. אם הסצנה לא מכוסה פיזית, המערכת מסמנת את האזור כלא מכוסה, ולא מפיקה אירועי שווא.

מדד כיצד מודדים מה משתנה
שיעור הפספוסים מדגם מתויג מהארכיון יורד פי כמה בסצנות מפתח
קרעים במסלולים השוואת מזהי מסלול בקטעים ארוכים האירוע לא נספר פעמיים
זמן תגובה יומן אירועים של המשמרת דקות → שניות
צפייה ידנית חלק הארכיון שנצפה בעין חיפוש לפי אירועים במקום גלילה

דרכים למעקב אחר אובייקטים: השוואה ומגבלות

בחירת שיטת המעקב קובעת לא את דיוק המודל, אלא איך המערכת תתנהג בסצנה האמיתית. ליווי פריים-אחר-פריים מתאים מלבנים בין פריימים סמוכים ומחזיק את המסלול כל עוד האובייקט נראה; זיהוי מקצה לקצה מוסיף מאפיין של מראה חיצוני ומשחזר את הקשר לאחר חפיפה, סיבוב או יציאה מהפריים. טעות בשכבה הזאת היא היקרה מכולן: מסלול קרוע אחד מייצר אירועים מיותרים ומונה מנופח.

אפשרות מתי מתאימה מגבלות
ליווי פריים-אחר-פריים (התאמה לפי חפיפת מלבנים, ByteTrack) זרם צפוף ויציב, אובייקטים כמעט לא חופפים המסלול נקרע בחפיפה, בחציה המזהה משתנה
זיהוי מקצה לקצה תורים, התקהלויות, חזרה של אדם לפריים נדרש מתאר של מראה חיצוני, עומס גבוה יותר, מתבלבל על לבוש אחיד
קונטור עיבוד מקומי מגבלות על הוצאת וידאו מהמתחם, השהיית אות קריטית תקרה במספר המצלמות והמודלים לאתר, עדכון בכל אתר
עיבוד וידאו בענן אתרים רבים, אנליטיקה משותפת, סקיילינג גמיש תלוי בערוץ התקשורת, נפח הנתונים המועברים גדל

איך בוחרים מצב בהתאם לסצנה

ההחלטה מתקבלת לפי שלושה נתוני פתיחה: כמה אובייקטים יש בפריים בו-זמנית, באיזו תדירות הם חופפים זה לזה, והאם יש דרישה להשאיר את הווידאו בתוך הקונטור של הלקוח. במשימות לוגיות פשוטות (ספירת כניסות, אזורים) מספיק ליווי פריים-אחר-פריים — הוא זול יותר בחישוב וצפוי יותר בכיול. זיהוי מקצה לקצה אנחנו מדליקים נקודתית, רק במצלמות שבהן קרע במסלול מעוות את התוצאה.

סכימה היברידית — מעקב ראשוני בקונטור מקומי, והשוואה ואגרגציה בענן — מסירה את המגבלות של שתי האפשרויות: לאתר עוברים רק אירועים ומטא-דאטה, ולא הזרם הגולמי. בקבלה אנחנו מריצים סצנות מוקלטות עם מספר אובייקטים ידוע ובוחנים את שיעור המסלולים שנשמרו, ולא רק את דיוק הגלאי.

כיצד אנו מטמיעים אנליטיקת וידאו: שלבי העבודה

לפני שכותבים קוד, אנחנו מבררים עם אילו נתונים נעבוד: זוויות מצלמה, פערי תאורה, צפיפות הזרם, סוגי האובייקטים. סדר העבודות זהה למחסן, להיקף ולגלריית מסחר — מה שמשתנה הוא אזורי הבקרה ולוגיקת האירועים.

  1. ביקורת ארכיון הווידאו. בוחנים הקלטות מכל מצלמה בשעות שונות ובמזג אוויר שונה: סנוור, חפיפות הדדיות, רעידת פריים. בפלט — רשימת מצלמות עם תמונה יציבה ונקודות שבהן נדרש תיקון בפריסה.
  2. תיוג סצנות. מסמנים אובייקטי מטרה, מטרות שווא ורקע בעייתי: הבזקים, צללים, השתקפויות בחלונות ראווה, תנועת ענפים. דילוג על השלב מתנקם באימון-מחדש כבר אחרי ההפעלה.
  3. כיול אזורי בקרה. קווים ואזורים מוצמדים לגאומטריה האמיתית של האתר, ולא לפיקסלים — בהזזת מצלמה האזור נשאר תקין. בודקים שהאובייקט לא "קופץ" בין אזורים על הגבול.
  4. כיוון ספי הפעלה. מכווננים זמן שהייה באזור, גודל אובייקט מינימלי ומספר פריימים מאשרים: נעלמות ההפעלות על ציפור חולפת ועל עובר אורח ליד האזור.
  5. בדיקה על הקלטות היסטוריות. מריצים את הקונפיגורציה המוכנה על הארכיון במשמרות שונות ומחשבים את שיעור אירועי השווא והפספוסים, ולא מעריכים "בעין".
  6. קבלת המערכת. מודדים דיוק על הזרם החי בשעות שיא ומתעדים את המדדים בפרוטוקול. מוסרים נהלים: איך מוסיפים מצלמה, מעדכנים אזור, מנתחים אירוע שנוי במחלוקת.

כל שלב מסתיים בארטיפקט בר-בדיקה — דוח, פרופיל מכוונן, פרוטוקול קבלה. לכן אפשר לשחזר את הקונפיגורציה באתר שני, ולא להרכיב אותה מחדש.

הרכב האספקה: קונפיגורציות, תרשימי אזורים, נהלים

לאחר העלייה לשימוש נשארים אצל הלקוח לא רק מערכת עובדת, אלא גם סט מלא של ארטיפקטים שלפיהם אפשר לתפעל אותה, להרחיב ולהעביר לצוות אחר. קונפיגורציות וכללים נשמרים במאגר עם היסטוריית שינויים — רואים מי ומתי שינה פרמטרים למצלמה מסוימת ולשם מה.

  • קונפיגורציות של גלאי ומעקב לכל מצלמה: זווית, אזור עניין, ספי רגישות, התנהגות בחפיפות ובעצירות.
  • תרשים אזורי בקרה: סימון אזורים וקווים, כיווני חציה, עדיפות אזורים, הצמדה לתוכנית האתר.
  • כללי הפעלה: מה נחשב לאירוע, חלונות דיכוי של הודעות חוזרות, תנאי איחוי תצפיות של אובייקט אחד למסלול אחד.
  • תרשים אינטגרציות: קליטת זרמי וידאו, פרסום אירועים למערכות חיצוניות, ייצוא קטעים ומטא-דאטה לניתוח.
  • תיעוד המערכת: ארכיטקטורה, מילון אירועים, תיאור הפרמטרים והשפעתם על איכות המעקב, סדר הכיול.
  • נהל משמרת תורנית: תגובה לכל סוג אירוע, מה לבדוק לפני הסלמה, אילו פעולות לא מבוצעות ללא מהנדס.
  • מסירת המערכת: תרחישי קבלה, הדרכת מפעילים ומחלקת תפעול, נקודת כניסה להמשך פיתוח.

סט כזה מסיר את התלות בקבלן: תיקון אזורים או שינוי כללים אפשר להטיל על צוות אחר, בלי לשחזר את הלוגיקה מתוך הקוד.

קייס: צמצמנו פי שלושה הפעלות שווא במחסן

האתר — מחסן הפצה עם פריקה בארבעה רציפים וזרם צפוף של כלי רכב: מלגזות, מובילים עם נתיכים והולכי רגל חולקים את אותם מעברים. המערכת צריכה לתעד כניסה ויציאה, לשלוט בתפוסת אזורי הפריקה ולאתר אנשים באזור מסוכן. לפנינו פעל באתר גילוי פריים-אחר-פריים: כל הפעלה של המודל יצרה אירוע נפרד, בלי קשר לאובייקט בזמן.

מה היה לפני ההטמעה

במשמרת הצטברו יותר מ-40 הפעלות שווא. הסיבה — היעדר קשר בין פריימים: מלגזה שנכנסה מאחורי ערימה נעלמה והופיעה שוב, והמערכת פתחה עבורה אירוע שני. צללים מהשמש, השתקפויות על בטון רטוב והבזקי פנסים יצרו "אובייקטים" שלא היו קיימים פיזית.

המפעיל עד אמצע המשמרת הפסיק להגיב לאותות, וניתוח מצבים שנויים במחלוקת נעשה לפי פריימים בודדים — אי אפשר היה להוכיח דבר לפיהם.

מה שינינו ומה קיבלנו

את המעקב בנינו מעל הגילוי: לאובייקט מוקצה מזהה שנשמר בחפיפות ובהיעלמויות קצרות מהפריים. את הכללים הצמדנו לאזורים ולכיוון התנועה — אירוע נוצר רק אם המסלול מחזיק יציב באזור מעבר לסף.

כלי רכב ואנשים נספרים לפי כללים שונים, וההערכה מתבצעת על מודולי NVIDIA, כך שכל הזרמים מעובדים בלי לפספס פריימים.

בחודש התפעול הראשון: הפעלות השווא ירדו מ-40+ ל-12–14 במשמרת, שיעור ההפרות שהוחמצו — מתחת ל-2%, ההשהיה מהאירוע ועד לאות למפעיל — 1–2 שניות. יומן המסלולים נשמר 30 יום, ולכן מקרה שנוי במחלוקת מנותח לפי קטע עם מזהה, ולא לפי פריים תלוש.

מה עושים אם המצלמות והארכיון כבר פרוסים?

אין צורך להחליף את מצלמות. האנליטיקה מתחברת לאותם זרמים שהמצלמות והמקליטים כבר מוציאים לרשת, ולכן ההקלטה ממשיכה כרגיל, והמעקב עובד במקביל על צומת חישוב נפרד ולא חוטף דבר בסכימה הקיימת.

נקודת המפתח — הפרדת זרמים. המעקב לוקח זרם ברזולוציה מופחתת ועובד עליו, ואילו זרם האיכות הראשית נשאר להקלטה בארכיון, כך שאיכות ועומק השמירה לא נפגעים. אם מצלמה לא מוציאה זרם נפרד, האנליטיקה מותקנת על עותק של הזרם הראשי דרך ממשק רשת נפרד, כדי שהמקליט לא יאבד פריימים.

יצרנים שונים של מצלמות ומקליטים מובלים לכניסה אחודה דרך פרופילי תאימות ONVIF, ולמודלים סגורים הזרם נלקח ישירות מהמקליט — כך שהפתרון לא נקשר למותג ציוד אחד.

עם הארכיון עובדים בשני מצבים. מעקב חי כותב אירועים לציר זמן משותף עם ההקלטות: התגיות מסונכרנות, והאובייקט במסלול תואם לאובייקט בארכיון עד לשבריר שנייה — החיפוש מתבצע לפי מסלול ומאפיינים, ולא לפי גלילה ידנית.

על ארכיון שכבר הצטבר מופעל חישוב נפרד: הוא קורא הקלטות במנות ולא מתחרה בקליטת נתונים חדשים, כך שעומק השמירה ושלמות המערך הישן לא נפגעים.

ההטמעה מתבצעת בשלבים. תחילה פיילוט על כמה מצלמות, שבו מודדים את דיוק המעקב ואת העומס על הרשת והדיסקים; אחר כך מחברים אזורים בגלים, החל מאלה שהאפקט בהם ניכר מיד.

החזרה לאחור פשוטה: מכבים את צומת האנליטיקה, והמצלמות והארכיון ממשיכים לעבוד במצב הקודם — את מערכת התצפית הקיימת אנחנו לא שוברים.

שאלות טכניות נפוצות ומגבלות

הספקות בשלב ההערכה נוגעות כמעט תמיד לגבולות: איך המערכת מתנהגת בזרם צפוף, בחושך, בחפיפות ועל מצלמות שכבר מותקנות. להלן תשובות קצרות של מהנדסים, בלי הבטחות שיווקיות: במקום שבו לשיטה יש גבול, אנחנו אומרים זאת לפני ההתחלה.

עד כמה המעקב עמיד בזרם צפוף?

את הגילוי ואת שמירת המזהה מודדים בנפרד: מה שמשמעותי הוא לא הדיוק הכללי, אלא שיעור הקרעים במסלול ומספר החלפות המזהה לאובייקט כשהמסלולים חופפים בתוך קהל.

מה עם תאורה חלשה וחפיפות?

את המודל מאמנים-נוספים על הקלטות של האתר הספציפי: לילה, צללים והבזקי פנסים מייצרים יותר שגיאות מאשר מחסור באור כשלעצמו. חפיפה קצרה נסגרת בחיזוי המיקום לפי פריימים קודמים — המסלול שורד מעבר מאחורי עמוד ומשחזר את המזהה.

צריך להחליף מצלמות באתר?

ככלל לא: אנחנו עובדים עם הזרם שהמצלמות של הלקוח כבר מוציאות לפי תקנים פתוחים, ובמודלים חלשים אנחנו מעריכים את ספיקת איכות הצילום לפני החתימה. צווארי בקבוק בכיסוי מתעדים בדוח הסקר, כדי לא לגלות אותם בקבלה.

מי אחראי להפעלות שווא?

את מדדי המטרה מסכמים מראש ובודקים על מדגם הקלטות מושהה של הלקוח, ולא על סרטוני הדגמה. במסירה אנחנו מפרקים שגיאות לפי מקורות — גלאי, שמירת מסלול או כללי אירועים — ומתקנים את השכבה שבה הן נוצרות.

נדון במשימה ונחזור עם הערכה ותוכנית

כדי לדון במשימה באופן ענייני ולא בסיסמאות, אנחנו צריכים מכם מינימום: כמה הקלטות וידאו ממצלמות אמיתיות — עם אותה תאורה, אותן זוויות ואותה צפיפות סצנה שבהן המערכת תעבוד. בנוסף רשימה קצרה של אובייקטים שצריך להבחין ביניהם, ומה נחשב לאירוע: חציית קו, הופעה באזור, אובדן ליווי.

זה מספיק כדי לחשב עומס ולהרכיב תוכנית הטמעה לקונטור שלכם — בלי התכתבות ארוכה והנחות באפלה. בתמורה אתם מקבלים חבילה שלפיה אפשר לקבל החלטה:

  • הערכה טכנית: דיוק ליווי אפשרי על ההקלטות שלכם, צווארי בקבוק של הסצנה (חפיפות, זרם צפוף, לילה), מחלקות כשל ומה עושים איתן.
  • תוכנית הטמעה עם שלבים, סדר עבודות ונקודות שבהן אתם מקבלים את התוצאה.
  • גבולות העבודה: מה נכנס לאזור שלנו ומה נשאר עליכם או על הספק של המצלמות והשרתים.
  • תרשים זרימות נתונים — מקליטת הפריים ועד לאירוע במערכת החשבונאית שלכם.
  • דרישות לצילום ולאתר, אם חלק מהבעיות נפתרות בכיוון מצלמות ולא בקוד.
  • קריטריוני קבלה: מדדים שלפיהם נבדוק יחד את התוצאה על הקלטות שלא השתתפו בכיול.

תארו את המשימה בצורה נוחה לכם — הקלטות, האובייקטים הנדרשים, ולאן צריכים להגיע האירועים. נחזור עם הערכה, תוכנית וגבולות אחריות ברורים, ולפיהם תחליטו אם יוצאים לדרך.