زیر سیستم HAL

این صفحه زیرسیستم HAL، شامل درخواست‌ها، زیرسیستم دوربین، توالی راه‌اندازی و عملیات، سطوح سخت‌افزاری و تعاملات را شرح می‌دهد.

درخواست‌ها

چارچوب برنامه، درخواست‌هایی برای نتایج ضبط‌شده به زیرسیستم دوربین ارسال می‌کند. یک درخواست مربوط به یک مجموعه از نتایج است. یک درخواست، تمام اطلاعات پیکربندی مربوط به ضبط و پردازش آن نتایج را در بر می‌گیرد. این شامل مواردی مانند وضوح و فرمت پیکسل؛ کنترل دستی حسگر، لنز و فلاش؛ حالت‌های عملیاتی 3A؛ کنترل پردازش RAW به YUV؛ و تولید آمار می‌شود. این امر امکان کنترل بسیار بیشتری بر خروجی و پردازش نتایج را فراهم می‌کند. چندین درخواست می‌توانند به طور همزمان در حال انجام باشند و ارسال درخواست‌ها بدون انسداد است. و درخواست‌ها همیشه به ترتیبی که دریافت می‌شوند پردازش می‌شوند.

مدل درخواست دوربین

شکل ۱. مدل دوربین.

زیرسیستم HAL و دوربین

زیرسیستم دوربین شامل پیاده‌سازی‌هایی برای اجزای موجود در خط لوله دوربین مانند الگوریتم 3A و کنترل‌های پردازش است. HAL دوربین رابط‌هایی را برای شما فراهم می‌کند تا نسخه‌های خود از این اجزا را پیاده‌سازی کنید. برای حفظ سازگاری بین پلتفرمی بین تولیدکنندگان متعدد دستگاه و فروشندگان پردازنده سیگنال تصویر (ISP یا حسگر دوربین)، مدل خط لوله دوربین مجازی است و مستقیماً با هیچ ISP واقعی مطابقت ندارد. با این حال، به اندازه کافی شبیه به خطوط لوله پردازش واقعی است تا بتوانید آن را به طور موثر به سخت‌افزار خود نگاشت کنید. علاوه بر این، به اندازه کافی انتزاعی است که امکان استفاده از چندین الگوریتم و ترتیب عملیات مختلف را بدون به خطر انداختن کیفیت، کارایی یا سازگاری بین دستگاهی فراهم کند.

خط لوله دوربین همچنین از محرک‌هایی پشتیبانی می‌کند که چارچوب برنامه می‌تواند برای روشن کردن مواردی مانند فوکوس خودکار، آنها را فعال کند. همچنین اعلان‌هایی را به چارچوب برنامه ارسال می‌کند و برنامه‌ها را از رویدادهایی مانند قفل فوکوس خودکار یا خطاها مطلع می‌سازد.

لایه انتزاعی سخت‌افزار دوربین

شکل ۲. لوله کشی دوربین.

توجه داشته باشید که برخی از بلوک‌های پردازش تصویر نشان داده شده در نمودار بالا در نسخه اولیه به خوبی تعریف نشده‌اند. خط لوله دوربین فرضیات زیر را در نظر می‌گیرد:

  • خروجی RAW Bayer هیچ پردازشی در داخل ISP انجام نمی‌دهد.
  • آمار بر اساس داده‌های خام حسگر تولید می‌شوند.
  • بلوک‌های پردازشی مختلفی که داده‌های خام حسگر را به YUV تبدیل می‌کنند، به ترتیب دلخواه قرار دارند.
  • در حالی که واحدهای مقیاس‌بندی و برش چندگانه نشان داده شده‌اند، همه واحدهای مقیاس‌بندی کنترل‌های ناحیه خروجی (زوم دیجیتال) را به اشتراک می‌گذارند. با این حال، هر واحد ممکن است وضوح خروجی و فرمت پیکسل متفاوتی داشته باشد.

خلاصه استفاده از API

این خلاصه‌ای کوتاه از مراحل استفاده از API دوربین اندروید است. برای جزئیات بیشتر این مراحل، از جمله فراخوانی‌های API، به بخش راه‌اندازی و توالی عملیات مورد انتظار مراجعه کنید.

  1. به دستگاه‌های دوربین گوش دهید و آنها را بشمارید.
  2. دستگاه را باز کنید و شنونده‌ها را متصل کنید.
  3. خروجی‌ها را برای مورد استفاده هدف (مانند ضبط یا تصویربرداری ثابت) پیکربندی کنید.
  4. درخواست‌هایی برای مورد استفاده هدف ایجاد کنید.
  5. درخواست‌ها و burstهای ضبط/تکرار.
  6. دریافت فراداده‌های نتایج و داده‌های تصویر.
  7. هنگام تغییر موارد استفاده، به مرحله 3 برگردید.

خلاصه عملیات HAL

  • درخواست‌های ناهمزمان برای ضبط از چارچوب می‌آیند.
  • دستگاه HAL باید درخواست‌ها را به ترتیب پردازش کند. و برای هر درخواست، فراداده نتیجه خروجی و یک یا چند بافر تصویر خروجی تولید کند.
  • اولین ورودی، اولین خروجی برای درخواست‌ها و نتایج، و برای جریان‌هایی که توسط درخواست‌های بعدی ارجاع داده می‌شوند.
  • مهرهای زمانی باید برای همه خروجی‌های یک درخواست مشخص یکسان باشند، تا چارچوب بتواند در صورت نیاز آنها را با هم مطابقت دهد.
  • تمام پیکربندی‌ها و حالت‌های ضبط (به جز روال‌های 3A) در درخواست‌ها و نتایج کپسوله‌سازی می‌شوند.
نمای کلی دوربین HAL

شکل ۳. نمای کلی دوربین HAL.

توالی راه‌اندازی و عملیات مورد انتظار

این بخش شامل توضیح مفصلی از مراحل مورد انتظار هنگام استفاده از API دوربین است. برای تعاریف رابط HIDL، به platform/hardware/interfaces/camera/ مراجعه کنید.

شمارش، باز کردن دستگاه‌های دوربین و ایجاد یک جلسه فعال

  1. پس از مقداردهی اولیه، چارچوب شروع به گوش دادن به هر ارائه‌دهنده دوربین موجود که رابط ICameraProvider را پیاده‌سازی می‌کنند، می‌کند. اگر چنین ارائه‌دهنده یا ارائه‌دهندگانی وجود داشته باشند، چارچوب سعی می‌کند اتصال برقرار کند.
  2. این چارچوب، دستگاه‌های دوربین را از طریق ICameraProvider::getCameraIdList فهرست می‌کند.
  3. این چارچوب با فراخوانی ICameraProvider::getCameraDeviceInterface_VX_X مربوطه، یک ICameraDevice جدید را نمونه‌سازی می‌کند.
  4. این چارچوب، ICameraDevice::open برای ایجاد یک جلسه ضبط فعال جدید ICameraDeviceSession فراخوانی می‌کند.

از یک جلسه دوربین فعال استفاده کنید

  1. این چارچوب ICameraDeviceSession::configureStreams با فهرستی از جریان‌های ورودی/خروجی به دستگاه HAL فراخوانی می‌کند.
  2. این چارچوب برای برخی موارد استفاده، با فراخوانی‌های ICameraDeviceSession::constructDefaultRequestSettings تنظیمات پیش‌فرض را درخواست می‌کند. این می‌تواند در هر زمانی پس از ایجاد ICameraDeviceSession توسط ICameraDevice::open رخ دهد.
  3. این چارچوب، اولین درخواست ضبط را با تنظیماتی بر اساس یکی از مجموعه تنظیمات پیش‌فرض و با حداقل یک جریان خروجی که قبلاً توسط چارچوب ثبت شده است، به HAL می‌سازد و ارسال می‌کند. این درخواست با ICameraDeviceSession::processCaptureRequest به HAL ارسال می‌شود. HAL باید بازگشت این فراخوانی را تا زمانی که برای ارسال درخواست بعدی آماده باشد، مسدود کند.
  4. این چارچوب به ارسال درخواست‌ها ادامه می‌دهد و در صورت لزوم، ICameraDeviceSession::constructDefaultRequestSettings برای دریافت بافرهای تنظیمات پیش‌فرض برای موارد استفاده دیگر فراخوانی می‌کند.
  5. وقتی ضبط یک درخواست شروع می‌شود (سنسور شروع به نوردهی برای ضبط می‌کند)، HAL با پیام SHUTTER، شامل شماره فریم و زمان شروع نوردهی، ICameraDeviceCallback::notify فراخوانی می‌کند. این فراخوانی notify لازم نیست قبل از اولین فراخوانی processCaptureResult برای یک درخواست اتفاق بیفتد، اما تا زمانی که notify برای آن ضبط فراخوانی نشود، هیچ نتیجه‌ای برای ضبط به برنامه تحویل داده نمی‌شود.
  6. پس از مدتی تأخیر در خط لوله، HAL شروع به بازگرداندن تصاویر ضبط شده کامل به چارچوب با ICameraDeviceCallback::processCaptureResult . این تصاویر به همان ترتیبی که درخواست‌ها ارسال شده‌اند، بازگردانده می‌شوند. بسته به عمق خط لوله دستگاه دوربین HAL، چندین درخواست می‌توانند همزمان در حال ارسال باشند.

پس از مدتی، یکی از موارد زیر رخ می‌دهد:

  • این چارچوب ارسال درخواست‌های جدید را متوقف می‌کند، منتظر می‌ماند تا ضبط‌های موجود تکمیل شوند (تمام بافرها پر می‌شوند، تمام نتایج بازگردانده می‌شوند)، و سپس دوباره ICameraDeviceSession::configureStreams را فراخوانی می‌کند. این کار سخت‌افزار دوربین و خط لوله را برای مجموعه‌ای جدید از جریان‌های ورودی/خروجی بازنشانی می‌کند. برخی از جریان‌ها را می‌توان از پیکربندی قبلی دوباره استفاده کرد. سپس چارچوب از اولین درخواست ضبط تا HAL ادامه می‌دهد، اگر حداقل یک جریان خروجی ثبت شده باقی مانده باشد. (در غیر این صورت، ابتدا ICameraDeviceSession::configureStreams مورد نیاز است.)
  • این چارچوب می‌تواند ICameraDeviceSession::close را برای پایان دادن به جلسه دوربین فراخوانی کند. این می‌تواند در هر زمانی که هیچ فراخوانی دیگری از چارچوب فعال نباشد، فراخوانی شود، اگرچه ممکن است فراخوانی تا زمانی که تمام ضبط‌های در حال انجام (تمام نتایج برگردانده شده، تمام بافرها پر شده باشند) تکمیل نشده باشند، مسدود شود. پس از بازگشت فراخوانی close ، هیچ فراخوانی دیگری به ICameraDeviceCallback از HAL مجاز نیست. پس از شروع فراخوانی close ، چارچوب نمی‌تواند هیچ یک از توابع دستگاه HAL دیگر را فراخوانی کند.
  • در صورت بروز خطا یا سایر رویدادهای ناهمزمان، HAL باید ICameraDeviceCallback::notify با پیام خطا/رویداد مناسب فراخوانی کند. پس از بازگشت از یک اعلان خطای مهلک در سطح دستگاه، HAL باید طوری عمل کند که گویی close روی آن فراخوانی شده است. با این حال، HAL باید قبل از فراخوانی notify ، تمام ضبط‌های برجسته را لغو یا تکمیل کند، به طوری که پس از فراخوانی notify با یک خطای مهلک، چارچوب فراخوانی‌های بیشتری از دستگاه دریافت نکند. متدهای علاوه بر close باید پس از بازگشت متد notify از یک پیام خطای مهلک، مقدار -ENODEV یا NULL را برگردانند.
جریان عملیات دوربین

شکل ۴. جریان عملیاتی دوربین.

سطوح سخت‌افزاری

دستگاه‌های دوربین می‌توانند بسته به قابلیت‌هایشان، چندین سطح سخت‌افزاری را پیاده‌سازی کنند. برای اطلاعات بیشتر، به سطح سخت‌افزاری پشتیبانی‌شده مراجعه کنید.

تعامل بین درخواست ضبط برنامه، کنترل 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 غیرفعال هستند.

کنترل‌های موجود در بلوک پردازش تصویر در شکل ۲، همگی بر اساس یک اصل مشابه عمل می‌کنند و هر بلوک دارای سه حالت است:

  • OFF : این بلوک پردازش غیرفعال است. بلوک‌های تنظیم منحنی تنالیته، تصحیح رنگ و دموساییک را نمی‌توان غیرفعال کرد.
  • FAST ): در این حالت، بلوک پردازش ممکن است نرخ فریم خروجی را در مقایسه با حالت OFF ) کاهش ندهد، اما در غیر این صورت باید با توجه به آن محدودیت، بهترین کیفیت خروجی ممکن را تولید کند. معمولاً از این حالت برای حالت‌های پیش‌نمایش یا ضبط ویدیو یا ضبط پشت سر هم برای تصاویر ثابت استفاده می‌شود. در برخی دستگاه‌ها، این حالت ممکن است معادل حالت خاموش ( OFF ) باشد (هیچ پردازشی بدون کاهش نرخ فریم قابل انجام نیست) و در برخی دستگاه‌ها، این حالت ممکن است معادل حالت HIGH_QUALITY باشد (بهترین کیفیت همچنان نرخ فریم را کاهش نمی‌دهد).
  • HIGH_QUALITY : در این حالت، بلوک پردازش باید بهترین کیفیت ممکن را تولید کند و در صورت نیاز، نرخ فریم خروجی را کاهش دهد. معمولاً از این حالت برای ضبط تصاویر با کیفیت بالا استفاده می‌شود. برخی از بلوک‌ها شامل یک کنترل دستی هستند که می‌توان به جای FAST یا HIGH_QUALITY به صورت اختیاری انتخاب کرد. به عنوان مثال، بلوک تصحیح رنگ از یک ماتریس تبدیل رنگ پشتیبانی می‌کند، در حالی که تنظیم منحنی تُن از یک منحنی نگاشت تُن سراسری دلخواه پشتیبانی می‌کند.

حداکثر نرخ فریمی که می‌تواند توسط یک زیرسیستم دوربین پشتیبانی شود، تابع عوامل زیادی است:

  • وضوح‌های درخواستی برای جریان‌های تصویر خروجی
  • در دسترس بودن حالت‌های binning/skipping روی تصویرگر
  • پهنای باند رابط تصویرگر
  • پهنای باند بلوک‌های پردازشی مختلف ISP

این عوامل می‌توانند بین ISPها و حسگرهای مختلف بسیار متفاوت باشند، بنابراین رابط HAL دوربین سعی می‌کند محدودیت‌های پهنای باند را تا حد امکان در یک مدل ساده خلاصه کند. مدل ارائه شده دارای ویژگی‌های زیر است:

  • حسگر تصویر همیشه طوری پیکربندی می‌شود که با توجه به اندازه جریان خروجی درخواستی برنامه، کوچکترین وضوح ممکن را خروجی دهد. کوچکترین وضوح به این صورت تعریف می‌شود که حداقل به اندازه بزرگترین اندازه جریان خروجی درخواستی باشد.
  • هر درخواستی می‌تواند از هر یا تمام جریان‌های خروجی پیکربندی‌شده‌ی فعلی استفاده کند، بنابراین حسگر و ISP باید طوری پیکربندی شوند که از مقیاس‌بندی یک ضبط واحد برای تمام جریان‌ها به طور همزمان پشتیبانی کنند.
  • جریان‌های JPEG برای درخواست‌هایی که شامل آنها نمی‌شوند، مانند جریان‌های YUV پردازش‌شده عمل می‌کنند؛ در درخواست‌هایی که مستقیماً به آنها ارجاع داده می‌شود، مانند جریان‌های JPEG عمل می‌کنند.
  • پردازنده JPEG می‌تواند همزمان با بقیه خطوط دوربین اجرا شود، اما نمی‌تواند بیش از یک تصویر را در یک زمان پردازش کند.