النظام الفرعي HAL

الطلبات

يصدر إطار عمل التطبيق طلبات للحصول على النتائج الملتقطة إلى النظام الفرعي للكاميرا. طلب واحد يتوافق مع مجموعة واحدة من النتائج. يقوم الطلب بتغليف كافة معلومات التكوين حول التقاط تلك النتائج ومعالجتها. يتضمن ذلك أشياء مثل الدقة وتنسيق البكسل؛ الاستشعار اليدوي، والعدسة، والتحكم في الفلاش؛ أوضاع التشغيل 3A؛ التحكم في معالجة RAW إلى YUV؛ وتوليد الإحصاءات. وهذا يسمح بمزيد من التحكم في إخراج النتائج ومعالجتها. يمكن إرسال طلبات متعددة في وقت واحد، كما أن تقديم الطلبات لا يؤدي إلى الحظر. وتتم معالجة الطلبات دائمًا بالترتيب الذي وردت به.

الشكل 1. طراز الكاميرا

HAL والنظام الفرعي للكاميرا

يتضمن النظام الفرعي للكاميرا تطبيقات المكونات الموجودة في مسار الكاميرا مثل خوارزمية 3A وعناصر التحكم في المعالجة. توفر لك الكاميرا HAL واجهات لتنفيذ إصداراتك من هذه المكونات. للحفاظ على التوافق عبر الأنظمة الأساسية بين العديد من الشركات المصنعة للأجهزة وموردي معالج إشارة الصور (ISP أو مستشعر الكاميرا)، يكون نموذج مسار الكاميرا افتراضيًا ولا يتوافق بشكل مباشر مع أي مزود خدمة إنترنت حقيقي. ومع ذلك، فهو مشابه بدرجة كافية لخطوط المعالجة الحقيقية بحيث يمكنك تعيينه على أجهزتك بكفاءة. بالإضافة إلى ذلك، فهو مجرد بما يكفي للسماح بخوارزميات وأوامر تشغيل متعددة ومختلفة دون المساس بالجودة أو الكفاءة أو التوافق عبر الأجهزة.

يدعم مسار الكاميرا أيضًا المشغلات التي يمكن لإطار عمل التطبيق تشغيلها لتشغيل أشياء مثل التركيز التلقائي. كما أنه يرسل إشعارات مرة أخرى إلى إطار عمل التطبيق، لإخطار التطبيقات بالأحداث مثل قفل التركيز التلقائي أو الأخطاء.

الشكل 2. خط أنابيب الكاميرا

يرجى ملاحظة أن بعض كتل معالجة الصور الموضحة في الرسم البياني أعلاه لم يتم تعريفها بشكل جيد في الإصدار الأولي. يقوم خط أنابيب الكاميرا بالافتراضات التالية:

• لا يخضع إخراج RAW Bayer لأي معالجة داخل مزود خدمة الإنترنت.
• يتم إنشاء الإحصائيات بناءً على بيانات المستشعر الأولية.
• إن كتل المعالجة المختلفة التي تحول بيانات المستشعر الأولية إلى YUV مرتبة بشكل تعسفي.
• أثناء عرض وحدات القياس والاقتصاص المتعددة، تشترك جميع وحدات القياس في عناصر التحكم في منطقة الإخراج (التكبير الرقمي). ومع ذلك، قد يكون لكل وحدة دقة إخراج مختلفة وتنسيق بكسل.

ملخص استخدام API
هذا ملخص مختصر لخطوات استخدام Android Camera API. راجع قسم بدء التشغيل وتسلسل العمليات المتوقعة للحصول على تفاصيل تفصيلية لهذه الخطوات، بما في ذلك استدعاءات واجهة برمجة التطبيقات (API).

1. الاستماع إلى أجهزة الكاميرا وتعدادها.
2. افتح الجهاز وقم بتوصيل المستمعين.
3. قم بتكوين المخرجات لحالة الاستخدام المستهدفة (مثل التقاط الصور الثابتة، والتسجيل، وما إلى ذلك).
4. قم بإنشاء طلب (طلبات) لحالة الاستخدام المستهدف.
5. التقاط/تكرار الطلبات ورشقات نارية.
6. تلقي البيانات الوصفية النتيجة وبيانات الصورة.
7. عند تبديل حالات الاستخدام، ارجع إلى الخطوة 3.

ملخص عملية HAL

• طلبات الالتقاط غير المتزامنة تأتي من إطار العمل.
• يجب أن يقوم جهاز HAL بمعالجة الطلبات بالترتيب. ولكل طلب، قم بإنتاج بيانات تعريف نتائج الإخراج وواحد أو أكثر من المخازن المؤقتة لصور الإخراج.
• الوارد أولاً، يخرج أولاً للطلبات والنتائج، وللتدفقات المشار إليها بواسطة الطلبات اللاحقة.
• يجب أن تكون الطوابع الزمنية متطابقة لجميع المخرجات من طلب معين، حتى يتمكن إطار العمل من مطابقتها معًا إذا لزم الأمر.
• يتم تغليف جميع تكوينات الالتقاط وحالتها (باستثناء إجراءات 3A) في الطلبات والنتائج.

الشكل 3. نظرة عامة على الكاميرا HAL

بدء التشغيل وتسلسل التشغيل المتوقع

يحتوي هذا القسم على شرح تفصيلي للخطوات المتوقعة عند استخدام واجهة برمجة تطبيقات الكاميرا. يرجى الاطلاع على النظام الأساسي/الأجهزة/الواجهات/الكاميرا/ للحصول على تعريفات واجهة HIDL.

تعداد وفتح أجهزة الكاميرا وإنشاء جلسة نشطة

1. بعد التهيئة، يبدأ إطار العمل في الاستماع إلى أي من موفري الكاميرات الحاليين الذين يقومون بتنفيذ واجهة ICameraProvider . في حالة وجود هذا الموفر أو الموفرين، سيحاول إطار العمل إنشاء اتصال.
2. يقوم الإطار بتعداد أجهزة الكاميرا عبر ICameraProvider::getCameraIdList() .
3. يقوم الإطار بإنشاء مثيل لـ ICameraDevice جديد عن طريق استدعاء ICameraProvider::getCameraDeviceInterface_VX_X() المعني.
4. يستدعي إطار العمل ICameraDevice::open() لإنشاء جلسة التقاط نشطة جديدة ICameraDeviceSession.

استخدام جلسة الكاميرا النشطة

1. يستدعي إطار العمل ICameraDeviceSession::configureStreams() مع قائمة تدفقات الإدخال/الإخراج إلى جهاز HAL.
2. يطلب إطار العمل الإعدادات الافتراضية لبعض حالات الاستخدام مع استدعاءات ICameraDeviceSession::constructDefaultRequestSettings() . قد يحدث هذا في أي وقت بعد إنشاء ICameraDeviceSession بواسطة ICameraDevice::open .
3. يقوم إطار العمل بإنشاء طلب الالتقاط الأول وإرساله إلى HAL باستخدام إعدادات تعتمد على إحدى مجموعات الإعدادات الافتراضية، ومع تدفق إخراج واحد على الأقل تم تسجيله مسبقًا بواسطة إطار العمل. يتم إرسال هذا إلى HAL باستخدام ICameraDeviceSession::processCaptureRequest() . يجب أن تمنع HAL عودة هذه المكالمة حتى تصبح جاهزة لإرسال الطلب التالي.
4. يستمر إطار العمل في إرسال الطلبات واستدعاء ICameraDeviceSession::constructDefaultRequestSettings() للحصول على مخازن الإعدادات الافتراضية لحالات الاستخدام الأخرى حسب الضرورة.
5. عندما يبدأ التقاط الطلب (يبدأ المستشعر في التعريض للالتقاط)، يستدعي HAL ICameraDeviceCallback::notify() مع رسالة SHUTTER، بما في ذلك رقم الإطار والطابع الزمني لبدء التعريض. ليس من الضروري أن يحدث رد اتصال الإشعار هذا قبل استدعاء 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() بإرجاع -ENODEV أو NULL بعد إرجاع طريقة notify() من رسالة خطأ فادحة.

الشكل 4. التدفق التشغيلي للكاميرا

مستويات الأجهزة

يمكن لأجهزة الكاميرا تنفيذ عدة مستويات من الأجهزة وفقًا لقدراتها. لمزيد من المعلومات، راجع مستوى الأجهزة المدعومة .

التفاعل بين طلب التقاط التطبيق والتحكم 3A وخط أنابيب المعالجة

اعتمادًا على الإعدادات الموجودة في كتلة التحكم 3A، يتجاهل مسار الكاميرا بعض المعلمات في طلب الالتقاط الخاص بالتطبيق ويستخدم القيم المقدمة بواسطة إجراءات التحكم 3A بدلاً من ذلك. على سبيل المثال، عندما يكون التعريض الضوئي التلقائي نشطًا، يتم التحكم في وقت التعريض ومدة الإطار ومعلمات حساسية المستشعر بواسطة خوارزمية النظام الأساسي 3A، ويتم تجاهل أي قيم محددة بواسطة التطبيق. يجب الإبلاغ عن القيم المختارة للإطار بواسطة إجراءات 3A في بيانات تعريف الإخراج. يصف الجدول التالي الأوضاع المختلفة لكتلة التحكم 3A والخصائص التي يتم التحكم فيها بواسطة هذه الأوضاع. راجع ملف النظام الأساسي/النظام/الوسائط/الكاميرا/docs/docs.html للحصول على تعريفات لهذه الخصائص.

تعمل عناصر التحكم الموجودة في كتلة معالجة الصور في الشكل 2 على مبدأ مماثل، وبشكل عام تحتوي كل كتلة على ثلاثة أوضاع:

• OFF: تم تعطيل كتلة المعالجة هذه. لا يمكن تعطيل كتل ضبط الديموزايك وتصحيح الألوان ومنحنى الدرجة اللونية.
• سريع: في هذا الوضع، قد لا تؤدي كتلة المعالجة إلى إبطاء معدل إطار الإخراج مقارنةً بوضع إيقاف التشغيل، ولكن يجب أن تنتج أفضل مخرجات ذات جودة ممكنة في ظل هذا التقييد. عادةً، سيتم استخدام هذا في أوضاع المعاينة أو تسجيل الفيديو، أو التقاط الصور الثابتة. في بعض الأجهزة، قد يكون هذا مكافئًا لوضع إيقاف التشغيل (لا يمكن إجراء أي معالجة دون إبطاء معدل الإطارات)، وفي بعض الأجهزة، قد يكون هذا مكافئًا لوضع HIGH_QUALITY (لا تزال الجودة الأفضل لا تؤدي إلى إبطاء معدل الإطارات).
• جودة عالية: في هذا الوضع، يجب أن تنتج كتلة المعالجة أفضل نتيجة جودة ممكنة، مما يؤدي إلى إبطاء معدل إطار الإخراج حسب الحاجة. عادةً، سيتم استخدام هذا لالتقاط صور ثابتة عالية الجودة. تتضمن بعض الكتل تحكمًا يدويًا يمكن تحديده اختياريًا بدلاً من FAST أو HIGH_QUALITY. على سبيل المثال، تدعم كتلة تصحيح الألوان مصفوفة تحويل الألوان، بينما يدعم ضبط منحنى الدرجة اللونية منحنى تعيين درجة اللون العالمية التعسفي.

الحد الأقصى لمعدل الإطارات الذي يمكن أن يدعمه نظام فرعي للكاميرا هو دالة لعدة عوامل:

• الدقة المطلوبة لتدفقات الصور الناتجة
• توفر أوضاع binning/تخطي على جهاز التصوير
• عرض النطاق الترددي لواجهة التصوير
• عرض النطاق الترددي لكتل ​​معالجة ISP المختلفة

نظرًا لأن هذه العوامل يمكن أن تختلف بشكل كبير بين مزودي خدمات الإنترنت وأجهزة الاستشعار المختلفة، تحاول واجهة HAL الخاصة بالكاميرا تجريد قيود عرض النطاق الترددي في نموذج بسيط قدر الإمكان. النموذج المقدم له الخصائص التالية:

• يتم دائمًا تكوين مستشعر الصورة لإخراج أصغر دقة ممكنة نظرًا لأحجام دفق الإخراج المطلوبة للتطبيق. يتم تعريف أصغر دقة على أنها كبيرة على الأقل مثل أكبر حجم دفق الإخراج المطلوب.
• نظرًا لأن أي طلب قد يستخدم أيًا من تدفقات الإخراج التي تم تكوينها حاليًا أو جميعها، فيجب تكوين المستشعر ومزود خدمة الإنترنت لدعم توسيع نطاق الالتقاط الفردي لجميع التدفقات في نفس الوقت.
• تعمل تدفقات JPEG مثل تدفقات YUV التي تمت معالجتها للطلبات التي لم يتم تضمينها لها؛ وفي الطلبات التي تتم الإشارة إليها مباشرةً، تعمل كتدفقات JPEG.
• يمكن أن يعمل معالج JPEG بشكل متزامن مع بقية مسار الكاميرا، لكن لا يمكنه معالجة أكثر من لقطة واحدة في المرة الواحدة.