hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
LZ77 및 LZ78 LZ77
다른 방식으로 보자면 다음과 같다. 인코딩하는 동안 검색 포인터가 검색 윈도우의 끝을 지나서 일치하는 쌍을 계속 찾으려면 오프셋 D에서 첫 번째 일치 항목부터 검색 윈도우 끝까지의 모든 문자가 입력과 일치해야 하며, 이들은 길이 LR의 단일 실행 단위를 구성하는 (이전에 본) 문자여야 하며, 이는 D와 같아야 한다. 그런 다음 검색 포인터가 검색 윈도우를 지나서 앞으로 진행하면서, 입력에서 실행 패턴이 반복되는 한, 검색 및 입력 포인터는 동기화되어 실행 패턴이 중단될 때까지 문자를 일치시킨다. 그러면 총 L 문자가 일치했고, L > D이며, 코드는 [D, L, c]이다.
LZ77 및 LZ78 LZ77
[D, L, c]를 디코딩할 때도 마찬가지로 D = LR이다. 첫 번째 LR 문자가 출력으로 읽힐 때, 이는 출력 버퍼에 추가된 단일 실행 단위에 해당한다. 이 시점에서 읽기 포인터는 해당 단일 버퍼링된 실행 단위의 시작 부분으로 int(L/LR) + (L mod LR ≠ 0일 경우 1)번만 돌아가서 LR 문자를 읽고(또는 마지막 반환 시 더 적은 수) 총 L 문자가 읽힐 때까지 반복하면 된다고 생각할 수 있다. 그러나 인코딩 프로세스를 반영하여 패턴이 반복적이므로 읽기 포인터는 총 L 문자가 출력으로 복사될 때까지 쓰기 포인터와 실행 길이 LR과 동일한 고정된 거리만큼 동기화되어 따라가기만 하면 된다.
위의 내용을 고려할 때, 특히 데이터 실행 압축이 지배적일 것으로 예상되는 경우, 윈도우 검색은 윈도우 끝에서 시작하여 뒤로 진행해야 한다. 실행 패턴이 존재한다면 먼저 발견되어 검색을 종료할 수 있기 때문이다. 현재 최대 일치 시퀀스 길이가 충족되면 절대적으로, 또는 충분한 길이가 충족되면 신중하게, 그리고 마지막으로 데이터가 더 최근이고 다음 입력과 더 잘 연관될 가능성이 있다는 단순한 이유 때문에 그렇게 해야 한다.
다음 의사 코드는 LZ77 압축 알고리즘의 슬라이딩 윈도우를 재현한 것이다.
모든 LZ77 알고리즘은 정의상 동일한 기본 원리로 작동하지만, 길이-거리 쌍의 숫자 범위를 변경하고, 길이-거리 쌍에 사용되는 비트 수를 변경하고, 길이-거리 쌍과 리터럴(길이-거리 쌍의 일부가 아닌 자체로 인코딩된 원시 데이터)을 구별하는 방식에 따라 압축된 데이터를 인코딩하는 방식이 크게 달라질 수 있다. 몇 가지 예는 다음과 같다.
틀:2008년 기준, 가장 널리 사용되는 LZ77 기반 압축 방식은 DEFLATE이다. 이는 LZSS와 허프먼 부호화를 결합한다. 리터럴, 길이, 그리고 현재 데이터 블록의 끝을 나타내는 기호는 모두 하나의 알파벳으로 함께 배치된다. 거리는 별도의 알파벳으로 안전하게 배치될 수 있다. 거리는 길이 바로 뒤에만 나타나기 때문에 다른 종류의 기호로 오해되거나 그 반대가 될 수 없다.
LZ77 및 LZ78 LZ78
LZ78 알고리즘은 입력에서 토큰 시퀀스의 사전을 구축한 다음, 데이터 스트림에서 해당 시퀀스의 두 번째 및 이후 발생을 사전 항목에 대한 참조로 대체하여 순차 데이터를 압축한다. 여기서의 관찰은 반복되는 시퀀스의 수가 시퀀스의 무작위적이지 않은 특성을 잘 나타내는 척도라는 것이다. 이 알고리즘은 사전을 n진 트리로 표현하며, 여기서 n은 토큰 시퀀스를 형성하는 데 사용되는 토큰의 수이다. 각 사전 항목은 dictionary[...] = {index, token} 형식으로, 여기서 index는 이전에 본 시퀀스를 나타내는 사전 항목에 대한 색인이고, token은 이 항목을 사전에서 고유하게 만드는 입력의 다음 토큰이다. 알고리즘이 탐욕적이어서 고유한 토큰이 발견될 때까지는 아무것도 테이블에 추가되지 않는다는 점에 유의해야 한다. 알고리즘은 마지막 일치 색인 = 0 및 다음 사용 가능한 색인 = 1로 초기화한 다음, 입력 스트림의 각 토큰에 대해 사전을 검색하여 일치하는 부분을 찾는다: last matching index, token}. 일치하는 부분이 발견되면 마지막 일치 색인이 일치하는 항목의 색인으로 설정되고, 아무것도 출력되지 않으며, 마지막 일치 색인은 지금까지의 입력을 계속 나타낸다. 일치하는 부분이 발견되지 않을 때까지 입력이 처리된다. 그런 다음 새 사전 항목이 생성된다: dictionary[next available index] = {last matching index, token}, 그리고 알고리즘은 마지막 일치 색인과 토큰을 출력한 다음, 마지막 일치 색인을 0으로 재설정하고 다음 사용 가능한 색인을 1 증가시킨다. 예를 들어, AABBA 토큰 시퀀스를 고려하면 다음과 같은 사전이 구성된다.
LZ77 및 LZ78 LZ78
그리고 압축된 데이터의 출력 시퀀스는 0A1B0B가 된다. 마지막 A는 알고리즘이 다음에 무엇이 올지 알 수 없으므로 아직 표현되지 않는다는 점에 유의해야 한다. 실제로는 EOF 마커가 입력에 추가된다. 예를 들어 AABBA$와 같이. 또한 이 경우 출력 0A1B0B1$가 원본 입력보다 길지만, 사전이 커질수록 압축률이 상당히 향상되며, 이진에서는 색인을 최소 비트 수 이상으로 표현할 필요가 없다는 점도 유의해야 한다.
LZ77 및 LZ78 LZ78
압축 해제는 압축된 시퀀스에서 사전을 재구성하는 것으로 구성된다. 시퀀스 0A1B0B1$에서 첫 번째 항목은 항상 종결자 0 {...} 이며, 시퀀스에서 첫 번째 항목은 1 {0,A} 가 된다. A는 출력에 추가된다. 입력에서 두 번째 쌍은 1B이며, 사전에서 항목 번호 2, 1,B}를 생성한다. 토큰 "B"가 출력되고, 그 앞에 사전 항목 1이 나타내는 시퀀스가 붙는다. 항목 1은 'A' (그 뒤에 "항목 0" - 아무것도 없음)이므로 AB가 출력에 추가된다. 다음으로 0B는 사전의 다음 항목으로 추가되며, 3 {0,B} 가 되고, B (그 앞에 아무것도 없음)가 출력에 추가된다. 마지막으로 1$에 대한 사전 항목이 생성되고 A$가 출력되어 A AB B A$ 또는 공백과 EOF 마커를 제거한 AABBA가 된다.
LZ77 및 LZ78 LZW
LZW는 모든 가능한 문자(기호) 또는 사전 초기화 에뮬레이션으로 미리 초기화된 사전을 사용하는 LZ78 기반 알고리즘이다. LZW의 주요 개선 사항은 일치하는 항목을 찾을 수 없는 경우 현재 입력 스트림 문자가 사전의 기존 문자열의 첫 번째 문자라고 가정하므로(사전이 모든 가능한 문자로 초기화되었기 때문에) 마지막 일치 색인만 출력된다는 것이다(이것은 이전 (또는 초기) 입력 문자에 해당하는 미리 초기화된 사전 색인일 수 있다). 구현 세부 사항은 LZW 문서를 참조하라.
BTLZ는 실시간 통신 시스템(원래 모뎀)에 사용하기 위해 개발된 LZ78 기반 알고리즘으로, CCITT/ITU에 의해 V.42bis로 표준화되었다. 트라이 구조 사전이 가득 차면, 사전이 변화하는 데이터에 계속 적응할 수 있도록 간단한 재사용/복구 알고리즘이 사용된다. 카운터는 사전을 순환한다. 새 항목이 필요하면 카운터는 리프 노드(종속 노드가 없는 노드)를 찾을 때까지 사전을 순환한다. 이 노드는 삭제되고 공간은 새 항목에 재사용된다. 이는 LRU 또는 LFU보다 구현이 간단하고 동등한 성능을 달성한다.
LZSS
렘펠-지브-스토러-시만스키(Lempel–Ziv–Storer–Szymanski, LZSS)는 비손실 데이터 압축 알고리즘으로, LZ77의 파생형이며 1982년 제임스 A. 스토러와 토마스 시만스키가 만들었다. LZSS는 Journal of the ACM에 실린 "Data compression via textual substitution"(1982, pp. 928–951) 기사에서 설명되었다.
LZSS는 사전 기반 부호화 기술이다. 이는 기호 문자열을 동일한 문자열의 사전 위치 참조로 바꾸려고 시도한다.
LZ77과 LZSS의 주요 차이점은 LZ77에서는 사전 참조가 실제로 대체하는 문자열보다 길 수 있다는 것이다. LZSS에서는 길이가 "손익분기점"보다 작으면 이러한 참조가 생략된다. 또한 LZSS는 다음 데이터 덩어리가 리터럴(바이트)인지 오프셋/길이 쌍에 대한 참조인지 나타내는 1비트 플래그를 사용한다.
LZSS 예시
다음은 편의를 위해 줄 시작 부분에 문자 번호가 붙은 닥터 수스의 녹색 달걀과 햄의 시작 부분이다. 녹색 달걀과 햄은 책 자체는 170단어임에도 불구하고 50개의 고유한 단어만을 포함하고 있기 때문에 LZSS 압축을 설명하는 좋은 예이다. 따라서 단어는 반복되지만 연속적이지는 않다.
이 텍스트는 압축되지 않은 형태로 177바이트를 차지한다. 손익분기점을 2바이트(따라서 2바이트 포인터/오프셋 쌍)로 가정하고 한 바이트의 개행 문자를 가정하면, 이 텍스트는 LZSS로 압축되어 95바이트가 된다.
참고: 여기에는 다음 텍스트 덩어리가 포인터인지 리터럴인지를 나타내는 11바이트의 플래그는 포함되지 않았다. 이를 추가하면 텍스트는 106바이트가 되며, 이는 여전히 원래의 177바이트보다 짧다.
LZSS 구현
ARJ, RAR, ZOO, LHarc와 같은 많은 인기 있는 압축 프로그램은 LZ77 대신 LZSS를 주 압축 알고리즘으로 사용한다. 리터럴 문자와 길이-거리 쌍의 인코딩은 다양하며, 가장 일반적인 옵션은 허프먼 부호화이다. 대부분의 구현은 하루히코 오쿠무라가 1989년에 만든 퍼블릭 도메인 코드에서 파생되었다. 알레그로 라이브러리 버전 4는 LZSS 형식을 인코딩 및 디코딩할 수 있지만 버전 5에서는 이 기능이 제거되었다. 게임보이 어드밴스 BIOS는 약간 수정된 LZSS 형식을 디코딩할 수 있다. 애플의 macOS는 LZSS를 커널 코드의 압축 방식 중 하나로 사용한다.
소프트웨어 가드 익스텐션
인텔 소프트웨어 가드 익스텐션(Intel Software Guard Extensions, SGX)은 일부 인텔 중앙 처리 장치(CPU)에 내장된 신뢰 실행 환경을 구현하는 명령어 집합이다. 이를 통해 사용자 수준 및 운영체제 코드가 인클레이브(enclave)라고 불리는 보호된 개인 메모리 영역을 정의할 수 있다. SGX는 보안 원격 컴퓨팅, 보안 웹 브라우징 및 디지털 권리 관리(DRM) 구현에 유용하도록 설계되었다. 다른 응용 프로그램으로는 사유 알고리즘 및 암호화 키 숨기기가 있다.
SGX는 CPU가 메모리 일부(인클레이브)를 암호화하는 것을 포함한다. 인클레이브에서 생성된 데이터와 코드는 CPU 내에서 실시간으로 복호화되어 다른 코드, 즉 운영체제 및 기본 하이퍼바이저와 같은 더 높은 권한 수준에서 실행되는 코드에 의해 검사되거나 읽히는 것을 방지한다. 이는 많은 종류의 공격을 완화할 수 있지만, 부채널 공격으로부터는 보호하지 못한다.
2021년 인텔의 정책 변경으로 11세대 및 12세대 인텔 코어 프로세서에서 SGX가 사용 중단되었지만, 클라우드 및 엔터프라이즈용 인텔 제온에서는 계속 개발되고 있다.
소프트웨어 가드 익스텐션 자세한 내용
SGX는 2015년에 스카이레이크 마이크로아키텍처 기반의 6세대 인텔 코어 마이크로프로세서와 함께 처음 도입되었다.
CPU의 SGX 지원은 CPUID "구조화 확장 기능 리프(Structured Extended feature Leaf)", EBX 비트 02에 표시되지만, 애플리케이션에서 사용하려면 바이오스/통합 확장 펌웨어 인터페이스 지원 및 선택적 활성화가 필요하며 이는 CPUID 비트에 반영되지 않는다. 이로 인해 애플리케이션의 기능 감지 로직이 복잡해진다.
SGX 에뮬레이션은 2014년에 QEMU 시스템 에뮬레이터의 실험 버전에서 추가되었다. 2015년 조지아 공과대학교 연구원들은 "OpenSGX"라는 오픈 소스 시뮬레이터를 발표했다.
소프트웨어 가드 익스텐션 자세한 내용
SGX가 보안에 사용된 한 가지 예는 울프SSL의 암호화 알고리즘을 위한 데모 애플리케이션이었다.
인텔 골드몬트 플러스(제미니 레이크) 마이크로아키텍처도 인텔 SGX를 지원한다.
11세대와 12세대 인텔 코어 프로세서 모두에서 SGX는 "사용 중단"으로 표시되어 "클라이언트 플랫폼" 프로세서에서는 지원되지 않는다. 이로 인해 파워DVD와 같이 공식적으로 라이선스가 부여된 소프트웨어에서 울트라 HD 블루레이 디스크 재생 지원이 중단되었다.
소프트웨어 가드 익스텐션 SGX 취약점 목록
2017년 3월 27일, 오스트리아 그라츠 공과대학교의 연구원들은 세분화된 타이머 대신 특정 CPU 명령어를 사용하여 캐시 DRAM 부채널을 악용함으로써 동일 시스템에서 실행되는 SGX 인클레이브로부터 RSA 키를 5분 이내에 획득할 수 있는 개념 증명을 개발했다. 이 유형의 공격에 대한 한 가지 대응책은 2017년 USENIX 보안 심포지엄에서 다니엘 그루스 등이 발표했다. 다른 공개된 대응책 중 하나로, 2017년 9월 28일에 컴파일러 기반 도구인 DR.SGX가 발표되었는데, 이는 다른 제안된 솔루션의 구현 복잡성을 제거하면서도 우수한 성능을 제공한다고 주장한다.
임페리얼 칼리지 런던의 LSDS 그룹은 스펙터 투기적 실행 보안 취약점을 안전한 인클레이브 공격에 적용할 수 있다는 개념 증명을 제시했다. 2018년 8월에 공개된 포어섀도 공격은 투기적 실행과 버퍼 오버플로를 결합하여 SGX를 우회한다. L1 터미널 폴트라고도 불리는 이 공격에 대한 보안 권고 및 완화책은 원래 2018년 8월 14일에 발표되었고 2021년 5월 11일에 업데이트되었다.
소프트웨어 가드 익스텐션 SGX 취약점 목록
2019년 2월 8일, 오스트리아 그라츠 공과대학교 연구원들은 일부 경우 인클레이브 자체 내에서 악성 코드를 실행할 수 있음을 보여주는 연구 결과를 발표했다. 이 익스플로잇은 페이로드를 재구성하기 위해 프로세스 메모리를 스캔한 다음 시스템에서 코드를 실행할 수 있다. 논문은 인클레이브의 기밀하고 보호된 특성 때문에 바이러스 백신 소프트웨어가 그 안에 있는 악성 코드를 탐지하고 제거하는 것이 불가능하다고 주장한다. 인텔은 이 공격이 SGX의 위협 모델 범위를 벗어났으며, 사용자가 실행하는 코드가 신뢰할 수 있는 소스에서 온 것임을 보장할 수 없으며, 소비자에게 신뢰할 수 있는 코드만 실행하도록 촉구한다는 성명을 발표했다.
소프트웨어 가드 익스텐션 SGX 취약점 목록
최신 컴퓨터 아키텍처를 괴롭히는 부채널 공격이 확산되고 있다. 이러한 공격 중 다수는 코드 실행의 미세하고 비결정적인 변동을 측정하므로, 공격자는 비밀을 알아내기 위해 많은 측정값(수만 개일 수도 있음)이 필요하다. 그러나 마이크로스코프 공격은 악성 OS가 프로그램의 실제 구조와 상관없이 코드를 임의의 횟수만큼 재생할 수 있게 하여 수십 가지의 부채널 공격을 가능하게 한다. 2022년 7월, 인텔은 SGX 인클레이브 프로그래머가 이러한 유형의 이벤트를 처리할 핸들러를 작성할 수 있도록 AEX-Notify라는 리눅스 패치를 제출했다.
보안 연구원들은 인클레이브 내 실행에 타이밍 특정 결함을 주입하여 정보 유출을 초래할 수 있었다. 이 공격은 원격으로 실행될 수 있지만, 프로세서의 전압과 주파수에 대한 특권 제어에 접근해야 한다. 이 공격에 대한 보안 권고 및 완화책은 원래 2018년 8월 14일에 발표되었고 2020년 3월 20일에 업데이트되었다.
소프트웨어 가드 익스텐션 SGX 취약점 목록
로드 값 주입(Load Value Injection)은 메모리에서 로드된 값을 대체하기 위해 프로그램에 데이터를 주입하는 것을 목표로 한다. 이 값은 오류가 발견되고 롤백되기 전까지 잠시 사용되며, 그 동안 LVI는 데이터 및 제어 흐름을 제어한다. 이 공격에 대한 보안 권고 및 완화책은 원래 2020년 3월 10일에 발표되었고 2021년 5월 11일에 업데이트되었다.
2020년에 발표된 SGX 취약점인 SGAxe는 캐시에 대한 투기적 실행 공격을 확장하여 인클레이브의 내용을 유출한다. 이를 통해 공격자는 원격 인증에 사용되는 개인 CPU 키에 접근할 수 있다. 다시 말해, 위협 행위자는 인텔의 대응책을 우회하여 SGX 인클레이브의 기밀성을 침해할 수 있다. SGAxe 공격은 인텔이 서명한 SGX의 개인 인용 인클레이브에서 인증 키를 추출하여 수행된다. 공격자는 그 다음 임의의 SGX 인증 인용에 서명함으로써 합법적인 인텔 기계로 위장할 수 있다. 프로세서 데이터 유출 또는 캐시 이빅션(Cache Eviction)이라고도 불리는 이 공격에 대한 보안 권고 및 완화책은 원래 2020년 1월 27일에 발표되었고 2021년 5월 11일에 업데이트되었다.
소프트웨어 가드 익스텐션 SGX 취약점 목록
2022년 보안 연구원들은 고급 프로그래머블 인터럽트 컨트롤러(APIC)에서 취약점을 발견했는데, 이는 루트/관리자 권한을 가진 공격자가 L1 및 L2 캐시의 데이터 전송을 검사하여 APIC를 통해 암호화 키에 접근할 수 있도록 한다. 이 취약점은 X86 CPU에서 발견된 최초의 아키텍처 공격이다. 이는 시끄러운 부채널을 사용하는 스펙터 및 멜트다운과는 다르다. 이 익스플로잇은 현재 인텔 코어 10세대, 11세대, 12세대 및 제온 아이스 레이크 마이크로프로세서에 영향을 미친다.
코드 서명은 인클레이브에만 있는 개인 키로 생성된다. 개인 키는 칩의 "퓨즈" 요소를 통해 인코딩된다. 이 과정에서 비트가 타버려 이진 값 0이 된다. 이 개인 키는 하드웨어에 인코딩되어 추출할 수 없다. 마크 에르몰로프(Mark Ermolov), 막심 고랴치(Maxim Goryachy), 드미트리 스클랴로프(Dmitry Sklyarov)는 https://github.com/chip-red-pill/glm-ucode#에서 SGX 개념의 신뢰성에 대한 주장을 반박했다.
소프트웨어 가드 익스텐션 SGX 악성 코드 주장
SGX가 우수한 악성 코드 생성을 가능하게 하는지에 대한 오랜 논쟁이 있었다. 옥스퍼드 대학교 연구원들은 2022년 10월에 발표한 논문에서 악성 코드 개발을 위해 SGX를 오용할 경우 공격자에게 잠재적인 장단점을 고려했다. 연구원들은 SGX 생태계에서 악용될 수 있는 일시적인 제로데이 취약점이 있을 수 있지만, 신뢰 실행 환경(TEE)의 핵심 원칙과 설계 특징은 악성 코드를 야생의 악성 코드보다 약하게 만들며, TEE는 그렇지 않은 경우 악성 코드에 크게 기여하지 않는다고 결론 내렸다.
LZ4 (압축 알고리즘)
LZ4는 압축 및 압축 해제 속도에 초점을 맞춘 비손실 데이터 압축 알고리즘이다. 이는 바이트 지향 압축 방식인 LZ77 계열에 속한다.
LZ4 (압축 알고리즘) 특징
LZ4 알고리즘은 속도와 압축률 간의 좋은 절충점을 제공하는 것을 목표로 한다. 일반적으로 유사한 LZO 알고리즘보다 압축률이 더 낮고(즉, 나쁘고), LZO는 다시 DEFLATE와 같은 알고리즘보다 나쁘다. 그러나 LZ4의 압축 속도는 LZO와 유사하며 DEFLATE보다 몇 배 빠르며, 압축 해제 속도는 LZO보다 훨씬 빠르다.
LZ4 (압축 알고리즘) 설계
LZ4는 사전 일치 단계(LZ77)만 사용하며, 다른 일반적인 압축 알고리즘과는 달리 이를 엔트로피 부호화 단계(예: DEFLATE의 허프먼 부호화)와 결합하지 않는다.
LZ4 알고리즘은 데이터를 일련의 시퀀스로 표현한다. 각 시퀀스는 두 개의 4비트 필드로 나뉜 1바이트 토큰으로 시작한다. 첫 번째 필드는 출력으로 복사될 리터럴 바이트 수를 나타낸다. 두 번째 필드는 이미 디코딩된 출력 버퍼에서 복사할 바이트 수를 나타낸다 (0은 최소 일치 길이인 4바이트를 나타낸다). 두 비트 필드 중 하나에서 15 값은 길이가 더 크며 길이에 추가될 추가 바이트 데이터가 있음을 나타낸다. 이러한 추가 바이트에서 255 값은 또 다른 바이트가 추가될 것임을 나타낸다. 따라서 임의의 길이는 255 값을 포함하는 일련의 추가 바이트로 표현된다. 리터럴 문자열은 토큰과 문자열 길이를 나타내는 데 필요한 추가 바이트 뒤에 온다. 그 다음에는 출력 버퍼에서 얼마나 뒤로 복사를 시작할지를 나타내는 오프셋이 온다. 일치 길이의 추가 바이트(있는 경우)는 시퀀스의 끝에 온다.
LZ4 (압축 알고리즘) 설계
압축은 스트림 또는 블록 단위로 수행할 수 있다. 최적의 일치를 찾는 데 더 많은 노력을 기울임으로써 더 높은 압축률을 달성할 수 있다. 이는 더 작은 출력과 더 빠른 압축 해제를 모두 가능하게 한다.
LZ4는 두 가지 프레임 형식을 가지고 있다. 이전 형식은 매우 제한적이었고 외부 파일 끝 신호에 의존했는데, 이는 리눅스 Initramfs에서 제로 패딩을 처리하기 위한 해결책이 필요하다는 문제로 나타났다. 새로운 형식은 훨씬 더 유연하며 자체적인 프레임 끝 마커를 가지고 있다. 이는 Zstd 프레임 형식과 디자인이 유사하다.
LZ4 (압축 알고리즘) 구현
얀 콜레의 C로 된 참조 구현은 BSD 라이선스에 따라 라이선스된다. 자바, C#, 러스트, 파이썬을 포함한 다양한 언어로 포트 및 바인딩이 존재한다. 아파치 하둡 시스템은 이 알고리즘을 빠른 압축을 위해 사용한다. LZ4는 리눅스 커널 3.11에도 네이티브로 구현되었다. FreeBSD, Illumos, 리눅스의 ZFS, ZFS-OSX의 ZFS 파일 시스템 구현은 즉석 압축을 위한 LZ4 알고리즘을 지원한다. 리눅스는 3.19-rc1부터 SquashFS에 LZ4를 지원한다. LZ4는 얀 콜레의 최신 Zstd 명령줄 유틸리티와 7-Zip-zstd라는 7-Zip 포크에서도 지원된다.
전향 변환
전향 변환(Move-to-front transform, MTF 변환)은 데이터 압축 기술인 엔트로피 부호화의 성능을 향상시키기 위해 설계된 데이터(일반적으로 바이트 스트림)의 인코딩이다. 효율적으로 구현될 경우, 데이터 압축 알고리즘에 추가 단계로 포함될 만큼 충분히 빠르다.
이 알고리즘은 1980년 보리스 랴브코가 "책 스택(book stack)"이라는 이름으로 처음 발표했다. 이후 1986년 J.K. 벤틀리 등이 재발견했으며, 이는 설명 노트에 명시되어 있다.
전향 변환 변환
주요 아이디어는 데이터의 각 심볼이 "최근 사용된 심볼" 스택에서의 해당 인덱스로 대체된다는 것이다. 예를 들어, 동일한 심볼의 긴 시퀀스는 동일한 수의 0으로 대체되는 반면, 오랫동안 사용되지 않은 심볼이 나타나면 큰 숫자로 대체된다. 따라서 최종적으로 데이터는 일련의 정수로 변환된다. 데이터가 많은 지역 상관관계를 나타내면 이 정수들은 작은 경향이 있다.
정확한 설명을 제공해 보겠다. 간단화를 위해 데이터의 심볼이 바이트라고 가정한다.
각 바이트 값은 알고리즘 실행 중에 변경되는 바이트 목록에서 해당 인덱스로 인코딩된다. 목록은 초기에는 바이트 값 순서(0, 1, 2, 3, ..., 255)로 정렬되어 있다. 따라서 첫 번째 바이트는 항상 해당 값으로 인코딩된다. 그러나 바이트를 인코딩한 후에는 다음 바이트로 진행하기 전에 해당 값을 목록의 맨 앞으로 이동시킨다.
예시를 통해 변환이 어떻게 작동하는지 명확히 할 수 있다. 바이트 대신 a-z 범위의 값을 인코딩한다고 상상해 보자. 다음 시퀀스를 변환하려고 한다.
전향 변환 변환
관례에 따라 목록은 초기에는 (abcdefghijklmnopqrstuvwxyz)이다. 시퀀스의 첫 글자는 b이며, 인덱스 1에 나타난다 (목록은 0부터 25까지 인덱싱된다). 출력 스트림에 1을 넣는다:
b는 목록의 맨 앞으로 이동하여 (bacdefghijklmnopqrstuvwxyz)를 생성한다. 다음 글자는 a이며, 이제 인덱스 1에 나타난다. 그래서 출력 스트림에 1을 추가한다. 이제:
그리고 글자 a를 다시 목록의 맨 위로 이동시킨다. 이런 식으로 계속하면 시퀀스는 다음으로 인코딩된다:
변환이 가역적임을 쉽게 알 수 있다. 동일한 목록을 유지하고 인코딩된 스트림의 각 인덱스를 목록의 해당 인덱스에 있는 문자로 대체하여 디코딩하면 된다. 이 방법과 인코딩 방법의 차이점에 주목하자: 각 값을 인덱스로 찾는 대신 목록의 인덱스가 직접 사용된다.
즉, 다시 (abcdefghijklmnopqrstuvwxyz)로 시작한다. 인코딩된 블록의 "1"을 가져와 목록에서 찾으면 "b"가 나온다. 그런 다음 "b"를 맨 앞으로 이동시키면 (bacdef...)가 된다. 다음 "1"을 가져와 목록에서 찾으면 "a"가 나오고, "a"를 맨 앞으로 이동시키는 식으로 계속한다.
전향 변환 구현
특히 디코딩을 위한 성능을 위해서는 구현 세부 사항이 중요하다. 인코딩의 경우 연결 리스트를 사용함으로써 명확한 이점이 없으므로 배열을 사용하여 목록을 저장하는 것이 허용되며, 최악의 경우 성능은 O(nk)이다. 여기서 n은 인코딩할 데이터의 길이이고 k는 값의 개수이다 (주어진 구현에 대해 일반적으로 상수).
자주 사용되는 심볼이 목록의 앞에 있을 가능성이 높고 더 일찍 일치할 가능성이 높기 때문에 일반적인 성능이 더 좋다. 이것은 전향 이동 자가 구성 목록의 아이디어와도 일치한다.
그러나 디코딩의 경우 특수화된 데이터 구조를 사용하여 성능을 크게 향상시킬 수 있다.
다음은 파이썬으로 구현한 전향 변환 알고리즘의 예시이다.
이 예시에서 MTF 코드가 입력 단어의 세 번 반복되는 i를 활용하는 것을 볼 수 있다. 그러나 여기서 공통 사전은 이상적이지 않다. 왜냐하면 MTF 코드의 설계 의도인 자주 사용되는 것을 앞에 두는 것과는 달리 거의 사용되지 않는 제어 코드 뒤에 더 일반적으로 사용되는 ASCII 인쇄 가능 문자로 초기화되었기 때문이다. 만약 사전을 회전시켜 더 자주 사용되는 문자를 더 앞쪽에 배치하면 더 나은 인코딩을 얻을 수 있다.
전향 변환 실제 데이터 압축 알고리즘에서의 사용
MTF 변환은 메시지의 엔트로피를 줄이기 위해 주파수의 지역 상관 관계를 활용한다. 실제로, 최근 사용된 글자들은 목록의 앞쪽에 머무르는 경향이 있다. 만약 글자의 사용이 지역 상관 관계를 보인다면, 이는 출력에서 "0"과 "1"과 같은 많은 작은 숫자를 생성할 것이다.
그러나 모든 데이터가 이러한 유형의 지역 상관 관계를 나타내는 것은 아니며, 일부 메시지의 경우 MTF 변환이 실제로 엔트로피를 증가시킬 수 있다.
MTF 변환의 중요한 용도는 버로우즈-휠러 변환 기반 압축이다. 버로우즈-휠러 변환은 플레인 텍스트 및 특정 다른 특별한 유형의 데이터에서 지역 주파수 상관 관계를 나타내는 시퀀스를 생성하는 데 매우 뛰어나다. 최종 엔트로피 인코딩 단계 전에 버로우즈-휠러 변환 다음에 MTF 변환을 적용하면 압축 효과가 크게 향상된다.
전향 변환 실제 데이터 압축 알고리즘에서의 사용
예를 들어, 햄릿의 독백 (사느냐 죽느냐 그것이 문제로다...)을 압축한다고 가정해 보자. 이 메시지의 크기는 7033비트이다. 순진하게 MTF 변환을 직접 적용하려고 시도할 수 있다. 그 결과는 7807비트의 메시지이다 (원본보다 높다). 그 이유는 영어 텍스트가 일반적으로 높은 수준의 지역 주파수 상관 관계를 나타내지 않기 때문이다. 그러나 먼저 버로우즈-휠러 변환을 적용한 다음 MTF 변환을 적용하면 6187비트의 메시지를 얻는다. 버로우즈-휠러 변환은 메시지의 엔트로피를 감소시키지 않는다. 단지 MTF 변환을 더 효과적으로 만들기 위해 바이트를 재정렬할 뿐이다.
기본 MTF 변환의 한 가지 문제는 빈도에 관계없이 모든 문자에 동일한 변경을 가한다는 것이다. 이는 드물게 발생하는 문자가 빈번한 문자를 더 높은 값으로 밀어내어 압축률을 저하시킬 수 있다. 이러한 이유로 다양한 변경 및 대안이 개발되었다. 한 가지 일반적인 변경은 특정 지점 이상의 문자는 특정 임계값까지만 이동할 수 있도록 하는 것이다. 또 다른 방법은 각 문자의 지역 빈도를 계산하고 이러한 값을 사용하여 어떤 지점에서 문자의 순서를 선택하는 알고리즘을 만드는 것이다. 이러한 변환의 대부분은 버로우즈-휠러 변환 후 데이터에서 가장 흔한 경우가 많으므로 반복 문자에 대해 여전히 0을 예약한다.
페리하산맥흰이마카푸친
페리하산맥흰이마카푸친(Cebus leucocephalus)은 꼬리감는원숭이과에 속하는 영장류의 일종이다. 콜롬비아와 베네수엘라에 서식하는 가냘픈꼬리감는원숭이속 카푸친이다. 이전에는 훔볼트흰이마카푸친원숭이의 아종으로 간주했지만, 2013년 미터마이어와 라이랜즈가 장 부블리의 유전학 연구를 바탕으로 별도의 종으로 재분류했다. 페리하산맥흰이마카푸친의 서식지는 콜롬비아 북부와 베네수엘라 북서부 일부 지역의 숲으로 제한되어 있다.
페리하산맥흰이마카푸친 특징
수컷 페리하산맥흰이마카푸친은 머리부터 몸통까지 길이가 37~40.7cm이고 꼬리 길이는 39~50cm이다. 암컷을 측정한 치수 정보는 없다. 베네수엘라와 콜롬비아 북부에 서식하는 모든 카푸친원숭이 중에서 가장 어두운 털을 가지고 있다. 머리꼭대기는 계피색에서 짙은 갈색이다. 등은 계피색이고, 등 윗부분은 황갈색을 띠며 등 아랫부분은 그을음 같은 색을 띤다. 옆면은 담배색이다. 어깨와 팔뚝 바깥쪽, 팔과 다리 안쪽도 계피색이다. 팔뚝 바깥쪽과 다리 아랫부분, 복부, 가슴 아랫부분은 붉은 기운이 도는 갈색이다. 가슴 윗부분과 팔뚝 안쪽은 불그스름한 주황색이다. 손목과 발목, 손과 발의 윗부분은 적갈색이다. 꼬리는 윗부분은 계피색이고 끝으로 갈수록 점점 밝아진다. 꼬리 아랫부분도 밝다.
페리하산맥흰이마카푸친 분류
베네수엘라 마라카이보호 서쪽 기슭에서 시에라 데 페리하 산맥 동쪽 기슭까지, 흰이마카푸친보다 훨씬 가볍고, 다리가 더 붉으며, 몸색이 더욱 대조적인 카푸친원숭이 형태가 있다. 1949년 포유류학자 필립 허쉬코비츠는 페리하산맥흰이마카푸친을 흰이마카푸친의 아종(Cebus albifrons adustus)으로 기술했다. 페리하산맥흰이마카푸친은 흰이마카푸친의 변종일 수도 있고, 다른 종일 수도 있다.
페리하산맥흰이마카푸친 생활사
페리하산맥흰이마카푸친은 습한 저지대 열대우림과 반건조 낙엽수림, 그리고 맹그로브 숲에 서식한다. 먹이와 번식, 그리고 다른 행동들은 아직 자세히 연구되지 않았다.
페리하산맥흰이마카푸친 보전 상태
IUCN은 현재 페리하산맥흰이마카푸친을 절멸위기종으로 지정하지 않았다. 서식지 내에는 세 곳의 보호구역이 있다.
LZFSE
LZFSE(Lempel–Ziv Finite State Entropy)는 애플이 만든 오픈 소스 비손실 데이터 압축 알고리즘이다. 더 간단한 알고리즘인 LZVN과 함께 출시되었다.
LZFSE 개요
이름은 렘펠-지브와 유한 상태 엔트로피(비대칭 숫자 시스템 구현)의 약어이다.
LZFSE는 애플이 2015년 세계 개발자 회의에서 발표했다. 그 해 iOS 9와 OS X 10.11 출시에 포함되었다.
애플은 LZFSE가 Zlib (DEFLATE)와 비슷한 압축률을 가지면서도 두세 배 더 빠르게 압축을 해제하고 더 적은 리소스를 사용하므로 zlib보다 더 높은 에너지 효율을 제공한다고 주장한다. 압축 해제 속도와 비율을 균등하게 우선시해야 하는 시나리오를 목표로 했다. 이러한 에너지 효율의 일부는 최신 마이크로아키텍처, 특히 ARM64에 맞게 알고리즘을 최적화함으로써 달성되었다. 타사 벤치마킹에 따르면 LZFSE가 zlib보다 압축 해제 속도가 빠르지만, 다른 많은 최신 압축 알고리즘이 밀도, 압축 속도 및 압축 해제 속도와 같은 더 유리한 압축 알고리즘 성능 특성을 상당한 차이로 가질 수 있음을 시사한다.
LZFSE 개요
스쿼시 벤치마크에 따르면 LZFSE는 Zstd (레벨 6)와 속도가 비슷하지만 비율은 약간 나쁘다. LZVN은 LZ4 레벨 4와 속도가 비슷하지만 비율도 약간 나쁘다. LZFSE와 LZVN 모두 런타임에 튜닝할 수 없지만, 일반적인 속도-비율 절충을 위해 컴파일 시간에 몇 가지 상수를 조정할 수 있다.
LZFSE 구현
에릭 바인빌이 작성한 참조 C 라이브러리는 2016년 WWDC 이후 3-절 BSD 라이선스로 공개되었다. 여기에는 LZFSE 스트림을 압축하고 해제하는 실행 파일도 포함된다. LZVN API를 노출할 계획은 없다.
애플의 LZFSE 구현은 입력이 LZFSE_ENCODE_LZVN_THRESHOLD (4096 바이트)보다 작을 때 LZVN이라는 더 간단한 알고리즘을 사용한다. 이는 엔트로피 부호화 없이 세 가지 너비의 REP (L,M,D) 패킷을 사용하는 LZSS 유형 알고리즘이다. 오픈 소스 참조 구현에서 애플은 LZFSE가 작은 크기에서 제대로 작동하지 않으므로 대신 LZVN을 사용한다고 설명한다. libfastCompression.a의 이 알고리즘은 이전에 Mac OS X 요세미티 개발자 프리뷰 1 (2014)에서 기본 커널캐시 압축 방식으로 발견되었으며, 하루히코 오쿠무라의 기존 lzss 압축을 대체했다.
LZFSE 사용법
HFS 플러스 및 애플 파일 시스템의 준투명 압축 메커니즘인 AppleFSCompression.framework (AFSC)는 OS X 10.9 이후 LZFSE 및 LZVN을 지원한다.
애플의 디스크 이미지 프레임워크는 Mac OS X 10.11 이후 ULFO라는 LZFSE 기반 인코딩을 제공하며, hdiutil(1) 및 일부 타사 이미지 유틸리티를 통해 접근할 수 있다.
애플은 2017년 macOS 하이 시에라에서 애플 아카이브 형식과 관련 API를 도입했다. 확장자명은 .aar (틀:MacOS 빅서 이후, 이전에는 .yaa)이다. 암호화는 macOS 몬터레이에서 도입되었으며, 이때 AA는 기본 아카이브 유틸리티 형식이 되었다. macOS에는 AA 파일을 처리하는 세 가지 명령줄 유틸리티가 제공된다. 타사 프로그램 중 Keka는 시스템 API를 사용하여 AA 파일을 처리할 수 있지만, 다른 시스템에는 독립적인 구현이 존재하지 않는다.
이미지 해상도
이미지 해상도(Image resolution)는 영상의 세부 수준이다. 이 용어는 디지털 이미지, 필름 이미지 및 기타 유형의 이미지에 적용된다. "고해상도"는 더 많은 이미지 세부 정보를 의미한다.
이미지 해상도는 다양한 방식으로 측정할 수 있다. 해상도는 선들이 서로 얼마나 가까이 있을 수 있는지, 그리고 여전히 눈에 띄게 구별될 수 있는지를 정량화한다. 해상도 단위는 물리적 크기(예: mm당 선, 인치당 선), 그림의 전체 크기(그림 높이당 선, 단순히 선, TV 선 또는 TVL로도 알려짐) 또는 각도에 연결될 수 있다. 단일 선 대신 어두운 선과 인접한 밝은 선으로 구성된 선 쌍이 자주 사용된다. 예를 들어, 밀리미터당 10선 해상도는 5개의 어두운 선과 5개의 밝은 선이 번갈아 나타나는 것을 의미하거나, 밀리미터당 5개의 선 쌍(5 LP/mm)을 의미한다. 사진 렌즈는 주로 밀리미터당 선 쌍으로 인용된다.
이미지 해상도 유형
디지털 카메라의 해상도는 여러 가지 방식으로 설명할 수 있다.
해상도라는 용어는 종종 디지털 이미징에서 화소 수와 동등하게 간주되지만, 디지털 카메라 분야의 국제 표준은 이미지 센서와 관련하여 "총 화소 수"로, 완전히 캡처된 것에 대해서는 "기록된 화소 수"로 불러야 한다고 명시하고 있다. 따라서 CIPA DCG-001은 "기록된 화소 수 1000 × 1500"과 같은 표기를 요구한다. 동일한 표준에 따르면, 이미지 센서 또는 디지털 카메라가 갖는 "유효 화소 수"는 최종 이미지에 기여하는 화소 센서의 수(해당 이미지에 없지만 이미지 필터링 프로세스를 지원하는 화소 포함)를 의미하며, 가장자리에 사용되지 않거나 빛에 차폐된 화소를 포함하는 총 화소 수와는 대조된다.
이미지 해상도 유형
N 화소 높이와 M 화소 너비의 이미지는 그림 높이당 N선 또는 N TV선보다 낮은 모든 해상도를 가질 수 있다. 그러나 화소 수가 "해상도"로 언급될 때, 관례적으로 화소 해상도를 두 개의 양의 정수로 설명하며, 첫 번째 숫자는 화소 열(너비)의 수이고 두 번째는 화소 행(높이)의 수이다. 예를 들어 7680 × 6876과 같다. 또 다른 일반적인 관례는 이미지의 총 화소 수로 해상도를 인용하는 것인데, 일반적으로 메가픽셀 수로 주어지며, 이는 화소 열에 화소 행을 곱한 다음 100만으로 나누어 계산할 수 있다. 다른 관례로는 길이 단위당 화소 또는 면적 단위당 화소를 설명하는 것이 있는데, 예를 들어 인치당 화소 또는 평방 인치당 화소가 있다. 이러한 화소 해상도 중 어느 것도 진정한 해상도는 아니지만, 널리 그렇게 불린다. 이들은 이미지 해상도의 상한으로 작용한다.
아래는 화소들이 거칠게 날카로운 사각형으로 렌더링될 경우 동일한 이미지가 다른 화소 해상도에서 어떻게 나타날 수 있는지를 보여주는 그림이다(일반적으로 화소로부터 부드러운 이미지 재구성이 선호되지만, 화소를 보여주기 위해서는 날카로운 사각형이 더 잘 드러낸다).
이미지 해상도 유형
너비 2048 화소, 높이 1536 화소인 이미지는 총 2048×1536 = 3,145,728 화소 또는 3.1 메가픽셀을 갖는다. 이는 2048 x 1536 또는 3.1 메가픽셀 이미지라고 할 수 있다. 이 이미지는 약 28.5인치 너비로 인쇄하면 매우 낮은 품질(72ppi)의 이미지가 되지만, 약 7인치 너비로 인쇄하면 매우 좋은 품질(300ppi)의 이미지가 된다.
컬러 디지털 카메라 이미지 센서의 광다이오드 수는 종종 생성되는 이미지의 화소 수의 배수인데, 이는 컬러 이미지 센서 배열의 정보가 단일 화소의 색상을 재구성하는 데 사용되기 때문이다. 이미지는 각 출력 화소에 대해 세 가지 색상을 모두 생성하기 위해 보간되거나 데모자이크되어야 한다.
흐릿함과 선명함이라는 용어는 디지털 이미지에 사용되지만, 이미지를 캡처하고 표시하는 하드웨어를 참조하는 데는 다른 설명자가 사용된다.
방사선학에서의 공간 해상도는 영상 모달리티가 두 물체를 구별하는 능력이다. 낮은 공간 해상도 기술은 서로 비교적 가까이 있는 두 물체를 구별할 수 없을 것이다.
이미지 해상도 유형
이미지에서 선들을 얼마나 가깝게 구별할 수 있는지에 대한 측정은 공간 해상도라고 불리며, 이는 인치당 화소 (ppi)의 화소 해상도뿐만 아니라 이미지를 생성하는 시스템의 속성에 따라 달라진다. 실제적으로 이미지의 선명도는 이미지의 화소 수가 아니라 공간 해상도에 의해 결정된다. 실제로 공간 해상도는 단위 길이당 독립적인 화소 값의 수이다.
소비자 디스플레이의 공간 해상도는 인치당 50에서 800 화소 선에 이른다. 스캐너의 경우, 광분해능은 때때로 공간 해상도를 인치당 화소 수와 구별하는 데 사용된다.
원격탐사에서 공간 해상도는 일반적으로 회절 한계, 수차, 불완전한 초점, 대기 왜곡에 의해 제한된다. 이미지의 지상 샘플 거리 (GSD), 즉 지구 표면의 화소 간격은 일반적으로 해상 가능한 스팟 크기보다 상당히 작다.
이미지 해상도 유형
천문학에서 종종 관측 지점에서 하위된 아크초당 데이터 포인트로 공간 해상도를 측정한다. 이는 이미지 내 개체 간의 물리적 거리가 개체의 거리에 따라 달라지며, 이는 관심 대상에 따라 크게 달라지기 때문이다. 반면에 주사전자현미경에서는 선 또는 간섭무늬 해상도는 인접한 평행선(예: 원자 평면 사이) 사이에서 감지 가능한 최소 분리이며, 점 해상도는 인접한 점 사이에서 감지 및 해석 가능한 최소 분리(예: 인접한 원자 기둥)이다. 전자는 종종 표본의 주기성을 감지하는 데 도움이 되지만, 후자(달성하기는 더 어렵지만)는 개별 원자가 어떻게 상호 작용하는지 시각화하는 데 중요하다.
입체 3D 이미지에서 공간 해상도는 스테레오 카메라의 두 시점(왼쪽 및 오른쪽 카메라)에서 기록되거나 캡처된 공간 정보로 정의될 수 있다.
화소 인코딩은 디지털 이미지에 저장된 정보를 제한하며, 컬러 프로파일이라는 용어는 디지털 이미지에 사용되지만, 이미지를 캡처하고 표시하는 하드웨어를 참조하는 데는 다른 설명자가 사용된다.
이미지 해상도 유형
스펙트럼 해상도는 스펙트럼 특징과 대역을 개별 구성 요소로 분해하는 능력이다. 컬러 이미지는 다른 스펙트럼의 빛을 구별한다. 다중 스펙트럼 이미지는 일반적인 RGB 컬러 이미지의 전통적인 3가지보다 더 많은 스펙트럼 또는 파장의 미세한 차이를 측정하고 저장하여 분해할 수 있다.
시간 해상도(TR)는 시간에 대한 측정의 정밀도이다.
영화 촬영기와 고속 카메라는 다른 시점의 이벤트를 해결할 수 있다. 영화에 사용되는 시간 해상도는 일반적으로 초당 24~48 프레임 (frames/s)인 반면, 고속 카메라는 초당 50~300프레임 또는 그 이상을 해결할 수 있다.
하이젠베르크 불확정성 원리는 입자의 좌표에 대한 정보의 최대 공간 해상도에 대한 근본적인 한계를 설명한다. 이는 운동량에 관한 정보가 어떤 정밀도로든 측정되거나 존재함으로써 부과된다.
이러한 근본적인 한계는 주사전자현미경을 사용하여 만날 수 있는 아원자 규모에서의 최대 이미징 해상도에 영향을 미칠 수 있다.
방사선 해상도는 시스템이 강도의 차이를 얼마나 정교하게 나타내거나 구별할 수 있는지를 결정하며, 일반적으로 레벨 수 또는 비트 수로 표현된다. 예를 들어, 컴퓨터 이미지 파일에 일반적으로 사용되는 8비트 또는 256레벨이 있다. 방사선 해상도가 높을수록 강도 또는 반사율의 미묘한 차이를 더 잘 표현할 수 있다. 적어도 이론적으로는 그렇다. 실제로는 유효 방사선 해상도는 일반적으로 표현 비트 수보다는 노이즈 수준에 의해 제한된다.
이미지 해상도 다양한 매체에서의 해상도
다음은 다양한 매체에 대한 전통적인 아날로그 수평 해상도 목록이다. 이 목록에는 희귀한 형식이 아닌 인기 있는 형식만 포함되어 있으며, 실제 품질은 기기나 테이프마다 다를 수 있으므로 모든 값은 근사치이다. 비교를 쉽게 하기 위해 모든 값은 NTSC 시스템 기준이다. (PAL 시스템의 경우 480을 576으로 대체한다.) 아날로그 형식은 일반적으로 색차 해상도가 낮았다.
많은 카메라와 디스플레이는 색상 구성 요소를 서로 상대적으로 오프셋하거나 시간 해상도와 공간 해상도를 혼합한다.
아날로그
320×200: 브라운관 모니터
333×480: VHS, Video8, Umatic
350×480: 베타맥스
420×480: 슈퍼 베타맥스, 베타캠
460×480: 베타캠 SP, Umatic SP, NTSC (공중파 TV)
580×480: 슈퍼 VHS, Hi8, 레이저디스크
700×480: 향상된 정의 베타맥스, 아날로그 방송 한계 (NTSC)
768×576: 아날로그 방송 한계 (PAL, SECAM)
이미지 해상도 다양한 매체에서의 해상도
디지털
352×240: 비디오 CD
500×480: Digital8
720×480: D-VHS, DVD, miniDV, Digital Betacam (NTSC)
720×480: 와이드스크린 DVD (아나모픽) (NTSC)
854×480: EDTV (향상된 정의 텔레비전)
720×576: D-VHS, DVD, miniDV, Digital8, Digital Betacam (PAL/SECAM)
720×576 또는 1024  ×  576: 와이드스크린 DVD (아나모픽) (PAL/SECAM)
1280×720: D-VHS, HD DVD, 블루레이, HDV (miniDV)
1440×1080: HDV (miniDV)
1920×1080: HDV (miniDV), AVCHD, HD DVD, 블루레이, HDCAM SR
1998×1080: 2K 플랫 (1.85:1)
2048×1080: 2K 디지털 시네마
2560 × 1440: QHD (쿼드 HD) 즉 HD 1280x720의 4배 화소
3840×2160: 4K UHDTV, 울트라 HD 블루레이
4096×2160: 4K 디지털 시네마
7680×4320: 8K UHDTV
15360×8640: 16K 디지털 시네마
이미지 해상도 다양한 매체에서의 해상도
30720 × 17280: 32K
최신 영화의 시퀀스는 고품질 시각 효과 편집을 위해 컴퓨터에서 2,000, 4,000 또는 심지어 8,000 컬럼으로 스캔되며, 이는 2K, 4K, 8K라고 불린다.
IMAX, IMAX HD 및 OMNIMAX 포함: 약 10,000×7,000 (7,000라인) 해상도. 이는 약 70MP로, 현재 단일 센서 디지털 영화 카메라 중 가장 높은 해상도이다 (2012년 1월 기준).
필름
35mm 필름은 2005년 기준 DVD 출시를 위해 1080 또는 2000 라인으로 스캔된다.
35mm 원본 카메라 네거티브의 실제 해상도는 많은 논쟁의 대상이다. 네거티브 필름의 측정된 해상도는 25–200 LP/mm 범위에 있었으며, 이는 2-perf의 경우 325 라인, T-Max 100으로 촬영된 4-perf의 경우 (이론적으로) 2300 라인 이상에 해당한다. 코닥은 35mm 필름이 IMAX의 수석 부사장에 따르면 수평으로 6K 해상도와 동등하다고 밝혔다.
이미지 해상도 다양한 매체에서의 해상도
현대 디지털 카메라 해상도
디지털 중형 포맷 카메라 – 단일, 결합되지 않은 대형 디지털 센서 – 80MP (2011년부터, 2013년 현재) – 10320 × 7752 또는 10380 × 7816 (81.1MP).
휴대폰 – 노키아 808 퓨어뷰 – 41MP (7728 × 5368), 노키아 루미아 1020 – 또한 41MP (7712 × 5360)
디지털 스틸 카메라 – 캐논 EOS 5DS – 51MP (8688 × 5792)
부대역 부호화
신호 처리에서 부대역 부호화(Sub-band coding, SBC, 서브밴드 부호화)는 일반적으로 고속 푸리에 변환을 사용하여 신호를 여러 주파수 대역으로 나누고 각 대역을 독립적으로 부호화하는 모든 형태의 변환 부호화를 말한다. 이 분해는 종종 오디오 및 비디오 신호의 데이터 압축을 위한 첫 번째 단계이다.
SBC는 MP3를 포함한 많은 인기 있는 손실 오디오 압축 알고리즘에 사용되는 핵심 기술이다.
부대역 부호화 오디오 신호 부호화
디지털로 오디오 신호를 부호화하는 가장 간단한 방법은 오디오 CD, DAT 녹음 등에서 사용되는 펄스 부호 변조(PCM)이다. 디지털화는 신호의 진폭을 균일한 간격으로 표본화하고 사용 가능한 비트 수로 표현 가능한 가장 가까운 값으로 반올림하여 연속적인 신호를 불연속적인 신호로 변환한다. 이 과정은 근본적으로 부정확하며, 간격 표본화로 인한 이산화 오류와 반올림으로 인한 양자화 오류라는 두 가지 오류를 포함한다.
부대역 부호화 오디오 신호 부호화
각 표본을 나타내는 데 사용되는 비트 수가 많을수록 디지털 표현의 세분성이 더 미세해지며, 따라서 양자화 오류는 더 작아진다. 이러한 양자화 오류는 일종의 잡음으로 생각될 수 있는데, 이는 원본 소스와 바이너리 표현 간의 실질적인 차이이기 때문이다. PCM에서는 이러한 오류의 가청 효과는 디더와 충분한 비트 수를 사용하여 잡음이 신호 자체 또는 다른 잡음원에 의해 마스킹될 만큼 충분히 낮게 유지되도록 함으로써 완화될 수 있다. 고품질 신호는 가능하지만, 높은 비트레이트(예: CD 오디오 한 채널당 700 kbit/s 이상)의 비용이 따른다. PCM은 인간의 귀가 어떻게 듣는지에 대한 가정을 하지 않기 때문에, 결과적으로 신호의 마스킹된 부분을 부호화하는 데 많은 비트가 낭비된다.
부호화 기술은 청각 시스템의 알려진 특성을 활용하여 비트레이트를 줄인다. 고전적인 방법은 뮤 법칙 알고리즘과 같은 비선형 PCM이다. 작은 신호는 큰 신호보다 더 미세한 세분성으로 디지털화된다. 그 효과는 신호 강도에 비례하는 잡음을 추가하는 것이다. 썬의 Au 파일 포맷은 뮤 법칙 부호화의 인기 있는 예이다. 8비트 뮤 법칙 부호화를 사용하면 CD 오디오의 채널당 비트레이트를 표준 속도의 절반인 약 350 kbit/s로 줄일 수 있다. 이 간단한 방법은 마스킹 효과를 최소한으로만 활용하기 때문에, 종종 원본보다 가청적으로 열등한 결과를 생성한다.
부대역 부호화 기본 원리
SBC의 유용성은 특정 예시를 통해 가장 잘 설명될 수 있다. 오디오 압축에 사용될 때, SBC는 청각계의 청각 마스킹을 활용한다. 인간의 귀는 일반적으로 넓은 주파수 범위에 민감하지만, 한 주파수에서 충분히 큰 신호가 존재할 때, 귀는 근처 주파수에서 더 약한 신호를 듣지 못한다. 우리는 더 큰 신호가 더 부드러운 신호를 마스킹한다고 말한다.
SBC의 기본 아이디어는 마스킹된 주파수에 대한 정보를 버림으로써 데이터 감소를 가능하게 하는 것이다. 결과는 원본 신호와 다르지만, 버려진 정보가 신중하게 선택되면 그 차이는 눈에 띄지 않거나, 더 중요하게는 불쾌하지 않을 것이다.
먼저 디지털 필터 뱅크가 입력 신호 스펙트럼을 여러 개(예: 32개)의 부대역으로 나눈다. 음향심리 모델은 이러한 각 부대역과 원본 신호의 에너지를 살펴보고, 음향심리 정보를 사용하여 마스킹 임계값을 계산한다. 각 부대역 표본은 동적으로 계산된 마스킹 임계값 미만으로 양자화 잡음을 유지하도록 양자화되고 부호화된다. 마지막 단계는 이러한 모든 양자화된 표본을 디코더의 최종 재생을 용이하게 하기 위해 프레임이라는 데이터 그룹으로 포맷하는 것이다.
부대역 부호화 기본 원리
복호화는 음향심리 모델이 포함되지 않으므로 부호화보다 훨씬 쉽다. 프레임은 압축이 풀리고, 부대역 표본은 복호화되며, 주파수-시간 매핑은 출력 오디오 신호를 재구성한다.
부대역 부호화 응용
1980년대 후반부터 동영상 전문가 그룹(MPEG)이라는 표준화 기관은 오디오와 비디오 모두에 대한 부호화 표준을 개발했다. 예를 들어, 부대역 부호화는 인기 있는 MP3 포맷(더 정확하게는 MPEG-1 오디오 레이어 III으로 알려짐)의 핵심이다.
부대역 부호화는 64 kbit/s의 비트레이트 내에서 부대역 적응 차분 펄스 부호 변조(SB-ADPCM)를 사용하는 G.722 코덱에 사용된다. SB-ADPCM 기술에서 주파수 대역은 두 개의 부대역(고역 및 저역)으로 분할되고 각 부대역의 신호는 ADPCM을 사용하여 부호화된다.