Why do you not just load it directly to texture rather than with ImageIO? I do this and an not seeing any problems. Also what is your geometry and UV texture coordinates?
Yes, but a) it may not be making the naked call, b) it’s not calling some imageLoader object that we don’t know what it is, c) it could be doing additional processing.
The point is that for everyone else in the known universe, loading JPGs in JME doesn’t do that. Nor is JME doing anything strange with the image data that would cause this… ergo: the image data passed to texture is bad already.
Well it looks like there is something manual going on. It’s clearly picking
up the luma channel, so something is wrong with the pixel packing. Jpgs
decode to an odd set of rasters IIRC with imageIO.
While its not a problem that would be missed. So I am still guessing there
is something wrong outside jme.
OP, try writing the BufferedImage back out again as a PNG and see if it’s right.
else if imageLoader is the AWTLoader then it would be interesting to know what image.getType() and image.getTransparency() return.
…and if it is AWTLoader then why not just let JME load the texture as has been suggested? Or is this part of tracking down the issue (which would have been useful info in the first post).
@pspeed Yes , imageLoader is an instance of AWTloader. I’ll load some later and out put the values. I was using AWTloader because some of the images I manually make changes too using Graphics 2d after they are loaded.
I did a test using texture instead of texture2d with the default loader and got the same result.