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

WGS84 imagery stretched

  • Thread starter Thread starter Aviasim
  • Start date Start date
A

Aviasim

Guest
I have my satellite image projected to WGS84 - currently it aligns perfectly.

However - it's getting a pain to edit because the projection stretches the image - so the question is:

How do I make the image so it isn't stretched by using the same system (WGS84)?

Thanks in advance
 
Hello:

For scenery to be accurately sized / shaped / placed within the FS 3D world in relation to the real world:

3D Modeling including G-Polys and airport object creation or placement via a BGL compiled by SDK BGLComp.exe, requires background imagery to be in a cartographic GIS 'projection' format that is "non-warped":

EPSG:3857

https://spatialreference.org/ref/sr-org/epsg3857-wgs84-web-mercator-auxiliary-sphere/



Terrain object creation or placement including imagery and other land class to be compiled by SDK Resample, as well as CVX vector objects to be compiled via SDK SHP2VEC, requires background imagery to be in a cartographic GIS 'projection' format that is "warped":

EPSG:4326 (aka Geographic Projection / WGS84 Datum)

https://spatialreference.org/ref/epsg/wgs-84/


NOTE: This cartographic projection format typically appears vertically compressed, horizontally 'stretched' and often rotated 1 to 3 degrees in a counter-clockwise direction ...for geographic locations in the Northern Hemisphere.


The FS rendering engine will "un-warp" this type of scenery content to fit onto the terrain vertices in the FS 3D world fixed grid system of quads, which have a variable size and shape depending on where they are located on the globe.

fsx_sphere_6_root_quads_extruded-jpg.30310


IIUC, you are able to use GIS software, based on your posts in this prior thread:

https://www.fsdeveloper.com/forum/threads/how-to-georeference-an-image.443658/#post-806485


I would recommend using QGIS or Global Mapper to re-project imagery to a CRS any current scenery content tasks require.

https://en.wikipedia.org/wiki/Spatial_reference_system


CAVEAT: I would NOT attempt imagery alignment via "rubber-sheeting" features or "trial-and-error" with coordinates


Hope this helps. :)

GaryGB
 
Last edited:
Could I translate this in: resample and then use ADE to put in the ground polys at their right place in top down view and connected through FSUIPC???
 
Indeed, that may work. :scratchch

If the imagery source files for SDK Resample are:

* projected to EPSG:4326

...and:

* correctly Geo-referenced (aka "calibrated") in the *.INF file

...FS will display it non-warped at run time in a flight session linked / connected to a FS utility such as ADE ...via FSUIPC.

GaryGB
 
Gary, thanks for your answer but it really confuses my question.

The original imagery was not warped or compressed but was in the wrong projection (not WGS84)
It only stretched after converting to WGS84.

I know from experience that previous imagery data has not been stretched in any way on a few of my recent projects and the ini included all the lat/lon points.

I want to do this because it's becoming a pain to apply a GTF to the images every time I edit.

I know how FS is drawing it all - I don't want to re-learn this just HOW TO MAKE THE IMAGE NON STRETCHED
 
Edit it in it ‘non stretched’ form, then convert it to WGS84 when you want to export it to the sim. It will be stretched in WSG84 projection ( possibly) unless you’re on the equator.
 
Hi there,

the trick is to ensure that the pixel dimensions are equal in the X and Y directions. Global Mapper offers this option when exporting imagery ("always generate square pixels") and other GIS packages should do so as well. The downside is that this increases your working image size by a bit, depending on latitude, but it's usually not too bad.

Note that this is only for the benefit of working on the source in Photoshop etc., it has no influence on the compiled bgl whether you use square or rectangular pixels because resample.exe deals with either as long as the .inf file is coded correctly.

Cheers, Holger
 
https://www.fsdeveloper.com/forum/threads/wgs84-imagery-stretched.445878/post-827547

Gary, thanks for your answer but it really confuses my question.

The original imagery was not warped or compressed but was in the wrong projection (not WGS84)
It only stretched after converting to WGS84.

I know from experience that previous imagery data has not been stretched in any way on a few of my recent projects and the ini included all the lat/lon points.

I want to do this because it's becoming a pain to apply a GTF to the images every time I edit.

I know how FS is drawing it all - I don't want to re-learn this just HOW TO MAKE THE IMAGE NON STRETCHED

Indeed, manually using a QGIS *.GTF file to write Geo-referencing into a *.TIF to restore it the GeoTIFF can be a 'pain'.

IIUC, this is necessary because: you edit GeoTIFF imagery source files in a graphics application (which deletes GeoTIFF Geo-referencing info).



After source imagery is formatted to:

EPSG:4326 (aka Geographic Projection / WGS84 Datum)

...AFAIK, if you also use Holger's work-flow in Global Mapper to output GeoTIFF imagery source files with "square pixels", you should have a image to edit which is 'somewhat' less "warped" (aka "stretched" by WGS84 Datum GIS format).

Provided that you never change the total number of pixel Rows and Columns in the source image during editing, there is a way to eliminate a need for manually using a QGIS *.GTF file to write Geo-referencing back into a *.TIF to restore the GeoTIFF internal data structure tags.

FYI: This is another work-flow that Holger has kindly shared with us in the past: :teacher:

* Keep the Geo-referencing for source images within the *.INF itself, even when working with GeoTIFF files.


That way when the source files and the *.INF are submitted to SDK Resample, all that is required is for the edited source files be present in the same folder with their original file names (and cartographic projection format) un-changed from that file originally listed in the *.INF.

This should work regardless as to whether the original GeoTIFF files have lost Geo-referencing tags as edited *.TIFs.


This can easily be done by using Ollyau's GeoTIFF to INF:

https://www.fsdeveloper.com/forum/resources/geotiff-to-inf.119/


Hope this helps with making your work-flow less of a "pain". :)

GaryGB
 
Last edited:
To put this into perspective:
It is a matter of making a distinction between editing the downloaded/purchased satellite imagery and afterwards putting in all the ground poly, scenery objects and the rest.
In my experience, every time you load your originally downloaded image, edit it and save it once more, it becomes degraded a bit (in all paint programs you do see this).
I suggest you use the downloaded (warped) satellite image and convert it to at least a 32 bit image and then work on that warped one before changing it back to a regular 24 bit warped one.
Always do the seasonal changes and other adaptations (like getting rid of the shadows, etc.) from this 32 bit warped one.
Once you have good 32-bit seasonal warped images, blend masks and water masks made from those, change them back to the 24 bit (for the seasonal and night textures) and make those blend and water masks 8 bit ones (still warped as it does not matter they are).
Only then you resample and (as I said before) use ADE or whatever program, to add ground polys.
But maybe I still did not grasp the problem Aviasim wanted to express?
 
Last edited:
Hi guys,

most source imagery is supplied in a metric projection, like UTM, with the pixels having the same dimension in meters, like 1m or 0.5m. Once this gets converted to Geographic/WGS84 the units change to decimal degrees and the X and Y dimensions are no longer the same because the meridians (longitudional lines) converge towards the poles making the pixel's width dimension change with latitude. That is what leads to the distortion of the imagery when viewed in an image editor like Photoshop that assumes that pixels have the same dimension in both axes: squares turn to rectangles and circles into ellipses.

I assume that is what Aviasim means by "stretched". To get around this one can artificially match the Y axis dimension of the pixel to that of the X axis and that's what the "always generate square pixels" function I mentioned above does. It can also be done directly in Photoshop (Image > Image Size) if one knows the X and Y pixel dimensions of the reprojected image and thus can calculate the factor to increase the Width by.

Cheers, Holger
 
Back
Top