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

[Minivation]

Hi,

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 4.5.14.34698
(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):

[Source]
Type = MultiSource
NumberOfSources = 4

[Source1]
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

[Source2]
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

[Source3]
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

[Source4]
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

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

 

[GaryGB]

Hello:

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

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

https://library.avsim.net/esearch.php?CatID=fsxsd&DLID=140539


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

Resample.exe "Pixel width and height must be greater than zero" - Google Search

GaryGB

 

[=rk=]

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.

 

[arno]

Hi,

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.

 

[arno]

Hi,

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

 

[GaryGB]

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:

GeoTIFF to INF

Description This program parses the metadata of a georectified image and allows the user to create an INF file containing the positional data of the image for use with the FSX Resample tool. This allows the user to edit the source imagery...

www.fsdeveloper.com

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


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

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.

GaryGB

 

[arno]

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.

 

[GaryGB]

Hi,

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.

'An Ounce of Prevention Is Worth a Pound of Cure'

Many things in life require careful thought and preparation. Sometimes we need to be cautious and take precautions. A great expression for that kind of behavior is, “An ounce of prevention is worth a pound of cure.”

learningenglish.voanews.com

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.

GaryGB

 

[JRobinson]

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

 

[GaryGB]

Hi Jim:

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

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

XML files

Hi Jeff, Which files from the XML folder does SODE read? I had an issue with duplicate objects while testing some things and I got the impression that the backup file made by my text editor (with the extension xml~) was also still read and processed. Could that be the case?

www.fsdeveloper.com

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

GaryGB

 

[Minivation]

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

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!

 

[JRobinson]

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?

 

[arno]

Seems more people encountered this calculator bug:

Copy paste result contains hidden character · Issue #504 · microsoft/calculator

Describe the bug Copy paste result contains hidden tailing character U+202C which can cause syntax errors to programming languages or breaks in Excel. Steps To Reproduce Steps to reproduce the beha...

github.com

 

[rhumbaflappy]

Ouch. That's a real problem between the calculator results and the text editor.