Wells LZW, from what I understand is basically a command based compression method, as opposed to say LZ77. Data is broken up into 9 bit lengths and read one at a time. The first code in any data should always be 0x100 which is the command called CLR. Codes that are between 0x00-0xFF are uncompressed colors, and codes between 0x100-0x107 are commands. I'm still in the process of understanding how each command works but even my crappy explanation makes better sense than the "proper" ones I've found on the internet. Once have it figured out, I'll try and explain how I did it
I think I'm starting to understand LZW better now. For a gif, the initial table of values is from 0x0-0x101...0x0-0xFF obviously being your 256 colors, and 0x100 and 0x101 are reserved for "CLR" and "END" commands respectively. Any code greater than 0x101 points to the extended part of your table which gets updated as you go through the file. A code value of 0x102 basically means the first color 0 repeated twice, a value of 0x103 is the first color and the second color (ie 0, 1) and so on.
The really confusing part in all the documentation is all this "string" crap they go on about, like one author claimed that every code could be translated into a string, even though string character don't start until 0x30 in terms of bytes, which makes no sense to me. So instead I'm using a double byte array for my "string table". I'm no expert, but honestly how can comparing strings be reliable when doing something like this? Anyways with luck the route I'm taking will just work and I can move on and get GIFs out of the way...
I also attempted at adding PNG support (in which to further add APNG support), but again I got stuck on the compression part, DEFLATE being significantly harder for me to make sense of compared to horrid little LZW.
However I really like the file structure of the PNG, it stores each piece of data in its own chunk, allowing for custom chunks to be added without crippling support with earlier versions. In the future I think making up my own custom formats using this chunk structure may be a much better way at manipulating files such as grouped ones like NCLR, NCGR, NSCR, NCER, NANR. My app works in a similar way when handling multiple types of data, it checks if combinable files are presently stored in memory and then loads them together. Also having a custom format, would allow me to retain a lot of the data that often gets lost when converting custom formats to pc based ones, especially with ones like mappers and sprite cells. It's just an idea at the moment though.