Mac's having trouble displaying maps

I have gotten a couple of people who have asked me to fix my mods because their mac’s won’t display the maps when they start the mod.

Is there a known problem with mac’s and larger map images?

Is there a fix?

Thanks

I do have the same problem with my SPQR / Devils Horsemen / Cataphract modules, created on XP with VASSAL 3.0.

Since I switched to Macbook pro OS X 10.5.7, with VASSAL 3.1.9, I do not see my maps anymore. The problem seems to be my *.png files that I used as map images. In my Conquest of Gaul module, I switched to *.gif and it solved the problem.

However, it would be nice if this had a fix that would prevent me from converting every single maps and charts in all my modules to ‘gif’ in order for Mac players to see those pictures. Note that the counter art, also ‘png’, is displayed correctly at all zoom levels.

I read something on the VASSAL sourceforge about a possible problem with older JAVA JRE not reading some large ‘png’ files correctly although I checked I had the latest version of the JRE and my charts, also ‘png’, are small files and are not displayed either.

Anyone?

Thus spake “freddel”:

This is a problem we’ve been told about many times already, but none of
the developers have a machine where they can reproduce it themselves, so
it’s difficult for us to troubleshoot.

I’m certain this isn’t a bug in VASSAL, though—it’s a problem with
either Java or something Java depends on.


J.


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

Post generated using Mail2Forum (mail2forum.com)

So this is only a problem on Macs? Bummer. I’ve noticed the same problem on my Mac (iMac, Intel core duo). Once I encountered the problem, I started using JPGs for maps. I spent some time today fiddling around with this, to figure out what seems to work well for maps and what doesn’t.

Works:
JPG
24-bit PNG (RGB, no alpha channel)
GIF, with no transparent color defined

Doesn’t work:
32-bit PNG (RGBA, i.e. with an alpha-channel)
Indexed (256-color) PNG, either with or without a transparent color defined
GIF, with a transparent color defined

Apparently, anything with transparency/alpha-channel is a no-go (for maps). GIFs seemed to be OK, as long as they don’t include a transparent color. Somewhat surprisingly, an indexed PNG didn’t seem to work, either with or without a transparent color.

What I found is that maps using the formats that didn’t work rendered horribly slowly if they were scaled at anything other than 1:1. They rendered fine at 1:1. Example: 1400x520 test images took about 60 sec. of CPU time (yes, a full minute!) to render when scaled to 62.5%. On the positive side, once first rendered they are apparently cached, since they subsequently displayed without any delay, at that specific scaling.

Of course, my 1400x520 test images would be a pretty small map! What you might be seeing with maps not appearing is that they are taking a VERY long time to render. If you wait long enough, they might show up. But it might take many minutes. And even then, any parts of the map that are out of the window may need to go through the same process when you scroll over to them.

Fortunately, this problem doesn’t seem to exist with game pieces, or if it does, it’s not nearly as noticeable. I also experimented with some large Game Pieces, using the same 1400x520 images. They rendered acceptably with all of the image formats listed above. Although I did notice that the “High-quality scaling” preference had a noticeable impact. However, that setting didn’t seem to affect the rendering problems with maps.

I also tried charts, and didn’t notice any problems (again, using the same 1400x520 images). I suspect that’s because charts are always rendered at 1:1, AFAIK. However, using a map component for a chart, I had the same problems if scaled other than 1:1.

Unfortunately, I don’t really have a solution to the problem other than changing the graphics files. But hopefully these details will help in some way.

I performed some tests with different file types of large maps.

I converted all my *.png (indexed) into *.gif.

Some maps were displaying, some not. None of the ‘gif’ files had an alpha channel so I was at a loss. File size/image size were not an issue as some large gif’s were loading fine while some smaller ones would give me an ‘image loading error’ VASSAL message.

Under the Finder, any (indexed) image that VASSAL fails to display has the following info:
Color Space: RGB
Alpha Channel: 0
Color Profile: sRGB

Any image that displays fine is lacking the last entry completely.

However, under Gimp, all the images have the same color profile:
sRGB IEC61966-2.1.
But, the GIF images that fail to display show a color profile of 256 while the PNG show 64 and the GIF that work show 64 colors!
Finally to add up to the confusion, the Xee app shows those same PNG to have 256 colors…

We seem to be caught between the alpha channel problem and how the Mac and/or the JRE determines the color properties of an indexed image…This is way above my skills and I did search the web for some Java/Mac bug report but unsuccessfully.

The only thing I found is that the implementation of JSE 1.4.2 ‘fixed’ some problems that Java had in dealing with PNG. I checked my versions and I have 1.4.2, so it must be something else.

Thus spake “freddel”:

Sometime in the next few days I’ll try to come up with a test case for
you guys so we can isolate the problem.

That’s unlikely to be relevant, since you can’t possibly be running VASSAL
with Java 1.4.2. It requires 1.5 or later, which you also have installed.


J.


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

Post generated using Mail2Forum (mail2forum.com)

I’m game. Especially since PNGs are recommended in the FAQ on the VASSAL wiki, and I use a Mac! :slight_smile:

What uckelman said. If you’re using Leopard (OS X 10.5), you should have J2SE 1.5, I would think. I’m running OS X 10.4 (Tiger) and at some point J2SE 1.5 was installed as a software update. Actually, both J2SE 1.4.2 and 1.5 seem to be installed, but it defaults to 1.5. Open Terminal and type “java -version” and see what it says. Or check the VASSAL errorLog file (probably in a VASSAL directory in your home directory) - the Java version is reported at the beginning of the errorLog.

Hmmm. I have not seen that “image loading error” message. Maybe the difference is Mac OS X 10.5, vs. my 10.4? Email or PM one of the bad files to me and I’ll give it a try.

I’m using GraphicConverter (mac-specific app) to fiddle with image files. I don’t have X-Windows installed, so can’t run Gimp. None of my images had a color profile. I tried adding color profiles to my PNGs, and they worked the same as before, and no error message (rendered slowly when the map was scaled, except for RGB PNG). I couldn’t add color profiles to GIFs - neither Preview nor GraphicConverter would do it.

For your case with Gimp, could it be that Gimp is using that sRGB profile as a default for images that don’t specify a profile?

Regarding GIFs and color profiles: I did a little research on the PNG and GIF formats. Wikipedia has a fairly good, detailed entry for PNG, less so for GIF, plus links to the specs. As I understand it, PNG specifically supports embedded color profiles, but the GIF spec does not. The GIF format does have a way it could be done, but there would need to be a spec to define how to encode the color profile. You are running the newer OS, so perhaps there is some support for color profiles in GIFs, but the tools I’m using won’t do it.

In this case, by “color profile” I presume you referring to the size of the color palette? A color profile is an entirely different animal. I d/l’ed and checked Xee - it showed “256 colors” for both a 256-color and a 16-color GIF, so I suspect it shows 256 for any indexed format. Other apps may show different information. “64” for a PNG or GIF is probably the actual size of the color palette defined in the file (it doesn’t have to be 256, as long as no pixel values exceed the bounds of the palette). I have no clue why a GIF with a 256-color palette wouldn’t work and 64-color would. My 256-color GIFs work (as long as there’s no transparency).

Now that I’ve been looking at this with excruciating detail :slight_smile:, one difficulty I’m having is ensuring my test images are formatted the way I expect. Different tools will format the image files differently, and GraphicConverter seems to be a bit inconsistent at times. Unfortunately, the only way I can be certain is to inspect the image file with a hex editor. Ugh.

Thus spake “mluscher”:

I’ve built a test case for you guys to try:

nomic.net/~uckelman/tmp/vass … getest.zip

To run it:

  1. Unzip it somewhere.
  2. In a terminal, cd to the mac-imagetest directory where you unzipped it.
  3. Run each of the following:

java Test someimage.png 0
java Test someimage.png 1
java Test someimage.png 2

You should see some diagnostic information in your terminal, followed by
a window which should show the image.

Try this with some of the images which loaded slowly for you and (and
some which didn’t) and let me know the results.


J.


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

Post generated using Mail2Forum (mail2forum.com)

Something that would be very useful would be for someone (!) to create (or find) a set of reference images that cover the range of all the different types of images Vassal supports. We could include it in the Vassal source tree. It would be very useful to assist with diagnosing these sort of problems.

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 have a bunch of images which have been problematic in the past. I’m sure
they don’t cover all of the possibilities, but I’ll make a note of tracking
them down. But don’t rely on me to do this soon.


J.


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

Post generated using Mail2Forum (mail2forum.com)

A quick look found schaik.com/pngsuite


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

Post generated using Mail2Forum (mail2forum.com)

Got it. I’ll give it a try.

My test results:

These files scale slowly when used for maps in VASSAL (hopefully the file names are descriptive enough of the format):

“RGBA opaque.png” (alpha = 255 everywhere)
Test 0: Reading: TYPE_CUSTOM, Converting: TYPE_INT_ARGB
Test 1: TYPE_CUSTOM, TYPE_INT_RGB
Test 2: TYPE_CUSTOM, TYPE_INT_ARGB_PRE

“RGBA transparent.png” (has transparent and semi-transparent regions)
Test 0: TYPE_CUSTOM, TYPE_INT_ARGB
Test 1: TYPE_CUSTOM, TYPE_INT_RGB, rendered image has a black background.
Test 2: TYPE_CUSTOM, TYPE_INT_ARGB_PRE

“RGB transparent color.png” (no alpha channel, but a single transparent color specified)
Test 0: TYPE_CUSTOM, TYPE_INT_ARGB
Test 1: TYPE_CUSTOM, TYPE_INT_RGB
Test 2: TYPE_CUSTOM, TYPE_INT_RGB
Neither the tests nor VASSAL render the transparent color as transparent!

“indexed no transparency.png”
Test 0: TYPE_BYTE_INDEXED, TYPE_INT_ARGB
Test 1: TYPE_BYTE_INDEXED, TYPE_INT_RGB
Test 2: TYPE_BYTE_INDEXED, TYPE_INT_RGB

“indexed transparent.png” (has color table and “alpha table”)
Test 0: TYPE_BYTE_INDEXED, TYPE_INT_ARGB
Test 1: TYPE_BYTE_INDEXED, TYPE_INT_RGB, rendered image has a black background.
Test 2: TYPE_BYTE_INDEXED, TYPE_INT_ARGB_PRE

“transparent.gif” (single transparent color specified)
Test 0: TYPE_BYTE_INDEXED, TYPE_INT_ARGB
Test 1: TYPE_BYTE_INDEXED, TYPE_INT_RGB, rendered image has a black background.
Test 2: TYPE_BYTE_INDEXED, TYPE_INT_ARGB_PRE

These files scale fine in VASSAL:

“RGB.png” (no alpha channel)
Test 0: TYPE_CUSTOM, TYPE_INT_ARGB
Test 1: TYPE_CUSTOM, TYPE_INT_RGB
Test 2: TYPE_CUSTOM, TYPE_INT_RGB

“opaque.gif” (no transparent color)
Test 0: TYPE_BYTE_INDEXED, TYPE_INT_ARGB
Test 1: TYPE_BYTE_INDEXED, TYPE_INT_RGB
Test 2: TYPE_BYTE_INDEXED, TYPE_INT_RGB

“RGB.jpg”
Test 0: TYPE_3BYTE_BGR, TYPE_INT_ARGB
Test 1: TYPE_3BYTE_BGR, TYPE_INT_RGB
Test 2: TYPE_3BYTE_BGR, TYPE_INT_RGB

Thus spake “mluscher”:

Were any of these particularly slow to load?


J.


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake “mluscher”:

What I learned from this is that the system-preferred storage type for
transparent images on Macs is TYPE_INT_ARGB_PRE, not TYPE_INT_ARGB like
I thought it was (and is on Linux and Windows).

I’ve uploaded a build I’d like you try, 3.1.10-svn5862:

nomic.net/~uckelman/tmp/vass … macosx.dmg

Do you see the same problems here?

Could you send me this image? This is an entirely different problem—there
are certain kinds of images which ImageIO doesn’t load properly. I thought
I’d written workarounds for all of them already.


J.


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

Post generated using Mail2Forum (mail2forum.com)

None were slow to load in the Test program, nor in VASSAL as long as the map was scaled at 100%. It’s rescaling the map via the “Zoom Capability” component thats slow.

Yes, same problems.

That’s sorta interesting. Perusing Apple’s developer docs a bit leaves me a little confused about whether or not pre-mutiplied alpha is preferred. Tho I imagine it could depend on which API as well. Also, I’m not running the latest version of OS X - I’m using 10.4 - so it might be good to see what results OS X 10.5 produce.

Nevertheless, if that’s the change you made in the svn5862 build, it didn’t seem to have a noticeable effect.

I suspected it might be a different problem. I only thought of that particular PNG variation when I was trying your tests, and figured I’d give that a try as well. I’ll email the file.

Thus spake “mluscher”:

I was hoping that you’d find that the transparent images which were not
loaded as TYPE_INT_ARGB_PRE would be slow to paint. It’s vexing that
that’s not the case.

It is, because it’s the type you get when you ask GraphicsConfiguration
for its preferred type.

Do you have memory-mapped images turned on or off? (Look in the preferences.)

Got it, thanks. I’ll have a look at this tonight.


J.


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake “mluscher”:

The image loads properly for me. What version of Java are you using?


J.


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

Post generated using Mail2Forum (mail2forum.com)

1.5.0_19 according to java -version and VASSAL error log.

I just “discovered” this option (i.e. tried it for the first time - it’s off by default), and it results in some significant differences. I think the changes are for the better mostly.

With memory-mapped images on, I found that maps using GIF or PNG images take longer to render into the window the first time at 100% scaling. But rescaling to different sizes is fast, even for images with transparency. This is essentially opposite of the behavior when memory-mapped images is off (transparent images draw quickly at 100% but rescale VERY slowly). However, with the option on, the loading/rendering time at 100% is an improvement over the very slow re-scaling with memory-mapping off, so I’d call this an improvement. OTOH, turing this option on also slows down initial rendering (at 100%) of formats that previously worked fine (RGB PNG, GIF with no transparency).

It’s kind of funny: with memory mapping on, if I give a map zoom capability and set the initial zoom to 0.9999 it draws pretty quickly, but if the initial zoom is 1.0, it’s slow!

I did see some inconsistency with a couple of files using transparent, indexed formats (GIF, PNG). Basically, with memory-mapping turned on, they still rendered like they did with memory-mapping off. I suspect this may have been due to the size of the image: what’s the definition of a “large” for the memory-mapping option?

Thus spake “mluscher”:

This matters for the following reason: There’s a bug in all versions of
Java 1.5 which causes the preferred method for loading PNGs (ImageIO)
to choke on PNGs which contain iTXt chunks. The workaround I wrote only
checked whether you are using Java 1.5, not whether there are actually
any iTXt chunks in the image. If there aren’t, then it might still be
OK to use ImageIO, depending on passing the tests for avoiding another
bug, this time one which affects all versions of Java of which I’m aware.

I’ve fixed the overzealous test in the workaround, and uploaded a build
for you to try, 3.1.10-svn5869:

nomic.net/~uckelman/tmp/vassal/

Please let me know whether this fixes the problem with the bad image for
you.

This is the expected behavior. What’s happening is that on the initial read,
some of the uncompressed image data is being written out to disk.

Again, this is what I’d expect to see, since for rescaling VASSAL might need
pull some data from disk.

Right now, “large” means “is a map image”.


J.


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

Post generated using Mail2Forum (mail2forum.com)