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

בדף הזה מתואר תת-המערכת HAL, כולל בקשות, תת-מערכת המצלמה, רצף ההפעלה והפעולה, רמות החומרה והאינטראקציות.

בקשות

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

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

‫HAL ומערכת המשנה של המצלמה

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

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

איור 2. צינור המצלמה.

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

• פלט RAW Bayer לא עובר עיבוד בתוך ה-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 עם הודעת הצילום, כולל מספר הפריים וחותמת הזמן של תחילת החשיפה. הקריאה החוזרת (callback) של ההודעה לא חייבת להתרחש לפני הקריאה הראשונה של processCaptureResult לבקשה, אבל לא מועברות תוצאות לאפליקציה לצילום עד שמתבצעת קריאה של processCaptureResult לצילום הזה.notify
6. אחרי עיכוב מסוים בצינור, ה-HAL מתחיל להחזיר ל-Framework לכידות שהושלמו עם ICameraDeviceCallback::processCaptureResult. התשובות מוחזרות באותו סדר שבו נשלחו הבקשות. יכולות להיות כמה בקשות בהמתנה בו-זמנית, בהתאם לעומק הצינור של מכשיר ה-HAL של המצלמה.

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

• המסגרת מפסיקה לשלוח בקשות חדשות, מחכה שהלכידות הקיימות יושלמו (כל המאגרים יתמלאו, כל התוצאות יוחזרו), ואז קוראת שוב ל-ICameraDeviceSession::configureStreams. הפעולה הזו מאפסת את חומרת המצלמה ואת צינור הנתונים שלה כדי ליצור קבוצה חדשה של זרמי קלט/פלט. אפשר להשתמש שוב בחלק מהשידורים מההגדרה הקודמת. לאחר מכן, המסגרת ממשיכה מבקשת הלכידה הראשונה אל HAL, אם נשאר לפחות פלט אחד רשום. (אחרת, קודם צריך להזין את ICameraDeviceSession::configureStreams).
• ה-framework יכול לקרוא ל-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	OFF	ללא.
	ON	‫android.sensor.exposureTime,‏ android.sensor.frameDuration,‏ android.sensor.sensitivity,‏ android.lens.aperture (אם נתמך) ו-android.lens.filterDensity (אם נתמך).
	ON_AUTO_FLASH	כל התכונות שכלולות בתוכנית ON, בנוסף ל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	OFF	ללא.
	WHITE_BALANCE_*	‫android.colorCorrection.transform. התאמות ספציפיות לפלטפורמה אם הערך של android.colorCorrection.mode הוא FAST או HIGH_QUALITY.
android.control.afMode	OFF	ללא
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	OFF	ללא.
	ON	אפשר לשנות את android.scaler.cropRegion כדי להפעיל ייצוב וידאו.
android.control.mode	OFF	התכונות AE,‏ AWB ו-AF מושבתות.
	AUTO	נעשה שימוש בהגדרות הפרטניות של AE,‏ AWB ו-AF.
	SCENE_MODE_*	אפשר להגדיר ערכים חלופיים לכל הפרמטרים שצוינו למעלה. אמצעי הבקרה האישיים של 3A מושבתים.

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

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

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

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

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

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