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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
