JPEG support?

[mattrl]

Any plans for JPEG support? Pigmap is fast to render but it's not fast when you actually want to view maps.. I found out the hard way how much of a difference there is between PNG and JPEG using Overviewer.

(I know we can use image magick to convert or PNG crush to uh crush the PNG's but I'm wondering if you plan native support)

[equalpants]

No plans for right now; maybe someday...

[Revenger]

I'm another server admin with mattrl.

I know you have no plans for JPEG support right now but its the one of the only thing holding us back from switching to pigmap.

We run a big map which our current rendering is overviewer using JPEG file format our current map is:

http://whopperohyeah.com/overviewer/

PNG support for us is too slow for the general public to use our map properly as it takes ages to load the tiles.

Also rendering time on overviewer takes about 24 hours for just the night render.

We have tested pigmap and had a full render done on a slower test server in about 8 hours.

Here is our pigmap render on a test server note the speed difference in loading between the two.

http://91.121.142.144/map/index.html

For us not having JPEG supoort like mentioned is a show stopper as PNG is just too slow for the end user as you can see looking at both links.

[equalpants]

If you want to code it up I'll be happy to add it.

This tool can probably help you out for now:

http://www.imagemagick.org/script/convert.php

[packetcollision]

I also wanted the faster load-times from using jpg images, so I wrote this script that gets executed after all full and incremental renders. It finds all new pngs and converts them to jpeg. Note that you can't delete the originals, because pigmap uses them for incremental updates. You need ImageMagick installed. Just paste the following code into a file, edit your paths, do a chmod +x and run it. Add it to the script you use for updates after your pigmap command executes, and it'll convert the new ones every time.

#!/bin/bash
echo Converting PNG images to JPG...
find /home/bukkit/worldmap/tiles/ -name \*.png -a -newer /home/bukkit/worldmap/lastupdate -print0 | xargs -0 mogrify -format jpg -background \#E5E3DF -flatten
touch /home/bukkit/worldmap/lastupdate
echo Done!

You can see the results at http://minecraft.packetcollision.com/ (pigmap updates every 15 minutes, and player updates are every 15 seconds)

[slicedlime]

I have done an implementation of jpeg support. It only works for full renders right now (haven't written any reader, plus since jpeg is lossy I'm not sure it'd work anyway), but my test renders come out good. Background is rendered white right now since there's no alpha support in standard jpeg... should be easy to add an option for that if someone wants one.

If there's any interest, I could clean it up for submission.

[packetcollision]

@slicedlime I agree that using jpg as a source for incremental renders is problematic, perhaps incremental renders could be enabled only if they also have png files around (and make an option to output both during full renders). A background-color option would also be a good idea.

[slicedlime]

@packetcollision Yeah... it will actually look for .png files now if you try to do an incremental render, but then output as jpeg. That does work, but i'm not sure of how much benefit it is. Adding the option to output both files at once is a bit messy because of how the output it done... I'm not sure it'd be worth it. To be honest, I'd rather just disable .jpeg output when doing incremental renders, but then again I don't use that feature so I'm not sure how much of a dealbreaker that'd be.

[slicedlime]

I've re-implemented this to properly support incremental builds. There's now a "both" output mode and incremental updates take both file types into account. There's a pull request for it open.

Can be improved with bg colors and such if this is merged in.