מערכת משנה של 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. המסגרת קוראת ל-ICameraDeviceSession::configureStreams עם רשימה של זרמי קלט/פלט למכשיר HAL.
2. המסגרת מבקשת הגדרות ברירת מחדל לכמה תרחישי שימוש באמצעות קריאות ל-ICameraDeviceSession::constructDefaultRequestSettings. המצב הזה יכול להתרחש בכל שלב אחרי ש-ICameraDevice::open יוצר את ICameraDeviceSession.
3. המסגרת בונה ושולחת את בקשת הצילום הראשונה ל-HAL עם הגדרות שמבוססות על אחת מקבוצות הגדרות ברירת המחדל, ועם לפחות זרם פלט אחד שנרשם קודם על ידי המסגרת. הוא נשלח ל-HAL עם ICameraDeviceSession::processCaptureRequest. שכבת ה-HAL צריכה לחסום את החזרה של השיחה הזו עד שהיא תהיה מוכנה לשליחת הבקשה הבאה.
4. המסגרת ממשיכה לשלוח בקשות ושיחות ICameraDeviceSession::constructDefaultRequestSettings כדי לקבל מאגרי הגדרות ברירת מחדל לתרחישי שימוש אחרים לפי הצורך.
5. כשמתחילים לצלם תמונה (החיישן מתחיל את החשיפה לצילום), ה-HAL קורא ל-ICameraDeviceCallback::notify עם הודעת הצילום, כולל מספר הפריים וחותמת הזמן של תחילת החשיפה. הקריאה החוזרת (callback) של ההודעה הזו לא חייבת להתרחש לפני הקריאה הראשונה של 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 יכול לפעול במקביל לשאר צינור העיבוד של המצלמה, אבל הוא לא יכול לעבד יותר מתמונה אחת בכל פעם.