תמיכה בכמה מצלמות

ב-Android 9 הוספנו תמיכה ב-API למכשירים עם כמה מצלמות באמצעות מכשיר מצלמה לוגי חדש שמורכב משתי מצלמות פיזיות או יותר שמכוונות באותו כיוון. מכשיר המצלמה הלוגי מוצג לאפליקציה כ-CameraDevice/CaptureSession יחיד, ומאפשר אינטראקציה עם תכונות של מצלמות מרובות המשולבות ב-HAL. לאפליקציות יש אפשרות לגשת למטא-נתונים, לפקדים ולשידורים הפיזיים של המצלמה ולשלוט בהם.

איור 1. תמיכה במספר מצלמות

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

דוגמאות ומקורות

יש לפרסם מכשירים עם כמה מצלמות עם היכולת הלוגית של כמה מצלמות.

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

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

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

הטמעה

רשימת משימות לתמיכה

כדי להוסיף מכשירים לוגיים עם כמה מצלמות בצד ה-HAL:

• מוסיפים יכולת ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA לכל מכשיר מצלמה לוגי שמבוסס על שתי מצלמות פיזיות או יותר שחשופות גם לאפליקציה.
• מאכלסים את שדה המטא-נתונים הסטטי ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS ברשימת מזהי המצלמות הפיזיות.
• מאכלסים את המטא-נתונים הסטטיים שקשורים לעומק, שנדרשים כדי ליצור התאמה בין הפיקסלים של הסטרימינג הפיזי של המצלמה: ANDROID_LENS_POSE_ROTATION,‏ ANDROID_LENS_POSE_TRANSLATION,‏ ANDROID_LENS_INTRINSIC_CALIBRATION,‏ ANDROID_LENS_DISTORTION,‏ ANDROID_LENS_POSE_REFERENCE.

• מגדירים את שדה המטא-נתונים הסטטי ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE לערך:

  • ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE_APPROXIMATE: חיישנים במצב main-main, ללא סנכרון של תריס/חשיפה בחומרה.
  • ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE_CALIBRATED: חיישנים במצב ראשי-משני, סנכרון של תריס/חשיפה בחומרה.

• מאכלסים את השדה ANDROID_REQUEST_AVAILABLE_PHYSICAL_CAMERA_REQUEST_KEYS ברשימת הפרמטרים הנתמכים של מצלמות פיזיות ספציפיות. הרשימה יכולה להיות ריקה אם המכשיר הלוגי לא תומך בבקשות ספציפיות.

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

• במכשירי Camera HAL בגרסה 3.5 (שנוספה ב-Android 10) ואילך, מאכלסים את מפתח התוצאה ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID באמצעות המזהה של המצלמה הפיזית הפעילה הנוכחית שתומכת במצלמה הלוגית.

במכשירים עם Android 9, מכשירי המצלמה חייבים לתמוך בהחלפה של שידור לוגי אחד מסוג YUV/RAW בשידורים פיזיים באותו גודל (לא רלוונטי לשידורי RAW) ובאותו פורמט משתי מצלמות פיזיות. הבעיה הזו לא רלוונטית למכשירים עם Android מגרסה 10.

במכשירים עם Android 10, שבהם גרסת המכשיר של HAL של המצלמה היא 3.5 ואילך, מכשיר המצלמה חייב לתמוך ב-isStreamCombinationSupported כדי שאפליקציות יוכלו לשלוח שאילתה לגבי תמיכה בשילוב ספציפי של סטרימינג שמכיל סטרימינג פיזי.

מפת הגדרות של מקור נתונים

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

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

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

שילוב של שידורים מובטחים

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

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

במכשירים עם Android 9, לכל שילוב של שידור מובטח, המצלמה הלוגיקלית חייבת לתמוך ב:

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

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

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

שיקולי ביצועים וצריכת חשמל

• ביצועים:

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

• כוח:

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

התאמה אישית

אפשר להתאים אישית את הטמעת המכשיר בדרכים הבאות.

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

אימות

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

שלוש בדיקות ה-ITS האלה מיועדות למערכות עם כמה מצלמות כדי לאפשר מיזוג תקין של התמונות:

• scene1/test_multi_camera_match.py
• scene4/test_multi_camera_alignment.py
• sensor_fusion/test_multi_camera_frame_sync.py

הבדיקות של סצנה 1 וסצנה 4 פועלות באמצעות ערכת הבדיקה ITS-in-a-box. הבדיקה test_multi_camera_match קובעת שהבהירות של מרכז התמונות תואמת כששתי המצלמות מופעלות. הבדיקה test_multi_camera_alignment מאמתת שהפרמטרים של המרווחים, הכיוונים והעיוותים של המצלמות נטענים בצורה תקינה. אם מערכת המצלמות המרובות כוללת מצלמה עם שדה ראייה רחב (מעל 90 מעלות), נדרשת גרסת rev2 של תיבת ה-ITS.

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

כל הקופסאות זמינות דרך AcuSpec, Inc.‏ (www.acuspecinc.com,‏ [e-mail]) ו-MYWAY Manufacturing‏ (www.myway.tw, ‏ [e-mail]). בנוסף, ניתן לרכוש את התיבה של ITS בגרסה 1 דרך West-Mark‏ (www.west-mark.com,‏ [e-mail]).

שיטות מומלצות

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

• (Android מגרסה 10 ואילך) מסתירים מצלמות משנה פיזיות מgetCameraIdList. כך ניתן לצמצם את מספר המצלמות שאפשר לפתוח ישירות דרך האפליקציות, וכך אין צורך באפליקציות עם לוגיקה מורכבת לבחירת מצלמה.
• (Android 11 ואילך) במכשיר לוגי עם כמה מצלמות שתומך בזום אופטי, מטמיעים את ה-API‏ ANDROID_CONTROL_ZOOM_RATIO ומשתמשים ב-ANDROID_SCALER_CROP_REGION רק לחיתוך לפי יחס גובה-רוחב. ANDROID_CONTROL_ZOOM_RATIO מאפשרת למכשיר להתרחק ולשמור על דיוק גבוה יותר. במקרה כזה, ‏HAL צריך לשנות את מערכת הקואורדינטות של ANDROID_SCALER_CROP_REGION,‏ ANDROID_CONTROL_AE_REGIONS,‏ ANDROID_CONTROL_AWB_REGIONS,‏ ANDROID_CONTROL_AF_REGIONS,‏ ANDROID_STATISTICS_FACE_RECTANGLES ו-ANDROID_STATISTICS_FACE_LANDMARKS כדי להתייחס לשטח התצוגה אחרי הזום כמערך הפעיל של החיישן. למידע נוסף על האופן שבו ANDROID_SCALER_CROP_REGION פועל בשילוב עם ANDROID_CONTROL_ZOOM_RATIO, אפשר לעיין במאמר camera3_crop_reprocess#cropping.
• במכשירים עם כמה מצלמות פיזיות עם יכולות שונות, חשוב לוודא שהמכשיר מצהיר על תמיכה בערך או בטווח מסוימים של אמצעי בקרה רק אם כל טווח הזום תומך בערך או בטווח האלה. לדוגמה, אם המצלמה הלוגיקלית מורכבת ממצלמת Ultrawide, ממצלמה רחבה וממצלמת טלפוטו, מבצעים את הפעולות הבאות:
  • אם הגדלים של המערך הפעיל של המצלמות הפיזיות שונים, ה-HAL של המצלמה צריך לבצע את המיפוי מהמערך הפעיל של המצלמות הפיזיות למערך הפעיל של המצלמה הלוגי עבור ANDROID_SCALER_CROP_REGION,‏ ANDROID_CONTROL_AE_REGIONS,‏ ANDROID_CONTROL_AWB_REGIONS,‏ ANDROID_CONTROL_AF_REGIONS,‏ ANDROID_STATISTICS_FACE_RECTANGLES ו-ANDROID_STATISTICS_FACE_LANDMARKS, כך שמבחינת האפליקציה, מערכת הקואורדינטות היא גודל המערך הפעיל של המצלמה הלוגי.
  • אם המצלמה הרחבה והמצלמה עם עדשת הטלפוטו תומכות במיקוד אוטומטי, אבל המצלמה עם עדשת ה-Ultrawide היא עם מיקוד קבוע, צריך לוודא שהמצלמה הלוגית מקדמת תמיכה במיקוד אוטומטי. ה-HAL צריך לדמות מכונת מצב של מיקוד אוטומטי למצלמת ה-Ultrawide, כך שכשהאפליקציה מרחיבה את התצוגה לעדשת ה-Ultrawide, העובדה שהמצלמה הפיזית הבסיסית היא עם מיקוד קבוע לא גלויה לאפליקציה, ומכונות המצב של המיקוד האוטומטי למצבי המיקוד האוטומטי הנתמכים פועלות כצפוי.
  • אם המצלמה הרחבה והטלפוטו תומכות ב-4K‏ @ 60fps, והמצלמה הרחבה במיוחד תומכת רק ב-4K‏ @ 30fps או ב-1080p‏ @ 60fps, אבל לא ב-4K‏ @ 60fps, צריך לוודא שהמצלמה הלוגיקלית לא מפרסמת 4K‏ @ 60fps בהגדרות הסטרימינג הנתמכות שלה. כך אפשר להבטיח את תקינות היכולות הלוגיות של המצלמה, וכך לא תהיה לאפליקציה בעיה של אי-השגת 4K‏ @ 60fps כשהערך של ANDROID_CONTROL_ZOOM_RATIO הוא קטן מ-1.
• החל מ-Android 10, אין צורך במצלמה לוגית עם כמה מצלמות כדי לתמוך בשילובי שידורים שכוללים שידורים פיזיים. אם ה-HAL תומך בשילוב עם מקורות נתונים פיזיים:
  • (Android 11 ואילך) כדי לטפל טוב יותר בתרחישי שימוש כמו עומק מסטריאו ומעקב אחר תנועה, כדאי להגדיל את שדה הראייה של הפלט הפיזי של הסטרימינג עד כמה שאפשר עם החומרה. עם זאת, אם שידור פיזי ושידור לוגי מגיעים מאותה מצלמה פיזית, מגבלות חומרה עשויות לאלץ את שדה הראייה של השידור הפיזי להיות זהה לשדה הראייה של השידור הלוגי.
  • כדי לטפל בלחץ על הזיכרון שנגרם על ידי מספר מקורות נתונים פיזיים, חשוב לוודא שהאפליקציות משתמשות ב-discardFreeBuffers כדי לבטל את ההקצאה של מאגרי הנתונים הפנויים (מאגרי נתונים שהצרכן שחרר אבל עדיין לא הוסרו מהתור על ידי היצרן) אם צפוי שמקור נתונים פיזי יהיה במצב חוסר פעילות למשך פרק זמן מסוים.
  • אם בדרך כלל לא מצורפים לאותה בקשה שידורים פיזיים ממצלמות פיזיות שונות, חשוב לוודא שהאפליקציות משתמשות ב-surface group כדי שתור אחד של מאגר יעמוד לרשות שתי פלטפורמות שמוצגות לאפליקציה, וכך לצמצם את צריכת הזיכרון.