Originally Posted by
carmangary
4 & 5 aren't extensions in the way that 2 & 3 are but I wouldn't go so far as to call them a different file format. It isn't like you have to totally rewrite code to read them. You only have to slightly change existing code. (We're talking only a few lines of code). So, for that reason, I would say they are very much extensions of the current formats. The only real difference being that 0 & 1 have an index for a color while 4 & 5 explicitly define the color. 0 & 1 seem like a natural thing to do when you have only a small fixed number of colors that can be used. 4 & 5 seem natural when the colors are expected to be unique and within a very large range. 3 doesn't seem natural at all. I consider it nothing more than a hack and based on it never coming to light I think others felt that way as well.
I'll give you credit in that your idea of using a combination of formats 3, 2 & 0 or 1 to be able to specify frames with > 256 colors while still being backwards compatible is clever. But, it's a bloated approach and not likely to actually work since the legacy apps that were written before format 3 will more than likely not handle format 3 and not load the files at all. I know a well written app should skip unrecognized format headers but I am not even entirely certain that will work with format 3 because if the color bytes happened to spell "ILDA" then the software could be fooled into thinking it was at the beginning of a frame.
Format 3 was fixed when they decided it wasn't going to be a format.