All Encompassing Image & Module Memory Reference Guide

[Mortar]

I am not sure if Unity will change this behaviour but typically the players reached the memory limit far before the GM ever gets close. I just opened up one of the development campaigns I am working on in FGU.

SavageWorlds ruleset with SWADE PG and SWADE GM guide, plus the Wiseguys Player's Companion and Don's Guide that I am working on, as well as the Wiseguys theme. Memory usage on my client started 791mb, but have rapidly climbed up to a high of about 1200mb and is currently at 1171mb.

[damned]

the relevant measure is pp5s (pixels per 5' square)!

[LordEntrails]

I want to make sure no one is getting cranky... I know their is some exasperation, but lets all make sure we maintain the good will and assumption of good intentions of everyone on this forum.

About the only thing I want to add (again) is that change in UI behavior is something that should be suggested on the wishlist. And, in most cases behavior is a preference, what someone is used to, and changing the behavior of an application that has been around for decades and has a very large user base is something not taken lightly.

[Weissrolf]

Edit: No getting cranky here, I do like deep technical discussions to learn from (including my errors) and share information. This thread still is about image memory usage and the compromises and different work approaches within those limits.

And here's your 62 "dpi" image saved at 600 dpi from Adobe Photoshop:

Indeed, except that in your 600 dpi image 600 pixels do not equal a one inch grid box in any software that cares to use dpi information. In Photoshop the squares will measure as 0.1 inch instead of 1 inch now. Since FG does not care for this, we can ignore that for pure FG VTT usage, though, especially when FG's own grid overlay is used. But when you try to import the original PDF map with hard-coded grid trying to match the size of the module image then dpi is your best way of measuring, because we users don't get to see the pixel dimensions of the module images.

They are displayed exactly the same. The pixels per grid square are exactly the same - because the grid has been drawn at 62 pixels per grid square. Nothing at all to do with embedded image DPI - Nothing. At. All.

When you want the imported image's dimensions and hardcoded grid to match the module's grid-size of 62 pixels then DPI based resampling is the way to get there. When images are only used within FG and you don't care to align dimensions between module maps and imported maps then yes. FG's module maps all seem to use different grid sizes for the same adventure anyway. But when for discussion of memory usage we need to create matching image files then grid boxes and dpi become the measure to use. This way we can find out what image sizes are used by prepaid modules.

Personally I need my maps both printed and (maybe) online, so it is more convenient to resize the map in order to match 1 inch per grid box (Photoshop selection tool helps with measuring) and then resample to a DPI according to the output medium (print and/or VTT). The "Hallod" map comes with 0.4 inch grid boxes when extracted from the PDF at 96 dpi, so it needs to be upsampled by 250% to print correctly. Instead of wrapping my head around different image dimensions for both usage cases I just stay with the 250% magnification factor (=output size in inch/cm) and then apply DPI resample factors accordingly. I have to do the calculation for printing anyway and then enter the output size in Topaz Gigapixel, also due to limits of the software when trying other input methods. From there I just change the dpi to either match my printer or the FG grid, a 62 pixel grid then becomes 62 dpi at original map print size dimensions in inch/cm.

All that being said I noticed that the image files embedded in FG modules are of much higher visual quality than what comes with the PDF. Even the extra paid for "interactive maps" PDF files are of bad image quality (in one case the map on the front-page was higher resolution than the one inside). The German PDF maps are of higher quality and resolution at least. So this would be a good reason to just use bought module maps, on top of them already being pinned with encounter information.

One reason against module maps would be that the module grid usually is different to the original grid from the adventure PDF. That may or may not work well, depending on the particular map/encounter. Originally I hoped that I could just import my own maps as a layer underneath the pinheads in FG, but that does not seem to be possible. It might not be necessary due to the higher quality of FG maps anyway, so less work is always welcome.

I have worked with the original PSD files from Paizo for a lot of their maps and they have the embedded dpi at widely differing values - some at 600 some at 300 some at 72...

I suspect that the 300 and 600 dpi ones were intended for HP or Canon printers at Paizo to see what they roughly look like on paper (maybe even with color proofing). But I do not claim to have any real knowledge about that.

...but in the end it doesn't matter, because that is just an embedded marker that is used for printing - FG doesn't read it at all. What matters is how many pixels there are per grid square - because that is all that FG will look at, it doesn't do anything with the dpi embedded in the image file (see my second screenshot above) it makes no difference.

You are correct as far as displaying the images in FG is concerned. Calculating image dimensions on dpi basis still is a better way of getting consistent image quality in FG. Telling me to keep dimensions below 2048 px is of little use when map sizes can vary so widely. How am I supposed to squeeze a 82 inch sized map into 2048 pixels while still providing a visually pleasing experience? What about a 10 inch sized one that is supposed to be of roughly equal visual quality? Calculating images for proper print sizes and then resampling dpi values for VTT usage is much more predictable. I always know what the image will roughly look like at 62 dpi (62 pixels per grid box) with dimensions depending on the specific map.

Ask anyone on these forums who does commercial conversions of modules - the map images received from the publisher will rarely have a dpi that matches the actual dots-per-grid-square - because it doesn't actually matter for displaying on a computer screen.

Again, you are correct for pure displaying on computer screens in software that does not care about dpi interpretations, even more so when the source image files are of high enough quality. But when your source files' quality is so bad that you need to do heavy lifting to get something workable then consistent or at least predictable output quality can better be achieved via dpi based processing (with the bonus of more convenient printing outside a VTT).

So, if as you say, the dpi/ppi of an image directly related to the dots-per-grid-square, why does the dots per grid square on this image (50) not match the dpi/ppi of 300? Because, as I've said many, many times in this thread - for displaying images on a computer screen, and in particular maps in Fantasy Grounds - dpi/ppi is not read, because it doesn't make any impact on how the image is displayed - it is all about physical pixels, and how many pixels per grid square are drawn on the actual image - FG does not automatically draw it's grid on an image, that needs to be manually drawn or manually set by the module developer.

And maybe because it was originally created using high resolution and proper measuring tools available for creation, possibly with 300 dpi printing as potential original target (or compromise). It was then downsampled to a measly 50 pixels per square before being handed over to you, not caring for embedded dpi information due to knowing FG to be the target. All pure speculation of course.

But yes, I agree, since FG does not interpret these dpi values for any of its own functions and uses a pure pixel based grid it really doesn't matter for this usage case. Personally I might not be happy with the visual quality/detail on this particular map and thus opt to resample it. One way then would be to just arbitrarily use different pixel dimensions, another way would be to properly resample for map size and destination dpi. With the latter approach again offering more consistent results and the added benefit that once I settle for a dpi/quality compromise I can always go back to the same values (dimensions then varying with each image). Or less convoluted: if 75 pp5s was my go-to goal then resampling everything to 75 dpi is the easiest way to go about it.

These are two different approaches. You can opt for constant memory size (pixel dimensions) or constant quality (dpi). Both achieve different goals via different compromises and both are valid for their different intents. Personally I like my computer's memory being put to full use, that's what I bought it for. Tests will have to show if this is still valid with clients being connected and maybe even running the FG server in a (Synology) virtual machine. Different goals, different means to reach them.

[LordEntrails]

You are correct as far as displaying the images in FG is concerned. ... How am I supposed to squeeze a 82 inch sized map into 2048 pixels while still providing a visually pleasing experience? ...

You won't. But you if you decide you want 150 pixels per 5ft square, then you are might find that a 12k square pixel image won't work in FGC

These are two different approaches. You can opt for constant (memory) size (pixel dimensions) or constant quality (dpi), ...

As long as the approach you chose doesn't crash the application.

As you are aware, you can greatly exceed the 2048x2048 pixel recommendation, but the recommendation is there for a reason, and part of that reason is that most users are not aware of what's going on int he background and if FG crashes they get upset, frustrated, and if we are lucky they come to the forums to ask how to solve the problem. If "we" are not lucky, they switch to a different VTT platform and badmouth FG without knowing the reasons behind their poor experience.

Personally, I exceed the 2048 pixel, 1MB, and 50 pixel per 5ft square ALL the time. But that's because I;
1) know what I'm doing
2) test process size impacts prior to game time
3) actively manage what content/images is shared with my players so they never experience crashes or other memory related issues
4) get my players to connect early when I have large images to share and I mark them for preload so they are already downloaded when I decide to share them

You can (and I encourage you to) do something similar, but "we" (the community) don't want to actually change the image recommendations for FGC because we don't want it to negatively impact the experience for users that don't want to be so actively engaged like you and I.

[Trenloe]

Telling me to keep dimensions below 2048 px is of little use when map sizes can vary so widely.

Actually, it's everything. Don't dismiss it as "of little use" - the recommendation is there not based on image quality, it's there based on FG memory use and efficient image processing. You can have one or two images a little bit bigger than this, but the *very firm* recommendation is to get maps below 2048x2048 pixels. This is the firm recommendation and shouldn't be ignored as "of little use".

How am I supposed to squeeze a 82 inch sized map into 2048 pixels while still providing a visually pleasing experience?

If by 82 inches you mean 82 grid squares across, then you're basically not supposed to use a map that size as a single image - split it up into smaller images. Make it 4 images with each grid square being 50 pixels.

In the end, you disagree with me. Therefore, you basically don't believe what I'm saying. All I can recommend is that you endeavor to keep each of your images within the FG Classic recommendations of 2048x2048 pixels (approx. 4.2 million pixels) and less than 1MB file size if possible. JPG files with compression that leaves the image good enough to view, but helps keep the file size down. These recommendations are based off years of experience using FG, supporting FG and come from the developers - not me. If you ignore them, then FG Classic probably won't run efficiently. If you have any issues in future, then please remember this thread and what we were trying to get across.

[notrealdan]

Dots/pixels per "inch" do not matter to FG, since inches are irrelevant to both the game mechanics and the VTT software. Game rules typically don't say "a medium size creature occupies 1 inch on your game board." They say something like "a medium size creature occupies one 5-foot square" (or similar depending on your game system), and this can be represented in different ways. Though they are typically 1 inch grids on a physical battlemap, that is a matter of physical world convenience and that has no relation to a VTT. Each player/DM will likely have a different size screen and be zoomed in to a different degree. So, for the VTT to know how to scale the grid, it only needs to know how many actual pixels long each side of that grid is, and that defines what a "5-foot square" is. It doesn't know or care how large in inches that will be displayed on anyone's screen.
1 square = X pixels = 5 in-game feet.

For the "82 inch sized map" typically for very large maps there will be a low-quality version for DMs with relatively few pixels per grid, plus smaller, higher-quality images that are individually shared with players (as Trenloe described). The DM versions will also often have pins, secrets, notes, etc. not meant for the players.

[Weissrolf]

Here is what irritates me. As a new user I am told to run my car at walking speed with the handbrake kept engaged so that I don't risk a crash!? The information we new users really needed instead was the speed limit and handling of the car. And what's with instilling so much fear of crashing in us new users? Is FG such an unstable program? Did I spend money on bad software?

Frankly it seems to me that FG and its new users are given a bit too little credit for their capabilities.

You won't. But you if you decide you want 150 pixels per 5ft square, then you are might find that a 12k square pixel image won't work in FGC

Except that it does work. I can load my 82" dungeon map at 150 pp5s, which corresponds to 9449 x 12402 px. On top of that I can concurrently load the same image at 100 pp5s, 75 pp5s, 50 pp5s, load all prebuild battle-maps and GM maps of the "Fall of Plaguestone" module and external versions of "Hallod's hideout" at 100 and 62 pp5s. Neither does FG crash, nor does it run out of memory.

Private (non swapable) memory usage on the server is around 2.2 gb at this point. A client loading all of the same maps from the server uses a bit less than 2 gb then.

As long as the approach you chose doesn't crash the application.

Again, what's with the crashes? I voluntarily made FG exceed its memory limit and it did not crash, but produce an error popup upon trying to load more images. When you are close to the memory limit it can also happen that you exceed the limit via actions other than loading more images, again I got a whole bunch of errors, but no outright crash.

There were some instances where FG misbehaved unexpectedly:

- When FG is left alone for 20-30 minutes (with no measurable CPU, SSD, network load happening) then most of the reserved private memory becomes shareable (as in can be swapped out to SSD). Memory usage dropped from 2.2 gb to less than 0.5 gb on the server and from 1.9 gb to less than 0.8 gb on the client. At this point you need to watch out to not cross the virtual memory size limit even when Task-Manager lists FG as only using much less memory.

- When the client computer went to standby after leaving it alone for too long FG had serious issues redrawing its UI, throwing dozens of graphic-driver related errors in its popup and eventually not being usable anymore (most of the UI staying black and the process mostly being unresponsive).

- When I tried to directly load TIFF files created by Topaz Gigapixel FG crashed right away. This is half a problem of FG and of Gigapixel, because the latter creates TIFF files that are not readable by all other applications, but still a lot of other applications can read them. The solution then is to rewrite the TIFF file with a more compatible program or just use JPEG for practical purposes (transfer to client) anyway.

As you are aware, you can greatly exceed the 2048x2048 pixel recommendation, but the recommendation is there for a reason, and part of that reason is that most users are not aware of what's going on int he background and if FG crashes they get upset, frustrated, and if we are lucky they come to the forums to ask how to solve the problem. If "we" are not lucky, they switch to a different VTT platform and badmouth FG without knowing the reasons behind their poor experience.

Well, FG should include the means to keep users happy instead of asking them to better walk than drive for safety reasons. There are some very odd memory allocation things happening, like FG allocating nearly double the memory of even Photoshop (as in 1.2 gb vs. 0.65 gb) when opening the same image. And that weird sudden switch of private memory to shareable for no apparent reasons.

Personally, I exceed the 2048 pixel, 1MB, and 50 pixel per 5ft square ALL the time. But that's because I;

Here is my "new user" perspective on these lowest common denominator kind of suggestions. I bought the adventure module "The Fall of Plaguestone" for FG. It includes 4 files larger than 1 mb, it includes several maps larger than 2048 px on at least one side and nearly all of its maps use more than 50 pp5s. I even counted, out of 9 battlemaps there is only 1 at 48, 1 at 62, 5 at 75 and 2 at 78. So 50 pp5s seems to be the exception rather than the norm.

1) know what I'm doing

FG should help with that. If it is loading too big an image or running low on memory then a clearly readable error message would go a long way of informing the users what they are doing wrong.

2) test process size impacts prior to game time

Graceful error handling that does not render the FG process mostly unusable should be the norm. Don't instill fear in your users, but confidence.

3) actively manage what content/images is shared with my players so they never experience crashes or other memory related issues

I recognize that this is more mandatory with users whose system you don't know. In a regular group it should be easy to find out if anyone is still on a 32-bit OS (most are not) or a generally slow system.

4) get my players to connect early when I have large images to share and I mark them for preload so they are already downloaded when I decide to share them

This is a bandwidth problem, not a memory problem. And what a problem it seems to be, so much so that I may have to file a bug-report. I get less than 3-4 mbit transfer speed over a local gbit connection that is otherwise perfectly fast. I only saw one single 15 mbit spike, and even that is excruciatingly slow.

You can (and I encourage you to) do something similar, but "we" (the community) don't want to actually change the image recommendations for FGC because we don't want it to negatively impact the experience for users that don't want to be so actively engaged like you and I.

As a new user myself the way of presentation (crash, crash, crash) and understatement of FG's capabilities leaves a negative impression about the software. I am very sure this is not your intention at all, but that's what I get from all of this. It should be made more clear that these recommendations are just a starting point for the uninitiated and nowhere near the capability limits of FG.

[Mortar]

Except you haven't said whether you shared those monstrous images with a player.

From experience...those images will crash a player's client long before the GM client crashes.



Yes, image handling has improved in FGC, but you will still run into the limitations of a 32 bit app. Images are still handled differently by a player's client.

[Weissrolf]

Except you haven't said whether you shared those monstrous images with a player.

Yes, I did, when I listed the memory consumption on the client/player side compared to the server side. The client used about 10% less memory compared to the server, loading all the same images as shared by the server (after an awkwardly slow transfer).

Private (non swapable) memory usage on the server is around 2.2 gb at this point. A client loading all of the same maps from the server uses a bit less than 2 gb then.

Later I also mentioned that the client switches to different private vs. shareable memory numbers compared to the server.

From experience...those images will crash a player's client long before the GM client crashes.

Not at all. And if it did then there would be a bug in the software, because software should not crash just because it is loaded with big images well inside its memory limitations.

Again I need to ask, what's with all the crashes? Is this software badly implemented? Should I have kept my money until it is fixed? This is the picture you are painting for me as a new user.

Yes, image handling has improved in FGC, but you will still run into the limitations of a 32 bit app. Images are still handled differently by a player's client.

My experiment was extreme compared to what people (including myself) load in a single session. It still worked and I provided the data. It also demonstrated that FG uses a lot more memory than the actually image data (about x2.3 - x2.7), this is unexpected to me and may be something that needs optimization.