Experimenting with AeroScenery

Makes sense
Levels are for LOD so if not using higher levels why use them

Save processing and disk space

Need to tune LOD/Levels to most common flying senarioes

To retain immersion, divert immersion breaking stuff

Quote from IZ0JUB

using ONLY levels 9 and 12

Which resolution did you choose, 2.3m or 4.6m?

Indeed, it seems that a level13 is needed for a 2.3m resolution to keep the picture sharp adequate.

Of cause its all a question of height how long it keeps sharp.

Quote from IZ0JUB

Tonight as an experiment I made one large size 9 scenery tile

Hello Michael,

regarding the duration of tile generation, I made a benchmark for you.

Area: Birnigham (no water tiles) Size 9 with 2.3m resolution.

Specs: CPU I7-6700K @4GHz, SSD+SSD, 32GB DDR4 RAM, GTX 1070, 100 MBit Internet Access

Downloading: 4min 30sec (with average 0.75MByte/s)

Stitching: 1min 30 sec

Geoconvertion 9,10,11,12: 17 min

Geoconvertion 9,12: 6.5 min

Geoconvertion 9,10,11,12: 7min

Please see the caching effect of conversion 2 and 3. (I did not close Aeroscenery between them)

So it seems, that the additional time for tile 10 and 11 only adds a small amount to the conversion time.

This also gets clear when you look at the count of tiles depending on level:

Lev9 = 1 tile

Lev10= 4 tiles

Lev11= 16 tiles

Lev12= 64 tiles

I did not convert Lev13 with 256 tiles, though that would be adequate to 2.3m resolution.

The tile count increases by 2x2 from step to step.

Thank you Michael for publishing your benching values too.

So it seems, that our geoconvert speed up to level 12 is nearly identical.

You are right, as a typical low height flyer, I normally prefer 2.3m with Lev13, but that takes time and produces bigger files. But it is worth the effort imho.

I can't think of a good reason why GeoConvert is so slow to be honest. Most of us are running it on really fast PCs and SSDs.

6 and 8 core chips should chew through this stuff if it's multi-threaded.

Even if you're resampling, converting an image format, compressing, and cutting up a large image into smaller chunks it's hard to end up at 2 hours unless you're doing thousands or tens of thousands of operations.

When I first wrote AeroScenery I said that IPACS should just open source GeoConvert so the community can fix it and optimise it. It's clear that IPACS don't have time to, which is understandable. I still stand by that.

Quote from nickhod

I can't think of a good reason why GeoConvert is so slow to be honest.

Hello Nick,

thank you for pointing out that Geoconvert is unnecessary slow.

I assume you get similar results when you run the bechmark as Michael and Me did them?

Please see details in #7: Experimenting with AeroScenery

Quote from TomSimMuc

Hello Nick,

thank you for pointing out that Geoconvert is unnecessary slow.

I assume you get similar results when you run the bechmark as Michael and Me did them?

Please see details in #7: Experimenting with AeroScenery

I'll benchmark it when I get a chance, but yes, it's just as slow for me too.

Hello Michael,

how is your setting of brightness? It looks a bit too dark.

Best regards from Bamberg, Germany

Thomas

Aeroscenery left corner settings -> right side Image Processing -> Brightness. i raised them up to +30 . contrast + 20. but i was experimenting also many times

this are my settings for covering bigger areas

Those sliders are THE chance to make the orthos more vivid and life without any punishment on the processing time.

You can even load a reference picture from the recent download, see direct live your adjustments on it and then start the stitching, aid and geoconversion.

With only those checkmarks set.

Alternative procedure:

You do the stiching, including the brightness/color correction.

Then you open the stiched files with PS or Gimp to remove cloudes, planes on airports etc.

Then you only checkmark aid and Geoconvert und START (the conversion)

But my setting don't works in areas with ice, glaciers etc. omg Paine National Parc in Chile is horrible.