Transparent image as texture causing black background

Questions
, ,
1

I have a Cube, with a Texture. I’m applying a transparent PNG as the Texture. For some reason though, when I apply the texture, it adds a black background. This happens for literally no other images except this one.

Pen: https://codepen.io/JasonStoltz/pen/NaBOGm

And in fact, if I download the image and re-upload the exact same image and just access it a different way, it works fine:
Pen: https://codepen.io/JasonStoltz/pen/QqBVYY

So literally, I can replace those images with any other PNG with transparency and it works fine. It’s just this one image that gives me issues. Any thoughts on what could cause this?

UPDATE:
The one difference that it could be is the file extension. In the first image, the file extension is .jpg even though the image is in fact a png. Could be that Three.js is infering (incorrectly) that the image is a jpg based on extension, rather than by looking at the content type.

2

I figured this out. Three.js is looking at file extension first to determine the image type, not content type. If i simply remove the extension all together, everything works fine:

3

Yes, three stores JPGs as RGB format rather than RGBA format to save memory and uses the file extension to determine the type since this is the easiest way to check. So any Alpha (transparency) data in the file will be discarded.

Why are you saving PNG files with a .jpg extension?

4

@looeee We’re saving it with a .jpg because the image sitting on the server is a .jpg. It gets converted to a PNG by a CDN sitting in-between. So, while the source image that we’re requesting has a .jpg extension, the content-type of what is actually returned is image/png.

Three.js could probably just as easily look only at the content-type of the image, rather than inferring it’s format from the file extension.

5

Does it get transparency data added as well?

Also, why aren’t you changing the file name while doing the conversion? That would be good practice.

6

It does.

And I’m not changing the extension bc that’s just not how the system works
and I’m not jumping through hoops just to get the extension to match the
content type. It’s just unnecessary in my case. The content type should be
the canonical source for determining file type, not the extension, imo.

7

OK, fair enough. If you don’t like the way it currently works you can always change it yourself anyway, or raise an issue on github.

The relevant check is here:

8

Thanks for the reply and help looee! I ended up just dropping the extensions from all of my urls for now to work around this.