HAL সাবসিস্টেম

এই পৃষ্ঠায় HAL সাবসিস্টেমের বর্ণনা দেওয়া আছে, যার মধ্যে অনুরোধ, ক্যামেরা সাবসিস্টেম, স্টার্ট-আপ এবং অপারেশন সিকোয়েন্স, হার্ডওয়্যার লেভেল ও ইন্টার‍্যাকশন অন্তর্ভুক্ত।

অনুরোধ

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

ছবি ১. ক্যামেরার মডেল।

HAL ও ক্যামেরা সাবসিস্টেম

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

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

ছবি ২. ক্যামেরা পাইপলাইন।

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

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

API ব্যবহারের সারসংক্ষেপ

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

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

HAL অপারেশন সারসংক্ষেপ

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

ছবি ৩. Camera HAL ওভারভিউ।

স্টার্ট-আপ ও প্রত্যাশিত অপারেশন সিকোয়েন্স

এই বিভাগে ক্যামেরা API ব্যবহার করার সময় যেসব ধাপ অনুসরণ করতে হবে তার বিস্তারিত ব্যাখ্যা দেওয়া আছে। HIDL ইন্টারফেসের সংজ্ঞার জন্য, platform/hardware/interfaces/camera/ দেখুন।

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

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

অ্যাক্টিভ ক্যামেরা সেশন ব্যবহার করা

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

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

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

ছবি ৪. ক্যামেরার অপারেশনাল ফ্লো।

হার্ডওয়্যার লেভেল

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

অ্যাপ ক্যাপচার অনুরোধ, 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-এর পরিবর্তে ঐচ্ছিকভাবে বেছে নেওয়া যায়। যেমন, কালার কারেকশন ব্লক, কালার ট্রান্সফর্ম ম্যাট্রিক্স সমর্থন করে, যেখানে টোন কার্ভ অ্যাডজাস্টমেন্ট, একটি নির্বিচারে গ্লোবাল টোন ম্যাপিং কার্ভ সমর্থন করে।

ক্যামেরা সাবসিস্টেমের মাধ্যমে কাজ করে এমন সর্বাধিক ফ্রেম রেট হল বিভিন্ন ফ্যাক্টরের ফাংশন:

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

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

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