렘펠 지브 웰치
Lempel–Ziv–Welch |
Lempel-Ziv-Welch(LZW)는 Abraham Lempel, Jacob Ziv 및 Terry Welch에 의해 작성된 범용 무손실 데이터 압축 알고리즘입니다.1978년 Lempel과 Ziv가 발표한 LZ78 알고리즘의 개선된 구현으로 1984년 Welch에 의해 출판되었다.이 알고리즘은 구현이 간단하며 하드웨어 [1]구현 시 매우 높은 throughput이 발생할 수 있습니다.널리 사용되는 Unix 파일 압축 유틸리티 압축 알고리즘이며 GIF 이미지 형식으로 사용됩니다.
알고리즘.
Welch의 1984년[1] 논문에서 설명된 시나리오는 8비트 데이터의 시퀀스를 고정 길이의 12비트 코드로 인코딩합니다.0 ~ 255 의 코드는, 대응하는 8 비트 문자로 이루어진 1 문자 시퀀스를 나타내며, 코드 256 ~4095 는, 부호화시에 데이터내에서 발생하는 시퀀스에 대해서 사전에 작성됩니다.압축의 각 단계에서 입력 바이트는 다음 문자가 사전에 아직 코드가 없는 시퀀스를 만들 때까지 시퀀스로 수집됩니다.시퀀스의 코드(이 문자가 없는 경우)가 출력에 추가되고, 새로운 코드(이 문자가 있는 시퀀스)가 사전에 추가됩니다.
그 생각은 다른 상황에 빠르게 적응되었다.예를 들어 컬러테이블을 기반으로 한 이미지에서 자연문자 알파벳은 컬러테이블 인덱스의 집합으로 1980년대에는 작은 컬러테이블(16색 정도)을 가진 이미지가 많았다.이렇게 축소된 알파벳의 경우 이미지가 크지 않은 한 완전한 12비트 코드는 압축이 잘 되지 않기 때문에 가변폭 코드의 아이디어가 도입되었습니다.코드는 일반적으로 부호화되는 기호보다 1비트 넓게 시작되며, 각 코드 크기가 사용됨에 따라 코드 폭은 규정된 최대값(일반적으로 12비트)까지 증가합니다.최대 코드 값에 도달하면 기존 테이블을 사용하여 인코딩이 진행되지만 테이블에 추가할 새 코드는 생성되지 않습니다.
또한 코드 테이블을 클리어하여 초기 상태로 복원해야 함을 나타내는 코드(일반적으로 개별 알파벳 문자의 값 바로 뒤의 첫 번째 값)와 데이터의 끝을 나타내는 코드(일반적으로 클리어 코드보다 큰 "정지 코드")를 예약하는 것이 개선되었습니다.클리어 코드를 사용하면 테이블이 가득 찬 후 재초기화할 수 있으므로 입력 데이터의 패턴 변화에 따라 인코딩이 조정됩니다.스마트 인코더는 압축 효율을 감시하고 기존 테이블이 입력과 잘 일치하지 않을 때마다 테이블을 클리어할 수 있습니다.
데이터에 의해 결정되는 방법으로 코드가 추가되기 때문에 디코더는 결과 코드를 보는 대로 테이블을 작성하는 것을 모방합니다.사용하는 LZW의 종류(알파벳의 크기, 최대 테이블사이즈(및 코드폭), 가변폭 부호화 사용 여부, 초기 코드 사이즈, 클리어 코드와 스톱 코드 사용 여부(및 그 값의 종류)에 대해 인코더와 디코더가 일치시키는 것이 중요합니다.LZW를 사용하는 대부분의 포맷은 이 정보를 포맷 사양에 포함시키거나 데이터 압축 헤더에 명시적인 필드를 제공합니다.
부호화
부호화 알고리즘의 개요를 다음에 나타냅니다.
- 길이가 1인 모든 문자열을 포함하도록 사전을 초기화합니다.
- 사전에서 현재 입력과 일치하는 가장 긴 문자열 W를 찾습니다.
- W를 출력하기 위한 사전 인덱스를 내보내고 입력에서 W를 제거합니다.
- 입력의 다음 기호와 W를 사전에 추가합니다.
- 스텝 2로 넘어갑니다.
사전은 가능한 모든 입력 문자에 대응하는 단일 문자열이 포함되도록 초기화됩니다(사용 중인 경우 클리어 코드와 정지 코드 이외에는 포함되지 않습니다).이 알고리즘은 입력 문자열을 스캔하여 사전에 없는 서브스트링을 찾을 때까지 연속적으로 긴 서브스트링을 검색합니다.이러한 문자열이 발견되면 마지막 문자가 없는 문자열(즉, 사전에 있는 가장 긴 하위 문자열)의 인덱스가 사전에서 검색되어 출력으로 전송되며, 사용 가능한 다음 코드와 함께 새 문자열(마지막 문자열 포함)이 사전에 추가됩니다.그런 다음 마지막 입력 문자를 다음 시작 지점으로 사용하여 하위 문자열을 검색합니다.
이렇게 하면 연속적으로 긴 문자열이 사전에 등록되고 단일 출력값으로 후속 인코딩에 사용할 수 있습니다.이 알고리즘은 패턴이 반복되는 데이터에 가장 적합하기 때문에 메시지의 첫 부분에는 압축이 거의 없습니다.그러나 메시지가 커짐에 따라 압축률은 점근적으로 최대가 되는 경향이 있습니다(즉, 압축률 또는 비율은 무한대에 걸쳐서가 아니라 한정된 시간 [2]내에 이론적인 최대치에 근접하는 선형적이 아니라 증가 곡선으로 개선됩니다).
디코딩
디코딩 알고리즘의 개요는 다음과 같습니다.
- 길이가 1인 모든 문자열을 포함하도록 사전을 초기화합니다.
- 인코딩된 다음 기호를 읽습니다.사전에 암호화되어 있나요?
- 네:
- 대응하는 문자열 W를 출력합니다.
- 출력에 출력된 이전 문자열을 W의 첫 번째 기호와 연결합니다. 이 기호를 사전에 추가합니다.
- 아니요:
- 출력에 출력된 이전 문자열을 첫 번째 기호와 연결합니다.이 문자열을 V라고 합니다.
- 사전에 V를 추가하고 출력할 V를 내보냅니다.
- 네:
- 입력 문자열이 끝날 때까지 스텝2를 반복합니다.
디코딩 알고리즘은 인코딩된 입력에서 값을 읽고 사전에서 대응하는 문자열을 출력하는 방식으로 작동합니다.단, 완전한 사전은 필요하지 않습니다.단일 문자열이 포함된 초기 사전만 필요합니다(또한 일반적으로 인코딩된 데이터와 함께 전송되는 대신 프로그램에서 하드 코딩됩니다).대신 디코딩 프로세스 중에 완전한 사전이 재구축됩니다.값을 디코딩하고 문자열을 출력한 후 디코더는 다음 디코딩된 문자열의 첫 번째 문자(또는 다음 값을 알 수 없는 경우 현재 문자열의 첫 번째 문자)와 연결합니다.이 반복에서 사전이 추가되므로 첫 번째 문자는 현재 문자열의 첫 번째 문자와 동일하며 새 문자열로 사전을 업데이트합니다.그 후 디코더는 다음 입력으로 진행되며(이전 반복에서 이미 읽혀진), 입력 스트림이 소진될 때까지 이전과 같이 처리됩니다.
가변 폭 코드
가변폭 코드를 사용하는 경우 스트림 내의 개별 코드 간에 경계가 일치하지 않도록 부호화 데이터 내의 동일한 포인트에서 폭을 변경하는 데 주의해야 합니다.표준 버전에서는 인코더는 테이블에 존재하지 않는 시퀀스 δ+s가 발생하면 폭을 p에서 p+1로 늘립니다만(따라서 코드 추가가 필요함) 테이블 내의 다음 사용 가능한 코드는 2입니다p(p+1비트가 필요한 첫 번째 코드).인코더는 폭 p로 at의 코드를 방출하고(이 코드는 p + 1비트가 필요하지 않기 때문에), 다음으로 방출되는 코드가 폭 p + 1비트가 되도록 코드 폭을 늘립니다.
디코더는 테이블을 작성할 때 항상 인코더 뒤에1개의 코드가 있기 때문에 코드2p - 1의 엔트리가 생성됩니다.이 시점에서 인코더가 코드 폭을 늘리기 때문에 디코더는 여기서도 폭을 늘려야 합니다(p비트 단위로 가장 큰 코드를 생성해야 합니다).
유감스럽게도 부호화 알고리즘의 초기 실장 중에는 코드 폭을 늘린 후 오래된 폭이 아닌 새로운 폭에서 θ를 방출하기 때문에 디코더에게는 폭이 하나의 코드를 너무 일찍 변경하는 것처럼 보입니다.이것을 「얼리 체인지」라고 부릅니다.이 때문에, Adobe는 PDF 파일에서는 양쪽의 버전을 허가하고 있습니다만, 각 LZW 압축 스트림의 헤더에 명시적인 플래그가 포함되어 있어 조기 변경이 사용되고 있는지를 나타냅니다.LZW 압축을 지원하는 그래픽 파일 형식 중 TIFF는 조기 변경을 사용하는 반면 GIF 및 기타 대부분은 그렇지 않습니다.
클리어 코드에 따라 테이블이 클리어되면 인코더와 디코더 모두 클리어 코드 직후의 코드부터 시작하여 클리어 코드 후의 코드폭을 초기 코드폭으로 되돌립니다.
포장순서
출력되는 코드는 일반적으로 바이트 경계에 속하지 않기 때문에 인코더와 디코더는 코드가 바이트로 패킹되는 방법에 대해 일치해야 합니다.두 가지 일반적인 방법은 LSB-first(" 최하위 비트 우선")와 MSB-first(" 최하위 비트 우선")입니다.LSB 첫 번째 패킹에서는 코드의 최하위 비트가 첫 번째 스트림바이트의 최하위 비트에 들어가도록 첫 번째 코드가 정렬되며, 코드에 8비트보다 많은 경우 상위 비트는 다음 바이트의 최하위 비트에 정렬됩니다.그 이후의 코드는 LSB가 최하위 비트로 패킹됩니다.현재 스트림 바이트에서 아직 사용되지 않은 개미 비트는 필요에 따라 추가 바이트로 진행됩니다.MSB 첫 번째 패킹은 첫 번째 스트림 바이트의 MSB에 최상위 비트가 들어가도록 첫 번째 코드를 정렬하고 다음 바이트의 MSB와 정렬되도록 합니다. 추가 코드는 MSB가 현재 스트림 바이트에서 아직 사용되지 않은 최상위 비트에 들어가도록 작성됩니다.
GIF 파일은 LSB 우선 포장 순서를 사용합니다.TIFF 파일 및 PDF 파일은 MSB 우선 포장 순서를 사용합니다.
예
다음으로 LZW 알고리즘의 동작 예를 나타냅니다.데이터 부호화와 복호화 모두 모든 단계에서 출력과 딕셔너리의 상태를 나타냅니다.이 예는 매우 짧은 메시지에 적절한 압축을 제공하도록 구성되어 있습니다.실제 텍스트 데이터에서는 일반적으로 반복이 덜 뚜렷하기 때문에 압축이 효율성을 높이기 전에 일반적으로 더 긴 입력 스트림이 필요합니다.
인코딩되는 평문(대문자만 사용하는 알파벳에서)은 다음과 같습니다.
토우노토부토토부토#
# 는 메시지의 끝에 도달했음을 나타내는 마커입니다.따라서 평문 알파벳에는 26개의 기호(대문자 A~Z 26개)가 있으며 # 문자는 정지 코드를 나타냅니다.이 값들은 문자에는 1 ~26, '#'에는 0을 임의로 할당합니다(LZW의 대부분의 플레이버에서는 데이터 알파벳 뒤에 정지 코드를 붙입니다만, 기본 알고리즘에서는 이 값을 필요로 하는 것은 없습니다).인코더와 디코더는 그 값이 어떤 값인지를 합의할 필요가 있습니다).
컴퓨터는 이것들을 비트열로 렌더링합니다.이 27개의 값 세트를 포함하기에 충분한 조합을 제공하려면 5비트코드가 필요해요.사전은 이 27개의 값으로 초기화됩니다.사전이 커짐에 따라 추가 엔트리를 수용하기 위해 코드의 폭이 커져야 합니다.5비트 코드는 2 = 32의 비트 조합을 제공하므로5 33번째 사전 워드가 생성될 때 알고리즘은 5비트 문자열에서 6비트 문자열로 전환되어야 합니다(이전에는 5비트만 출력된 값을 포함).all-zero code 00000이 사용되고 "0"이라는 라벨이 붙어 있기 때문에 33번째 사전 엔트리는 32라는 라벨이 붙어 있습니다.(이전 생성된 출력은 코드 폭 변경의 영향을 받지 않지만 사전에서 6비트 값이 생성되면 다음 출력의 폭이 6비트로 변경되어 수용될 수 있습니다.)e 그거)
초기 딕셔너리는 다음 항목으로 구성됩니다.
| 기호. | 바이너리 | 십진수 |
|---|---|---|
| # | 00000 | 0 |
| A | 00001 | 1 |
| B | 00010 | 2 |
| C | 00011 | 3 |
| D | 00100 | 4 |
| E | 00101 | 5 |
| F | 00110 | 6 |
| G | 00111 | 7 |
| H | 01000 | 8 |
| I | 01001 | 9 |
| J | 01010 | 10 |
| K | 01011 | 11 |
| L | 01100 | 12 |
| M | 01101 | 13 |
| N | 01110 | 14 |
| O | 01111 | 15 |
| P | 10000 | 16 |
| Q | 10001 | 17 |
| R | 10010 | 18 |
| S | 10011 | 19 |
| T | 10100 | 20 |
| U | 10101 | 21 |
| V | 10110 | 22 |
| W | 10111 | 23 |
| X | 11000 | 24 |
| Y | 11001 | 25 |
| Z | 11010 | 26 |
부호화
사전에는 " + 다음 문자가 없을 때까지의 시퀀스 "의 버퍼 입력 문자.,의 코드를 내보내고 + + 다음 문자를 사전에 추가합니다.다음 문자로 버퍼링을 다시 시작합니다.(인코딩되는 문자열은 'TOBEORNOTTOBEORNOT#'입니다).
| 현재 시퀀스 | 다음 문자 | 산출량 | 확장 사전 | 평. | ||
|---|---|---|---|---|---|---|
| 코드 | 비트 | |||||
| 특수한 순서 | T | |||||
| T | O | 20 | 10100 | 27: | 로. | 27 = 0 ~ 26 이후 사용 가능한 첫 번째 코드 |
| O | B | 15 | 01111 | 28: | OB | |
| B | E | 2 | 00010 | 29: | 있다 | |
| E | O | 5 | 00101 | 30: | EO | |
| O | R | 15 | 01111 | 31: | 또는 | |
| R | N | 18 | 10010 | 32: | RN | 32에는 6비트가 필요하므로 다음 출력에는 6비트를 사용합니다. |
| N | O | 14 | 001110 | 33: | 아니요. | |
| O | T | 15 | 001111 | 34: | OT | |
| T | T | 20 | 010100 | 35: | TT | |
| 로. | B | 27 | 011011 | 36: | 토비 | |
| 있다 | O | 29 | 011101 | 37: | BEO | |
| 또는 | T | 31 | 011111 | 38: | 동작하다 | |
| 토비 | E | 36 | 100100 | 39: | 되려고 | |
| EO | R | 30 | 011110 | 40: | EOR | |
| RN | O | 32 | 100000 | 41: | RNO | |
| OT | # | 34 | 100010 | # 는 알고리즘을 정지하고 cur seq 를 송신합니다. | ||
| 0 | 000000 | 및 정지 코드 | ||||
- 부호화되지 않은 길이 = 25개 기호 × 5비트/125비트
- 부호화 길이 = (6 코드 × 5 비트/코드) + (11 코드 × 6 비트/코드) = 96 비트
LZW를 사용하면 125비트 중 29비트가 절약되어 메시지가 23% 이상 감소합니다.메시지가 더 길면 사전 단어는 텍스트의 더 긴 섹션을 나타내기 시작하여 반복 단어를 매우 간결하게 보냅니다.
디코딩
LZW 압축 아카이브를 디코딩하려면 사용된 초기 사전을 미리 알아야 하지만 항상 이전 엔트리의 단순한 결합이기 때문에 추가 엔트리를 재구성할 수 있습니다.
| 입력 | 출력 시퀀스 | 새 사전 항목 | 평. | ||||
|---|---|---|---|---|---|---|---|
| 비트 | 코드 | 가득한 | 추측 | ||||
| 10100 | 20 | T | 27: | T? | |||
| 01111 | 15 | O | 27: | 로. | 28: | 오? | |
| 00010 | 2 | B | 28: | OB | 29: | B? | |
| 00101 | 5 | E | 29: | 있다 | 30: | E? | |
| 01111 | 15 | O | 30: | EO | 31: | 오? | |
| 10010 | 18 | R | 31: | 또는 | 32: | R? | 작성된 코드 31(5비트에 마지막으로 맞는 코드) |
| 001110 | 14 | N | 32: | RN | 33: | N? | 따라서 6비트에서 입력을 읽기 시작합니다. |
| 001111 | 15 | O | 33: | 아니요. | 34: | 오? | |
| 010100 | 20 | T | 34: | OT | 35: | T? | |
| 011011 | 27 | 로. | 35: | TT | 36: | 에게? | |
| 011101 | 29 | 있다 | 36: | 토비 | 37: | BE? | 36 = TO + 첫 번째 기호(B)/ |
| 011111 | 31 | 또는 | 37: | BEO | 38: | 아니면? | 수신된 다음 코드화된 시퀀스(BE) |
| 100100 | 36 | 토비 | 38: | 동작하다 | 39: | 토비? | |
| 011110 | 30 | EO | 39: | 되려고 | 40: | EO? | |
| 100000 | 32 | RN | 40: | EOR | 41: | RN? | |
| 100010 | 34 | OT | 41: | RNO | 42: | OT? | |
| 000000 | 0 | # | |||||
디코더는 각 스테이지에서 코드 X를 수신하여 테이블 내에서 X를 검색하여 시퀀스 「코드」를 출력하고, 인코더가 방금 추가한 엔트리로 「+」를 추측합니다.이는 인코더가 「+」를 테이블내에 존재하지 않기 때문에, 인코더는 「+」를 X로 출력하고, 인코더를 계속하여 추가합니다.하지만 사라진 편지는 무엇일까요?디코더가 수신하는 다음 코드 Z에 의해 코드화된 시퀀스의 첫 번째 문자입니다.따라서 디코더는 Z를 검색하여 시퀀스 and로 디코딩하고 첫 번째 문자 z를 가져와 다음 사전 엔트리로 of의 끝에 탭합니다.
수신한 코드가 디코더 사전에 있는 한, 시퀀스로 디코딩할 수 있습니다.디코더가 사전에 없는 코드 Z를 수신하면 어떻게 됩니까?디코더는 항상 인코더 뒤에1개의 코드만 존재하기 때문에 Z는 인코더가 인코더의 딕셔너리에 존재할 수 있습니다.이거는 인코더가 인코더를 방금 생성했을 때에만 인코더의 딕셔너리에 포함되기 때문입니다.따라서 Z는 δ + ?인 일부 δ를 코드화하고 디코더는 다음과 같이 알 수 없는 문자를 판별할 수 있습니다.
- 디코더에는 X가 표시되고 다음으로 Z가 표시됩니다.여기서 X는 시퀀스 「」를 코드하고 Z는 미지의 시퀀스 「」를 코드합니다.
- 디코더는 인코더가 Z를 「」+「알 수 없는 문자 c」의 코드로 추가한 것을 알고 있기 때문에, 「=」+ 「c」입니다.
- c는 입력 스트림의 첫 번째 문자이며, "는 " 바로 뒤에 나타나는 문자열이므로 c는 시퀀스 "의 첫 번째 문자여야 합니다.
- is는 ,의 첫 번째 서브스트링이므로 c도 χ의 첫 번째 문자여야 합니다.
- 따라서, Z코드가 표에 없는 경우에도, 디코더는 미지의 시퀀스를 추론할 수 있고, Z의 값으로 테이블에 δ +(θ의 첫 번째 문자)를 더한다.
이 상황은 인코더가 cScSc 형식의 입력을 검출할 때마다 발생합니다.여기서 c는 단일 문자, S는 문자열, cS는 딕셔너리에 이미 존재하지만 cSc는 존재하지 않습니다.인코더는 cS용 코드를 방출하고 cSc용 새로운 코드를 딕셔너리에 넣습니다.다음으로 입력(cSc의 두 번째 c부터 시작)에 cSc가 표시되어 방금 삽입한 새로운 코드를 내보냅니다.위의 인수는 디코더가 사전에 없는 코드를 수신할 때마다 다음과 같은 상황이 발생함을 나타냅니다.
cScSc 형식의 입력은 거의 없을 것 같지만 입력 스트림이 상당한 반복으로 특징지어지면 이 패턴은 매우 일반적입니다.특히, 단일 문자의 긴 문자열(LZW는 부호화에 자주 사용됨)은 이러한 종류의 패턴을 반복적으로 생성합니다.
추가 코딩
위에서 설명한 간단한 스킴은 LZW 알고리즘 자체에 초점을 맞추고 있습니다.많은 응용 프로그램이 출력 기호 시퀀스에 추가 인코딩을 적용합니다.일부에서는 코드화된 스트림을 어떤 형식의 바이너리-텍스트 인코딩을 사용하여 인쇄 가능한 문자로 패키징합니다.이것에 의해, 부호화 길이가 길어지고 압축 레이트가 저하됩니다.반대로, 압축은 종종 적응형 엔트로피 인코더로 달성할 수 있습니다.이러한 부호화기는 지금까지 관측된 값의 빈도를 바탕으로 다음 기호 값의 확률 분포를 추정한다.다음으로 Huffman 부호화 또는 산술 부호화 등의 표준 엔트로피 부호화는 확률이 높은 값에 대해 짧은 코드를 사용합니다.
사용하다
LZW 압축은 컴퓨터에서 널리 사용되는 최초의 범용 데이터 압축 방식이 되었습니다.큰 영어 텍스트 파일은 보통 LZW를 통해 원래 크기의 약 절반으로 압축할 수 있습니다.
LZW는 퍼블릭 도메인 프로그램 압축에 사용되었으며, 1986년경 Unix 시스템에서 다소 표준 유틸리티가 되었습니다.LZW 특허를 침해하고 Gzip이 LZ77 기반의 DEFLATE 알고리즘을 사용하여 압축률을 높였기 때문에 많은 배포에서 사라졌지만 2008년 현재 최소 FreeB.SD는 배포의 일부로 압축과 압축 해제를 모두 포함합니다.다른 일반적인 압축 유틸리티도 LZW 또는 밀접하게 관련된 방법을 사용했습니다.
LZW는 1987년 GIF 이미지 포맷의 일부가 되면서 매우 널리 쓰이게 되었다.TIFF 및 PDF 파일에서도 사용할 수 있습니다(LZW는 Adobe Acrobat 소프트웨어에서도 사용할 수 있지만 기본적으로는 PDF 파일의 텍스트 및 컬러 테이블 기반 이미지 데이터 대부분에 DEFLATE를 사용합니다).
특허
LZW 및 유사한 알고리즘에 대한 다양한 특허가 미국 및 기타 국가에서 발행되었습니다.LZ78은 렘펠, 지브, 콘, 이스트먼이 1981년 8월 10일 제기한 미국 특허 4,464,650의 적용을 받았다.LZW 알고리즘에 대한 미국 특허는 빅터 S. 밀러와 마크 N에 의해 미국 특허 481만4746건이다. 1983년 6월 1일 IBM에 배정된 Wegman과 1983년 6월 20일 Sperry Corporation, 후에 Unisys Corporation에 배정된 Welch의 미국 특허 4,558,302가 제출되었습니다.
Welch의 1983년 특허는 상기 특허 외에 1980년 NEC의 Jun Kanatsu의 일본 특허 2건(JP9343880A와 JP17790880A), John S의 미국 특허 4,021,782(1974) 등 영향을 준 여러 특허에 대한 인용도 포함하고 있다.호이닝, 클라우스 E로부터 미국 특허 4,366,551(1977년).Karl Eckhart Heinz가 1981년 독일 특허([3]DE19813118676)를 취득했습니다.
1993-94년과 1999년에도 Unisys Corporation은 GIF 이미지에서 LZW에 대한 라이센스 요금을 적용하려고 했을 때 광범위한 비난을 받았다.1993~1994년 Unisys-CompuServe 논란(CompuServe가 GIF 포맷의 창시자)은 GIF 대체 파일 포맷에 대한 Usenet comp.graphics에 대한 논의를 촉진시켰고, 이는 결국 1995년 특허가 없는 PNG 형식의 PNG(Portable Network Graphics)를 만들었다.
Unisys의 LZW 알고리즘에 대한 미국 특허는 출원된 지 20년 후인 2003년 [4]6월 20일에 만료되었습니다.영국, 프랑스, 독일, 이탈리아, 일본, 캐나다에서 출원된 특허도 마찬가지로 출원된 지 20년이 지난 [4]2004년에 모두 만료되었다.
변종
- LZMW(1985년, V별).Miller, M. Wegman)[5] – 사전에서 이미 가장 긴 문자열("현재" 일치)을 검색합니다. 이전 일치와 현재 일치의 연결을 사전에 추가합니다. (사전 엔트리는 더 빠르게 증가하지만 이 스킴은 구현하기가 훨씬 더 복잡합니다.또한 Miller 및 Wegman은 사전이 가득 차면 사전에서 저주파 항목을 삭제할 것을 권장합니다.
- LZAP(1988년, James Storer에 [6]의한) – LZMW의 수정: 현재 일치와 이전 일치의 연결만 사전에 추가하는 것이 아니라 현재 일치의 각 초기 하위 문자열에 이전 일치의 연결을 추가합니다("AP"는 "모든 접두사"를 나타냅니다).예를 들어 이전 일치가 "wiki"이고 현재 일치가 "pedia"인 경우 LZAP 인코더는 "wikip", "wikipe", "wikipedi" 및 "wikipedia"의 5개의 새 시퀀스를 사전에 추가합니다.여기서 LZMW 인코더는 하나의 시퀀스만 추가합니다.이를 통해 사전 항목을 추가하는 대신 LZMW의 복잡성을 일부 해소할 수 있습니다.
- LZWL은 LZW의 음절 기반의 변형입니다.
「 」를 참조해 주세요.
- LZ77 및 LZ78
- LZMA
- 렘펠 지브 스토르 시만스키
- LZJB
- 컨텍스트 트리 가중치
- JPEG 및 MPEG 코딩 표준에서 사용되는 손실 압축 알고리즘인 이산 코사인 변환(DCT)
레퍼런스
- ^ a b Welch, Terry (1984). "A Technique for High-Performance Data Compression" (PDF). Computer. 17 (6): 8–19. doi:10.1109/MC.1984.1659158.
- ^ Ziv, J.; Lempel, A. (1978). "Compression of individual sequences via variable-rate coding" (PDF). IEEE Transactions on Information Theory. 24 (5): 530. CiteSeerX 10.1.1.14.2892. doi:10.1109/TIT.1978.1055934.
- ^ 미국 특허 4,558,302
- ^ a b "LZW Patent Information". About Unisys. Unisys. Archived from the original on June 26, 2009. Retrieved March 6, 2014.
- ^ Data Compression, David Salomon – 완전 레퍼런스, 제4판, 209페이지.
- ^ Data Compression, David Salomon – 완전 레퍼런스, 제4판, 212페이지.
외부 링크
- Rosettacode Wiki, 다양한 언어의 알고리즘
- 미국 특허 4,558,302, 테리 A.Welch, 고속 데이터 압축 및 압축 해제 장치 및 방법
- SharpLZW – C# 오픈소스 구현
- MIT Open Course Ware: LZW 알고리즘을 포함한 강의
- 닥터 돕스 저널의 LZW 데이터 압축 마크 넬슨(1989년 10월 1일)
- 축소, 축소 및 축소: 레거시 ZIP 압축 방법에서는 LZW와 PKZ에서 LZW가 어떻게 사용되었는지 설명합니다.아이피
