I was testing loading different images to a quad when I noticed that jpeg(s) come out distorted. Here it the code. Works fine with a standard png.
File file = new File(filePath);
image = ImageIO.read(file);
this.defaultTexture = new Texture2D(imageLoader.load(image, true));
material.setTexture("ColorMap", defaultTexture);
The jpeg comes out like this. Is there a way to fix this or should I avoid using jpeg(s).
Do not use jpegs, pngs, bmps or any other common formats. Use compression that are supported by devices.
Read this: http://vandaengine.org/an-overview-to-common-compressed-texture-formats/
Google for more.
Anyway, it looks like a bug, which version do you use? 3.0 or 3.1? Never had any problems with jpg in 3.0.
JME 3.1 beta snapshot
However, I don’t recommend to compress UI elements such as texts and icons, because their artifacts are more noticeable.
These indeed are UI elements
So someone from core devs needs to take a look at this.
For UI elements use png. jpg does not have alpha channel which is really useful in any UI/HUD.
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?
I agree with delt0r. Load the image in the standard way and see if it also fails.
By the time you put the image in a Texture, JME is doing nothing special with it. So the image data itself is bad. What is imageLoader?
As far As I remember DesktopAssetsManager uses AWTLoader for jpgs, which uses ImageIO internally.
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.
//test = texture;
this.test = app.getAssetManager().loadTexture(file.getName());
material.setTexture("ColorMap", test);I printed out the getType for both the image and texture however I couldn’t find a getTransparency.
System.out.println(test.getType().toString());
System.out.println(image.getType());
TwoDimensional
5
At this point I’m really thinking I just downloaded some corrupt or oddly made files.
Okay after some additional testing I can confirm it was the images that where bad.