I'm pretty sure (but not 100% convinced as it's possible I'm misunderstanding something) that rgb32_top_left_rle_colormap.tga isn't actually a valid TGA file.

I've run it through TGAPACK.EXE from Truevision's TGA Utilities Package (with the -unpack option and also having removed the footer as it doesn't like footers) and the resulting file has indices out of the range of the colour map. Some TGA loaders are giving an error related to this, but I've seen a lot of incomplete and broken TGA loaders over the past couple of weeks, so I'm not reading too much into that. It's completely possible that the image would work fine if someone tried loading it on an actual Truevision card. If so, I'd be thankful for an explanation of what's going on.

Go already supports Palette and Gray models, so at least some colormapped/monochrome images can be stored in Go without much convertion. Takes less space too.

The TGA decoding itself works flawlessly, awesome work.

Now, my issue... it's really quite strange!

So first off, with this use-case A it works great: I have one Go program where both image/png and ftrvxmtrx/tga are imported directly (not "anonymously" via _ underscore). It just converts TGAs to PNGs --- so decodes TGA and encodes PNGs both directly, without Go's "automagical looking for the registered decoder". All works fine, source here

Now I have another use-case B which i can't seem to get working properly with the tga package:

• So I have a simple texture loader that imports both image/jpeg and image/png as unnamed/anon _ (underscore) packages and then later does a simple image.Decode()
• This simple loader works in two test apps that both load jpg and png textures (both local and over http). image.Decode finds the right decoder just from the byte stream / io.Reader supplied to it
• If I just add ftrvxmtrx/tga as an unnamed/anon _ (underscore) package to the above simple loader, and don't even attempt to load TGAs (ie. the two test apps remain unchanged and still only attempt to load jpg and png files!) none of those get decoded properly anymore.

So I must conclude: just importing tga unnamed/anonymously/side-effect-only screws up all other registered image decoders. Direct named import however does not seem to affect at least other encoders (not sure about other decoders, not a use-case right now).

(Note since I am in OpenGL my geometry just remains black but I verified that just importing ftrvxmtrx/tga as _ kills the whole image.Decode() functionality, removing the tga import all textures get decoded and loaded again perfectly.)

So not sure if tga is supposed to work as an unnamed / side-effect import like the other decoders or only directly... any thoughts? ;)