commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: svn commit: r1551026 - in /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress: archivers/zip/UnshrinkingInputStream.java compressors/z/AbstractLZWInputStream.java compressors/z/ZCompressorInputStream.java
Date Wed, 18 Dec 2013 08:21:22 GMT
On 2013-12-17, Damjan Jovanovic wrote:

> I am wondering how far this can be taken. TIFF's LZW uses an
> end-of-information code after the clear code, allows both
> little-endian and big-endian packing of bytes, and increases the code
> size one step too early. Is it even possible to generalize LZW (any
> further), and would it be a good idea, given how uniquely it's
> implemented in each file format?

TBH my changes were driven by the code and not by actually understanding
LZW :-)

The end-of-information part could probably be dealt with in the subclass
specific implementation of decompressNextSymbol and increasing the code
size may happen in addEntry, not sure.  As for endianess, Emmanuel
briefly mentioned a BitInputStream he had for the IMPLODE algortihm on
IRC, maybe this could be used inside readNextCode and hide the concrete
endianess?

Like you I'm not actually sure it would be worth the effort if this base
class became the only reason for making imaging depend on compress.
Rather not.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message