All Encompassing Image & Module Memory Reference Guide

[RobboNJ69]

At 100 dpi/ppi (pixel per inch) you get 100 px per 5 ft grid square (1 square = 1 inch). 100 dpi seems like a sensible compromise for current displays, albeit I would prefer 150 dpi. Fantasy Ground already crashes trying to load the 100 DPI (150 mb) image, though, so I will have to run more tests on what works in practice.

Wow! Are you trying to show dust and carpet fibers in your maps? lol

[Trenloe]

At 100 dpi/ppi (pixel per inch) you get 100 px per 5 ft grid square (1 square = 1 inch). 100 dpi seems like a sensible compromise for current displays, albeit I would prefer 150 dpi. Fantasy Ground already crashes trying to load the 100 DPI (150 mb) image, though, so I will have to run more tests on what works in practice.

DPI doesn't match to dots-per-grid-square on a map - unless you're exactly matching a grid square to be physically one-inch on your screen. It may seem the same, but it's actually not when looking at computer image dpi, because you can save a map at 300dpi through a graphics app but still have 50 dots-per-grid-square. In FG we tend to think of pixels-per-grid-square.

Oh, and you're going to have to get used to using compressed images in FG - be it classic or Unity. 150mb file size is way too big for efficient processing and terrible for sharing with players.

Will Unity be 64 bit?

Yes.

[LordEntrails]

At 100 dpi/ppi (pixel per inch) you get 100 px per 5 ft grid square (1 square = 1 inch). 100 dpi seems like a sensible compromise for current displays, albeit I would prefer 150 dpi. Fantasy Ground already crashes trying to load the 100 DPI image (both TIF and JPG), though, so I will have to run more tests on what works in practice.

Will Unity be 64 bit? More usable memory and less crashes are always a plus when dealing with large map images.

So as mentioned, dpi/ppi doesn't mean anything on a screen. Those are printing terms

So, if you make a map that is 100 pixels per 5 ft square, whether it crashes FG or not has to do with the total number of pixels the image has. i.e. 15k x 15k pixels is a huge image, and when opened into RAM uses up lots of memory, and hence crashes any 32 bit program. It doesn't matter if that image is 50 dpi or 600 dpi/ppi.

I believe Gimp and other programs will tell you under image properties how much memory an image takes when opened (it's different than file size). Or of course you can open it in Paint or such and see what the process size it.

[Weissrolf]

Wow! Are you trying to show dust and carpet fibers in your maps? lol

This is a 100% crop from a 100 ppi image. The original already is low on quality (blurred square lines), but I am using specialized software (Topaz Gigapixel AI) to get rid of aliasing staircasing and invent new details into objects (like the open book on the table). With maps from Pathfinder adventure paths I also get rid of compression artifacts.

briarstone_asylum_main_floor_by_bigrin42-danuhq1-edit (2)_cr.jpg

Unfortunately the software does not identify all parts of the image, having problems with the blurred ground floor and most of the grass patches. But the furniture, papers, books and other details on the map are much improved over the original image and 100 ppi is close to my own display's native ppi. And with other images this works superbly well.

Word of warning: Your browser may (by default) resample the image even when you set it too 100% zoom, this depends on your OS display dpi settings and browser settings.

DPI doesn't match to dots-per-grid-square on a map - unless you're exactly matching a grid square to be physically one-inch on your screen.

Which I do, at least close to my own physical screen. This is why I called 100 dpi a sensible compromise for todays' screens (will have to check the specs of my group members' screens for a good compromise). I calculate the physical size of the map to make its squares physically match 1 inch (or 2 inch for the example map above), additionally I resample to the target DPI (printer) or PPI (FG). I tried 100 ppi for FG both as uncompressed TIFF and high quality JPEG, but that crashed the program. Next I will test if this is an issue of file-size or of total pixel dimensions.

It may seem the same, but it's actually not when looking at computer image dpi, because you can save a map at 300dpi through a graphics app but still have 50 dots-per-grid-square.

I specifically resampled the image to match 100 pixels per physical inch. Since this specific map comes with 10 ft squares each square is 200 px. You can check this with the example posted above.

Oh, and you're going to have to get used to using compressed images in FG - be it classic or Unity. 150mb file size is way too big for efficient processing and terrible for sharing with players.

150 mb is nothing on my desktop computer, but for sharing purposes it makes sense to compress the images. I listed uncompressed size to give a better understanding of the bitmap size of one single large map. At 92% quality YCbCr (no subsampling) this already squeezes down to 20 mb JPEG size, more compression certainly is easily possible. But FG crashes with the 20 mb file, too, so its not about original (compressed) file-size.

So, if you make a map that is 100 pixels per 5 ft square, whether it crashes FG or not has to do with the total number of pixels the image has. i.e. 15k x 15k pixels is a huge image,

My test image is 6299 x 8268 at 100 ppi, which corresponds to only 150 mb uncompressed memory being used.

and when opened into RAM uses up lots of memory, and hence crashes any 32 bit program.

According to some other forum post FG can address up to 3.5 gb on 64 bit Windows. Faststone Image Viewer can display a 1.9 gb 22677 x 29764 px image within its 32-bit address space without crashing, so FG crashing with a 150 mb image is not even close to any memory limits.

[LordEntrails]

My test image is 6299 x 8268 at 100 ppi, which corresponds to only 150 mb uncompressed memory being used.

Yep, depends on file format and what FG uses to display the image. Stuff I don't know enough to comment on.

According to some other forum post FG can address up to 3.5 gb on 64 bit Windows. Faststone Image Viewer can display a 1.9 gb 22677 x 29764 px image within its 32-bit address space without crashing, so FG crashing with a 150 mb image is not even close to any memory limits.

Yep, but if a player of your is on 32 bit Windows them then are limited to about 1.3GB total process size.

[Weissrolf]

6299 x 8268 x 24 bit (RGB) = 149 mb

File sizes of uncompressed file formats (like uncompressed TIFF) usually closely correspond to the real memory usage of an image, plus some minor overhead.

You can turn this into a 5 mb JPEG and it will still use 149 mb memory after being loaded. Compression then just serves the intend of sharing it with other players over a supposedly slow net connection.

[Trenloe]

This is a 100% crop from a 100 ppi image. The original already is low on quality (blurred square lines), but I am using specialized software (Topaz Gigapixel AI) to get rid of aliasing staircasing and invent new details into objects (like the open book on the table). With maps from Pathfinder adventure paths I also get rid of compression artifacts.

briarstone_asylum_main_floor_by_bigrin42-danuhq1-edit (2)_cr.jpg

Unfortunately the software does not identify all parts of the image, having problems with the blurred ground floor and most of the grass patches. But the furniture, papers, books and other details on the map are much improved over the original image and 100 ppi is close to my own display's native ppi. And with other images this works superbly well.

Word of warning: Your browser may (by default) resample the image even when you set it too 100% zoom, this depends on your OS display dpi settings and browser settings.


Which I do, at least close to my own physical screen. This is why I called 100 dpi a sensible compromise for todays' screens (will have to check the specs of my group members' screens for a good compromise). I calculate the physical size of the map to make its squares physically match 1 inch (or 2 inch for the example map above), additionally I resample to the target DPI (printer) or PPI (FG). I tried 100 ppi for FG both as uncompressed TIFF and high quality JPEG, but that crashed the program. Next I will test if this is an issue of file-size or of total pixel dimensions.


I specifically resampled the image to match 100 pixels per physical inch. Since this specific map comes with 10 ft squares each square is 200 px. You can check this with the example posted above.


150 mb is nothing on my desktop computer, but for sharing purposes it makes sense to compress the images. I listed uncompressed size to give a better understanding of the bitmap size of one single large map. At 92% quality YCbCr (no subsampling) this already squeezes down to 20 mb JPEG size, more compression certainly is easily possible. But FG crashes with the 20 mb file, too, so its not about original (compressed) file-size.


My test image is 6299 x 8268 at 100 ppi, which corresponds to only 150 mb uncompressed memory being used.


According to some other forum post FG can address up to 3.5 gb on 64 bit Windows. Faststone Image Viewer can display a 1.9 gb 22677 x 29764 px image within its 32-bit address space without crashing, so FG crashing with a 150 mb image is not even close to any memory limits.

Lots and lots of info you're posting here - and it makes me concerned because you really, really, really need to start thinking a lot smaller for use within a client/server VTT environment, even in FGU under a 64-bit environment. FG is not just about maps, it has lot of other complex functionality, whereas FG Unity might be able to cope with large maps, if you're overloading either the GM or player side then other aspects of the VTT can run very slowly - making your gaming experience pretty painful - but, hey, you'd have nice maps!

And, slightly related, if you want to match one FG grid-square to one physical inch on the TV screen, then you can use this FG extension, no matter what pixels-per-grid square your map is setup in Fantasy Grounds: https://www.fantasygrounds.com/forum...-To-Face-games

[Weissrolf]

I just had a look at the FG version of "Hallod's Hideout" map from the PF2 "The Fall of Plaguestone" adventure, it seems to be using 62 PPI.

Unfortunately FG's UI scales maps with both its own UI scale setting and Windows display DPI setting, even combining both. So setting map size to "Original size" leads to different image sizes depending on the combination of these settings. I hope that Unity will improve UI scaling (especially fonts).

...whereas FG Unity might be able to cope with large maps, if you're overloading either the GM or player side then other aspects of the VTT can run very slowly...

Could you explain why FG will run slowly when there is still enough memory free after loading "nice maps"? Loading the "Hallod's Hideout" map at 100 PPI and zooming/scrolling around in it does not even tax my CPU enough to make it leave lower power saving clock-rates. So besides the memory imprint what else could go wrong?

Speaking of memory imprint:

I noticed that FG reserves about 3 times more private memory than the size of the 62 PPI image, both the one provided by the FG adventure module and my own version. So a 20 mb uncompressed image makes FG reserve about 60 mb private memory. With my 100 PPI image it reserved about 2.5 times the image size, so 50 mb turned 125 mb. When the image is closed FG only releases part of the memory and then takes another few seconds to release the rest again.

[LordEntrails]

Could you explain why FG will run slowly when there is still enough memory free after loading "nice maps"? Loading the "Hallod's Hideout" map at 100 PPI and zooming/scrolling around in it does not even tax my CPU enough to make it leave lower power saving clock-rates. So besides the memory imprint what else could go wrong?

Because if it takes 1 or 2 minutes for you to share an image with your players, that's a bummer. "Here', let me share this image with you" (hold on, it's coming, I swear...).
Because you can't control what your players are doing. Some of them will open multiple images at a time and not close them.
Because some players might be on 32 bit windows. Or might be running as a different screen resolution or Windows Scaling than you.

So what an image looks like on your screen, and how it appears when you do an "Original size" really doesn't matter. Because it is going to be different for every player.
Players are going to (and they should) resize image windows, move them around, and change the zoom on the images.

I'm not surprised about your observations with private memory and images. Not sure why it does that, maybe because that image might have a mask layer and a pointer layer, so 3 times the size would be expected. But it does mean that you will run into process size limits sooner than you might otherwise expect.

Look, nobody is saying you can't use flashy images, we are just saying that in our years of experience it's not needed or worth it. IMO, it's not worth the time you are putting into it

[Weissrolf]

Ok, so mostly only memory and bandwidth limitations to consider. In my fixed group of players I would have control over that. Good to know.

Concerning "Original Size": This is how maps are loaded by default. Being scaled twice (program + Windows scaling) leads to huge windows that don't fit the screen. Even at 100% some map windows don't fit my 30" screen (2560 px) when being opened, so I personally I would prefer if maps and images were not automatically scaled at all.

In the context of this thread I used the function to calculate the ppi of paid FG content (Paizo adventure), which turned out to be 62 ppi for the map I checked. Since I prefer to buy such content anyway, this is what I will be playing with if I ever try to GM an online game.

There are some other issues with scaling, but I reserve that for another thread once Unity is out.