Region-based ground overlays tend to be somewhat glitchy
Jonathan van Tuijl
GE:
http://earthobservatory.nasa.gov/Newsroom/BlueMarble/
After finding (read: programming) a way to resample and tile an image
of nearly 4 gigapixels, and generating tens of thousands of KML files,
it finally appears. From a distance it looks much better than a bunch
of high-res sources stitched together, but the experience can't quite
match that of the base imagery. When moving quickly I can occasionally
look at the base imagery before the overlays appear. Sometimes
overlays never appear at odd angles due to the limitations of (min|
max)LodPixels. Always 'showing' the lower-res images would help there,
if it wasn't for the bad performance and odd behavior of 7 overlays on
top of each other. That solution also prevents me from looking at the
standard imagery as I get closer. Currently I stack about 3 overlays
(maxLodPixels=8*minLodPixels) because it doesn't completely kill
performance and doesn't glitch nearly as much as fewer either, but
it's still nothing like the base imagery. Is there or will there be a
better way?
For your information, if you want an example, I don't have serious
hosting with enough space. I can describe the patterns, of course.
Jonathan
ManoM
Have you look at Regionator? http://code.google.com/p/regionator/
It embodies a lot fo what we think of as best practices in using
Regions.
Any time you deal with large image files, there will be problems, but
you can minimize them. The most effective thing that people find is
using quadtrees to break up the data.
If that's not helpful, maybe you could upload a small sample of what
you're working on?
ManoM
Jonathan van Tuijl
post here because it started out as something mostly inappropriate
here. Summary:
- The idea of trying a PhotoOverlay with an ImagePyramid just to check
performance. I also thought of that, but I don't think it will tell me
anything I didn't know already.
- Did I see this?
http://bbs.keyhole.com/ubb/showthreaded.php/Cat/0/Number/761485/page/vc/vc/1
http://onearth.jpl.nasa.gov/KML.html
No. After checking the differences all I can conclude, if anything, is
that it's smoother because it can't deliver the data rapidly.
- Most large overlays don't use maxLodPixels yet don't hit performance
as hard as my attempt at a stack of many levels. Perhaps some related
but different factor made it slow.
- Regions slightly larger than the overlays might help reduce
glitchiness (if it actually gets to load images ahead sooner and
doesn't choke on even more images), but without maxLodPixels you
wouldn't need that.
- Speculation that PNG loading slower than JPEG could have a
significant impact on performance. Especially now that I think of how
libpng (GE seems to use it indirectly) isn't optimized much for the
PowerPC.
Barry, add anything I didn't mention that you think is important.
ManoM wrote:
> Have you look at Regionator?http://code.google.com/p/regionator/
> It embodies a lot fo what we think of as best practices in using
> Regions.
As far as I can tell I'd still need some way to scale and tile an
image several times larger than the virtual address space and MUCH
larger than can fit in physical memory. Generating the KML is a piece
of cake compared to that. I can see how the Regionator can help, but I
can already generate the files by other means now.
> Any time you deal with large image files, there will be problems, but
> you can minimize them. The most effective thing that people find is
> using quadtrees to break up the data.
I do use quadtrees for the most part. Only at the top level where I
could no longer halve the size to integers
(2^-7*86400x43200=675x337.5) I don't have any particular organization,
but there are only 18 links/overlays there (fewer should I switch to
larger tiles).
> If that's not helpful, maybe you could upload a small sample of what
> you're working on?
Only a large sample can really demonstrate the maxLodPixels problem.
Jonathan
Jonathan van Tuijl
while to process what's closer to terapixels than gigapixels on a
logarithmic scale. No maxLodPixels doesn't lead to problems, although
the framerate could be better. At view sizes around a megapixel this
so-called PowerBook easily drops to a few frames per second at times,
whereas the base imagery can display at or near the refresh rate (60
Hz) with few hitches.
At that framerate GE seems to delay terrain loading/synthesizing so
that after a large movement, the Earth is rather polygonal and often
otherwise deformed or ruptured for a few seconds.
Another problem at that framerate is that the mouse controls get very
sluggish (not the thing at the top right, but dragging the Earth and
such, especially rotating with the middle mouse button), as if it
drops movements. It also does that at higher framerates, but because
frames are shorter then it isn't as bad. The SpaceNavigator, on the
other hand, still feels very solid and works about as well as it CAN
work at low framerates. Should I take this part to a more general
group such as earth-help?
Jonathan