2014-10-14 5 views
2

TIFF 디코더를 작성하는 중입니다. 내가 사용하고있는 LZW 디코더는 디코딩 된 코드 문자열의 버퍼 오버플로를 제외한 모든 LZW 압축 GIF 및 TIFF 이미지와 잘 작동합니다. 필자는 com.sun.media.imageioimpl.plugins.tiff 패키지의 TIFFLZWDecompressor를 테스트하여 "java.lang.UnsupportedOperationException : TIFF 5.0 스타일 LZW 코드가 지원되지 않음"예외를 throw합니다.TIFF 5.0 스타일 LZW 압축의 특별한 점

저는 5.0 스타일 LZW에 대한 특별한 것을 찾기 위해 노력해 왔습니다. 아무도 이것에 대해 어떤 생각을 가지고 있습니까?

참고 : TIFFLZWDecompressor 소스 코드에서 TIFF 5.0 스타일 LZW 압축 지시자는 압축 된 데이터의 첫 번째 두 바이트 {0x00, 0x01}입니다.

답변

2

TIFF 6.0 사양은 말한다 :

개정 5.0의 초안 2에 설명 된대로 LZW 문자 깊이, BitsPerSample에 해당하는 LZW의 버전을 구현하는 것이 가능하다. 그러나이 접근법에는 큰 문제인 이 있습니다. BitsPerSample이 11보다 크면 은 12 비트 최대 코드를 사용할 수 없으며 결과 LZW 테이블은 허용 할 수 없을 정도로 커집니다.

(TIFF6.pdf, 페이지 58 ~ 59)

그것은이 그들이 언급하는 것입니다 수 있습니다.

는 반면에 ... 내 자신의 독자에서 나는 발견

참고 :이 사양의 위반입니다. 그러나 libTiff는 이러한 파일을 읽습니다. TZF 6.0 사양, 13 절 : "LZW 압축"/ "알고리즘", 61 페이지 : LZW 압축 코드는 바이트 순서대로 높은 순서로 저장됩니다. 즉 FillOrder 은 1로 간주됩니다 . 압축 된 코드들은 압축 데이터는 그것이 'II'또는 'MM'파일인지 동일하게되도록 바이트 (되지 단어)로 기록된다. "

것은 약하는 0x00 0x01로 실제로이며 "clear code"를 "reverse"(즉, 바이트 순서에 따라 무시하는 것이 아니라 사양에 따라).

+0

감사합니다. 필자는 fillOrder 문제를 생각하는 경향이 있지만 디코더에 대한 간단한 변경은 그것을 증명하지 못했습니다. 더 테스트해야 할 수도 있습니다 – dragon66

+0

정말 함께 작업을 시작해야합니다.하지만 어쨌든 [LZWDecoder.java] (https://github.com/haraldk/TwelveMonkeys/blob/master/imageio/imageio-tiff/)를 살펴보십시오. src/main/java/com/twelvemonkeys/imageio/plugins/tiff/LZWDecoder.java), 0x00, 0x01이 발견되었을 때 실행되는 호환성 모드가 있습니다. 실제로 구현이 올바른지 확인하기 위해 더 많은 샘플 파일을 사용하면 유용 할 것입니다. 하지만 또 다시 ... 그게 우리가 가진거야. – haraldK

+1

이 경우처럼, LZW 디코딩은 GIF LZW로 완전히 넘어집니다. 조기 코드 크기가 늘어나더라도 이전의 attemps에서 놓친 부분이 있습니다. 어쨌든, 이제 작동합니다! – dragon66

2

TIFF LZW 인코더를 쓰는 동안 최근에 동일한 문제가 발생했습니다. 도구는 이미지를 올바르게 디코딩하는 동안 "구식 LZW 코드"에 대해 불평했습니다. 몇 가지 연구 끝에 LZW 압축기의 구현이 변경되었음을 알게되었습니다. 원래 (구식) 형식은 GIF LZW 압축기와 정확히 동일한 작동 모드를 사용했습니다. 사실, 작동하는 GIF 압축기를 사용하여 많은 노력없이 TIFF 구현에 넣을 수 있으며, 대부분의 TIFF 판독기에서 허용하는 파일을 생성합니다. (내가 찾은 한 가지 주목할만한 예외는 코렐 페인트 샵 프로 X7이었다.)

"이전 스타일"과 "새로운 스타일"의 차이는 두 개의 인코딩 정보에 적용

  • LZW 코드가 기록됩니다 역방향 비트 순서로 스트림.
  • "New-style"은 "old-style"(이른바 "Early Change")보다 한 기호 앞에 코드 크기를 증가시킵니다.

클레버 TIFF 디코더는 비트 스트림의 첫 번째 또는 두 번째 바이트를 검사하여 "구식"인코딩을 감지합니다. 이는 첫 번째 심볼이 항상 0x100의 명확한 코드라는 사실 때문에 가능합니다. 첫 번째 바이트가 0x00이면, 이는 분명히 선행 1 비트 뒤의 8 제로 비트이므로 "구식"입니다. "새 스타일"비트 스트림은 1 비트로 시작하므로 첫 번째 바이트는 0x01입니다.