Chapter 06

영상 처리 엔진과 데이터 흐름

센서가 내보내는 것은 사진이 아니라 수천만 개의 숫자입니다. 이 숫자를 1초에 수십 번, 수 기가바이트씩 받아 사진과 영상으로 바꾸고, 압축해 메모리 카드에 써 넣는 일은 카메라 안의 작은 컴퓨터인 영상 처리 엔진(Image Processor)이 맡습니다. 이 장에서는 그 컴퓨터를 블록 단위로 뜯어 보고, 데이터가 센서에서 카드까지 흐르는 길을 따라가며 어디가 병목이 되는지 숫자로 확인합니다.

영상 처리 엔진(SoC)을 이루는 블록: 센서 인터페이스, ISP, CPU, NPU, 코덱, 메모리 컨트롤러, 입출력이 각각 하는 일을 안다.
ISP 파이프라인의 각 단계를 실제 픽셀 데이터에 켜고 끄며, 순서가 왜 그렇게 정해졌는지 설명할 수 있다.
화소 수 × 비트 심도 × 초당 장수로 데이터 예산을 계산하고, 버퍼와 카드 속도로 연사 지속 시간을 예측한다.
동영상 코덱(인트라·Long-GOP, 10비트, 4:2:2)이 비트레이트와 카드 요구 사양을 어떻게 바꾸는지 안다.
처리량이 곧 전력이고 전력이 곧 열이라는 관계로, 동영상이 왜 카메라를 뜨겁게 하는지 설명한다.

카메라 안의 컴퓨터

카메라를 열어 보면 메인 기판 한가운데에 손톱만 한 칩이 하나 있습니다. 제조사마다 이름은 다르지만 하는 일은 같습니다. 센서의 데이터를 받아 사진을 만들고, 화면에 보여 주고, 초점과 노출을 계산하고, 파일로 저장합니다. 스마트폰의 애플리케이션 프로세서처럼 여러 기능 블록을 한 칩에 모은 SoC(System on Chip)이며, 고급 기종은 처리 칩을 두 개 이상 두거나 AI 처리를 따로 맡는 보조 칩을 붙이기도 합니다.

그림 6-1. 영상 처리 엔진의 블록 구성. 센서 데이터는 전용 인터페이스로 들어와 ISP를 거치고, 대부분의 중간 결과는 바깥의 DRAM을 오가며 처리됩니다. 모든 블록이 같은 메모리를 나눠 쓰므로 메모리 대역폭이 숨은 병목이 됩니다.

센서 인터페이스센서와 칩을 잇는 여러 가닥의 고속 직렬 레인(MIPI CSI-2 같은 표준이나 전용 규격). 레인 하나가 초당 수 Gbit를 실어 나르고, 고속 센서는 레인을 여러 개 묶습니다.

ISPISP(Image Signal Processor)는 픽셀 처리 전용 하드웨어 파이프라인입니다. 계산 순서가 고정된 대신 같은 일을 범용 CPU보다 흔히 수십 배 적은 에너지로 해냅니다.

CPU 코어메뉴·버튼·파일 시스템, 렌즈 통신, 각 블록의 일정 관리. 픽셀을 직접 만지기보다 '지휘'를 맡습니다.

NPUNPU(Neural Processing Unit)는 신경망 추론 전용 블록. 눈·사람·동물·탈것을 실시간으로 찾아 AF에 넘깁니다(07장).

코덱동영상을 H.264/H.265로, 사진을 JPEG·HEIF로 압축하는 전용 회로. 초당 수억 화소를 실시간으로 압축해야 하므로 소프트웨어로는 불가능합니다.

메모리 컨트롤러바깥 DRAM과의 통로. ISP의 여러 단계, 코덱, 화면 출력, 버퍼가 모두 이 길을 나눠 씁니다.

이 구조는 스마트폰 SoC와 거의 같습니다. 차이는 규모입니다. 풀프레임 센서는 스마트폰 센서보다 픽셀 수가 비슷하거나 많고 비트 심도가 높으며, 무엇보다 연사·동영상에서 쉬지 않고 데이터를 쏟아냅니다. 스마트폰 쪽 구조는 PhoneBook의 SoC 장과 카메라 모듈 장에서 다룹니다. 센서가 숫자를 만드는 과정은 05장, 전체 시스템 지도는 01장을 보세요.

ISP 파이프라인 한 단계씩

센서가 내보내는 RAW 데이터는 한 픽셀에 숫자 하나뿐인 흑백 모자이크입니다. 각 픽셀 위에 빨강·초록·파랑 중 한 색 필터만 얹혀 있기 때문입니다(베이어 패턴). 여기에는 센서의 바닥값, 고장 난 픽셀, 렌즈 가장자리의 어두움, 조명의 색이 그대로 섞여 있습니다. ISP는 이것을 정해진 순서로 하나씩 걷어 내고, 마지막에 사람 눈과 모니터에 맞게 다듬습니다.

그림 6-2. 대표적인 ISP 파이프라인. 실제 칩은 단계가 더 많고(왜곡·색수차 보정, 다중 프레임 합성, 로컬 톤 매핑 등), 일부 순서는 제조사마다 다릅니다. 그러나 '선형 영역에서 물리 보정 → 비선형 영역에서 보기 좋게'라는 큰 흐름은 같습니다.

단계	무엇을 하나	왜 이 자리에 있나
블랙 레벨 보정	빛이 0이어도 센서가 내놓는 바닥값(예: 14비트에서 수백~1,000 DN 안팎)을 뺀다	모든 곱셈(게인·행렬)은 '빛 0 = 값 0'이어야 맞다. 빼지 않으면 그림자가 뿌옇게 뜨고 색이 틀어진다
결함 화소 보정	항상 밝거나(핫) 어두운(데드) 픽셀을 같은 색 이웃 값으로 메운다	디모자이크 전에 고쳐야 한다. 뒤로 가면 한 점이 주변 색까지 번진다
렌즈 셰이딩 보정	렌즈 주변부 광량 저하(비네팅)를 위치별 게인으로 되돌린다	렌즈 프로필(03장)에서 온 보정 지도. 가장자리 노이즈도 함께 커진다
화이트 밸런스	R·B 채널에 게인을 곱해 흰 물체가 R=G=B가 되게 한다	조명의 색은 채널별 곱셈이므로 선형일 때 정확히 되돌릴 수 있다. 게인 값은 AWB가 추정(07장)
디모자이크	각 픽셀의 빠진 두 색을 이웃에서 보간해 RGB 3채널을 만든다	데이터가 세 배로 불어나는 지점. 고운 무늬에서 거짓 색·지퍼 무늬가 생긴다
색 보정 행렬	3×3 행렬로 센서 고유의 색 응답을 표준 색 공간으로 옮긴다	센서 필터는 서로 겹치는 스펙트럼을 가져 색이 탁하다. 행렬이 이를 풀어 주지만 노이즈도 키운다
노이즈 감소	가장자리는 지키며 평탄한 곳의 얼룩을 줄인다. 색 노이즈는 더 강하게	CCM이 키운 노이즈까지 함께 처리. 너무 세면 피부·잎이 뭉개진다(13장)
톤 커브·감마	선형 값을 사람 눈과 모니터에 맞는 밝기 곡선으로 바꾼다	여기서부터 값은 빛에 비례하지 않는다. 그래서 물리 보정은 모두 앞에서 끝낸다
샤프닝	밝기의 가장자리 대비를 키운다(언샤프 마스크)	노이즈 감소 뒤에 해야 노이즈를 키우지 않는다
색 공간 변환·압축	RGB → YCbCr, 색 정보 절반·4분의 1로 줄이고 JPEG/HEIF로 압축	파일 크기를 줄이는 마지막 단계(19장)

SIMULATOR

ISP 파이프라인 실험실: 단계를 끄고 켜 보기

클릭: 그 자리 ×4 확대

조명

감도(노이즈)

보고 있는 단계—

데이터 형태—

이 브라우저 처리 시간—

45 MP·20 fps라면—

모델: 320×200 장면(풍경·색 차트·방사형 해상도 차트)을 선형광으로 바꾼 뒤, 센서 색 응답(서로 겹치는 3×3 혼합 행렬)·조명 색·렌즈 비네팅(모서리 약 −1.4스톱)·RGGB 베이어 샘플링·광자 샷 노이즈(√전자 수)와 읽기 노이즈·블랙 레벨 1024 DN(14비트)·결함 화소(실제보다 과장해 약 0.2%)를 더해 가짜 RAW를 만듭니다. 각 단계는 이 데이터에 실제로 계산됩니다: BLC는 (DN−1024)/(16383−1024), DPC는 같은 색 이웃 8개 범위를 크게 벗어난 값 교체, LSC는 비네팅 지도의 역수 곱, WB는 흰색 기준 채널 게인, 디모자이크는 쌍선형 보간, CCM은 센서 혼합 행렬의 역행렬, NR은 밝기 5×5 양방향(bilateral) 필터 + 색차 블러, 톤은 sRGB 감마 + 약한 S 곡선, 샤프닝은 밝기 언샤프 마스크, 마지막은 YCbCr 8비트 양자화 + 4:2:0 색 다운샘플링입니다. 화이트 밸런스 게인은 조명을 '알고' 있다고 가정했습니다. 썸네일 중 톤 단계 이전 것은 선형 데이터라 표시용 감마만 씌워 보여 줍니다(큰 화면의 최종 결과는 그대로). 해볼 것: ① 블랙 레벨만 끄기 → 안개 낀 듯 뜨고 색이 바랩니다. ② 디모자이크를 끄면 RAW의 정체인 흑백 체크무늬가 드러납니다. 방사형 차트를 확대해 디모자이크의 거짓 색을 보세요. ③ CCM을 끄면 색이 탁해지고, 켜면 선명해지지만 ISO 6400에서 색 얼룩이 늘어납니다. ④ 톤을 끄면 선형 데이터가 얼마나 어둡게 보이는지. ⑤ NR을 끄고 샤프닝만 켜면 노이즈가 날카로워집니다.

사용자 쪽에서 보면이 파이프라인의 대부분은 메뉴의 한 줄로 드러납니다. 화이트 밸런스와 픽처 스타일은 18장, 노이즈 감소 강도는 13장, 그리고 이 처리를 카메라가 하지 않고 PC로 미루는 선택이 19장의 RAW 촬영입니다. RAW 파일은 대략 이 그림의 '센서 RAW' 칸에 블랙 레벨·WB 게인·색 행렬 같은 메타데이터를 붙여 저장한 것입니다.

ISP를 더 깊이실제 ISP는 이보다 훨씬 정교합니다. 방향을 보는 디모자이크, 여러 프레임을 겹치는 시간 축 노이즈 감소, 영역마다 다른 로컬 톤 매핑, 렌즈 왜곡·색수차 보정, 그리고 AE·AF·AWB에 쓰일 히스토그램과 초점 값 같은 3A 통계를 처리 도중에 뽑아냅니다. 각 알고리즘의 원리는 SensorBook의 ISP 장과 컬러 장에서 자세히 다룹니다.

초당 기가바이트

센서에서 나오는 데이터의 양은 곱셈 하나로 계산됩니다.

$$R_{\text{data}} = N_{\text{px}} \times b \times f$$

$N_{\text{px}}$: 판독하는 화소 수, $b$: 화소당 비트 수(ADC 비트 심도), $f$: 초당 판독 횟수

4,500만 화소(45 MP)를 14비트로 초당 20장 읽으면 45×10⁶ × 14 × 20 = 126억 bit/s, 바이트로 약 1.6 GB/s입니다. 영화 한 편 분량의 데이터가 몇 초마다 쏟아지는 셈입니다. 그리고 이것은 입구일 뿐입니다. ISP 안에서 디모자이크 뒤의 RGB 데이터는 화소당 값이 세 개로 늘고, 중간 결과는 대개 16비트로 다뤄지므로 같은 사진이 처리 도중에는 몇 배로 부풀었다가 압축 단계에서야 줄어듭니다.

지점 (45 MP, 20 fps 연사 예)	화소당	데이터율	비고
센서 → 센서 인터페이스	14 bit	≈ 1.6 GB/s	고속 직렬 레인 여러 개 필요
디모자이크 뒤 RGB(16비트 × 3)	48 bit	≈ 5.4 GB/s	단계마다 DRAM을 읽고 쓰면 그 배수
무손실 압축 RAW 기록	≈ 8~10 bit	≈ 0.9~1.1 GB/s	장면에 따라 다름
JPEG(고화질) 기록	≈ 2~4 bit	≈ 0.2~0.45 GB/s	장당 십수~20여 MB
4K 30p 동영상(H.265, 150 Mbps)	≈ 0.6 bit	≈ 0.02 GB/s	판독은 수백 MB/s 이상

그래서 영상 처리 엔진 설계의 핵심 숫자 중 하나는 DRAM 대역폭입니다. 카메라용 SoC는 대개 저전력 DRAM(LPDDR)을 넓은 버스로 붙여 초당 수십 GB를 오가게 하는데, 이 대역폭을 ISP·코덱·화면 출력·버퍼가 나눠 씁니다. 처리 단계를 칩 안의 작은 SRAM에서 줄 단위로 흘려보내 DRAM 왕복을 줄이는 설계(라인 버퍼 방식)가 중요한 이유입니다. 센서 쪽 판독 속도와 적층형 센서의 내부 메모리는 05장과 SensorBook의 판독 회로, 인터페이스 장에서 다룹니다.

판독은 '찍을 때'만 일어나지 않는다미러리스는 전원이 켜져 있는 동안 EVF를 위해 센서를 초당 60~120번 읽습니다. 보통은 화소를 묶거나 건너뛰어 수백만 화소만 읽지만, 그래도 이 '보고 있기만 하는' 데이터 흐름이 배터리를 꾸준히 씁니다. 마지막 절의 시뮬레이터에서 '라이브 뷰 대기'를 확인해 보세요.

버퍼와 메모리 카드

연사 중에는 1.6 GB/s가 들어오는데 메모리 카드는 그만큼 빨리 받아 주지 못합니다. 그 차이를 메워 주는 것이 DRAM의 일부를 떼어 쓰는 버퍼입니다. 물탱크로 생각하면 쉽습니다. 위에서 들어오는 물(촬영)이 아래로 빠지는 물(카드 쓰기)보다 많으면 수위가 오르고, 가득 차면 들어오는 양을 빠지는 양에 맞출 수밖에 없습니다. 그 순간 연사가 '툭' 느려집니다.

그림 6-3. 버퍼의 물탱크 모델. 초당 장수 $f$, 장당 파일 크기 $s$, 카드 연속 쓰기 속도 $c$, 버퍼 용량 $B$. 입력이 출력보다 작으면 탱크는 차지 않고 연사는 끝없이 이어집니다.

$$N_{\text{burst}} \approx \frac{B}{\,s - c/f\,}, \qquad t_{\text{full}} = \frac{B}{f s - c}, \qquad t_{\text{clear}} = \frac{B}{c}$$

한 장 찍을 때마다 $s$만큼 들어오고, 그 사이($1/f$초) 카드가 $c/f$만큼 빼 간다. 가득 찬 뒤의 연사 속도는 $c/s$ 장/초.

카드 규격	인터페이스 최대	실사용 연속 쓰기(대략)	동영상 등급 예
SD UHS-I	104 MB/s	30 ~ 90 MB/s	V30 (최소 30 MB/s 보장)
SD UHS-II	312 MB/s	90 ~ 300 MB/s	V60 · V90
CFexpress Type A	≈ 1 GB/s	400 ~ 800 MB/s	VPG200 · VPG400
CFexpress Type B	≈ 2 GB/s	1,000 ~ 1,700 MB/s	VPG400

표의 '실사용' 값은 카드 제품과 카메라의 카드 슬롯 구현에 따라 크게 달라지는 대략적인 범위입니다. 포장에 큰 글씨로 적힌 숫자는 대개 읽기 최대 속도이고, 연사·동영상에 중요한 것은 지속 쓰기 속도입니다. 동영상 등급(V30·V60·V90, VPG)은 '최소 이만큼은 꾸준히 쓴다'는 보장값이라 동영상 비트레이트와 바로 비교할 수 있습니다. 최신 CFexpress 4.0 세대는 인터페이스 속도가 한 단계 더 올라갔습니다.

SIMULATOR

연사와 버퍼: 언제 느려지고, 언제 다 비워지나

화소 수

RAW 비트 심도

파일 형식

연사 속도 버퍼 용량

메모리 카드

셔터를 누르고 있는 시간

장당 파일 크기—

입력 / 카드 속도—

느려지기 전까지—

그 뒤 연사 속도—

손 뗀 뒤 비우는 시간—

모델: 장당 크기 = 비압축 RAW는 화소 수 × 비트 심도 ÷ 8 + 메타데이터·미리보기 2 MB, 무손실 압축 RAW는 그 데이터의 60%(실제로는 장면에 따라 대략 50~70%), JPEG는 화소당 약 3 bit(고화질 기준 예시값). 버퍼에는 '기록될 파일 크기'만큼 쌓인다고 단순화했고(실제 기종은 처리 전 데이터를 담기도 함), 카드는 표시한 연속 쓰기 속도(UHS-I 80, UHS-II 250, CFexpress A 700, B 1500 MB/s)로 쉬지 않고 쓴다고 봅니다. 위 그래프는 버퍼 사용률, 아래는 누적 장수(점선 = 이론상 연사)입니다. 해볼 것: ① 45 MP 비압축 RAW·20 fps에서 카드를 SD UHS-I로 바꿔 보기. 버퍼가 몇 초 만에 차고, 그 뒤엔 초당 1장 남짓으로 떨어집니다. ② 같은 조건에서 JPEG로 바꾸면 버퍼가 거의 차지 않습니다. ③ 버퍼를 두 배로 늘리면 '느려지기 전까지'는 두 배가 되지만 '비우는 시간'도 두 배가 됩니다. 연사가 중요하다면 결국 카드 속도가 답입니다. 사용 요령은 20장에서 다룹니다.

동영상 코덱

4K(3840×2160) 30p 영상을 10비트 4:2:2로 압축 없이 저장하면 830만 화소 × 20 bit × 30 = 약 5 Gbit/s, 128 GB 카드가 3분 반 만에 찹니다. 그래서 동영상은 거의 언제나 코덱(codec)을 거칩니다. 코덱은 두 가지 중복을 줄입니다.

한 장면 안의 중복(공간): 하늘처럼 비슷한 이웃 화소를 블록 단위 주파수 변환과 양자화로 줄입니다. JPEG와 같은 생각입니다.
장면과 장면 사이의 중복(시간): 1/30초 뒤의 장면은 거의 같습니다. 앞뒤 프레임에서 '무엇이 어디로 움직였는지(움직임 벡터)'와 남은 차이만 저장합니다.

그림 6-4. All-Intra는 모든 프레임을 사진처럼 따로 압축해 크지만 편집이 가볍습니다. Long-GOP는 몇십 프레임마다 한 번 완전한 I 프레임을 두고, 사이에는 앞을 참조하는 P, 앞뒤를 참조하는 B 프레임으로 차이만 저장해 같은 화질에서 데이터가 몇 분의 일로 줄어듭니다. 대신 한 프레임을 보려면 다른 프레임들까지 풀어야 해 편집 컴퓨터가 힘들어합니다.

H.264 · H.265가장 흔한 압축 규격. H.265(HEVC)는 더 크고 유연한 블록과 더 많은 예측 방식을 써서 같은 화질을 대략 절반의 비트레이트로 담지만, 압축·재생 계산이 더 무겁습니다.

10비트와 4:2:2밝기 단계를 256 → 1,024로 늘리면 Log 영상과 하늘의 계조가 버팁니다. 4:2:2는 색 정보를 가로로만 절반, 4:2:0은 가로·세로 모두 절반으로 줄인 것입니다.

중간 코덱ProRes·DNxHR 같은 편집용 코덱은 인트라 방식에 압축률을 낮춰 화질과 편집 속도를 택합니다. 대신 비트레이트가 수백 Mbps~수 Gbps입니다.

RAW 동영상디모자이크 전 센서 데이터를 (가볍게 압축해) 그대로 담습니다. 화소당 값이 하나뿐이라 의외로 RGB 비압축보다 작지만, 여전히 Gbps급입니다.

SIMULATOR

비트레이트와 카드 용량 계산기

해상도

프레임 레이트

비트 심도

색 샘플링

코덱

비압축 데이터율—

비트레이트—

128 GB 카드에—

1시간 용량—

필요한 카드 등급—

모델: 비압축 데이터율 = 가로 × 세로 × fps × 비트 심도 × 색 샘플링 계수(4:2:0 = 1.5, 4:2:2 = 2배의 값/화소). RAW는 디모자이크 전이므로 화소당 값 1개(색 샘플링 무관, 판독 영역 = 출력 해상도로 단순화). 비트레이트 = 비압축 ÷ 압축비이며, 압축비는 화질 '고정'을 가정한 예시값입니다: H.265 Long-GOP 70:1, H.264 Long-GOP 35:1, H.264 All-Intra 15:1, 중간 코덱(ProRes 422 HQ급) 7:1, 압축 RAW 4:1. 실제 압축비는 장면의 움직임과 디테일, 제조사의 설정에 따라 크게 달라지고, 카메라는 대개 몇 단계의 고정 비트레이트만 제공합니다. 그래프 가로축은 로그 눈금(M = Mbps, G = Gbps)이고 점선은 카드 등급의 최소 보장 속도입니다. 카드 등급은 비트레이트를 넘는 최소 보장 속도(V30 = 240, V60 = 480, V90 = 720 Mbps, VPG200 = 1.6, VPG400 = 3.2 Gbps)로 골랐으며 실제로는 여유를 두는 것이 좋습니다. 해볼 것: ① 4K 30p 10비트 4:2:2에서 H.265와 All-I의 비트레이트 차이. ② 같은 조건을 60p로 바꾸면 거의 정확히 두 배. ③ 8K 60p 비압축 RAW는 어떤 카드로도 힘든 이유. 촬영 쪽 선택은 22장에서 다룹니다.

비트레이트는 화질의 '상한'일 뿐같은 100 Mbps라도 코덱이 다르면 화질이 다르고, 같은 코덱이라도 나뭇잎이 흔들리는 장면과 하늘만 있는 장면에 필요한 비트는 몇 배 차이가 납니다. 비트레이트가 모자라면 움직임이 많은 장면에서 먼저 블록 무늬와 뭉개짐이 나타납니다.

전력과 처리량

디지털 회로는 숫자 하나를 옮기고 계산할 때마다 작은 에너지를 씁니다. 그래서 대략 이렇게 말할 수 있습니다. 전력 ≈ (화소당 에너지) × (초당 화소 수). 사진 한 장은 수천만 화소를 한 번 처리하고 끝나지만, 4K 60p 동영상은 오버샘플링을 위해 센서에서 2,000만 화소 가까이를 초당 60번, 쉬지 않고 읽어 처리하고 압축합니다. 연사 2초는 잠깐의 전력 봉우리이고, 30분 촬영은 같은 전력이 30분 내내 이어지는 것입니다.

그리고 전기 에너지는 결국 전부 열이 됩니다. 손바닥만 한, 방진·방적을 위해 틈을 막은 금속 상자 안에서 몇 와트가 끊임없이 나오면 온도가 오르고, 센서 노이즈가 늘고, 결국 보호를 위해 촬영이 멈춥니다. 그 열을 어떻게 빼내는지는 08장의 주제입니다.

SIMULATOR

모드별 전력 예산: 처리량이 곧 열이다

살펴볼 모드

ISP 에너지 DRAM 왕복 횟수 배터리

판독 화소율—

총 전력(= 열)—

프레임당 처리 에너지—

배터리로 연속—

모델(자릿수만 맞춘 예시): 전력 = 기본(CPU·AF·IBIS·전원 변환 손실 1.5 W) + 화면(EVF/LCD 1.0 W) + 센서 판독·ADC(1.0 nJ/화소) + ISP(슬라이더, 기본 0.6 nJ/화소) + DRAM(화소당 4 B × 왕복 횟수, 8 pJ/bit) + 압축(동영상 H.265 0.8 nJ/출력 화소, 사진 0.15 nJ/화소). 모드별 판독은 라이브 뷰 8 MP×60, 연사 45 MP×20, 4K30·4K60은 약 20 MP(6K) 오버샘플, 4K120은 8.3 MP 판독, 8K30은 33 MP입니다. 계수는 실측값이 아니라 결과가 실제 미러리스의 전형적 소비 전력(수 W)과 같은 자릿수가 되도록 고른 값이며, 공정 세대와 설계에 따라 몇 배씩 다를 수 있습니다. 모든 전력은 결국 열이 됩니다. 해볼 것: ① 라이브 뷰만 켜 놓아도 몇 W를 쓴다는 점. ② 4K30 → 4K60에서 처리 부분만 두 배가 되는 것. ③ DRAM 왕복을 줄이는(라인 버퍼) 설계가 얼마나 아끼는지. ④ 연사의 '프레임당 에너지'는 크지만 지속 시간이 짧다는 점.

설계자의 선택지같은 4K라도 센서 전체를 읽어 줄이는 오버샘플링은 화질이 좋지만 판독·처리 화소가 두세 배라 뜨겁고, 줄을 건너뛰는 라인 스킵은 시원하지만 계단 현상과 모아레가 늘어납니다. 고프레임 모드가 화면을 잘라 내는(크롭) 경우가 많은 것도 같은 예산 문제입니다. 미세 공정의 새 칩이 나오면 같은 일을 더 적은 에너지로 하게 되어, 같은 바디 크기에서 더 높은 해상도·프레임 레이트가 가능해집니다.

핵심 정리

영상 처리 엔진은 센서 인터페이스·ISP·CPU·NPU·코덱·메모리 컨트롤러·입출력을 한 칩에 모은 SoC이며, 모든 블록이 DRAM 대역폭을 나눠 쓴다.
ISP는 선형 영역에서 물리 보정(블랙 레벨 → 결함 화소 → 셰이딩 → WB)을 끝내고, 디모자이크·색 행렬·노이즈 감소를 거쳐, 마지막에 톤·샤프닝·압축으로 '보기 좋게' 만든다. 순서가 바뀌면 결과가 틀어진다.
센서 데이터율 = 화소 수 × 비트 심도 × 초당 장수. 45 MP·14 bit·20 fps는 약 1.6 GB/s이고, 처리 도중에는 몇 배로 부푼다.
연사 지속 장수 ≈ 버퍼 ÷ (장당 크기 − 카드 속도/fps). 버퍼가 차면 연사 속도는 카드 속도 ÷ 장당 크기로 떨어진다.
동영상 코덱은 공간·시간 중복을 줄인다. Long-GOP는 작고 All-Intra·중간 코덱은 크지만 편집이 가볍다. 카드는 동영상 등급(V·VPG)을 비트레이트와 비교해 고른다.
전력 ≈ 화소당 에너지 × 초당 화소 수이고, 전력은 모두 열이 된다. 쉬지 않는 동영상이 발열의 주범이다.

확인 퀴즈

2,400만 화소(24 MP) 센서를 12비트로 초당 30번 읽으면 센서 데이터율은 대략?

24×10⁶ × 12 bit × 30 = 8.64 Gbit/s ÷ 8 ≈ 1.08 GB/s. 비트와 바이트(÷8)를 헷갈리지 않는 것이 핵심입니다.

블랙 레벨 보정을 빼먹으면 사진에 어떤 일이 생길까?

WB 게인과 색 행렬은 '빛 0 = 값 0'을 전제로 한 곱셈입니다. 바닥값이 남아 있으면 어두운 곳이 들뜨고 색 균형도 어긋납니다. 반짝이는 점은 결함 화소 보정의 몫입니다.

ISP에서 데이터 양이 한 화소당 값 1개에서 3개로 늘어나는 단계는?

베이어 모자이크의 각 화소에 빠진 두 색을 이웃에서 보간해 RGB 3채널을 만드는 것이 디모자이크입니다.

버퍼 4 GB, 들어오는 데이터 1,500 MB/s, 카드 연속 쓰기 250 MB/s. 버퍼가 가득 차기까지 대략 몇 초?

수위가 오르는 속도 = 1,500 − 250 = 1,250 MB/s. 4,000 MB ÷ 1,250 MB/s = 3.2초. 카드가 비우는 몫을 빼먹으면 2.7초로 잘못 계산합니다.

Long-GOP 코덱이 All-Intra보다 같은 화질에서 훨씬 작은 이유는?

I 프레임 사이의 P·B 프레임은 참조 프레임에서 움직임 벡터와 남은 차이만 담습니다. 그 대가로 편집 시 디코딩이 무겁습니다.

같은 카메라에서 사진 연사보다 4K 동영상 촬영이 발열 경고를 더 잘 일으키는 근본 이유는?

전력 ≈ 화소당 에너지 × 초당 화소 수. 연사는 순간 전력이 높아도 몇 초로 끝나지만, 동영상은 같은 수준이 계속됩니다. 열 설계는 08장에서.