Beta 4&5, PNGs won't remove background

[Grudunza]

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.

[Brent_Easton]

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:

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.

---

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

Post generated using Mail2Forum (mail2forum.com)

[Grudunza]

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…

@Brent Easton

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:

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.

---

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

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

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.

[Brent_Easton]

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.

[uckelman]

Thus spake “Brent Easton”:

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 par
t, cut it out, then save the image, the image looks the same, but will now lo
ad into 3.1 correctly.

B.

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)

[uckelman]

Thus spake “Brent Easton”:

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 par
t, cut it out, then save the image, the image looks the same, but will now lo
ad into 3.1 correctly.

B.

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)

[uckelman]

Thus spake Joel Uckelman:

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:

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)

[uckelman]

Thus spake Joel Uckelman:

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.

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)

[Brent_Easton]

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.

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)

[uckelman]

Thus spake “Brent Easton”:

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

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.

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

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)

[Brent_Easton]

I may be able to answer the Gimp question. The Gimp PNG plugin is
partially
broken on specific types of palettized transparency (the feature was
implemented with respect to GIF transparency and they never fixed it)

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)

[Brent_Easton]

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)

[Brent_Easton]

But why has only 1 person ever reported this problem? And why does a

quick pl

ay with the image in Gimp fix the problem?

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.

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)

[uckelman]

Thus spake Jeffrey Brent McBeth:

I may be able to answer the Gimp question. The Gimp PNG plugin is partially
broken on specific types of palettized transparency (the feature was
implemented with respect to GIF transparency and they never fixed it)

Jeff

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

Image: /home/uckelman/bar.png

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

Rendering intent: Saturation
Gamma: 0.45455
Chromaticity:
red primary: (0.64,0.33)
green primary: (0.3,0.6)
blue primary: (0.15,0.06)
white point: (0.3127,0.329)
Resolution: 72x72
Units: Undefined
Filesize: 2.32031kb

545c551
< Background color: white

Background color: rgb(1,1,1)

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)

[uckelman]

Thus spake “Brent Easton”:

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

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

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

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)

[Brent_Easton]

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

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

I agree

In fact, the images are not indexed at all. I have just loaded up the

one I s

ent you in Gimp and it tells me it is a full RGB image with no indexing.

Mere

ly saving the image from Gimp is enough to fix the problem.

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.

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)

[uckelman]

Thus spake Jeffrey Brent McBeth:

the bKGD chunk (the background color) that Joel is seeing added by the GIMP
is simply an optional chunk that tells a renderer what color to use as a
background if the renderer doesn’t have anything else. You can change which
background color gets used in the GIMP just be setting the background color
in your chooser. You can suppress the saving of that value by not selecting
“Save background color” in the Save as PNG dialog.

Transparency can happen in two different ways in a PNG file. It can be
encoded directly into the color (in the IHDR), or in a seperate tRNS
chunk.

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)

[uckelman]

Thus spake “Brent Easton”:

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

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)

[Grudunza]

I used Corel Photo-Paint to make the PNGs.