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

ב-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 של rev1 דרך 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 כדי שתור אחד במאגר הנתונים הזמני ישמש לגיבוי בין שתי פלטפורמות שמטרגטות את האפליקציות, וכך יפחת צריכת הזיכרון.