Vassal Won't Process Image Files?????

[Stiglr]

This is becoming a worrisome trend, and I do NOT LIKE IT ONE BIT!!!

While trying to edit modules and swap out maps, Vassal is now displaying the Processing Image Tiles dialog .... and it never gets past 0% which would happen with varying speeds before. It just sits there, like a stale fart.

Then, the interface comes up and, when you try to launch a new game, shows Bad Data for the map (which seemingly never loaded in the first place). What's going ON with this???? I am not doing anything different than I've done while editing modules for YEARS now.

I don't know if this makes any difference whatsoever, but the last times this has happened, I've been editing a module that had Vassal-generated pieces instead of scanned artwork.

I'm not getting any crashes or problems saving, so there's no bug report.

[JoelCFC25]

Have you tried launching VASSAL, then immediately going to Tools -> Clear Tile Cache? Note that after doing this, tiling will occur one time for modules that wouldn't normally need it done.

Just wondering if something got messed up in the tile cache.

[Stiglr]

Yes, but the program HUNG leaving an inoperative module list screen.

[zgrose]

The Error Log in the Help menu often has useful information in it.

[JoelCFC25]

If using the built-in command to clear the tile cache isn't working, the manual equivalent would be deleting the contents of the tiles folder altogether.

It's found at: C:\Users\*your-username-here*\AppData\Roaming\VASSAL\tiles

[Stiglr]

Thank you! I was snooping around in the Vassal root directory and couldn't find anything....

[Stiglr]

Hmmmm. I managed to get a Clear Tile Cache command completed, but now, the file stops at 11% of the tiling process. I'm now looking into possible file corruption for the map file I'm trying to swap out, but can't imagine why that file would be problematic....

[JoelCFC25]

Did you create the image file yourself or did it come from someone else? If you link it I can throw it in a test module and see if I can get it to tile.

[Stiglr]

Figured it out. The map was an export from Illustrator, but it was based in CYMK, instead of RGB. Even though the file was always a .jpg, the CYMK didn't play well with Vassal. Once I re-exported a RGB .JPG, the file would load properly.

Whew. Sonething else to remember when building modules.

Thanks for the help in tracking down this issue

[JoelCFC25]

Ah yes--the CMYK model is largely for physical printing applications where you need screen-to-paper color fidelity. Stick with RGB for things that will always remain digital and be displayed on screens...I'm pretty sure this yields a much broader range of potential colors anyway.

[uckelman]

Thus spake Stiglr via messages:
> Figured it out. The map was an export from Illustrator, but it was based
> in CYMK, instead of RGB. Even though the file was always a .jpg, the
> CYMK didn't play well with Vassal. Once I re-exported a RGB .JPG, the
> file would load properly.
>
> Whew. Sonething else to remember when building modules.
>
> Thanks for the help in tracking down this issue

Oh, that's an interesting problem. Would I be able to get a copy of the
offending image?

--
J.

[Stiglr]

I suppose I could get you one. What's the best way to transfer it? Email, DropBox, or....?

[uckelman]

I'd still appreciate having a copy of that image. I can't seem to create any JPEGs with CMYK profiles myself.

[uckelman]

Never mind, I managed to create a JPEG with a CMYK color profile. (These must be extremely rare in the wild.) The stack trace the tiler produces is this:

Code: Select all

VASSAL.tools.image.ImageIOException: images/scale_cmyk.jpg
   at VASSAL.tools.image.ImageIOImageLoader.wrapImageIO(ImageIOImageLoader.java:463)
   at VASSAL.tools.image.ImageIOImageLoader.load(ImageIOImageLoader.java:376)
   at VASSAL.tools.image.tilecache.FileArchiveImageTiler.run(FileArchiveImageTiler.java:77)
   at VASSAL.tools.image.tilecache.ZipFileImageTiler.main(ZipFileImageTiler.java:173)
Caused by: javax.imageio.IIOException: Unsupported Image Type
   at java.desktop/com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(JPEGImageReader.java:1139)
   at java.desktop/com.sun.imageio.plugins.jpeg.JPEGImageReader.read(JPEGImageReader.java:1110)
   at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468)
   at VASSAL.tools.image.ImageIOImageLoader$1.run(ImageIOImageLoader.java:483)
   at VASSAL.tools.image.ImageIOImageLoader$1.run(ImageIOImageLoader.java:469)
   at VASSAL.tools.image.ImageIOImageLoader.wrapImageIO(ImageIOImageLoader.java:428)
   ... 3 common frames omitted


There's not much we can do about the root cause, which is that Java's JPEG decoder has no idea what to do with a CMYK color profile.

[Stiglr]

Indeed. I didn't think it would make a difference; I thought if it was a "viable" .jpg (or .png, for that matter) it would play fine with any app that treated such files as valid. Live and learn, eh?