Optimal Token Image Quality in Fantasy Grounds...

[HoloGnome]

Recently, there has been some discussion about optimal image quality in Fantasy Grounds. See this thread: Silverhex, Page 4 (https://www.fantasygrounds.com/forums/showthread.php?24327-PFQ-The-Silverhex-Chronicles-for-those-who-missed-my-first-game/page4)

Further to my comments in the thread, attached are some token images at different scale factors so that you can see how they look. These images use tokens at the following native resolutions:
- 63x63 (really for portraits, but there has been confusion on this issue)
- 100x100
- 150x150 (my preferred size for best image quality)

Each token size is shown on a grid of:
- 35x35 (minimal grid size I have used in PFS scenarios)
- 50x50 (typical grid)
- 100x100 (large grid)
- 125x125 (maximum grid size I have used in PFS scenarios)
- 35x35 with the map zoomed in to show what happens with lower resolution tokens on smaller grids when zooming

In addition, each grid includes images of the tokens as 4x (large) size (as if using an Enlarge spell, for example).

From the attached images, tokens that are 150x150 produce the best and sharpest overall image quality across all grid sizes. Also, I will add that, in the numerous games I have run, I have not experienced any token-related issues at this size. So, if you like sharp token images when you game with Fantasy Grounds, my recommendation is to use 150x150 tokens to cover the widest distribution of map grid sizes and GM preferences.

Another tip for optimal token image quality: Avoid dragging the token from the character window to the token slot on the character sheet. It will work in a pinch if you have no token, but Fantasy Grounds will do a lossy rescaling of the image. DO use the dedicated tokens folder in the FG data directory for higher resolution token images.

Image resolution is a gaming detail that not everyone may care about to the same degree. For me, I always prefer sharp character and map images, so for those who have a similar preference, I hope you find this information useful. :)

[damned]

if you use a larger grid then lager tokens will give better quality.
i use 50px grid so Im good with the smaller images

[HoloGnome]

if you use a larger grid then lager tokens will give better quality.
i use 50px grid so Im good with the smaller images

:confused: Not sure what you mean here, but if your grid size is larger than the native token resolution, image quality will always be more blurry. If you meant to say that if the native token size is larger than the grid size, that is definitely better.

However, refer to this image for the 50x50 grid (https://www.fantasygrounds.com/forums/attachment.php?attachmentid=10195&d=1433881624). 150x150 still yields the sharpest image quality at that grid size, especially for large creatures and/or if you zoom in the map (which you can extrapolate from the 35x35 zoomed in (https://www.fantasygrounds.com/forums/attachment.php?attachmentid=10198&d=1433881665) example).

Also, bear in mind that, as a GM, the token size choice affects all players at the table. So, as long as nobody ever uses enlarge, you don't have any large monsters, and nobody ever zooms in the map, smaller tokens are OK, just not optimal in terms of sharpness vs. all use cases.

[damned]

your 63x63px will be blurry at 50px because they have to be downsampled and there is detail that could get lost - especially in your examples with hair. Until very recently Ive always used 50px tokens for my 50px grids. Ive started using some of teh 63px portraits as tokens and this will cause some additional bluriness....

does that make more sense?

[Trenloe]

There are two things that can effect the apperance of a token:

Blurrines caused by the token being up-scaled (made larger).
Pixelation caused by the image being down-scaled (made smaller).

We can see examples of both of these in HG's sample images.

If you want to avoid blurriness then make sure that the token size is larger than the grid size in pixels (take into account zooming in if you zoom in regularly). If the grid is larger than the token size, or the image is zoomed in so the grid pixel dimensions increase beyond the pixel dimensions on the token, the token will be up-scaled. It is mainly up-scaling that loses details in the token which results in it appearing slightly blurry. The more the token is up-scaled the more blurry it will appear. HG's example images bear this out.

If you look at the 63x63 token (single square) in the 50 and 35 pixel grid sizes it looks similar to the other tokens as the token isn't being up-scaled, it's being slightly down-scaled. What's interesting is that the 150x150 image in the 50 pixel grid size has become pixelated and doesn't look as good as the lower resolution tokens.

If you want to avoid this pixelation use tokens that are close to the grid size you're going to use so that down-scaling is kept to a minimum.

However, in general, pixelation due to down-scaling an image is usually less obvious than blurriness from up-scaling. Having larger tokens will give you better token quality in most situations - just be aware that having lots and lots of tokens (even if you aren't using them on a map) will take up FG memory so don't go nuts with lots of big tokens! :)

As I mentioned in another thread that HG links in the first post of this thread - go with a token size that is close to the regular grid size that you use, taking into account any zooming that you might do that will adjust the resulting grid size. I go with a 50 pixel grid so I usually work with 50x50 or very close to that for my token sizes. However, I don't spend hours resizing my tokens, a bit of blurriness or pixelation doesn't particularly bother me.

[HoloGnome]

I agree with damned and Trenloe that there is some slight over-sharpening of the 150x150 token at grid sizes of 35 and 50, but it is barely perceptible and mostly when there are sequential high frequency image transitions (like in the hair in my posted examples). I prefer it to the other images.

However, in the case of the images I posted, the main reason it may be perceptible is because of zooming in to see the static screenshots (which is not the case in FG when the grid zooms and dynamically rescales the tokens, where image quality actually improves when using higher resolution tokens). The advantage of the larger tokens at grid sizes of 35 or 50 is that when you zoom the live FG map or become or use large size creatures (4x token size), the tokens remain sharp.

Tokens that are the same size as the grid size are, unfortunately, always going to look blurry when zooming the map or using enlarge (4x size) which, in my experience, happens frequently. I make all my tokens at 150x150 so that they have high portability across all campaigns, grid sizes, uses, etc., including custom tokens for each PFS scenario and for the characters that will be at the table (if they don't already have a 150x150 token). It amounts to about 20 tokens per PFS scenario, and I agree with Trenloe that resizing tokens is a waste of time (which, again, is why I use 150x150 - so I never have to resize for any specific use).

If you are concerned about memory being used by FG, then smaller tokens may be a better choice, but I have not encountered any problems in that area. My tokens directory may reference about 750-1000 images and about 125 of those are character tokens. It's hard to get an exact count, because I use symbolic linking to load tokens from all my scenario build folders (that are not in the FG data directory).

In terms of real-world data for my setup, loading FG with the tokens directory disabled uses 709,560K (which also disables my symbolic links). Loading with the token directory enabled uses 793,136K (a difference of about 80mb). So, memory usage is not a huge concern in my use so far.

Try it for yourself and see what works best for you in your use of FG. Attached are the sample images I used for my test so you can compare and contrast your results.

Good luck and have fun. :)

[LordEntrails]

HG, thanks for all of that. esp the last post with the memory/size numbers.

[HoloGnome]

Sure! Glad to help. :)

As a further test, this morning, I added another 125 tokens that are mostly all 150x150 and the memory use climbed to 869,412K, or around +75mb (or .6mb/token for files that are ~40K/token). On disk, these new files occupy ~5mb. So, when loaded into memory by FG, there is an ~15x expansion.

I then repeated this experiment with 125 63x63 tokens and memory use climbed to 861,212K, or around +66.5mb. On disk, these 63x63 tokens occupy ~1.2mb. So, when loaded into memory by FG, they exhibit an ~55x expansion. The delta between the 2 tests is <10mb, so the token resolution, whether 63x63 or 150x150 has little to do with memory use in FG and smaller tokens are not likely to save much memory. The excess use seems to be in the form of other file/heap overhead that is not resolution-related. Notably, the delta in RAM use is equal to about 2x the actual token size, which could be token + mask, for example, which would make sense and track the physical token size.

I'm not sure why FG has that degree of file/memory overhead, but maybe there is room for improved image efficiency and/or better heap management at some point in the future (not to mention completely eliminating the portraits directory, since it is just a smaller copy of token data). However, even with the inherent file overhead/expansion, it's still not really a huge issue unless you're trying to run on a 1-2gb RAM machine. My machine has 8gb of RAM and has no issue.

If RAM is a huge concern, then your best bet is to physically remove tokens that you aren't using vs. trying to use smaller ones based on the behavior and overhead I have observed in my testing.

I hope this information is useful!

[Dakadin]

Just a warning, FG is a 32-bit application so you won't be able to take advantage of the full 8 GB. Its been a few years but I seem to remember it crashed at around 1.7-1.8 GB committed memory for the process.

[Nylanfs]

And plus it's a single thread app so it sends tokens to each player one at a time.

[Griogre]

Holognome, pics are generally loaded in memory without compression. Thus the differences you are seeing while they might, be increased by some memory "slack" (ie a group of pics that doesn't fit perfectly in a page of memory), mostly the effective memory of a pic in RAM is the about the same size of that pic as an uncompressed BMP file. Thus the size of pic in memory is just about always a direct result of the size of the dimensions of the image and the bit depth of the image, IE pixel length times pixel width times bit depth of the image = memory footprint.

My suspicion is that if you converted you tokens with a mass picture converter to BMP files, those the folder holding those BMP files would be about the same size as the memory usage (hard dives *do* have a boat load of slack compared to memory so you should compare actual image size not space used on the hard drive). If memory foot print is a concern then by far the easiest thing you can do to digital images is reduce the bit depth. Most art programs by default make their output print quality. Something totally wasted when displayed on almost all monitors. If you reduce your images from 32 bits to 8 bits (256 colors) the difference is not noticeable on most monitors and your images will be reduced to 1/4 the size. After that the math is simple if you half the dimensions your pic size, is the pic size also reduced to 1/4 the size.

Personally, I think you should use what ever size images that make you happy. :) I will point out that unless all your players have the same size monitor, in the same size resolution, they are down or upsampling your map and token images anyway - so you are strictly doing this for you - unless, of course - you are projecting the map for use in a face to face game.

[HoloGnome]

Just a warning, FG is a 32-bit application so you won't be able to take advantage of the full 8 GB. Its been a few years but I seem to remember it crashed at around 1.7-1.8 GB committed memory for the process.

Good to know. On 64-bit Windows, at least, 32-bit apps can be compiled/linked with the IMAGE_FILE_LARGE_ADDRESS_AWARE flag that will allow access to 4gb application space. There used to also be a runtime flag for 3gb that I used in the transition between 32- and 64-bit XP->Vista->7, but haven't used that in a while. Might be helpful, but I think it still needs the flag. If FG is currently still crashing at the typical 2gb limit, then maybe changing the build flags will help (on Windows, anyway), assuming it doesn't introduce any other issues.

Griogre: Maybe, but I don't think compression explains the delta - at most the difference between PNG and BMP is probably only 30-40% (of the native image size) and it also doesn't explain the overhead and minimal difference in 63x63 vs. 150x150. I'll check it, however. It looks like there is other process overhead in the allocation of the graphical objects - maybe in Windows or the app. Who knows - it's a code profiling experiment to understand what is getting allocated, where, how and what is the state of the memory space after it happens. Maybe there's dead space and Windows is the culprit, where some additional memory management might release associated memory. Or...Locks? Leaks? Who knows?

At this point, 1080p is the prevailing desktop standard and most have at least 1366x768 (15" laptop). So, with remote clients, higher resolution tokens would seem to be relevant. That being said, I am also now running local games in loopback mode on a 1080p IPS 24" for the table, which is great. It takes a little work to convince the die-hard table mappers, but I think I'm winning them over. ;) ...especially since I don't have to say...now go take a bio-break while I draw this next map. And besides that, there is all the other rich graphical content that Fantasy Grounds provides to the gaming experience. So far, it's working well! :)

[HoloGnome]

Attached is a quick manual check on a small sample size of some of my 150x150 tokens. PNG compression vs. BMP: 29.35%

It doesn't look like compression explains the memory usage.

[Trenloe]

On 64-bit Windows, at least, 32-bit apps can be compiled/linked with the IMAGE_FILE_LARGE_ADDRESS_AWARE flag that will allow access to 4gb application space.
FG has been compiled with this set. On a 64-bit Windows operating system FG starts to have issues above 3GB of memory use.

[Dakadin]

FG has been compiled with this set. On a 64-bit Windows operating system FG starts to have issues above 3GB of memory use.

Thanks Trenloe. I was pretty sure that was the case but couldn't remember exactly.

[HoloGnome]

Good to know - thanks! I have room for 2000 more tokens!! :D