Beta 4&5, PNGs won't remove background

I created a module with 3.0.17 and everything looks and works great, but when I load it with the beta (4 or 5) all of the PNG images show their white backgrounds.

PLEASE, PLEASE, PLEASE

When you report a possible new bug like this, please provide a link to the module so that we can look into it further.

Regards,
B.

*********** REPLY SEPARATOR ***********

On 8/11/2008 at 7:20 PM Grudunza wrote:


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Hi, Brent. Sorry, I wish I could have linked it, but I was denied permission to publish the module publically. I can probably send it to you privately, though, in the interest of Vassal improvement…

Hi Eric,

I got your PM, but I was unable to download the module from the supplied link. I got a ‘Page Not Found’. Could you please check and resend?

Thanks,
Brent.

Joel,

There is a difference in the way 3.0 and 3.1 is handling the loading of some images. I have sent you one of the images by direct email.

Under 3.0, this image loads into a Basic Piece with a transparent background. Loading the same image in the same way into 3.1 and the transparent part of the image is white.

It is something about the format of the image. In Gimp, If I load this image, it looks normal with a transparent surround. If I select the transparent part, cut it out, then save the image, the image looks the same, but will now load into 3.1 correctly.

B.

Thus spake “Brent Easton”:

I think this images uses bitmask transparency instead of alpha transparency.
I suspect that I know where the problem is.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

The image is indexed 8-bit, with one color specified as transparent. It
appears that the transparent color (which happens to be white) is not
being recognized as transparent.

I thought at first that this was a bug introduced by the work I did two
weeks ago on loading compatible images, but then I tried loading the image
in 3.1.0-beta3, and get at white background there, also—so this problem
has been around for some time.

I now think that either we’re not using ImageIO correctly, or this is an
ImageIO bug. Try loading this image with the following test program:

import javax.imageio.ImageIO;
import javax.swing.*;
import java.io.File;

public class Test {
public static void main(String[] args) throws Exception {
final JFrame frame = new JFrame();
final JLabel label =
new JLabel(new ImageIcon(ImageIO.read(new File(args[0]))));

frame.add(label);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.pack();
frame.setVisible(true);
}
}

What I see is an image with an opaque white background atop a grey panel.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake Joel Uckelman:

This looks a lot like our problem:

bugs.sun.com/view_bug.do?bug_id=6703368


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake Joel Uckelman:

In contrast, the following works properly:

import javax.imageio.ImageIO;
import javax.swing.*;
import java.io.File;
import java.awt.Toolkit;
import java.net.URL;

public class Test {
public static void main(String[] args) throws Exception {
final JFrame frame = new JFrame();
final JLabel label = new JLabel(new ImageIcon(
Toolkit.getDefaultToolkit().createImage(new URL(“file://” + args[0]))));

frame.add(label);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.pack();
frame.setVisible(true);
}
}

That’s obnoxious, as it looks like we have to start using the Toolkit
again for loading images unless we have a way of detecting these images
on the fly.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

But why has only 1 person ever reported this problem? And why does a quick play with the image in Gimp fix the problem?

It sounds more like a problem with the format of these particular images.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

I think when you save the images with Gimp they end up as 32-bit ARGB,
which ImageIO has no problem loading. It’s probably the case that there
are very few 8-bit indexed transparent PNGs in use in modules, which
would explain why we hadn’t heard of this before.

They’re prefectly legal PNGs, so far as I can tell. ImageIO should be able
to load them successfully, so I think this is an ImageIO bug which I’ll
report to Sun.

We can work around this if I can figure out a way to detect when we have
an image of this type, and use Toolkit.createImage() for just those cases.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

So Gimp is incorrectly saving the images in a slightly different format that is fixing our problem?


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Hi Eric,

How did you create the images for this module? What Image program did you use?

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

No, I use them all the time and have never had this problem.

In fact, the images are not indexed at all. I have just loaded up the one I sent you in Gimp and it tells me it is a full RGB image with no indexing. Merely saving the image from Gimp is enough to fix the problem.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake Jeffrey Brent McBeth:

I discovered something interesting just now: If I do nothing more than
open and save the image again in GIMP, whatever that changes is enough
for ImageIO.read() to do the right thing.

It turns out that I was wrong about GIMP saving the image out as 32-bit
ARGB. The image I saved was still indexed 8-bit.

If I compare the two images with ‘identify -verbose’, this is what’s
different between the original (<) and the one saved by GIMP (>):

< Image: /home/uckelman/foo.png

540,543c540,549
< Rendering intent: Undefined
< Resolution: 59.05x59.05
< Units: PixelsPerCentimeter
< Filesize: 2.25781kb

545c551
< Background color: white

My guess is that the change which made the difference is the Background
color entry. Possibly the PNG we’re dealing with here doesn’t actually
follow the standard?


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

I think now there’s something weird about this particular image.

GIMP puts you in RGB mode when you load them, but they’re stored as
256-color indexed when you save, so long as you have 256 or fewer colors.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

I agree

No, Gimp only converts when writing PNG’s, not reading. If you load an indexed PNG image, you get put into Indexed mode, not RGB mode. Try loading back the image you saved in the previous step.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake Jeffrey Brent McBeth:

I’ve already looked at that. The original has no bKGD chunk, but it’s also
possible to get the GIMP to save one which lacks that too, and still loads
in ImageIO properly. So it’s not the lack bKGD chunk that’s the problem.

For the tRNS chunk, none of the working PNGs I save in the GIMP have one.
The original PNG has the following as its tRNS chunk:

00 FF 00 FF 00 FF 37 58 1B 7D 00 00 00 09

This looks odd to me, though I don’t see that it violates the specification.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

Hold on, you’re right. There’s no PLTE chunk in this PNG. It’s 8-bit, but
not indexed.

According to the IHDR chunk, this PNG has colour type 2. This means that
the tRNS chunk, which was these 14 bytes

00 FF 00 FF 00 FF 37 58 1B 7D 00 00 00 09

isn’t legal, as it should be 6 exactly bytes long.

Hence, this PNG is broken.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

I used Corel Photo-Paint to make the PNGs.