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

P3D v4 Resolved: Resample.exe "Pixel width and height must be greater than zero"


After hours of trying to solve the problem, I'm stumped.

When I try to compile some photoscenery with resample.exe, the compiler throws an error as follows
D:\Backup 20200516\Prepar3D Projects\Scenery - Norfolk Intl Photoreal>"resample.exe" "KORF_PS_2.inf"
Lockheed Martin(R) api_strings
(C) Lockheed Martin. All rights reserved.

Resample Info File: 'KORF_PS_2.inf'
[Source] Type = 'MultiSource'
[Source] NumberOfSources = 4
[Source1] Type = 'BMP'
[Source1] SourceDir = '.'
[Source1] SourceFile = 'KORF_PS_Summer.BMP'
[Source1] Layer = 'Imagery'
[Source1] Channel_BlendMask = '3.0'
[Source1] ULXMAP = -76.218511
[Source1] ULYMAP = 36.910349
[Source1] XDIM = 5.343000
[Source1] YDIM = 0.000000
[Source1] Variation = 'April, May, June, July, August, September, October'
Pixel width and height must be greater than zero.
Unable to open data source 'D:\Backup 20200516\Prepar3D Projects\Scenery - Norfolk Intl Photoreal\KORF_PS_Summer.BMP'.
Failed to create data source.

D:\Backup 20200516\Prepar3D Projects\Scenery - Norfolk Intl Photoreal>pause
Press any key to continue . . .

I have two daytime images (summer and winter), one nighttime image, and one alpha. The INF file, the four image sources, and the Resample executable are all in the same folder: D:\Backup 20200516\Prepar3D Projects\Scenery - Norfolk Intl Photoreal

The images are 6000px wide and 6779px tall. They are saved in 24-bit BMP.
The photoreal boundary coordinates are: (N) 36.910349 (S) 36.881381 (N-S difference) 0.028968 // (E) -76.186453 (W) -76.218511 (E-W difference) 0.032058

What stumps me is that the error - presumably caused because the computer thinks my xDim and yDim values are 0 (or otherwise invalid) - is that the compiler thinks that my xDim = 5.343000, which is =/= 5.343e-6. Equally weird is the compiler thinks my yDim is 0.000000 when I clearly put 4.27...e-6.

I've successfully compiled multiple photoreal files in the past with smaller xDim/yDim values (as low as 1.5...e-6) and I can confirm that those projects still compile OK.

Could anyone perhaps point me in the right direction regarding this issue? Am I missing something?

Thanks much in advance.

The INF file is as follows (also attached for your convenience):
Type = MultiSource
NumberOfSources = 4

Type = BMP
Layer = Imagery
SourceDir = "."
SourceFile = "KORF_PS_Summer.BMP"
ulxMap =-76.218511
ulyMap = 36.910349
xDim = 5.343‬e-6
yDim = ‭4.27319663e-6‬
Channel_BlendMask = 3.0
Variation = April, May, June, July, August, September, October

Type = BMP
Layer = Imagery
SourceDir = "."
SourceFile = "KORF_PS_Winter.BMP"
ulxMap =-76.218511
ulyMap = 36.910349
xDim = 5.343e-6
yDim = ‭4.27319663e-6‬
Channel_BlendMask = 3.0
Variation = November, December, January, February, March

Type = BMP
Layer = None
SourceDir = "."
SourceFile = "KORF_PS_Alpha.BMP"
ulxMap =-76.218511
ulyMap = 36.910349
xDim = 5.343e-6
yDim = ‭4.27319663e-6‬
SamplingMethod = Gaussian
NullValue = 255,255,255

Type = BMP
Layer = Imagery
SourceDir = "."
SourceFile = "KORF_PS_LM.BMP"
ulxMap =-76.218511
ulyMap = 36.910349
xDim = 5.343‬e-6
yDim = ‭4.27319663e-6‬
Channel_BlendMask = 3.0
Variation = Night

DestFileType = BGL
DestDir = "."
DestBaseFileName = "KORF_PS_2"
LOD = Auto
CompressionQuality = 95
UseSourceDimensions = 1


  • KORF_PS_2.txt
    1.1 KB · Views: 148

You may wish to review this excellent tutorial by Luis Feliz-Tirado: :teacher:

Make photo-real ground textures


File Description:
It is very easy to create your very own high-resolution, custom (photo-real) ground textures. This document explains the concepts and techniques and illustrates the use of SBuilderX with which you can quickly and easily download aerial images and make this type of scenery. So, why hesitate? Make Flight Simulator scenery as real as it gets! Very sorry - no support of any kind is offered. Please do not write. For any questions, please post in the Avsim Scenery Design Forum.

Filename: make_photo-real_ground_textures_in_fs_x.zip
License: Freeware
Added: 21st November 2009, 23:20:06
Downloads: 17714
Author: Luis Feliz-Tirado
Size: 2143kb


You may also wish to review the results of this Google query:

I'm pretty sure Luis did not go into detail about compile errors - or I'd remember, because then the document would be reference instead of a tutorial; but, if you need someone to type in your problem, click search and post the link to those Google search terms, we're done here! If you'd like to talk about other things, I'd like to know what you've tried already. When I hit compiler errors like that, I usually try variations and simpler compiles, until I discover the cause. In fact I am quite confident I've encountered that particular error message and I'll have to apologize for forgetting the solution, but that's the adventure of discovery.

The first thing I noticed is that the number of decimal places for the yDim value, seems too high. It seems odd that the x axis dimensional multiplier is such a large, whole number with only 3 decimal places, while the y has almost 3 times as many places. I know these values are arbitrary, but it would be a simple explanation as to why the compiler outright rejects that value and reports it as zero. Another thing I am not comfortable with, is the scientific notation. I am not claiming it to be wrong, if you know it works from previous complies, but another thing that I notice happens, is that the compiler strips the notation entirely, so we are left comparing 5.343 to what would be ‭4.27319663, if it had not been stripped. Now I hope we are not treading out into uncharted waters, when I point out that 5.343/‭4.27319663, works out to be a very different ratio from 5.343‬e-6/4.27319663e-6‬. So something is going there.
Finally, I believe you can express these values as entirely whole numbers, without the notation and I would attempt a compile in that configuration. If you could say how you gathered your images, software used and procedure, that might help also.

Just opening the txt file you attacked shows that there are weird characters before and after the yDim value. Probably from some copy paste. I'm quite sure that removing them will fix your issue.

To clarify my post, I happened to open the TXT file on my phone first, where it shows the weird characters. Now on my laptop in either Notepad or Notepad++ they are not visible, but you can see that there are two characters between the = and the start of the number by pressing the right arrow key and watching the cursor (you need to press twice to move the one space).
I agree with Arno's observation that there 'could' be an issue with the format of ASCII characters for parameter values read by SDK Resample in the *.INF.

Due to the late (or was that 'early'?) hour in which I replied, I did not attempt at that time to post a more explicit reply for the OP or submit an edited *.INF.

When one reviews the LFT tutorial linked above (which IMHO contains so much useful info that it might also be regarded as a 'reference'), it will become clear that Luis shows use of 8-Bit TIFF (*.TIF) files for Blend and Land-Water Masks with SDK Resample as an alternative to the *.BMP format.

Although technically one can use *.BMP for Masks when working directly with SDK Resample, this would prove complicated when compiling via SBuilderX GUI.

I recommend the OP make GeoTIFFs from copies of his source *.BMP files in a GIS application, then process them in ollyau's GeoTIFF-To-INF utility: :idea:

Note that the SDK Resample 'Type' parameter value in the *.INF file output by GeoTIFF-To-INF will substitute "GeoTIFF" for "BMP". :pushpin:

In the event that the OP is not ready / willing / able to convert all his copied EPSG:4326 GIS-projection format *.BMP source files to GeoTIFF, he may be able to copy his WGS84 Geographic coordinates and xDIM ,YDIM parameter values from the [Source] section of the *.INF output by GeoTIFF-To-INF for his
"KORF_PS_Summer.BMP" input file, and utilize it for his other sources in conjunction with the UseSourceDimensions=1 parameter value in his [Destination] section of that *.INF.

This appears permissible as IIUC, all listed *.INF input sources appear to be treated as 'identical' in Geographic extent of coverage and Pixel dimensions based on the info provided by the OP's original *.INF 'attached' above (which, BTW, I had not "attacked" in my reply above :laughing: ).

That method would still require individual Type parameter values for the actual submitted file format within each source sub-section of the multi-source *.INF.

Working with GeoTIFFs to compile custom photo-real imagery land class BGLs makes ones task easier with less at risk for errors and troubleshooting. :)

Last edited:
Gary, why all the advice to change the images if the only issue is that the ING file has an invalid character? Sounds like a lot of work to change all images, while that is not needed at all.

After hours of trying to solve the problem, I'm stumped.

Gary, why all the advice to change the images if the only issue is that the ING file has an invalid character? Sounds like a lot of work to change all images, while that is not needed at all.

AFAIK, the OP is just learning to make custom photo-real imagery land class BGLs via the direct method with SDK, and had spent hours trying to solve the problem to no avail.

When I see that with a participant who to date has only 14 posts here, I am compelled to post info which will be more likely to prevent such issues from occurring again in his future endeavors. ;)

And again, he 'could' change a copy of only (1) submitted source image as detailed in the latter part of my reply above, to process via GeoTIFF-To-INF and thereby eliminate the potential of parameter value character format errors.

I must say, though, that the OP's familiarity with the procedure for working with a multi-source *.INF is already off to an auspicious start, and shows he has done considerable self-study. :)

Last edited:
Those weird characters actually appear to turn ydim= into a negative number if you open it in Notepad++ and do Encoding > Encode in ANSI
Hi Jim:

Indeed, the OP does not state which text editor he is using. :scratchch

Another CAVEAT to consider when working with text editors to be used with the FS SDK is discussed here: :pushpin:

Use of NotePad++ would seem to be another way to prevent future problems when working with the FS SDK. :idea:

Last edited:
Hi again all,

Wow, thank you everyone for your incredible help! Given the fact that I made this original post at 3AM, I went ahead a slept in a bit this morning :coffee:

It appears the suggestion about the encoding of the INF file may have been the culprit. I use Notepad++ as my default text editor, and yes, while I have tried troubleshooting the problem by looking for any anomalies in the file using different text editors, I did not realize all of them were set to UTF-8. When I selected ANSI, the following appeared (the values may be a bit different / use different notations and sig. figs because I've tinkered around with them a bit since)
xDim = 0.000005343
yDim = 4.2731966366720755273639179820032e-6‬

Switching the program back to UTF-8 hides the "‬" at the end.

Another example, using the original resolutions I was working with (23904px wide, 27009px tall), is as follows:
xDim = ?1.3411144578313253012048192771084e-6?

So, what causes this?

I use Windows 10 and most of my casual calculations are done on the default Windows calculator. As it turns out, when I use the "Select All" function on the Calculator's drop-down menu, the value shown on the screen seems to copy normally when viewed with UTF-8, but when using ANSI, it shows the two "?"s, one before the copied string and another after it. If I manually highlight the number and copy it, the problem does not manifest.

Also, thank you for the pointer to the tutorial. That tutorial has actually been critical in my scenery development hobby as I used it in 2013 when I compiled my first scenery. I downloaded it again because it serves as a great reference just in case I'd forgotten something over the years (I touch base with scenery development on-and-off over the years)

To that end, I've been able to successfully compile the abovementioned file as well as a derivative of it using slightly higher image resolutions (xDim and yDim ~ 3e-6).

Again, thank you all for your help. I greatly appreciate it!
I should add that the txt file looked perfectly normal in Notepad++ until I did Encoding > Encode in ANSI. I'm a TextPad person actually and TextPad squawked about the characters and the encoding when I first opened the file.


EDIT: And BTW after TextPad converted them to "the system default" it looked like this: yDim = ?4.27319663e-6?
Last edited:
Ouch. That's a real problem between the calculator results and the text editor.