Remember the problem we had with Sun’s ImageIO PNG decoder being unable to
correctly read transparency for PNGs with 8 bits per channel and color type 2?
I wrote a workaround for that which shunts those PNGs off to the Toolkit PNG
decoder, which can read them successfully.
Well, tonight somebody sent me an 8-bit type-2 PNG which causes the Toolkit’s
PNG decoder to throw an Exception which it swallows silently, so that you get
only a null back for the returned Image. I haven’t figured out what we need to
detect here in order to prevent this yet… Must be some feature of the PNG we
can spot beforehand. Of course, I’m not sure what we’re supposed to do if the
Toolkit chokes and ImageIO doesn’t render it properly.
Why can’t Sun provide a working PNG decoder?! It’s not that hard.
I now know exaclty what the problem is and have solved it. What was wrong
was a combination of three things:
There’s a program called SplitImage which some module designers use to
slice countersheet images into individual counter images. This program writes
broken PNGs. In particular, it writes 3-byte tRNS chunks for color type 2
images, instead of 6-byte ones like it should according to the standard.
We use Toolkit.createImage() to load color type 2 images instead of
ImageIO.read() because the latter doesn’t handle tRNS chunks for those images
correctly. The PNG decoder used by Toolkit.createImage() is less forgiving
than the one used by ImageIO.read(), and returns a bogus Image with negative
dimensions if you feed it a broken PNG (which is not documented, BTW).
However, because it does return an Image (instead of null) and we never
considered the possibility that it would return a junk Image, we end up
converting it to a junk BufferedImage which has a null ColorModel—and that
causes an NPE somewhere down the line.
So, I’ve added some additional code to ImageUtils.getImage() to check for
the case where Toolkit.createImage() fails, and in that case we log that
the PNG being loaded is broken and fallback to ImageIO.read() so that we
can display something which resembles the intended image.
This sounds like a utility we could/should include in VASSAL. It’s probably one of the most common things module designers do. It’s not terribly hard either.
This also begs the question: Why aren’t people using ImageMagick? Is it not available for Windows?
In the GIMP, you set guides where you want the cuts, and then select
Image > Transform > Guillotine.
This is pretty much trivial with ImageMagick, so long as you can specify
the cuts in a regular way.
These are both freely available, and anyway are generally useful tools for
module designers. My feeling is that we will not be able to implement
something which does it better than either one of them, and so the effort
would be entirely wasted. We should instruct people on how to use the tools
which already exist rather than duplicating them badly ourselves.
Module creation tutorials need to mention these methods.
Raises the question, yes. (It doesn’t beg the question because you’re not
assuming the thing you’re trying to demonstrate. Sorry, that particular
misuse bugs me.)
I don’t know why people don’t use ImageMagick for this. I believe it is
available for Windows.
It would be a good thing to have a turorial which showed how to use
ImageMagick for module creation; also one which shows where the relevant
features are in the GIMP.
Because those of us with CS3 or Corel feel those programs are better perhaps?
From: Michael Kiefte mkiefte@dal.ca To: VASSAL Engine Forums Mailing List messages@forums.vassalengine.org Sent: Wednesday, January 21, 2009 7:44:05 AM Subject: Re: [Developers]Sun’s PNG decoders suck
This sounds like a utility we could/should include in VASSAL. It’s probably one of the most common things module designers do. It’s not terribly hard either.
This also begs the question: Why aren’t people using ImageMagick? Is it not available for Windows?
Probably Adobe CS3 suite: Photoshop & Illustrator being the most useful components for image and graphics work.
Gimp is similar to Photoshop. ImageMagick is a bit different, being fundamentally a command-line tool. And there’s also InkScape, which is more Illustrator like. All of these are free, whereas Adobe charges a fair amount for their (excellent) tools.
SplitImage is an excellent program that does nothing except cut up images, so it has a number of features that make it a much better choice than either GIMP or ImageMagick to do the actual cutting.
I use it all the time, but always transform the cut images afterwards by running them through ImageMagick via an auto-generated script to crop, scale and add a border. This fixes any problems in the images (lucky for me!). There is only a problem where people use the split images directly in a module.
This leaves you with a million new images that you must now individually name and save. This is extremely painful. The average counter sheet has some 200 counters. This is not a method I would recommend to my worst enemy. SplitImage names all of the split images for you using a user supplied prefix and a counter and saves them all to a folder.
Having processed close to 50 countersheets sourced direct from the artist over the last year or so, I have yet to find one where you could specify the cuts in a regular way.
SplitImage allows you to drag guidelines (similiar to the Gimp guides), or to specify a regular grid, that you can then modify manually for an exact fit.
SplitImage is far superior to any other tool, with the caveat that you must resave the images using another image program. I’m adding this caveat to the FAQ pages.
I’m with Michael a bit on this one though, I think it would be fairly easy to a write a tool for the module editor to do this, using SplitImage as the spec. Perhaps we could even provide a basic front-end to ImageMagick to allow cropping, scaling, bordering etc. and then pump the results into my new Mass Piece Loader to have the counters auto-magically generated?
If that’s your sole complaint about using GIMP for this job, then it’s easily
addressed. What you need is a Script-Fu script which will name and save all
of the resulting images for you. I haven’t looked for one, but I wouldn’t
be surprised at all if one existed already. If there isn’t one, then writing
one would be a better use of our efforts and far more efficient than creating
a custom program for chopping images—such a script wouldn’t run to more
than a few dozen lines.
Have you done a lot of games where there is a mix of counter sizes all on
one countersheet?
I did some looking around, and discovered that a Script-Fu scirpt isn’t
even necessary for this—it turns out that neither of us looked in the
right place in GIMP. Guillotine does give you all of the pieces as open
images. If you want them all saved with a given prefix instead, then you
want Filters > Web > Slice.
Slice does exactly what you requested. So, again: I contend that there
is no need for us to create such a thing ourselves.
No, none, but between gutters and artists not feeling the need to be pixel perfect, I rarely find a counter sheet that you can place a fixed grid over.
I agree. I think it’s probably going to be a lot easier to do in ImageMagick,
especially if you’re going to to several sheets with the same layout or if
you’re doing a bunch of other scripted processing after cutting the sheets.
Actually, my argument was that SplitImage wins the ease of use contest hands down, followed by Gimp/Slice (It is practically impossible for the average Windows user to install it), followed by ImageMagick running a long way last
Would you like to find a way to contact the author of SplitImage, then, so
he can fix his bug? I’ve tried, but the only email address I found on his
site (which seems not to have been updated since 2005) bounces.
