디지털 이미지와 영상 학습 메모: 픽셀·프레임률·flick 구분하기

『1일 1로그 100일 완성 IT지식』 2246쪽을 읽으며 디지털 정보, 이미지, 영상 형식을 정리했었다. 당시 메모에는 “한 픽셀은 RGB 검출기 세 개”, “영화는 24fps, TV는 2530fps”, “옛 영화의 깜빡임에서 flicks가 생겼다”는 식의 지나친 단순화가 남아 있었다.

이미지와 영상에서는 같은 “픽셀”과 “프레임”이라는 말도 저장 파일, 디스플레이, 카메라 센서에서 가리키는 대상이 다르다. 이 경계를 나눠 다시 정리했다.

픽셀은 언제나 RGB 검출기 세 개가 아니다

픽셀(pixel)은 picture element, 즉 디지털 이미지의 논리적인 표본 위치를 뜻한다. 하지만 그 위치에 저장되거나 측정되는 값은 형식과 장치에 따라 다르다.

• RGB 이미지 파일은 한 픽셀에 R·G·B channel 값을 저장할 수 있다.
• RGBA 형식은 여기에 alpha channel을 더한다.
• 영상은 YCbCr와 chroma subsampling을 사용해 밝기와 색차를 서로 다른 해상도로 저장할 수 있다.
• 디스플레이의 물리 픽셀은 여러 subpixel로 빛을 낼 수 있다.
• 카메라 센서의 photosite는 color filter array를 통해 특정 색 대역의 빛을 주로 측정하고, 주변 표본을 이용한 demosaicing으로 RGB 값을 복원할 수 있다.

따라서 “픽셀 하나에 빨강·초록·파랑 검출기가 각각 하나씩 있다”는 설명은 보편적인 정의가 아니다. Sony의 Quad Bayer 센서처럼 같은 색 filter를 가진 인접 픽셀을 묶고 상황에 따라 신호를 합산하거나 remosaic하는 구조도 있다.

4000×3000은 약 12MP지만 화질 전체를 뜻하지 않는다

이미지 크기가 4000 × 3000이면 표본 위치는 12,000,000개이므로 약 12 megapixel이다.

4000 × 3000 = 12,000,000 pixels ≈ 12 MP

그러나 megapixel 수만으로 실제 해상력이나 화질을 결정할 수는 없다. sensor 크기와 pixel pitch, lens, 초점, 노이즈, 동적 범위, 압축, 처리 알고리즘이 함께 영향을 준다. 여러 sensor pixel을 합쳐 하나의 출력 pixel을 만드는 binning도 있어 “sensor의 표기 MP = 최종 이미지의 세부 묘사”라고 단정할 수 없다.

frame rate와 refresh rate를 나눠 본다

frame rate는 영상이 1초에 기록하거나 재생하는 frame 수다. refresh rate는 디스플레이가 1초에 화면을 갱신하는 횟수다. capture frame rate, encoded frame rate, playback rate, display refresh rate는 서로 같을 수도 있고 다를 수도 있다.

영화는 항상 24fps, TV는 항상 25 또는 30fps, 게임은 항상 60fps라고 외우면 현재 환경을 설명하지 못한다. ITU-R BT.709만 보더라도 24·25·30 계열뿐 아니라 50·60 계열 frame rate를 다룬다. 지역 방송 규격, 촬영 의도, 네트워크 대역폭, 기기 성능, 사용자가 선택한 게임 설정에 따라 달라진다.

높은 frame rate가 언제나 더 좋은 것도 아니다. 움직임을 더 자주 표본화해 부드럽게 보일 수 있지만, 데이터 양과 처리 비용이 커지고 motion blur와 표현 방식도 달라진다. 필요한 목적에 맞춰 capture, encode, display 전체를 함께 정해야 한다.

영화 속어 flick과 시간 단위 flicks는 구분해야 한다

flick은 영화를 가리키는 오래된 구어 표현으로도 쓰인다. 하지만 Facebook이 공개한 Flicks 프로젝트의 flick은 frame-tick을 줄인 정밀 시간 단위다.

1 flick = 1 / 705,600,000 second

이 값은 24, 25, 30, 50, 60, 120Hz 같은 여러 frame duration과 주요 audio sample duration을 정수 개수로 표현하도록 고른 값이다. 부동소수점 오차를 누적하지 않고 미디어 시간을 다루려는 목적이다.

프로젝트 README에 따르면 이 단위는 2016년 말 Facebook에 공개된 기술 질문에서 시작됐다. 옛 영화가 12fps라서 깜빡였고 그 흔적이 Netflix와 이 시간 단위까지 이어졌다는 설명을 뒷받침하지는 않는다. 영화의 속어, 회사 이름의 조어, frame-tick 시간 단위를 어감만으로 하나의 어원처럼 연결하면 안 된다.

Unicode의 문자 수와 코드 포인트 공간도 다르다

Unicode를 설명할 때도 “지원하는 문자 수”와 “가능한 code point 수”를 구분해야 한다. Unicode 17.0의 공식 통계에서 graphic character와 format character의 합은 159,801개다.

한편 Unicode code space는 U+0000부터 U+10FFFF까지 1,114,112개의 code point 위치를 가진다. 여기에는 아직 할당되지 않은 위치, surrogate, private-use, noncharacter 등이 포함된다. 사용자에게 보이는 glyph 수도 font와 조합 sequence에 따라 달라진다.

문자(character) ≠ 코드 포인트(code point) ≠ 글리프(glyph)

“Unicode에는 14만 개가 넘는 문자가 있다”는 메모는 당시 버전의 대략적인 설명일 수 있지만, 버전과 집계 기준 없이 고정 숫자로 쓰면 곧 낡는다. 공식 버전 통계를 함께 표시하는 편이 정확하다.

이번 범위에서 남길 기준은 간단하다. 파일의 pixel 값, 화면의 subpixel, sensor의 photosite를 구분하고, frame rate와 refresh rate를 분리하며, 비슷한 이름의 기술 용어는 공식 정의를 확인한다.

참고 자료

• Sony Semiconductor Solutions: Quad Bayer Coding
• ITU-R BT.709: HDTV parameter values
• Facebook Archive: Flicks
• Unicode 17.0 Character Counts