0
왜 LZW 대신에 LZ77 DEFLATE가 허프만 인코딩을 사용합니까? 최적의 조합에 대해 뭔가가 있습니까? 그렇다면 LZW의 출력 특성이 LZW 나 다른 방법보다 전체적으로 허프만 압축에 더 적합합니까? LZ77과 허프만 함께 작동하는 방법의DEFLATE 메서드 추론
A
답변
0
LZW는 LZ77이라고 부르는 첫 번째 스테이지와 마찬가지로 반복되는 문자열을 활용하려고합니다. 그런 다음 정보를 엔트로피로 코딩하는 일이 불량합니다. LZW는 현대적인 접근 방식으로 완전히 대체되었습니다. (GIF 형식의 레거시 사용 제외) LZ77에서 리터럴 및 성냥 목록을 생성하면 LZW가 활용할 수있는 것이 없으므로 거의 완전히 비효율적 인 엔트로피 코더가됩니다.
+0
허프만 인코딩과 같은 역할을 수행하는 다른 압축 방법이 있습니까? 높은 빈도의 문자를 사용하는 이점이 있습니까? 허프만 인코딩이 최적 인 것으로 입증 되었습니까? –
+0
예, 여러 가지가 있습니다. 예 : 산술 코딩, 범위 코딩 및 유한 상태 엔트로피는 속도면에서 더 나은 압축을 제공합니다. –
+0
압축의 성능이 압축의 크기보다 더 중요한 이유는 무엇입니까? 성능의 차이가 위대합니까? 또한 이러한 다른 방법을 살펴 보겠습니다. –
0
Mark Adler could best answer this question.
세부 사항은 몇 가지 세밀한 조사가 필요합니다. 원시 데이터가 일련의 문자 및 특수 길이, 거리 쌍으로 변환되면 이러한 요소는 호프만 코드로 나타내야합니다.
아니요, 표준 용어가 아니고 반복해서 읽으려는 지점을 "신호음"비트로 시작하십시오. 결국 발신음은 특정 전화로 매핑되는 일련의 번호를 지정하기 시작할 수있는 곳입니다. 그래서 처음부터 "발신음"이라고 부릅니다. 다이얼 톤에서 문자, 길이 - 거리 쌍 또는 블록의 끝 세 가지 중 하나가 이어질 수 있습니다. 가능한 모든 문자 ("리터럴"), 가능한 길이의 범위를 나타내는 요소 ("길이") 및 특수 end-of-block 표시기가 모두 하나의 알파벳으로 병합되는지 여부를 알 수 있어야하므로 . 이 알파벳은 호프만 나무의 기초가됩니다. 이 알파벳에 거리를 포함시키지 않아도됩니다. 거리를 따라 곧바로 나타날 수 있기 때문입니다. 리터럴이 디코딩되었거나 길이 - 거리 쌍이 디코딩되면 우리는 또 다른 "다이얼 톤"지점에 있으며 다시 읽습니다. 물론 블록 끝 심볼을 얻었 으면 다른 블록의 시작 부분이나 압축 된 데이터의 끝 부분에 있습니다.
길이 코드 또는 거리 코드는 실제로 기본 값을 나타내는 코드 일 수 있으며 기본 값에 추가 할 정수를 형성하는 추가 비트가 뒤 따릅니다.
...
길고도 짧은 이야기. LZ77은 중복 제거 기능을 제공합니다. 허프만 코딩은 비트 감소를 제공합니다. It's also on the wiki.
그들은 범위 코더를 백엔드로 사용할 수있었습니다 (하지만 속도가 느리고 비트 스트림 내부에 확장 비트를 두는 것이 귀찮습니다) 또는 오늘날 ANS 일 것입니다. – harold