এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

HAL সাবসিস্টেম

অনুরোধ

অ্যাপ ফ্রেমওয়ার্ক ক্যামেরা সাবসিস্টেমে ক্যাপচার করা ফলাফলের জন্য অনুরোধ জারি করে। একটি অনুরোধ ফলাফলের একটি সেটের সাথে মিলে যায়। একটি অনুরোধ সেই ফলাফলগুলি ক্যাপচার এবং প্রক্রিয়াকরণ সম্পর্কে সমস্ত কনফিগারেশন তথ্যকে এনক্যাপসুলেট করে৷ এর মধ্যে রেজোলিউশন এবং পিক্সেল ফরম্যাটের মতো জিনিস রয়েছে; ম্যানুয়াল সেন্সর, লেন্স এবং ফ্ল্যাশ নিয়ন্ত্রণ; 3A অপারেটিং মোড; RAW থেকে YUV প্রক্রিয়াকরণ নিয়ন্ত্রণ; এবং পরিসংখ্যান প্রজন্ম। এটি ফলাফলের আউটপুট এবং প্রক্রিয়াকরণের উপর অনেক বেশি নিয়ন্ত্রণের অনুমতি দেয়। একাধিক অনুরোধ একবারে ফ্লাইটে হতে পারে এবং অনুরোধ জমা দেওয়া অ-ব্লকিং। এবং অনুরোধগুলি সর্বদা সেগুলি প্রাপ্ত করার ক্রমে প্রক্রিয়া করা হয়।

চিত্র 1. ক্যামেরা মডেল

এইচএএল এবং ক্যামেরা সাবসিস্টেম

ক্যামেরা সাবসিস্টেমে ক্যামেরা পাইপলাইনের উপাদানগুলির বাস্তবায়ন অন্তর্ভুক্ত থাকে যেমন 3A অ্যালগরিদম এবং প্রক্রিয়াকরণ নিয়ন্ত্রণ। ক্যামেরা HAL এই উপাদানগুলির আপনার সংস্করণগুলি বাস্তবায়নের জন্য আপনার জন্য ইন্টারফেস সরবরাহ করে। একাধিক ডিভাইস প্রস্তুতকারক এবং ইমেজ সিগন্যাল প্রসেসর (আইএসপি, বা ক্যামেরা সেন্সর) বিক্রেতাদের মধ্যে ক্রস-প্ল্যাটফর্ম সামঞ্জস্য বজায় রাখার জন্য, ক্যামেরা পাইপলাইন মডেলটি ভার্চুয়াল এবং সরাসরি কোনো বাস্তব আইএসপির সাথে সঙ্গতিপূর্ণ নয়। যাইহোক, এটি বাস্তব প্রক্রিয়াকরণ পাইপলাইনগুলির সাথে যথেষ্ট সমান যাতে আপনি এটিকে আপনার হার্ডওয়্যারে দক্ষতার সাথে ম্যাপ করতে পারেন। উপরন্তু, গুণমান, দক্ষতা, বা ক্রস-ডিভাইস সামঞ্জস্যের সাথে আপস না করেই একাধিক ভিন্ন অ্যালগরিদম এবং অপারেশনের আদেশের অনুমতি দেওয়ার জন্য এটি যথেষ্ট বিমূর্ত।

ক্যামেরা পাইপলাইনটি ট্রিগারগুলিকেও সমর্থন করে যা অ্যাপ ফ্রেমওয়ার্ক অটো-ফোকাসের মতো জিনিসগুলি চালু করতে শুরু করতে পারে। এটি একটি স্বয়ংক্রিয়-ফোকাস লক বা ত্রুটির মতো ইভেন্টগুলির অ্যাপগুলিকে অবহিত করে, অ্যাপ ফ্রেমওয়ার্কে আবার বিজ্ঞপ্তি পাঠায়।

চিত্র 2. ক্যামেরা পাইপলাইন

অনুগ্রহ করে মনে রাখবেন, উপরের ডায়াগ্রামে দেখানো কিছু ইমেজ প্রসেসিং ব্লক প্রাথমিক রিলিজে ভালভাবে সংজ্ঞায়িত নয়। ক্যামেরা পাইপলাইন নিম্নলিখিত অনুমান করে:

RAW Bayer আউটপুট ISP এর ভিতরে কোন প্রক্রিয়াকরণের মধ্য দিয়ে যায় না।
পরিসংখ্যান কাঁচা সেন্সর ডেটার ভিত্তিতে তৈরি করা হয়।
বিভিন্ন প্রসেসিং ব্লক যেগুলি কাঁচা সেন্সর ডেটাকে YUV-তে রূপান্তরিত করে সেগুলি ইচ্ছামত ক্রমে রয়েছে৷
যখন একাধিক স্কেল এবং ক্রপ ইউনিট দেখানো হয়, সমস্ত স্কলার ইউনিট আউটপুট অঞ্চল নিয়ন্ত্রণ (ডিজিটাল জুম) ভাগ করে। যাইহোক, প্রতিটি ইউনিটের আলাদা আউটপুট রেজোলিউশন এবং পিক্সেল ফর্ম্যাট থাকতে পারে।

API ব্যবহারের সারাংশ
এটি অ্যান্ড্রয়েড ক্যামেরা API ব্যবহার করার জন্য পদক্ষেপগুলির একটি সংক্ষিপ্ত সারাংশ। API কল সহ এই ধাপগুলির বিশদ বিবরণের জন্য স্টার্টআপ এবং প্রত্যাশিত অপারেশন সিকোয়েন্স বিভাগটি দেখুন।

ক্যামেরা ডিভাইসের জন্য শুনুন এবং গণনা করুন।
ডিভাইস খুলুন এবং শ্রোতাদের সংযুক্ত করুন।
লক্ষ্য ব্যবহারের ক্ষেত্রে (যেমন এখনও ক্যাপচার, রেকর্ডিং, ইত্যাদি) জন্য আউটপুট কনফিগার করুন।
লক্ষ্য ব্যবহারের ক্ষেত্রে অনুরোধ(গুলি) তৈরি করুন।
ক্যাপচার/পুনরাবৃত্তি অনুরোধ এবং বিস্ফোরণ.
ফলাফল মেটাডেটা এবং ইমেজ ডেটা পান।
ব্যবহারের ক্ষেত্রে পরিবর্তন করার সময়, ধাপ 3 এ ফিরে যান।

HAL অপারেশন সারাংশ

ক্যাপচারের জন্য অ্যাসিঙ্ক্রোনাস অনুরোধগুলি ফ্রেমওয়ার্ক থেকে আসে।
এইচএএল ডিভাইস অবশ্যই ক্রমানুসারে অনুরোধগুলি প্রক্রিয়া করবে। এবং প্রতিটি অনুরোধের জন্য, আউটপুট ফলাফল মেটাডেটা এবং এক বা একাধিক আউটপুট ইমেজ বাফার তৈরি করুন।
অনুরোধ এবং ফলাফলের জন্য ফার্স্ট-ইন, ফার্স্ট-আউট এবং পরবর্তী অনুরোধ দ্বারা উল্লেখিত স্ট্রিমগুলির জন্য।
একটি প্রদত্ত অনুরোধ থেকে সমস্ত আউটপুটগুলির জন্য টাইমস্ট্যাম্পগুলি অবশ্যই অভিন্ন হতে হবে, যাতে প্রয়োজনে কাঠামোটি তাদের একসাথে মেলে।
সমস্ত ক্যাপচার কনফিগারেশন এবং অবস্থা (3A রুটিনগুলি ব্যতীত) অনুরোধ এবং ফলাফলগুলিতে অন্তর্ভুক্ত করা হয়েছে।

চিত্র 3. ক্যামেরা HAL ওভারভিউ

স্টার্টআপ এবং প্রত্যাশিত অপারেশন ক্রম

এই বিভাগে ক্যামেরা API ব্যবহার করার সময় প্রত্যাশিত পদক্ষেপগুলির একটি বিশদ ব্যাখ্যা রয়েছে৷ HIDL ইন্টারফেস সংজ্ঞার জন্য দয়া করে প্ল্যাটফর্ম/হার্ডওয়্যার/ইন্টারফেস/ক্যামেরা/ দেখুন।

গণনা করা, ক্যামেরা ডিভাইস খোলা এবং একটি সক্রিয় অধিবেশন তৈরি করা

সূচনা করার পরে, ফ্রেমওয়ার্কটি ICameraProvider ইন্টারফেস বাস্তবায়ন করে এমন যেকোনো বর্তমান ক্যামেরা প্রদানকারীর জন্য শুনতে শুরু করে। এই ধরনের প্রদানকারী বা প্রদানকারী উপস্থিত থাকলে, কাঠামো একটি সংযোগ স্থাপন করার চেষ্টা করবে।
ফ্রেমওয়ার্ক ICameraProvider::getCameraIdList() এর মাধ্যমে ক্যামেরা ডিভাইসগুলি গণনা করে।
ফ্রেমওয়ার্ক সংশ্লিষ্ট ICameraProvider::getCameraDeviceInterface_VX_X() কল করে একটি নতুন ICameraDevice সূচনা করে।
ফ্রেমওয়ার্ক একটি নতুন সক্রিয় ক্যাপচার সেশন ICameraDeviceSession তৈরি করতে ICameraDevice::open() কল করে।

একটি সক্রিয় ক্যামেরা সেশন ব্যবহার করে

ফ্রেমওয়ার্ক ICameraDeviceSession::configureStreams() HAL ডিভাইসে ইনপুট/আউটপুট স্ট্রীমগুলির একটি তালিকা সহ কল করে।
ফ্রেমওয়ার্ক ICameraDeviceSession::constructDefaultRequestSettings() এ কল সহ কিছু ব্যবহারের ক্ষেত্রে ডিফল্ট সেটিংসের অনুরোধ করে। ICameraDeviceSession ICameraDevice::open দ্বারা তৈরি হওয়ার পরে যে কোনো সময় এটি ঘটতে পারে।
ফ্রেমওয়ার্ক ডিফল্ট সেটিংসের একটি সেটের উপর ভিত্তি করে সেটিংস সহ এবং ফ্রেমওয়ার্ক দ্বারা আগে নিবন্ধিত হওয়া অন্তত একটি আউটপুট স্ট্রীম সহ প্রথম ক্যাপচার অনুরোধটি HAL-কে তৈরি করে এবং পাঠায়। এটি ICameraDeviceSession::processCaptureRequest() সহ HAL-এ পাঠানো হয়। পরবর্তী অনুরোধ পাঠানোর জন্য প্রস্তুত না হওয়া পর্যন্ত HAL-কে অবশ্যই এই কলের রিটার্ন ব্লক করতে হবে।
ফ্রেমওয়ার্ক অনুরোধ জমা দিতে থাকে এবং প্রয়োজন অনুযায়ী অন্যান্য ব্যবহারের ক্ষেত্রে ডিফল্ট সেটিংস বাফার পেতে ICameraDeviceSession::constructDefaultRequestSettings() কল করে।
যখন একটি অনুরোধের ক্যাপচার শুরু হয় (ক্যাপচারের জন্য সেন্সর প্রকাশ করা শুরু করে), HAL ICameraDeviceCallback::notify() কে SHUTTER বার্তা সহ, ফ্রেম নম্বর এবং এক্সপোজার শুরুর জন্য টাইমস্ট্যাম্প সহ কল করে। এই বিজ্ঞপ্তি কলব্যাকটি একটি অনুরোধের জন্য প্রথম processCaptureResult() কলের আগে ঘটতে হবে না, তবে ক্যাপচারের জন্য notify() কল না করা পর্যন্ত ক্যাপচারের জন্য একটি অ্যাপ্লিকেশনে কোনো ফলাফল সরবরাহ করা হয় না।
কিছু পাইপলাইন বিলম্বের পরে, HAL ICameraDeviceCallback::processCaptureResult() দিয়ে ফ্রেমওয়ার্কে সম্পূর্ণ ক্যাপচার ফিরিয়ে দিতে শুরু করে। এগুলি একই ক্রমে ফেরত দেওয়া হয় যেভাবে অনুরোধগুলি জমা দেওয়া হয়েছিল৷ ক্যামেরা HAL ডিভাইসের পাইপলাইনের গভীরতার উপর নির্ভর করে একাধিক অনুরোধ একবারে ফ্লাইটে হতে পারে।

কিছু সময়ের পরে, নিম্নলিখিতগুলির মধ্যে একটি ঘটবে:

ফ্রেমওয়ার্ক নতুন অনুরোধ জমা দেওয়া বন্ধ করতে পারে, বিদ্যমান ক্যাপচারগুলি সম্পূর্ণ হওয়ার জন্য অপেক্ষা করতে পারে (সমস্ত বাফার ভরা, সমস্ত ফলাফল ফিরে এসেছে), এবং তারপরে আবার ICameraDeviceSession::configureStreams() কল করুন। এটি ইনপুট/আউটপুট স্ট্রীমের একটি নতুন সেটের জন্য ক্যামেরা হার্ডওয়্যার এবং পাইপলাইন রিসেট করে। কিছু স্ট্রীম আগের কনফিগারেশন থেকে পুনরায় ব্যবহার করা হতে পারে। ফ্রেমওয়ার্ক তারপর প্রথম ক্যাপচার অনুরোধ থেকে HAL-এর কাছে চলতে থাকে, যদি অন্তত একটি নিবন্ধিত আউটপুট স্ট্রিম থেকে যায়। (অন্যথায়, ICameraDeviceSession::configureStreams() প্রথমে প্রয়োজন।)
ফ্রেমওয়ার্ক ক্যামেরা সেশন শেষ করতে ICameraDeviceSession::close() কল করতে পারে। ফ্রেমওয়ার্ক থেকে অন্য কোনও কল সক্রিয় না থাকলে এটি যে কোনও সময়ে কল করা যেতে পারে, যদিও সমস্ত ইন-ফ্লাইট ক্যাপচার সম্পূর্ণ না হওয়া পর্যন্ত কলটি ব্লক হতে পারে (সমস্ত ফলাফল ফিরে এসেছে, সমস্ত বাফার পূর্ণ)। close() কল রিটার্ন করার পর, HAL থেকে ICameraDeviceCallback এ আর কোনো কল করার অনুমতি নেই। একবার close() কল চলছে, ফ্রেমওয়ার্ক অন্য কোনো HAL ডিভাইস ফাংশন কল করতে পারে না।
একটি ত্রুটি বা অন্যান্য অ্যাসিঙ্ক্রোনাস ইভেন্টের ক্ষেত্রে, HAL অবশ্যই উপযুক্ত ত্রুটি/ইভেন্ট বার্তা সহ ICameraDeviceCallback::notify() কল করতে হবে। একটি মারাত্মক ডিভাইস-ব্যাপী ত্রুটি বিজ্ঞপ্তি থেকে ফিরে আসার পরে, HAL-এর এমনভাবে কাজ করা উচিত যেন এটিতে close() বলা হয়েছে। যাইহোক, HAL-কে notify() কল করার আগে সমস্ত বকেয়া ক্যাপচার বাতিল বা সম্পূর্ণ করতে হবে, যাতে একবার notify() মারাত্মক ত্রুটির সাথে কল করা হলে, ফ্রেমওয়ার্ক ডিভাইস থেকে আর কলব্যাক পাবে না। একটি মারাত্মক ত্রুটির বার্তা থেকে notify() পদ্ধতিটি ফিরে আসার পরে close() এর পাশাপাশি পদ্ধতিগুলি -ENODEV বা NULL ফিরে আসা উচিত।

চিত্র 4. ক্যামেরা অপারেশনাল প্রবাহ

হার্ডওয়্যার স্তর

ক্যামেরা ডিভাইসগুলি তাদের ক্ষমতার উপর নির্ভর করে বিভিন্ন হার্ডওয়্যার স্তর প্রয়োগ করতে পারে। আরও তথ্যের জন্য, সমর্থিত হার্ডওয়্যার স্তর দেখুন।

অ্যাপ্লিকেশন ক্যাপচার অনুরোধ, 3A নিয়ন্ত্রণ, এবং প্রক্রিয়াকরণ পাইপলাইনের মধ্যে মিথস্ক্রিয়া

3A কন্ট্রোল ব্লকের সেটিংসের উপর নির্ভর করে, ক্যামেরা পাইপলাইন অ্যাপ্লিকেশনের ক্যাপচার অনুরোধের কিছু প্যারামিটার উপেক্ষা করে এবং পরিবর্তে 3A নিয়ন্ত্রণ রুটিন দ্বারা প্রদত্ত মানগুলি ব্যবহার করে। উদাহরণস্বরূপ, যখন অটো-এক্সপোজার সক্রিয় থাকে, তখন সেন্সরের এক্সপোজারের সময়, ফ্রেমের সময়কাল এবং সংবেদনশীলতা প্যারামিটারগুলি প্ল্যাটফর্ম 3A অ্যালগরিদম দ্বারা নিয়ন্ত্রিত হয় এবং যেকোন অ্যাপ-নির্দিষ্ট মান উপেক্ষা করা হয়। 3A রুটিন দ্বারা ফ্রেমের জন্য নির্বাচিত মানগুলি আউটপুট মেটাডেটাতে রিপোর্ট করা আবশ্যক। নিম্নলিখিত সারণী 3A কন্ট্রোল ব্লকের বিভিন্ন মোড এবং এই মোডগুলির দ্বারা নিয়ন্ত্রিত বৈশিষ্ট্যগুলি বর্ণনা করে। এই বৈশিষ্ট্যগুলির সংজ্ঞার জন্য প্ল্যাটফর্ম/system/media/camera/docs/docs.html ফাইলটি দেখুন।

প্যারামিটার	অবস্থা	বৈশিষ্ট্য নিয়ন্ত্রিত
android.control.aeMode	বন্ধ	কোনোটিই নয়
	চালু	android.sensor.exposureTime android.sensor.frameDuration android.sensor.sensitivity android.lens.aperture (যদি সমর্থিত হয়) android.lens.filterDensity (যদি সমর্থিত হয়)
	ON_AUTO_FLASH	সবকিছু চালু আছে, প্লাস 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	বন্ধ	কোনোটিই নয়
	আলোর ভারসাম্য_*	android.colorCorrection.transform. android.colorCorrection.mode দ্রুত বা HIGH_QUALITY হলে প্ল্যাটফর্ম-নির্দিষ্ট সমন্বয়।
android.control.afMode	বন্ধ	কোনোটিই নয়
	ফোকাস মোড_*	android.lens.focusDistance
android.control.videoStabilization	বন্ধ	কোনোটিই নয়
	চালু	ভিডিও স্ট্যাবিলাইজেশন বাস্তবায়ন করতে android.scaler.cropRegion সামঞ্জস্য করতে পারে
android.control.mode	বন্ধ	AE, AWB, এবং AF অক্ষম
	অটো	স্বতন্ত্র AE, AWB, এবং AF সেটিংস ব্যবহার করা হয়
	SCENE_MODE_*	উপরে তালিকাভুক্ত সমস্ত পরামিতি ওভাররাইড করতে পারে। স্বতন্ত্র 3A নিয়ন্ত্রণ অক্ষম করা হয়েছে।

চিত্র 2-এর ইমেজ প্রসেসিং ব্লকের নিয়ন্ত্রণগুলি একই নীতিতে কাজ করে এবং সাধারণত প্রতিটি ব্লকের তিনটি মোড থাকে:

বন্ধ: এই প্রক্রিয়াকরণ ব্লক নিষ্ক্রিয় করা হয়েছে. ডেমোজাইক, রঙ সংশোধন, এবং টোন বক্ররেখা সমন্বয় ব্লক অক্ষম করা যাবে না।
দ্রুত: এই মোডে, প্রসেসিং ব্লকটি বন্ধ মোডের তুলনায় আউটপুট ফ্রেম রেটকে ধীর নাও করতে পারে, তবে অন্যথায় সেই সীমাবদ্ধতা প্রদান করতে পারে এমন সেরা-মানের আউটপুট তৈরি করা উচিত। সাধারণত, এটি প্রিভিউ বা ভিডিও রেকর্ডিং মোড বা স্থির চিত্রের জন্য বার্স্ট ক্যাপচারের জন্য ব্যবহার করা হবে। কিছু ডিভাইসে, এটি অফ মোডের সমতুল্য হতে পারে (ফ্রেম রেট কমিয়ে না দিয়ে কোনও প্রক্রিয়াকরণ করা যাবে না), এবং কিছু ডিভাইসে, এটি HIGH_QUALITY মোডের সমতুল্য হতে পারে (সেরা গুণমান এখনও ফ্রেম রেট কমিয়ে দেয় না)৷
HIGH_QUALITY: এই মোডে, প্রসেসিং ব্লকটি সম্ভাব্য সর্বোত্তম মানের ফলাফল তৈরি করবে, প্রয়োজন অনুযায়ী আউটপুট ফ্রেম রেট কমিয়ে দেবে। সাধারণত, এটি উচ্চ-মানের স্টিল ক্যাপচারের জন্য ব্যবহার করা হবে। কিছু ব্লকে একটি ম্যানুয়াল নিয়ন্ত্রণ রয়েছে যা দ্রুত বা HIGH_QUALITY এর পরিবর্তে ঐচ্ছিকভাবে নির্বাচন করা যেতে পারে। উদাহরণস্বরূপ, রঙ সংশোধন ব্লক একটি রঙ রূপান্তর ম্যাট্রিক্স সমর্থন করে, যখন টোন বক্ররেখা সমন্বয় একটি নির্বিচারে গ্লোবাল টোন ম্যাপিং বক্ররেখা সমর্থন করে।

সর্বাধিক ফ্রেম রেট যা একটি ক্যামেরা সাবসিস্টেম দ্বারা সমর্থিত হতে পারে তা অনেকগুলি কারণের একটি ফাংশন:

আউটপুট ইমেজ স্ট্রীম এর রেজোলিউশন অনুরোধ করা হয়েছে
ইমেজারে বিনিং/স্কিপিং মোডের উপলব্ধতা
ইমেজার ইন্টারফেসের ব্যান্ডউইথ
বিভিন্ন আইএসপি প্রসেসিং ব্লকের ব্যান্ডউইথ

যেহেতু এই কারণগুলি বিভিন্ন ISP এবং সেন্সরগুলির মধ্যে ব্যাপকভাবে পরিবর্তিত হতে পারে, তাই ক্যামেরা HAL ইন্টারফেস ব্যান্ডউইথের সীমাবদ্ধতাগুলিকে যতটা সম্ভব সহজ মডেলে বিমূর্ত করার চেষ্টা করে। উপস্থাপিত মডেলের নিম্নলিখিত বৈশিষ্ট্য রয়েছে:

অ্যাপ্লিকেশানের অনুরোধকৃত আউটপুট স্ট্রীম আকারের ভিত্তিতে ইমেজ সেন্সরটি সর্বদা সম্ভাব্য ক্ষুদ্রতম রেজোলিউশন আউটপুট করার জন্য কনফিগার করা হয়। ক্ষুদ্রতম রেজোলিউশনকে সর্ববৃহৎ অনুরোধকৃত আউটপুট স্ট্রীম আকারের হিসাবে অন্তত বড় হিসাবে সংজ্ঞায়িত করা হয়।
যেহেতু যেকোন অনুরোধ যেকোন বা সমস্ত বর্তমানে কনফিগার করা আউটপুট স্ট্রীম ব্যবহার করতে পারে, তাই সেন্সর এবং আইএসপিকে অবশ্যই একই সময়ে সমস্ত স্ট্রীমে একটি একক ক্যাপচার স্কেল করার জন্য কনফিগার করতে হবে।
JPEG স্ট্রীমগুলি প্রসেসড YUV স্ট্রিমগুলির মতো কাজ করে যেগুলির জন্য সেগুলি অন্তর্ভুক্ত নয়; যে অনুরোধগুলিতে তারা সরাসরি উল্লেখ করা হয়েছে, তারা JPEG স্ট্রীম হিসাবে কাজ করে।
JPEG প্রসেসর বাকি ক্যামেরা পাইপলাইনে একযোগে চলতে পারে কিন্তু একবারে একাধিক ক্যাপচার প্রক্রিয়া করতে পারে না।