• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Background Image Issues

scruffyduck

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,981
Country
unitedkingdom
Over the past several versions of ADE we have made attempts to improve the handling of background images.

What follows is a catolog of my 'ignorance' :o

The first attempt was to limit the size of the incoming image. This is relevant up to a point but is a by product of the real cause of image handling problems.

The next attempt was to use a quality factor to try and encode the image to use less memory. As far as I can tell this is a complete waste of effort.

The third attempt was to 'resample' the image to have it match the actual display size of the image in ADE. This will work to some extent if a large or high quality image is being used. Part of the resample attempts to change the number of bytes used per pixel for things like color. This caused a different set of fails and I missed the obvious that images in ADE are all about the memory needed to store them.

Finally thanks to the last round of problem images and realizing (after trying to understand the issues with an image to be sized to 10km on a side) that the real problem is how much memory the underlying windows graphics needs to display an image. Generally each pixel can have anywhere between 1 and 8 bytes per pixel. In ADE a pixel represents 1m x 1m so a 10km square needs 10,000 x 10,000 x number of bytes per pixel of memory. This also has to be in one chunk so if the graphics engine can't find a single block of memory that might be over 400Mb then it fails.

So how to solve this. Well practically a number of small background images would be better than one large one. Also these should cover the airport and not a lot of surrounding real estate.

Reducing the color depth from a standard 4 bytes per pixel to 2 allowed me to increase the image size to 20km square at reduced image quality and color depth. However performance of the graphics engine that ADE uses is total crap with this size of image.

So to the questions:

What do y'all want ADE to do?

Stop the loading of large images? Well it has to do that since the underlying graphics throws an error.

Allow users to try and load images to cover larger areas by reducing the color information in the image

Or......

Certainly warnings will now be based on the area an image is being asked to cover rather than the size of file on disk.
 
Personally, now that I understand the issues, I haven't had any trouble working around them
 
Well, I do not have any problems loading 7,5 km2 bmp's with file sizes over 50MB (ADE 1.50). Guess this is due to my powerful computer, with lotsa RAM and SSD's all the way.

I get some stuttering when zooming in now and then, but I can live with that.

Cheers,
:stirthepo
 
Hi Jon:

Perhaps an option might be conversion of source imagery input by end users into Progressive JPEG (8:1 to 10:1 compression ratio) versus Lossless JPEG (2:1 compression ratio) in conjunction with slicing of the original image into tiles placed on the geographic coordinates of the FS Quad Matrix grid NW corners or Area Point 'centers' without alpha blending ?

http://en.wikipedia.org/wiki/JPEG

http://en.wikipedia.org/wiki/Lossless_JPEG



BTW: I'm not sure if this option for storage of converted source imagery would alleviate the run time display memory issues, but I found this treatise on the "Flashpix" and "Microsoft's (COM) structured storage format which stores hierarchical data in a single file" rather intriguing (...as a possible description of the 'new' FSX SDK Resample BGL custom land class photoreal imagery tile format ?) ;)

http://en.wikipedia.org/wiki/FlashPix

http://www.isprs.org/proceedings/XXXIV/5-W10/papers/georgoul.pdf

http://www.hackerfactor.com/blog/index.php?/archives/271-JPEG-Application-Blocks.html

http://www.fileinfo.com/extension/fpx

http://en.wikipedia.org/wiki/COM_Structured_Storage



Alternatively, a Flashpix extension of the EXIF file format might allow geo-tagging of multi-resolution imagery tiles:

http://en.wikipedia.org/wiki/Exchangeable_image_file_format


Hope these ideas might prove helpful to the innovation and 'imagineering' process for ADE ! :)

GaryGB
 
Last edited:
Thanks Gary but the real issue is where the image hits the screen. This is all pixels and no image compression or other tricks or formats will help once we get that far. The size calculation is simple but brutal. Multiply width by height by the number of bytes per pixel needed to render the color palette. The resulting calculation represents the number of bytes of contiguous memory needed. If the system can't find it then poof! - an error is generated by the code trying to create the bitmap to fit the space and it is all over.
 
(excuse my ignorance)

Would a 64bit compilation help with memory allocation at all, or is it just a 'graphics handling" thing.

It sounds like an annoying issue.

I presume that programs like Globalmapper get around this because they are written in something else?
 
It is certainly a consequence of the development environment used. I expect that I could get better memoery allocation if I used something closer to assembler where I could manipulate memory directly. I will look to see if there are any ways to do this by going out of the managed code into something else. However, in the end, unless I change the ADE graphics engine entirely I am a bit stuck. I am not sure that 64bit would help at all. I suppose if I were to release a 64bit version then there might be some gain. However I can safely create images up to 20km square in the development environment by reducing the number of bytes used for color rendering. I would hope that a 20km square image should be big enough for most users. Also it is better to have a series of smaller images rather than one large one.
 
You must log in or register to reply here.
Back
Top