Beyond 4.75 m/pixel

[Guest flightsimstudios]

Hey can we please make sure that everyone uses 4.75m/pix as 4.8 is not the FS standard and will produce error in drifting images when images are converted... This is confirmed by the SDK's.I've already emailed Elrond about this as his tool is incorrect in it's calculations... We should be using 4.75m per pixel *not* 4.8...This is highly crucial! My tests showed that 4.75 will produce a 100% accurate lat/lon image, 4.8 will make the image drift further and further away from the correct lat/lon over long distances...I have tested the data with both GPS and Terraserver against what the SDK resample.exe produces and I can confirm that 4.75m is correct and everything lined up exactly in the gps, terraserver and FS for the exact same co-ordinates...I'd encourage everyone no to refer to FS using 4.8m per pix, this is wrong... It's 4.75.

[Guest cathay]

can you give us two sample images to show the differences please?

[arno 1]

Hi Dean,I think it is not that simple. The size of a LOD square depends on the longitude as well. If I did the maths correct (and using the earth model as given in the Fs2000 SDK) you would get a texture size of:4.77x6.36 meters at the equator4.77x4.09 meters at 50 degrees longitudeSo we can't speak of one exact size for the entire world.EDIT: Calculation error fixed

[Guest flightsimstudios]

I can't exactly give the 4.8m image sample. I'll try and post the 4.75 examples though when I get a moment... Will have to pull the images from one server and post them to another...But it's in the SDK's... 4.8 came about because it was a best guess that was estimated before the SDK's came out... The SDK's make it very clear that 4.75 is the correct value.

[Guest flightsimstudios]

Resample takes that into account and it's based on the WGS84 reference datum... 4.75 is correct and Australia is very far south what I am saying is true, and it can be proven with any location in the world if WGS84 reference datum is used...My images were 100% spot on... I even had a guy go out and take a GPS reading on the other side of the world and was able to verify the correct location...FS Resample tools helps get the correct dimension data for the cell pix but the 4.8 value will give you image drift...I'll see what I can do to compile a 4.8 vs 4.75 image... It'll just take me a while I want to finish up my 'home' city which is now on the other side of the world to me...When I used the 4.75 data it was so accurate, I was able to replicate every single lat/lon within the sim and it matched exactly what I saw in terraserver when I input the exact same data... Which is exactly what my friend's GPS showed his location to be.We did some specific tests that would be visually traceable in the satellite imagery (i.e. a large square object i.e. corner of a tarmac) that will also be visible at 4.75m resolution... I guarantee you what the SDK's say about 4.75 is correct. I've verified it and it's easily replicated...

[arno 1]

This is what the terrain SDK lists for LOD13:LOD 13Sample Size Meters 4.8Lat Deg Boundaries 0.010986328Lon Deg Boundaries 0.014648438Span Meters 1223Divide the 1223 by 256 and you will get 4.77 meters. But as a LOD square has a fixed size in degrees the size in meters must change with the position on the earh as well.

[Guest flightsimstudios]

Forgot to mention though, the SDK mentions that it is set up to use images that are aligned to the WGS84 reference datum... This means any images already have the distortion built into them. The photoscenery SDK says this, I am guessing you are using the FS2000 SDK or the terrain SDK but not the FS2004 phototerrain SDK which says:

It is assumed that the image has been projected to the WGS84 Latitude/Longitude datum. The latitude and longitude of the northwest corner of the image must be known as well as the spacing (in decimal degrees) between the image pixels. The north/south extent of each terrain texture pixel is about 4.75 meters in Flight Simulator 2004. The resampling process will filter the raw image to the right size.  If the raw image is more than 4.75 meters per pixel (low resolution), the final result may appear blurry.  If the raw image is less than 4.75 meters per pixel (high resolution), some fine details might be lost.

Arno, I don't know why you are arguing with me over this. You're constantly saying the FS2000 sdk says 'xyz' we're not talking about FS2000 anymore. We're talking FS2004 and I have proven with correct placement in the sim that what I am saying is true. There is no argument to be had, it is 4.75m pix period.

[arno 1]

It says the north/south extent of each terrain texture pixel is about 4.75 meters. I am not arguing about that, if you do the calculations exactly it is 4.77 meters (the 1223 meter span as also given in the SDK divided by 256 pixels).What I am trying to make clear is that the east/west extent of each pixel is not fixed (that is not mentioned in the SDK either). This depends on the longitude on the earth.

[Guest flightsimstudios]

Arno, do you understand what the WGS84 projection is and what it entails?That is what the WGS84 datum addresses... All geocorrected WGS84 source images are already corrected for the compression, it's called ortho correction so that 'flat' images can correctly be placed on a round globe.Here's the images that prove the data I have stated is correct... 4.8m was completely off, this is how it turned out using the correct SDK data of 4.75m per pixel... The 4.8m per pixel was over 50 meters off by the time it reached Brisbane airport, 4.75 was exactly where it should be, using WGS84 data.These images were tested by someone going out and getting the GPS readings first from the real world.. The data was put into flightsim and terraserver... All the results lined up and the person who took the readings says that it is all correct. 4.8m threw the image off to where this location was north west about 50-100 meters north west of where it should have been. Doing the math, of a 25cm difference for each pixel over a 50km distance proved the error and was how I was able to get the whole image aligned correctly... I read the SDK which mentioned 4.75, did the math, saw that the error was what was expected using 4.8m, changed the value to 4.75 and this was the result. Now I put in the GPS co-ordinates for my house which is about 30km further south and it was also dead on...

[rhumbaflappy 113]

The datum is not in question. It is the projection.Resample assumes the projection is geographic ( lat-long ). Any projection, such as UTM, that uses distance measurement as a projection should first be reprojected to geographic.The problem here is that the projection conversion can cause blurring in an image ( probably will ).Arno is simply stating that the lines of longitude converge at the poles... and this is quite evident in all versions of flight simulator. LOD13 areas all converge as well, as they are geographic in nature ( not based on distance measurement ). Each slice from resample is an LOD13 Area. The east-west distance near the poles is quite different than the east-west distance at the equator. North-south remains the same.This confusion of 4.8 meters sizing has been caused by the writer's of Microsoft's SDKs... they should have never even mentioned it. It's misleading.VTP, LWM, photoreal and landclass are all geographic in projection.Dick

[Guest griss0m]

hi Dick :-wave i understand lat (north-south) stays the same but is there a formula to get the optimal longtitude (east-west) texture resolution for resample.exe in degrees/pixel? i hope that made sense!i personally only use resample.exe for the texture naming and manually slice and sharpen the images in photoshop. A WAY better result!kind regardsmitch

[rhumbaflappy 113]

If you know the extents of the resample in latitude and longitude, you should be able to compute the degrees per pixel exactly. Each LOD13 ( each slice ) is 256 x 256 pixels.If you match that, then resample will probably "pass" the image for slicing without resizing... that's just how it behaves with mesh.Again, this has nothing to do with pixels per meter, but has to do with pixels per degree.A problem will arise when this is displayed on the sim, as the sim itself will restretch, or shrink, the slices to accommidate the difference in measurement width near the poles or near the equator.Look at this distortion near the poles in northern Greenland:http://forums.avsim.net/user_files/108816.jpgAs you can see, the sim will squish the LOD13 area near the poles. This is because even though the output from resample, or LWM or VTP is degree-based in measurement, the sim reprojects that on the fly to fit it's distance-based display. We can't do anything about that.Even if your image prior to resample was stretched or squished to approximate the final display, Resample will force square degree-based slices, and then resquish or restretch them as needed.Any LOD13 slice can be renamed and placed in the sim anywhere using a resample bgl, and it will "fit", as the sim decides the final stretching or squishing.... and will blur the resultant images as well, as the sim's ( not resample's ) algorithm decides.In addition, your monitor, and the screen resolution on your computer may also affect how the image looks, as well as the zoom factor of your viewport, and the underlying mesh!Dick

[Guest griss0m]

Thanks Dick!That was very helpful indeed. :D CheersMitch

[Holger 0]

Howdy,regarding the formula for calculating W-E distances: Joachim and I just discussed this a few weeks ago because he too was unhappy about the way meter distances are stated in the SDK. He found out that the latitude of equal pixel width and height (in meters) is at about 42 degrees. Using that as a starting point I would give the formula like this:W-E distance (meters) = N-S-distance * cos(latitude) * 1.3456with 1.3456 being the correction factor for having equal width and height at 42 degrees: 1 / cos(42)Using half of the 40007.0km polar circumference as a base (Creating Terrain SDK, p. 18) and the latitudional degrees from the LOD table (1 pixel = 1/256th of a LOD13 Area) we get 4.76920 meters for the fixed N-S dimension of each image pixel.Using the above formula we can determine, for example, that a pixel at the equator will be 6.42 meters wide and at 80 degrees latitude only 1.1 meters.Again, though, these meter values are just for reference because resample.exe uses fractional degrees only for its computations.Cheers, Holger