World domination: Advanced export screenshot function

[torstan]

So now that I have my tiles I have found that it is quicker to create a nice looking dungeon map in maptool than any other software. Not only that but a number of people have seen screenshots of some of these dungeons and asked for printable pdfs of areas at 100dpi... Now if I export a screenshot at that resolution I only get a few grid squares in each direction. What would be great would be the ability to have a camera tool that would allow a rectangle to be dragged out. Then a jpg (or png) would be generated of all of the area within that rectangle at the native resolution (Ie as if the view were at 100%). This would be a bit of a godsend for me and allow for maptool to provide the printable multipage pdfs that the people on Dungeon a Day are after.

Is this a complicated addition to the export screenshot function?

[Brigand]

That would be awesome and far easier than taking a bunch of copy/pastes and stitching them together.

[Lindharin]

+1!!!

[Azhrei]

Trevor indicated awhile back that the problem here is that the rendering only takes place within the visible area of the screen. So it has to be visible or it isn't rendered.

I thought about this to see if I could think of a way to make it work. All I came up with is a technique that would be pretty slow (I think) and I never wrote any code to try it.

Basically, create an off-screen buffer that represents the top N% of the image. For an image that's 100 grid squares tall, choose 10 grid squares for example. Setting the clipping rectangle to the top 10 squares of the map (rows 0..9) and render the map into the buffer. Now compress the buffer and write it out (more on this step in the next paragraph). Advance the clipping rectangle so that it covers rows 10..19 and repeat.

The reason this can't be done right now is that JPEG requires the entire image to be available in order to do the compression. PNG does not -- it has an RLE format option (run-length encoded) that allows each row to be specified incrementally. The provided Java libraries do not allow for incrementally created PNG images, however. The libraries require the entire image to be buffered and then the file can be written. But a custom PNGIMage class could be created that uses the off-screen buffer mentioned above. As rows are requested by the class that writes the image to a PNG file, the map is rendered into the buffer and the data returned.

I think this would work. But I don't know enough about the innards of the Java image libraries to know for sure. And if it did work, it would likely be pretty slow for large maps.

[Phergus]

Is this a complicated addition to the export screenshot function?

It isn't quite falling-off-a-log simple.

The "easy" path means allocating a big bitmap in memory to paste all of the various graphics assets onto one layer at a time. Problematic because of memory issues.

Alternatively you create strips of the image in memory of the appropriate width and only a handful of grid cells in height. Less memory but now you are doing your own image writing routine which probably means taking the easy route and doing Targa or BMP as they are trivial to do. Still have the potential for memory problems.

Another route would be to output the whole map in page-sized chunks.

[Brigand]

Sounds like it would be worth it as a 1.4 feature, so that quality full scale maps can be made for print. It would still be faster than using print screen and stitching them together, even if you had to let it "render" the map for an hour.

[Phergus]

The reason this can't be done right now is that JPEG requires the entire image to be available in order to do the compression.

Nope. It works in MCUs and in typical JPEG using 4:2:2 YCbCr that means you need an 8x16 pixel chunk at a time. The IJG base implementation works off full rows of MCU blocks. There are probably Java JPEG libraries that can accept 8 scanlines at a time but it isn't worth the bother. If you can't buffer the whole bitmap into memory just dump it out a few scanlines at a time into an uncompressed BMP or Targa.

[torstan]

So if the zoom is low so that a lot of map is visible, java clearly has to render a lot of the tiles and images and so on in the window. Surely there's not a large step to render out all of these elements at their native resolution, or is the current zoom level hard coded into the rendering of the elements so that this is impossible to do?

As for the memory issue, I guess maptool could well throw a warning - as gimp does - when this is done for too large a map. People should be warned before they try to create a 1Gb image. After that, it's their own look out.

[Azhrei]

So if the zoom is low so that a lot of map is visible, java clearly has to render a lot of the tiles and images and so on in the window. Surely there's not a large step to render out all of these elements at their native resolution, or is the current zoom level hard coded into the rendering of the elements so that this is impossible to do?

The entire map needs to be rendered into an off-screen buffer, so you've got one extra chunk of memory. Then (apparently) the library code that does the saving of the image needs a good size chunk of memory to process the image while writing it. Since maps can be of infinite size essentially...

As for the memory issue, I guess maptool could well throw a warning - as gimp does - when this is done for too large a map. People should be warned before they try to create a 1Gb image. After that, it's their own look out.

Java is not the best language for calculating memory se requirements in advance. Heck, it won't even tell you how much memory is actually available, since some of the freed memory may not have been garbage collected yet, so it's not actually "available".

Although I suppose it wouldn't be too tough to at least code up a test and see how the memory spikes...

[Brigand]

Why not go with preset sizes starting from a user defined left/top coordinate? The size for printing is pretty universal, regardless of what grid size is used in MapTool. Almost every game uses 1" squares because that's the scale miniatures work best at. So code it to accept a user-defined x/y coordinate (top left of the map) and render the map into several images that are 8 squares by 10 squares by default.

Just make an option for different paper sizes. If people have access to a large scale printer, they will have the capability of stitching together the images on their own and having them all the same size in a specific pattern will make it easy. Could probably even create a script in photoshop to do it.

[torstan]

That would be a possibility I guess, and a good start. I prefer to use posterazor to cut up pdfs, but an 8x10 grid page export would cover most eventualities nicely, and avoid the need for much in the way of postprocessing.

[Brigand]

Well the 8x10 squares option would be user configurable, up to memory limits. Say they didn't want it for print but a webpage, they could set it to render 20x20 squares at a certain resolution.

[lmarkus001]

Clearly you need a bigger monitor... say 20 feet on the diagonal should do it?