All Encompassing Image & Module Memory Reference Guide

[Trenloe]

I know IrfanView, Faststone, XnView, ACDSee, Lightroom, Photoshop, Paint.net, GIMP and lots of others. Of course none of these would ever apply UI scaling to the image content they are displaying/editing when an image is displayed at 1:1 (100%). This is UI usability stuff and thus has nothing to do with pixel-resolution expectations.

Again, you're "expecting" Fantasy Grounds to be a purely image viewing application - it is not. Any scaling of the UI (be it in FG or via the operating system) matches throughout all UI elements. A FG image (map or flavour image) is not just a static image - it contains a grid, links, tokens, mask, pointers, etc.. These are not graphics applications image tools with layers etc.. So please try not to thing of Fantasy Grounds as the same as any of the purely graphical applications you mention!

I am experiencing these usability issues with content/maps created and sold by your shop.

To be perfectly clear here - no one who's responded to you in this thread works for SmiteWorks - we are all unpaid community members who try to help out. It is not "our" shop. I just wanted to make that perfectly clear.

Anyway, my question was about FG's memory usage for opening *any* image, and thus more on-topic to this thread. The 62 dpi image of "Hallod's hideout" from "The Fall of Plaguestone" PF2 adventure corresponds to 20 mb of pure image data, yet FG uses 60 mb of private memory to open the corresponding map window.

So I am curious why the overhead is so large? I also wonder why the overhead of my 100 dpi image was only 2.5 times instead of the same 3 times (should I check again)? Is this expected behavior?

As has been mentioned a few time, dpi means little for an onscreen VTT image. The size is all about total pixel dimensions. And if you're really talking about pixels per grid square - those are just that, pixels per grid square, not dpi or ppi. This may seem a purely academic distinction, but it really isn't. Again, please shift you thoughts from purely graphical, print quality thought, and move it to a VTT application designed to allow people to play RPG systems.

A FG image will frequently have a FG grid superimposed, have FG links embedded in the image database record (which are then superimposed on the map), etc. then there are many things that will increase the memory that Fantasy Grounds uses to display one image compared to another. And, let's be realistic here, accurately estimating memory use in a dynamic application is virtually impossible without specific code in the application designed to do so - all you can do is a rough estimate. 2.5x vs. 3x is within 20%, which is close enough for the inaccurate measurement method used.

[Weissrolf]

...These are not graphics applications image tools with layers etc.. So please try not to thing of Fantasy Grounds as the same as any of the purely graphical applications you mention!

I am fine with that, but then consider not calling it "Original size", because it clearly is not original once it is scaled. This is where the confusion stems from. And again, this should not increase the borders of the map window outside the desktop area (aka off-screen).

To be perfectly clear here - no one who's responded to you in this thread works for SmiteWorks - we are all unpaid community members who try to help out. It is not "our" shop. I just wanted to make that perfectly clear.

Sorry for mixing this up. I thought you were an employed moderator.

As has been mentioned a few time, dpi means little for an onscreen VTT image. The size is all about total pixel dimensions. And if you're really talking about pixels per grid square - those are just that, pixels per grid square, not dpi or ppi.

Ok, this is where you are confusing things and unnecessarily complicating things with semantics. There are image standards, these include dpi/ppi for image being embedded in the image file for viewing applications (like FG) to properly scale images. Additionally the grid in FG usually represents one inch on a printed map (depending on the game), so pixels per grid practically equals pixels per inch. Of course size is about total pixel dimensions, but when we talk about memory and then mention a mere 62 ppi image pulled from FG released content then I expect both of us to recognize what this represents.

That being said, I specifically presented the math behind how image data size is calculated in the 149 mb example. You could have derived from this example that I do know what we both are talking about instead of (somewhat rudely) keeping to insist that I don't understand the topic at hand. We are talking about memory consumption of image files, here is the abstract math:

Width x Height x 8 bit per channel (24 bit for RGB without alpha) = total bits of an image / 8 = total bytes of an image / 1024 = kbytes / 1024 = mbytes. With uncompressed image formats like TIFF and PNG this mostly corresponds to the final file size, save for some minor overhead.

The original image of "Hallod's Hideout" from the PF2 adventure PDF is 2002 x 2597 px at 62 px per grid square (encoded as 62 dpi in the file format). FG's version bought as a module must be close to these dimensions, give or take some dozen pixels.

And, let's be realistic here, accurately estimating memory use in a dynamic application is virtually impossible without specific code in the application designed to do so - all you can do is a rough estimate. 2.5x vs. 3x is within 20%, which is close enough for the inaccurate measurement method used.

I retested this and it turns out that this time the small images only use about x2.5 (up to x2.68 for the external file) and the large one about x2 (up to x2.5 for a short time, but then some memory is released again).

Every time I load the 20 mb map I see FG's private memory increase by about 50 mb (give or take a little). Every time I close the map FG releases said private memory again, with the last few mb taking a few seconds. I can repeat this dozen of times and FG reproducibly keeps allocating over 2 times the private memory that the pure image data would take up. Notice how I did not write x2.5 here, because sometimes it happens that not all memory get freed up again when the map is closed, so with more memory usage to begin with the next opening of the map may only take around x2.3 times the image data.

This is quite a lot, especially when larger images still use up around at least 2 times their data, instead of just a fixed overhead for pins and overlays and whatnot. Someone suggested this to be due to several layers being put on top of each other.

My question is whether this is expected behavior? If so then it should be specifically listed in a "Memory Reference Guide".

[Trenloe]

There are image standards, these include dpi/ppi for image being embedded in the image file for viewing applications (like FG) to properly scale images.

No. No. No. dpi/ppi embedded in an image file have nothing at all to do with how a map in FG should be displayed on the screen. This is what we’ve been trying to tell you *multiple* times. Forget dpi/ppi when it comes to FG images, because they are for physically printing images where actual dots per inch on a sheet of paper mean something. Please stop thinking that dpi/ppi embedded in an image have any impact whatsoever on how FG should display an image! I know you have these preconceived ideas that FG is a graphical application and should adhere to graphical physical print quality standards, but FG is not that type of application, and it doesn’t need to be. Please, as has been asked many times, stop thinking of FG this way. If you’re expecting FG to adhere to these high quality image for printing standards then you’re going to continue to be disappointed. And FGU won’t do anything differently in this aspect than FGC already does - because it doesn’t need to!!!

[Weissrolf]

And to clarify. I don't think that FG does anything wrong with the memory allocation of images. Paint.net uses at least as much memory for opening the same test image and Photoshop uses a *lot* more. This is why I ask if this is "expected" and provide the information for others who want to know about memory usage with images/maps in FG.

[Trenloe]

My question is whether this is expected behavior?

Yes.

[Weissrolf]

No. No. No. dpi/ppi embedded in an image file have nothing at all to do with how a map in FG should be displayed on the screen. This is what we’ve been trying to tell you *multiple* times. Forget dpi/ppi when it comes to FG images, because they are for physically printing images where actual dots per inch on a sheet of paper mean something.

I know that you keep telling me that and I keep disagreeing. When you want your FG grid to match the grid of an original D&D/Pathfinder adventure as printed (or PDF) then the DPI of the image file matches *exactly* the grid size in FG. Pixels per grid are interchangeable with pixels per inch then, because Pathfinder adventures use a 1 inch grid.

The FG grid size of Pathfinder's "Hallod's hideout" is 62 pixels, this corresponds to a 62 dpi image file when FG's grid is meant to match the Pathfinder grid. Of course we know that those hard-coded map grids in printed adventures are grossly misaligned and thus hard to correctly measure, but overall you get the same "original" image size when you match ppi with ppg (pixel per grid).

Here is the original sized FG map (aligned grid) right beside a 62 dpi imported version (hard-coded misaligned grid, extracted and resampled from PDF):

Attachment 30649

And FGU won’t do anything differently in this aspect than FGC already does - because it doesn’t need to!!!

I don't expect FGU to handle file embedded DPI information differently than FGC, it is correctly handled as it is. I hope it will generally handle scaling better (especially window borders and fonts).

It might or might not use more or less memory for opening the same image, that depends on internals. Its current overhead is known now, I will take another look once Unity is out, knowing that it becomes less important for a native 64 bit application anyway.

[Mortar]

Thanks for the hint. This works, albeit it does reset *all* windows positions, not just single ones. So "peril" might be the correct description.

Don't delete the windowstate.xml.

Look through it and delete any <imagewindow> references you see, that will just clear those saved locations.

[Mortar]

A couple of other thoughts for you to think about.

I didn't see it mentioned, but once you load an image the player client handles it differently than the GM's. It can use up to 4 times the memory on a player client. I am not aware if that has changed.

Second your internet speed means nothing to the players downloading the files from you, if they have a lower grade internet than you that 150mb image you shared with your players will cause havoc in your game.

[Weissrolf]

Thanks for the hints, including the one for windowstate.xml. Of course I never meant to share a 150 mb uncompressed image over the web, but it still should not make FG crash when being loaded. Sharing a 20 mb JPEG version over a local network would be less of a problem, but it would still eat at least 150 mb memory once loaded, likely over 2 times as much after overhead.

My above example of "Hallod's Hideout" is embedded as 1.02 mb JPEG file in the module DAT file that I bought from SW. Judging from my external 62 dpi image of same "original" size this turns into about 20 mb of uncompressed image data once the JPEG is loaded. Then overhead is added for a total of around x50 times the memory being used compared to the JPEG file size (x2.5 compared to uncompressed image data).

I will take a look at how much memory the same map eats on a client. Again this ought to be less problematic with 64 bit Unity and even the current 3.5 gb limit would not be problematic as long as FG does not crash for no apparent reason.

[Trenloe]

I know that you keep telling me that and I keep disagreeing. When you want your FG grid to match the grid of an original D&D/Pathfinder adventure as printed (or PDF) then the DPI of the image file matches *exactly* the grid size in FG. Pixels per grid are interchangeable with pixels per inch then, because Pathfinder adventures use a 1 inch grid.

The FG grid size of Pathfinder's "Hallod's hideout" is 62 pixels, this corresponds to a 62 dpi image file when FG's grid is meant to match the Pathfinder grid. Of course we know that those hard-coded map grids in printed adventures are grossly misaligned and thus hard to correctly measure, but overall you get the same "original" image size when you match ppi with ppg (pixel per grid).

Here is the original sized FG map (aligned grid) right beside a 62 dpi imported version (hard-coded misaligned grid, extracted and resampled from PDF):

Attachment 30649

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



And here's the two images, side by side in FG - one with 62dpi embedded in the image and one with 600dpi embedded:



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.

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, 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.

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.

Here's an example of a PSD I received from Paizo last year for the Doomsday Dawn playtest. Each grid square is 50 pixels - see the ruler measuring tool - 500 pixels over 10 grid squares:



But, this image is set at 300 pixels per inch in it's embedded image data:



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.