ב-Android 9 נוספה תמיכה ב-API למכשירים עם כמה מצלמות, באמצעות מכשיר מצלמה לוגי חדש שמורכב משני מכשירי מצלמה פיזיים או יותר שמכוונים לאותו כיוון. מכשיר המצלמה הלוגי מוצג כאובייקט CameraDevice/CaptureSession יחיד לאפליקציה, ומאפשר אינטראקציה עם תכונות של מצלמות מרובות שמשולבות ב-HAL. אפליקציות יכולות לגשת לזרמי מצלמה פיזיים, למטא-נתונים ולפקדים ולשלוט בהם.
איור 1. תמיכה במספר מצלמות
בתרשים הזה, מזהי מצלמות שונים מקודדים בצבעים. האפליקציה יכולה להזרים בו-זמנית מאגרי נתונים גולמיים מכל מצלמה פיזית. אפשר גם להגדיר אמצעי בקרה נפרדים ולקבל מטא-נתונים נפרדים ממצלמות פיזיות שונות.
דוגמאות ומקורות
מכשירים עם כמה מצלמות צריכים להיות מפורסמים עם יכולת לוגית של כמה מצלמות.
לקוחות המצלמה יכולים לשלוח שאילתה לגבי מזהה המצלמה של המכשירים הפיזיים שמצלמה לוגית מסוימת מורכבת מהם על ידי קריאה ל-getPhysicalCameraIds().
המזהים שמוחזרים כחלק מהתוצאה משמשים לשליטה במכשירים פיזיים בנפרד באמצעות setPhysicalCameraId().
אפשר לשלוף את התוצאות של בקשות בודדות כאלה מתוך התוצאה המלאה באמצעות הפונקציה getPhysicalCameraResults().
יכול להיות שבבקשות נפרדות למצלמה פיזית תהיה תמיכה רק בקבוצת משנה מוגבלת של פרמטרים. כדי לקבל רשימה של הפרמטרים הנתמכים, מפתחים יכולים להתקשר אל
getAvailablePhysicalCameraRequestKeys().
יש תמיכה בסטרימינג ממצלמות פיזיות רק בבקשות שלא כוללות עיבוד מחדש, ורק בחיישנים מונוכרומטיים ובחיישני באייר.
הטמעה
רשימת משימות תמיכה
כדי להוסיף מכשירים לוגיים עם כמה מצלמות בצד 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: עבור חיישנים במצב ראשי-ראשי, אין סנכרון של תריס/חשיפה בחומרה. -
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.
- מגרסה Android 10, שכבת ה-HAL יכולה לצמצם את מספר המצלמות שאפליקציה יכולה לפתוח ישירות, על ידי בחירה שלא לפרסם חלק ממזהי המצלמות הפיזיות או את כולם ב-
getCameraIdList. הפעלתgetPhysicalCameraCharacteristicsצריכה להחזיר את המאפיינים של המצלמה הפיזית.
אימות
מכשירים עם מצלמות לוגיות מרובות חייבים לעבור את בדיקת התאימות של המצלמה, כמו כל מצלמה רגילה אחרת.
אפשר למצוא את תרחישי הבדיקה שמיועדים לסוג המכשיר הזה במודול LogicalCameraDeviceTest.
שלוש הבדיקות האלה של ITS מיועדות למערכות מרובות מצלמות כדי להקל על מיזוג התמונות בצורה נכונה:
scene1/test_multi_camera_match.pyscene4/test_multi_camera_alignment.pysensor_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, fred@acuspecinc.com) ו-MYWAY Manufacturing (www.myway.tw, sales@myway.tw). בנוסף, אפשר לרכוש את תיבת ה-ITS rev1 דרך West-Mark (www.west-mark.com, dgoodman@west-mark.com).
שיטות מומלצות
כדי ליהנות מכל היתרונות של התכונות שמופעלות על ידי מצלמות מרובות, תוך שמירה על תאימות האפליקציה, מומלץ לפעול לפי השיטות המומלצות הבאות כשמטמיעים מכשיר לוגי עם מצלמות מרובות:
- (Android גרסה 10 ואילך) הסתרת מצלמות משנה פיזיות מ-
getCameraIdList. הפעולה הזו מצמצמת את מספר המצלמות שאפליקציות יכולות לפתוח ישירות, וכך לאפליקציות לא נדרש לוגיקה מורכבת לבחירת מצלמה. - (Android 11 ואילך) במכשיר עם מצלמה לוגית מרובת עדשות שתומכת בזום אופטי, צריך להטמיע את
ANDROID_CONTROL_ZOOM_RATIOAPI ולהשתמש ב-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, כך שמנקודת המבט של האפליקציה, מערכת הקואורדינטות היא הגודל של המערך הפעיל של המצלמה הלוגית. - אם המצלמות הרחבה והטלה-פוטו תומכות בפוקוס אוטומטי, אבל המצלמה האולטרה-רחבה היא עם פוקוס קבוע, צריך לוודא שהמצלמה הלוגית מפרסמת תמיכה בפוקוס אוטומטי. שכבת ה-HAL צריכה לדמות מכונת מצבים של פוקוס אוטומטי עבור מצלמת ה-Ultrawide, כך שכשהאפליקציה מבצעת זום אאוט לעדשת ה-Ultrawide, העובדה שהמצלמה הפיזית הבסיסית היא עם פוקוס קבוע תהיה שקופה לאפליקציה, ומכונות המצבים של הפוקוס האוטומטי עבור מצבי הפוקוס האוטומטי הנתמכים יפעלו כמצופה.
- אם המצלמות הרחבה והטלה תומכות ב-4K ב-60 fps, והמצלמה הרחבה במיוחד תומכת רק ב-4K ב-30 fps או ב-1080p ב-60 fps, אבל לא ב-4K ב-60 fps, צריך לוודא שהמצלמה הלוגית לא מפרסמת 4K ב-60 fps בהגדרות הנתמכות של הזרמת נתונים. כך מובטחת שלמות היכולות של המצלמה הלוגית, ומוודאים שהאפליקציה לא תיתקל בבעיה של אי השגת 4k @ 60 fps בערך של
ANDROID_CONTROL_ZOOM_RATIOפחות מ-1.
- אם הגדלים של המערכים הפעילים של המצלמות הפיזיות שונים, ה-HAL של המצלמה צריך לבצע את המיפוי מהמערכים הפעילים של המצלמות הפיזיות למערך הפעיל של המצלמה הלוגית עבור
- ב-Android מגרסה 10 ואילך, לא נדרשת מצלמה לוגית מרובת עדשות כדי לתמוך בשילובים של סטרימינג שכוללים סטרימינג פיזי.
אם שכבת ה-HAL תומכת בשילוב עם זרמים פיזיים:
- (Android מגרסה 11 ואילך) כדי לטפל טוב יותר בתרחישי שימוש כמו עומק מסטריאו ומעקב תנועה, צריך להגדיל את שדה הראייה של הפלט של הזרם הפיזי עד כמה שאפשר באמצעות החומרה. עם זאת, אם סטרימינג פיזי וסטרימינג לוגי מגיעים מאותה מצלמה פיזית, יכול להיות שמגבלות חומרה יכריחו את שדה הראייה של הסטרימינג הפיזי להיות זהה לזה של הסטרימינג הלוגי.
- כדי לטפל בעומס על הזיכרון שנגרם מכמה זרמים פיזיים, צריך לוודא שהאפליקציות משתמשות ב-
discardFreeBuffersכדי לבטל את ההקצאה של המאגרים החופשיים (מאגרים שהצרכן משחרר, אבל עדיין לא הוצאו מהתור על ידי היצרן) אם צפוי שזרם פיזי יהיה במצב המתנה למשך זמן מסוים. - אם בדרך כלל לא מצרפים לאותה בקשה סטרימינג פיזי ממצלמות פיזיות שונות, צריך לוודא שהאפליקציות משתמשות ב-
surface groupכדי שתור במאגר נתונים זמני (buffer queue) אחד ישמש לגיבוי של שני ממשקים שפונים לאפליקציה, וכך יצטמצם השימוש בזיכרון.