מערכת משנה של HAL

בקשות

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

איור 1. דגם המצלמה

‫HAL ותת-מערכת המצלמה

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

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

איור 2. פייפליין של מצלמה

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

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

סיכום השימוש ב-API
זהו סיכום קצר של השלבים לשימוש ב-Android Camera API. בקטע 'רצף ההפעלה והפעולה הצפוי' מפורטים השלבים האלה, כולל קריאות ל-API.

1. האזנה למכשירי מצלמה וספירתם.
2. פותחים את המכשיר ומחברים את המאזינים.
3. מגדירים את הפלט לתרחיש השימוש הרצוי (למשל, צילום תמונה, הקלטה וכו').
4. יוצרים בקשות לתרחיש השימוש הרצוי.
5. לזהות בקשות חוזרות ופרצי תנועה.
6. קבלת מטא-נתונים של התוצאה ונתוני תמונה.
7. כשעוברים לתרחיש שימוש אחר, חוזרים לשלב 3.

סיכום פעולות HAL

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

איור 3. סקירה כללית של Camera HAL

רצף ההפעלה והפעולה הצפוי

בקטע הזה מוסבר בפירוט על השלבים שצריך לבצע כשמשתמשים בממשק ה-API של המצלמה. הגדרות של ממשק HIDL מופיעות בכתובת platform/hardware/interfaces/camera/.

מנייה, פתיחה של מכשירי מצלמה ויצירה של סשן פעיל

1. אחרי האתחול, המסגרת מתחילה להאזין לכל ספקי המצלמות הנוכחיים שמטמיעים את הממשק ICameraProvider. אם יש ספק או ספקים כאלה, המסגרת תנסה ליצור חיבור.
2. המסגרת מפרטת את מכשירי המצלמה באמצעות ICameraProvider::getCameraIdList().
3. המסגרת יוצרת מופע חדש של ICameraDevice על ידי קריאה ל-ICameraProvider::getCameraDeviceInterface_VX_X() המתאים.
4. המסגרת קוראת ל-ICameraDevice::open() כדי ליצור סשן פעיל חדש של לכידה ICameraDeviceSession.

שימוש בסשן פעיל של המצלמה

1. ה-framework קורא ל-ICameraDeviceSession::configureStreams() עם רשימה של זרמי קלט/פלט למכשיר HAL.
2. המסגרת מבקשת הגדרות ברירת מחדל לכמה תרחישי שימוש באמצעות קריאות ל-ICameraDeviceSession::constructDefaultRequestSettings(). המצב הזה יכול להתרחש בכל שלב אחרי ש-ICameraDevice::open יוצר את ICameraDeviceSession.
3. המסגרת בונה ושולחת את בקשת הצילום הראשונה ל-HAL עם הגדרות שמבוססות על אחת מקבוצות הגדרות ברירת המחדל, ועם לפחות זרם פלט אחד שנרשם קודם על ידי המסגרת. הוא נשלח ל-HAL עם ICameraDeviceSession::processCaptureRequest(). שכבת ה-HAL צריכה לחסום את החזרה של השיחה הזו עד שהיא תהיה מוכנה לשליחת הבקשה הבאה.
4. המסגרת ממשיכה לשלוח בקשות ושיחות ICameraDeviceSession::constructDefaultRequestSettings() כדי לקבל מאגרי הגדרות ברירת מחדל לתרחישי שימוש אחרים לפי הצורך.
5. כשמתחיל הצילום של בקשה (החיישן מתחיל את החשיפה לצילום), ה-HAL קורא ל-ICameraDeviceCallback::notify() עם הודעת הצילום, כולל מספר הפריימים וחותמת הזמן של תחילת החשיפה. הקריאה החוזרת notify לא חייבת להתבצע לפני הקריאה הראשונה processCaptureResult() לבקשה, אבל לא מועברים תוצאות לאפליקציה לצילום מסך עד שהקריאה notify() לצילום המסך הזה מתבצעת.
6. אחרי עיכוב מסוים בצינור, ה-HAL מתחיל להחזיר ל-Framework לכידות שהושלמו עם ICameraDeviceCallback::processCaptureResult(). התשובות מוחזרות באותו סדר שבו נשלחו הבקשות. יכולות להיות כמה בקשות בהמתנה בו-זמנית, בהתאם לעומק הצינור של מכשיר ה-HAL של המצלמה.

אחרי זמן מה, אחת מהאפשרויות הבאות תתרחש:

• יכול להיות שהמסגרת תפסיק לשלוח בקשות חדשות, תחכה עד שהלכידות הקיימות יושלמו (כל המאגרים יתמלאו, כל התוצאות יוחזרו), ואז תקרא שוב ל-ICameraDeviceSession::configureStreams(). הפעולה הזו מאפסת את חומרת המצלמה ואת צינור הנתונים שלה כדי ליצור קבוצה חדשה של זרמי קלט/פלט. יכול להיות שחלק מהשידורים יחזרו מההגדרה הקודמת. לאחר מכן, המסגרת ממשיכה מבקשת הלכידה הראשונה אל HAL, אם נשאר לפחות פלט אחד רשום. (אחרת, קודם צריך להזין את ICameraDeviceSession::configureStreams()).
• יכול להיות שהמסגרת תקרא ל-ICameraDeviceSession::close() כדי לסיים את סשן המצלמה. אפשר לקרוא לפונקציה הזו בכל שלב שבו אין שיחות אחרות פעילות מהמסגרת, אבל יכול להיות שהקריאה תיחסם עד שכל הלכידות הפעילות יושלמו (כל התוצאות יוחזרו, כל המאגרים ימולאו). אחרי שהקריאה ל-close() חוזרת, לא ניתן לבצע יותר קריאות ל-ICameraDeviceCallback מ-HAL. אחרי שמתחילה שיחה עם close(), יכול להיות שהמסגרת לא תקרא לפונקציות אחרות של מכשיר HAL.
• במקרה של שגיאה או אירוע אסינכרוני אחר, שכבת ה-HAL צריכה לקרוא ל-ICameraDeviceCallback::notify() עם הודעת השגיאה או האירוע המתאימה. אחרי החזרה מהתראה על שגיאה קריטית במכשיר, שכבת ה-HAL צריכה לפעול כאילו בוצעה בה קריאה ל-close(). עם זאת, מודול ה-HAL צריך לבטל או להשלים את כל הלכידות התלויות ועומדות לפני שהוא קורא ל-notify(), כדי שכאשר קוראים ל-notify() עם שגיאה קריטית, המסגרת לא תקבל עוד קריאות חוזרות מהמכשיר. שיטות אחרות מלבד close() צריכות להחזיר ‎-ENODEV או NULL אחרי שהשיטה notify() מחזירה הודעת שגיאה חמורה.

איור 4. רשימת השלבים להפעלת המצלמה

רמות חומרה

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

אינטראקציה בין בקשת לכידת האפליקציה, בקרת 3A וצינור העיבוד

בהתאם להגדרות בבלוק הבקרה של 3A, צינור המצלמה מתעלם מחלק מהפרמטרים בבקשת הצילום של האפליקציה ומשתמש בערכים שסופקו על ידי שגרות הבקרה של 3A. לדוגמה, כשחשיפה אוטומטית פעילה, הפרמטרים של זמן החשיפה, משך הפריימים והרגישות של החיישן נשלטים על ידי אלגוריתם 3A של הפלטפורמה, וכל הערכים שצוינו באפליקציה מתעלמים. הערכים שנבחרו למסגרת על ידי שגרות ה-3A צריכים להיות מדווחים במטא-נתונים של הפלט. בטבלה הבאה מתוארים המצבים השונים של בלוק הבקרה 3A והמאפיינים שמנוהלים על ידי המצבים האלה. הגדרות הנכסים האלה מפורטות בקובץ platform/system/media/camera/docs/docs.html.

פרמטר	מדינה	מאפיינים מבוקרים
android.control.aeMode	כבוי	ללא
	מופעל	‫android.sensor.exposureTime ‫android.sensor.frameDuration ‫android.sensor.sensitivity ‫android.lens.aperture (אם נתמך) ‫android.lens.filterDensity (אם נתמך)
	ON_AUTO_FLASH	הכול מופעל, בנוסף ל-android.flash.firingPower,‏ android.flash.firingTime ו-android.flash.mode
	ON_ALWAYS_FLASH	זהה ל-ON_AUTO_FLASH
	ON_AUTO_FLASH_RED_EYE	זהה ל-ON_AUTO_FLASH
android.control.awbMode	כבוי	ללא
	WHITE_BALANCE_*	‫android.colorCorrection.transform. התאמות ספציפיות לפלטפורמה אם הערך של android.colorCorrection.mode הוא FAST או HIGH_QUALITY.
android.control.afMode	כבוי	ללא
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	כבוי	ללא
	מופעל	אפשר לשנות את הערך של android.scaler.cropRegion כדי להטמיע ייצוב וידאו
android.control.mode	כבוי	התכונות AE,‏ AWB ו-AF מושבתות
	אוטומטי	נעשה שימוש בהגדרות נפרדות של AE,‏ AWB ו-AF
	SCENE_MODE_*	אפשר להגדיר ערכים חלופיים לכל הפרמטרים שצוינו למעלה. אמצעי הבקרה האישיים של 3A מושבתים.

הפקדים בבלוק Image Processing (עיבוד תמונה) באיור 2 פועלים על פי עיקרון דומה, ובדרך כלל לכל בלוק יש שלושה מצבים:

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

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

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

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

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