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.
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.
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
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…
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.
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.
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.
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?
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:
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.
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?
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?
It would be charitable to call Java’s JPEG decoder a dumpster fire. A
better JPEG decoder—say, like libjpeg, which nearly everthing else
uses—would be able to handle a JPEG with a CMYK color profile. We
won’t have this problem with VASSAL 4 when we’re no longer using Java.