Decoder works great when used in isolation. Does not play with other decoders (such as the image/png/jpg built-ins)?
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? ;)
The problems lays in the TGA format itself.
For side-effect-only decoders to work, image.RegisterFormat must be called in the decoder's init(). It accepts the header argument, which allows image package choose the right decoder based on the header.
Unfortunately TGA doesn't have one :)
So the only solution I could come up with is importing as _ "github.com/ftrvxmtrx/tga" BEFORE any other image decoder, so it tries using TGA decoder only after all other decoders.
Not sure if it's possible to return some kind of "not so faulty" error from image decoder, so it actually tries other decoders as well.
Cheers, good to know! Will give the "import-first" approach a go... in due course ;D
FWIW, there is a fork that removes the automatic registration of TGA, replacing with a tga.RegisterFormat() function.
https://github.com/dblezek/tga
FWIW, decoder tests do not pass for me with Go 1.5 on OSX. I suppose the assumptions about the package registration order may have been broken during the compiler refactoring. Registering it as a default fallback sounds brittle to me. If TGA format does not lend itself to sniffing, then you should probably not try to do it.
What about integrating @dblezek changes or something similar?
That makes sense to me.
@blezek thanks for that fork, solved my problem