photoreal project (size issue)

[Guest griss0m]

hi there, :-waveit's been a while, (2 year absence) but i'm back into creating quite a large scenery area for FS2004! it's good to be back on avsim.com! first off.. if you've got half of your area as water and you've used an alpha mask, that area still counts as texture and takes up space right? so ideally it'd be better to use the smallest (LOD13) around these coastal/river areas? anyone working on a large scenery project? what size areas do you normally work with (LOD)? any other helpful formatting guidlines?it's late right now but i'm sure i'll churn out more questions tomorrow!kind regards,-mitch

[Guest flightsimstudios]

I'm working on a huge project right now, 7000 pix by 12000 pix... I'm trying to figure out the same questions...I can say though that the pixel size is 4.75m/pix *not* 4.8 as has been erroneously held... With 4.8m pix you'll get image drift the further away you get from your top left lat/lon...4.75 will nail it 100% accurate... I've done compares between FS, GPS and terraserver locations and all 3 match up over a distance of 100km... :)I'm trying to figure out how to crop my LOD when I have my top left corner outside of my LOD cell I want to start in...Also, I'm having problems with my water masking on cells that are out in a waterclass cell... They don't turn to water... :(

[arno 1]

>I can say though that the pixel size is 4.75m/pix *not* 4.8 as>has been erroneously held... With 4.8m pix you'll get image>drift the further away you get from your top left lat/lon...The pixel size depends on your location at the earth as well of course. The closer you get to the poles, the smaller the LOD squares becomes, but still one texture is mapped on it. So there is not a fixed value for the resolution.

[Guest flightsimstudios]

No it's all got to do with the GWS84 projection on the earth.... FS is coded to this datum and adjusts the pixel cell sizes accordingly.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...

[Guest griss0m]

>I'm working on a huge project right now, 7000 pix by 12000>pix... I'm trying to figure out the same questions...>>I can say though that the pixel size is 4.75m/pix *not* 4.8 as>has been erroneously held... With 4.8m pix you'll get image>drift the further away you get from your top left lat/lon...>>4.75 will nail it 100% accurate... I've done compares between>FS, GPS and terraserver locations and all 3 match up over a>distance of 100km... :)>>I'm trying to figure out how to crop my LOD when I have my top>left corner outside of my LOD cell I want to start in...>>Also, I'm having problems with my water masking on cells that>are out in a waterclass cell... They don't turn to water...>:(Get LodCalc (file library) for calculating LOD boundaries. That should stop the black border thing you'll be getting if your top left corner isn't completely filling a LOD tile.With water masks you'll need to fill in the alpha channel (which i assume you've done) AND on the image. Your satellite image should have pure black on the areas of water. Should work fine.-mitch

[Guest griss0m]

>No it's all got to do with the GWS84 projection on the>earth.... FS is coded to this datum and adjusts the pixel cell>sizes accordingly.>>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...i think what you experienced was 4.8m/pixel when the source image wasn't.. therefore distorting it larger than normal? maybe 4.75m/pixel was the correct res for your source image. because wether it's 30m/px to 4.75m/px if it's correct in resample the source image and projected in WGS84 everything should line up perfectly.we should be talking about degrees/pixel anyway with the WGS84 geographic projection.-mitch

[Guest flightsimstudios]

>Get LodCalc (file library) for calculating LOD boundaries.>That should stop the black border thing you'll be getting if>your top left corner isn't completely filling a LOD tile.>>With water masks you'll need to fill in the alpha channel>(which i assume you've done) AND on the image. Your satellite>image should have pure black on the areas of water. Should>work fine.>Thanks for the LODCalc reference... I'll give that one a shot...When you say pure black on the images, what I've got is the water has complete black on the alpha channel. are you saying the main image also needs to be pure black?I'll try and grab a screen shot to show how some tiles are turning to water and some LOD cells aren't, even though they are both coded with the exact same alpha channel (it's a large area)...In terms of the 4.75, 4.75 is the correct setting that resample.exe uses! Why are people trying to reinvent the wheel and claim something that the SDK clearly states that 4.75 is the correct value to use as well as making sure your data conforms to the WGS84 datum. What I have posted above is correct. WGS84 projection fixes the lat/lon dimensions. WGS84 is the key.You guys can dogmatically hold on to your beliefs but I have proven that 4.75 is the correct resolution to use and all the data lines up correctly. It is NOT region specific it is correct for the whole world because of the way FS is coded. If you guys don't want to follow the advice and instructions in the SDK then you will find that your images are not projected correctly and you will get drift and your satellite imagery will be wrong.

[Holger 0]

Hi Dean,I don't really understand your exasperation. I assume this 4.77 vs. 4.75 issue is just a matter of talking about different things.I'd like to know from you how exactly you enter or use the meter value in the process? All the photoreal projects I worked on were directly made with the help of .inf files, which never asks about meters. The important parameters are the NW lat/long input, the row/column numbers, and the resulting pixel dimensions in decimal degrees. Could you please outline your process for me? Perhaps that'll help clear up the misunderstandings?Cheers, HolgerP.S.: I also responded to your statement regarding maximum autogen density in the Flightsim forum - another misunderstanding, it seems ;-)

[rhumbaflappy 113]

From the FS9 SDK:Image RequirementsMore than likely, the image you want to use will be an aerial or satellite photo. The raw image must be either a 24-bit per pixel Windows .bmp file or a 32-bit per pixel Targa .tga file. For some file formats, you can use Imagetool (found in the Terrain SDK

[Guest flightsimstudios]

The designer of FS resample tools is the one who has been mislead... His calculations are completely off and the images using his tool *do not* conform to the correct standards because it is using 4.8m as a definition which leads to the placement being off by several hundred meters.This is the issue that needs to be addressed and resolved. He based his calculations on 4.8, rather than 4.75 which leads to huge errors in his tool.It simply isn't correct and the value of 4.8m per pix needs to be elimated from 'commonly' taught values.Most of the people I've been talking with have been dealing with mesh, not so much the phototerrain aspect.I've been able to get it right, so why are you questioning what I am saying. I have proven the data to be correct BY CORRECT POSITIONING IN THE SIM EXACTLY AS IT IS IN THE REAL WORLD.

[Holger 0]

Hi Dean,you still haven't answered our questions though: in which utility do you enter meter data? Even if there's a bug in resample.exe how could you change it if you can't enter metric values? Are you somehow adjusting the cell width/height input to adjust for the error?Knowledge is confirmed and accepted only if others are able to independently verify new findings or procedures. All you tell us is that we're supposed to use a different input value but you're not telling us how or in which tool. Cheers, Holger

[Guest flightsimstudios]

Hey Holger...I mentioned a couple of times but not clearly that FS Resample Tools is the tool I've been using. It's using a value somehow hard coded into its design as 4.8 for it's calculations. With those settings the placement and image resampling ends up totally off by several hundred meters over a 50km distance from the top left pixel.In terms of image resizing, as per the SDK if you use an image below 4.75 you will get issues with quality, same if you are above 4.75 on your source image. It is best to to do the main resampling in photoshop with a bicubic setting to help smooth out the image. For one this will help the GPU and memory on the videocard by providing less 'jaggies' the FS engine has to deal with when uncompressing and writing the images to the screen. resample.exe does resize the image, but very poorly... I'm planning on retiling my tiles in photoshop soon, to make things even smoother. If you smooth the image before it hits the FS graphics engine you will reduce file size on the images and also make the GPU work less hard... You end up with fewer blurries and less image popping.You can set the scale used for the image as per the SDK (it seems most have not looked closely at this detail), if your source image used feet you can put in a scale value (in meters) on the image before compile with resample. Say your image is a 4.75m source, you type in 4.75, if it's 1 foot per pixel (as noted in the 2004 SDK) type in 0.3xxx blah blah blah...When I get a chance I'll do up a demo of what happens in FS Resample Tools to prove what I'm talking about, an image speaks a thousand words...If you're hand coding the photoscenery though through the SDK only you will have done the homework for the tiles and pixel resolution cell dimensions, so all this doesn't matter in that type of case.The primary issue is FS Resample Tools. Using the two point image size tool. The author of the program seems to have some wrong values and it stems from the mistaken belief of 4.8 instead of 4.75 for WGS84 projected images. The LOD 13 cell may be 4.8, but the images are what the SDK's say and it is what MS has based all their calculations and math on. I'm still scratching my head as to why people want to ignore what is so clearly stated in the SDK.Give me a little time, I just fixed up my bounding issues for my LOD squares (ended up hand coding), and am currently enjoying my photoscenery from my old hometown..I'll post data soon to show what is wrong with FS resample tools and how the 4.8 value messes things up...

[arno 1]

OK, so we are talking about a tool that makes the INF file for you. As Dick and Holger have mentioned before as well, I have usually written my INF files by hand. And in that case you only have to enter the borders of your images in degrees and how many pixels your image is (as Dick already mentioned before). If the resolution of the image is 4.75, 4.77 or 4.8 does not matter for this information.Which version of FS Resample Tools are you using? I found a v0.95 beta, but that only had an option for meters or feet when dealing with the altitude data when making a DEM BGL file. I did not found any box to enter information for photo scenery.

[rhumbaflappy 113]

Mitch's original question asked about a minimum size for photoreal coverage in BGLs. To answer Mitch, 4 LOD13 areas is the minimum size. Resample actually deals with verticies, not the spans between the verticies. Any landclass or photoreal designation assigns a value to the vertex from Resample. So the minimum size possible is the 4 LOD13 Areas that touch a single vertex, for all landclass. I'll bet you didn't realize that photoreal is just a landclass value?The only thing special about it's production is that Resample stretches, crops, and names the slices in addition to creating the landclass BGL. The odd-looking names for photoreal are hardcoded for the sim for specific locations. The BGL just uses a landclass value to assign the proper LOD13 spaces for that type of landclass value. Value #252 is seasonal photoreal. Value #253 is non-seasonal photoreal. Value #254 is a null value.You can use TMFViewer to look at a photoreal BGL to confirm this.Dick

[rhumbaflappy 113]

Hi Dean.Apparently you are using Elrond Elvish's "FS Resample Tools" program.This program is a bit old. Honestly, some things were not as well known in late 2000 ( when Elrond developed the program ), as they are now. Most photoreal designers would not use this program.When we write of Resample, we are refering to Microsoft's Resample.exe, released with it's SDKs. 2 versions of resample are generally used: FS2000 SDK version and FS9's SDK version.Elrond's program actually makes an INF file from an image. Elrond, and others, in 2000, did not realise the importance of using image reprojection to insure the source image is WGS84 datum, and geographic projection.Elrond's program was an attempt to find valid image extents of an image using distance-based projection. That attempt is doomed to failure, as we now know. Using an image source that is based on meters/pixel will absolutely be distorted in the sim. The source image MUST be expressed as degrees/pixel... and for most image sources, that will require reprojection of the source to create a new image that is geographic in projection.I do not know the projection and datum of your source image, but if it is already WGS84-geographic, then Elrond's program will only give you the wrong INF data.The correct INF file can be made using the clues provided by the FS9 Niagara example, or you can search the forum for "inf" and "photoreal", and you should get a good idea of how easy it is to make such a file for use with MS' Resample.I assure you, Arno, Holger, and I are absolutely correct in our assertation that Resample cares NOTHING about meters per pixel. It only deals with degrees of latitude and longitude and the spans of the image ( which are the degrees divided by (number of pixels minus 1) ).Your use of Elrond's old program would be one cause of your problems. Another possible cause would be the projection of your source image.Dick