Skip to content
This repository has been archived by the owner on May 9, 2020. It is now read-only.

Decoder works great when used in isolation. Does not play with other decoders (such as the image/png/jpg built-ins)? #3

Open
ghost opened this issue Oct 24, 2012 · 6 comments

Comments

@ghost
Copy link

ghost commented Oct 24, 2012

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? ;)

@ftrvxmtrx
Copy link
Owner

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.

@ghost
Copy link
Author

ghost commented Oct 27, 2012

Cheers, good to know! Will give the "import-first" approach a go... in due course ;D

@blezek
Copy link

blezek commented Jun 26, 2015

FWIW, there is a fork that removes the automatic registration of TGA, replacing with a tga.RegisterFormat() function.

https://github.com/dblezek/tga

@pmezard
Copy link

pmezard commented Aug 15, 2015

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?

@dmitshur
Copy link

That makes sense to me.

@Yugloocamai
Copy link

@blezek thanks for that fork, solved my problem

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants