زیر سیستم 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

شکل 3. نمای کلی دوربین 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 تابع ICameraDeviceCallback::notify() با پیام SHUTTER، شامل شماره فریم و زمان شروع نوردهی، فراخوانی می‌کند. این فراخوانی 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) خاموش هیچکدام
روشن زمان نوردهی حسگر اندروید، مدت زمان فریم حسگر اندروید، حساسیت حسگر اندروید، دیافراگم لنز اندروید (در صورت پشتیبانی) فیلتر لنز اندروید، تراکم پیکسلی (در صورت پشتیبانی)
روشن_خودکار_فلش همه چیز روشن است، به علاوه android.flash.firingPower، android.flash.firingTime و android.flash.mode
روشن_همیشه_فلش همانند ON_AUTO_FLASH
روشن_خودکار_فلش_قرمز_چشم همانند ON_AUTO_FLASH
حالت کنترل اندروید (android.control.awbMode) خاموش هیچکدام
تراز سفیدی_* android.colorCorrection.transform. تنظیمات مختص پلتفرم در صورتی که android.colorCorrection.mode روی FAST یا HIGH_QUALITY باشد.
حالت کنترل اندروید (android.control.afMode) خاموش هیچکدام
حالت فوکوس فاصله کانونی لنز اندروید
اندروید.کنترل.ویدئو.تثبیت خاموش هیچکدام
روشن می‌توان android.scaler.cropRegion را برای پیاده‌سازی تثبیت‌کننده ویدیو تنظیم کرد.
حالت کنترل اندروید خاموش AE، AWB و AF غیرفعال هستند
خودکار تنظیمات AE، AWB و AF به صورت جداگانه استفاده می‌شوند
حالت صحنه می‌تواند تمام پارامترهای ذکر شده در بالا را لغو کند. کنترل‌های تکی 3A غیرفعال هستند.

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

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

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

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

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

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