1，Camera基本工作原理

答案： 光線通過鏡頭Lens進(jìn)入攝像頭內(nèi)部，然后經(jīng)過IR Filter過濾紅外光，最后到達(dá)sensor（傳感器），senor分為按照材質(zhì)可以分為CMOS和CCD兩種，可以將光學(xué)信號(hào)轉(zhuǎn)換為電信號(hào)，再通過內(nèi)部的ADC電路轉(zhuǎn)換為數(shù)字信號(hào)，然后傳輸給DSP（如果有的話，如果沒有則以DVP的方式傳送數(shù)據(jù)到基帶芯片baseband，此時(shí)的數(shù)據(jù)格式Raw Data，后面有講進(jìn)行加工）加工處理，轉(zhuǎn)換成RGB、YUV等格式輸出。

數(shù)據(jù)流是如何從sensor到APP的？

上述描述結(jié)束后，在ISP處理后面的階段，數(shù)據(jù)會(huì)進(jìn)行分流，分為capture,preview，video等以供后續(xù)動(dòng)作使用。例如zsl拍照，就是通過下發(fā)request,并獲取capture stream的數(shù)據(jù)流，進(jìn)行編碼壓縮，進(jìn)而上報(bào)APP，完成拍照動(dòng)作

2，OTP是干什么的？platform otp和sensor otp的區(qū)別？

OTP用于存儲(chǔ)Lens shading參數(shù)、AWB參數(shù)、AF position等數(shù)據(jù)的校準(zhǔn)數(shù)據(jù),用于校準(zhǔn)

平臺(tái)端 otp:沒有otp的自校正功能，需要我們BB端（服務(wù)器）進(jìn)行校校準(zhǔn)，從存儲(chǔ)空間（外掛eeprom或者sensor內(nèi)部存儲(chǔ)空間）中read出數(shù)據(jù)，然后將數(shù)據(jù)送給BB（BBinder）進(jìn)行校準(zhǔn)。

sensor otp:sensor有otp的自校準(zhǔn)功能，從存儲(chǔ)空間（外掛eeprom或者sensor內(nèi)部存儲(chǔ)空間）中read出數(shù)據(jù)，然后寫回sensor寄存器，送給BB端的RawData是已經(jīng)校正過的數(shù)據(jù)

3，Qcom CPP功能/MTK 數(shù)據(jù)流程

QCOM：高通CPP主要功能包括Denoise,Scale,Sharpen,Rotate

MTK：Pass1, Pass2; Pass1主要是加入tuning參數(shù)以及其他處理，Pass2主要是完成Crop，Resize、數(shù)據(jù)分流等操作

雙攝同步FrameSync，AEsync 雙攝verification原理？如果有問題，如何分析？（中心點(diǎn)，光軸，AE不同步） 是否遇到過花屏/變綠的情況，如何解決？都有哪些原因會(huì)導(dǎo)致該問題？尺寸不能被16整除；

4，高通平臺(tái)，如何做sensor兼容？,

平臺(tái)已經(jīng)做好兼容，只要在camera_config.xml中配置上sensor_name即可區(qū)分不同sensor。

5，打開相機(jī)預(yù)覽界面卡頓，對(duì)比正常log和卡頓log，發(fā)現(xiàn)在人臉識(shí)別環(huán)節(jié)處理速度較慢，導(dǎo)致幀率下降。

解決辦法：1.更新人臉識(shí)別算法庫(kù)。2.是人臉識(shí)別時(shí)跳幀處理，減少耗時(shí)。

6，簡(jiǎn)述HDR或者美顏算法的移植過程

以HDR算法為例，首先，需要在Android.mk中添加需要編譯的源文件，需要加載的頭文件，指定編譯生成的so庫(kù)．在parameters中增加hdr模式key值，在takepicture函數(shù)中從HDR算法中獲取需要拍照的張數(shù)及EV值，在parameters中增加hdr模式，encodedata函數(shù)中增加進(jìn)入HDR算法的入口函數(shù)m_QCameraArcHDR.init和m_QCameraArcHDR.process，將拍的三張圖片幀以EV值分別為-6,0,6去處理．

7，開發(fā)過程中遇到的問題：閃光燈狀態(tài)設(shè)為auto,暗環(huán)境下拍照，點(diǎn)擊縮略圖查看圖片，返回相機(jī)界面迅速再拍照，閃光燈有時(shí)會(huì)不閃．

分析：查看log拍照過程中flashmode設(shè)置正確，takepicture之前和之后分別加log打印mFlashNeeded值，顯示拍照之前該值為0,拍照過程中該值變成１，查看相關(guān)代碼，mFlashNeeded是在metadata　callback中從AE中獲取的，而獲取值和拍照在兩個(gè)不同的線程中完成的，兩個(gè)線程會(huì)出現(xiàn)同步不上的情況，所以會(huì)引起這個(gè)問題．

解決辦法：在拍照之前，判斷flashmode為auto, mFlashNeeded為０時(shí)，等待100毫秒左右的時(shí)間，讓另外一個(gè)線程有時(shí)間獲取mFlashNeeded值的狀態(tài)．,

8，遇到的問題： 圖像中有不斷變化的細(xì)密的水平條紋（與熒光燈的頻閃造成的大面積的滾動(dòng)水平條紋不同，表現(xiàn)出來的是一個(gè)像素高的水平條紋狀躁點(diǎn)，位置不固定，數(shù)量比較多，而且隨光線強(qiáng)弱有一定的變化）

解決辦法： 因?yàn)樵O(shè)置某些sensor寄存器的時(shí)候，會(huì)影響到這些水平條紋的顏色，所以基本上排除是在數(shù)據(jù)傳輸過程中板子對(duì)數(shù)據(jù)造成的干擾，也排除接觸不良的可能性，應(yīng)該是數(shù)據(jù)在sensor內(nèi)部已經(jīng)存在這些水平條紋。此外相同的初始化序列，相同的sensor，在廠商的demo版上也沒有發(fā)生這種情況，所以也基本排除軟件的問題。最后，發(fā)現(xiàn)原先為了節(jié)省硬件成本，將sensor的兩個(gè)電壓相同的模擬電和數(shù)字電由同一芯片輸出供給，導(dǎo)致兩者之間互相干擾，影響了sensor的正常工作

9，切某些模式后預(yù)覽亮度變暗怎么分析．

排查：直接從驅(qū)動(dòng)搜索sensor_fill_exposure_array接口下發(fā)的參數(shù)中的gain值和fl_line值，從實(shí)際設(shè)入sensor的參數(shù)來判斷是由于iso的設(shè)定還是幀率的設(shè)定導(dǎo)致變暗的問題．

10，HAL3　cts （獲取到的sensitivity的值和實(shí)際設(shè)定的值始終有略微的差值）

分析過程：首先看代碼先確定HAL3中g(shù)etsensitivity和setsensitivity對(duì)應(yīng)操作到的參數(shù)具體是ISO值（也就是驅(qū)動(dòng)中對(duì)應(yīng)的gain值），發(fā)現(xiàn)每次都有略微的差值，懷疑是哪邊的某種轉(zhuǎn)換丟失了部分值，確定最終下到驅(qū)動(dòng)的值是多少（發(fā)現(xiàn)和get到的值一致，也是丟了某些精度）．代碼從下往上排查傳入sensor_fill_exposure_array的gain參數(shù)在傳入前有沒有什么轉(zhuǎn)換（同時(shí)郵件咨詢FAE驅(qū)動(dòng)中有無對(duì)應(yīng)轉(zhuǎn)換動(dòng)作），代碼上看到gain在傳入sensor_fill_exposure_array前（set_exposure時(shí)）經(jīng)過了驅(qū)動(dòng)接口的sensor_calculate_exposure函數(shù)的操作，使的gain值失去了一定的精度．咨詢FAE得知是由于sensor本身并不是無級(jí)的可設(shè)置gian值，需要根據(jù)下發(fā)的gain切到對(duì)應(yīng)的實(shí)際能支持的最接近的gain值上．所以和下發(fā)的gain值有了略微區(qū)別．

解決方法：針對(duì)對(duì)應(yīng)sensor型號(hào)，把轉(zhuǎn)換前的gain值賦值給獲取sensitivity會(huì)讀取的參數(shù)上．

11，sensor圖像數(shù)據(jù)轉(zhuǎn)換流程

sensor內(nèi)部的感光芯片是按順序排列的，光線進(jìn)來通過bayer pattern后中間已經(jīng)經(jīng)過光信號(hào)到電信號(hào)到數(shù)字信號(hào)的轉(zhuǎn)換了，然后數(shù)據(jù)開始通過MIPI從sensor傳給平臺(tái)，MIPI打包后（主控最前端）就得到了RAW Data。高通平臺(tái)的是RAW Data經(jīng)過ob，shading之后再經(jīng)過Demosaic轉(zhuǎn)換成了RGB，其實(shí)Demosaic就是一個(gè)插值出每個(gè)像素點(diǎn)R,G,B值的一個(gè)過程，之后再由ACE從RGB轉(zhuǎn)換成YUV，hal層那邊在通過jpegencodeconfig進(jìn)行encode成jpeg數(shù)據(jù)通過回調(diào)上傳給app。

12，相機(jī)專業(yè)模式倒計(jì)時(shí)開啟狀態(tài)下，快門時(shí)間調(diào)到3s以上，快門計(jì)時(shí)還沒有結(jié)束就發(fā)出聲音

在相機(jī)進(jìn)行專業(yè)拍照的時(shí)候，狀態(tài)機(jī)進(jìn)行了改變，走的是非zsl模式，點(diǎn)擊拍照會(huì)停止預(yù)覽，然后進(jìn)行非zsl拍照，可是在停止預(yù)覽操作到徹底關(guān)閉通道和流數(shù)據(jù)之前查看log發(fā)現(xiàn)還會(huì)有幀數(shù)據(jù)進(jìn)行了上傳，這時(shí)候狀態(tài)機(jī)是為4的狀態(tài)下，callback函數(shù)那邊的playshutter會(huì)進(jìn)行判斷，這時(shí)候狀態(tài)機(jī)已經(jīng)為非zsl模式，又有了幀數(shù)據(jù)，就會(huì)進(jìn)行playshutter。根本原因是stoppreview關(guān)閉流和通道需要一些時(shí)間，會(huì)有一些幀數(shù)據(jù)依然回調(diào)，雖然不會(huì)進(jìn)行處理，可是playshutter那邊依然會(huì)發(fā)出聲音。解決辦法：自己新添加了一個(gè)標(biāo)志位，當(dāng)執(zhí)行stoppreview時(shí)候?qū)⑵渲脼?，再playshutter那邊新增判斷條件，不讓其發(fā)出聲音。

13，手動(dòng)設(shè)置ISO&S連拍后，查看照片信息，發(fā)現(xiàn)信息顯示的ISO&S數(shù)值錯(cuò)誤

問題分析：手動(dòng)設(shè)置ISO&S后，單拍發(fā)現(xiàn)照片信息顯示正常，但是連拍照片信息顯示錯(cuò)誤，將連拍的相片散開發(fā)現(xiàn)，只有第一張照片顯示正常，其他均錯(cuò)誤;進(jìn)一步抓log分析發(fā)現(xiàn)，單拍時(shí)，camera處于ZSL模式，而連拍時(shí)，camera處于非ZSL模式。

?ZSL模式:sensor通過MIPI接口將數(shù)據(jù)流傳送到ISP中并分成多個(gè)相同(size不同)的流(preview流、thumbnail流、capture流)，在拍照時(shí)，takepicture會(huì)從capture流中取到數(shù)據(jù)傳輸給APP,此時(shí)也就是說，預(yù)覽和拍照處于相同全尺寸流狀態(tài)，即拍照只是從流里取一張而已

??非ZSL模式:拍照時(shí)，stream off，會(huì)停止preview，takepicture從sensor獲取一張圖片數(shù)據(jù)傳給APP，APP接收到圖片后，發(fā)送一個(gè)命令給sensor,sensor會(huì)通過(preview setting、capture setting、video setting等)重新使stream on，重新preview,sensor通過MIPI接口將數(shù)據(jù)流傳送到ISP中并分成多個(gè)相同(size不同)的流(preview流、thumbnail流、capture流)，takepicture從capture 流獲取圖片數(shù)據(jù)傳送給APP(故此時(shí)的圖片信息與第一張圖片信息會(huì)有所差異),預(yù)覽是小尺寸，拍照需切換設(shè)置到全尺寸，會(huì)有一定的延時(shí)

解決方案：將連拍模式的camera模式強(qiáng)制轉(zhuǎn)化成ZSL模式，即將hardware/qcom/camera/QCamera2/HAL/QCameraParameters.cpp中setZslMode()函數(shù)下的

if(!strcmp(str_asus_camera_mode_val,"PRO")||!strcmp(str_asus_camera_mode_val,"HDR")){}改成

if(/*!strcmp(str_asus_camera_mode_val,"PRO")||*/!strcmp(str_asus_camera_mode_val,"HDR")){}

???????

總結(jié)

以上是生活随笔為你收集整理的相机面试问题总结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。