Overlays

[thorpie]

Hello
I am making png overlays from SRTM elevation data, currently using the 90 metre pixel size. There is a lot of transparent area on the png files created.
Google earth fades between the colors, so instead of getting a 90 metre square of one color it is fading up to the color from the adjoining pixels. Only the central point of the 90 metre pixel is the actual pixel color.
For pixels next to a transparent pixel (all are either fully transparent or fully opaque) it picks up the color allocated to the transparent pixel and fades in from that color.
I need sharp transitions between the pixel colors, particularly between the transparent and the opaque. Is there any way to sharpen the rendering of overlays so that they don't fade in and out between pixels?
Thanks

[Forkboy2]

Might help if you posted an example, but I don't think there is anyway to control that. Is there a reason you must use transparency?

[tpstigers]

I'm not really clear on what you're trying to do, so I'm not sure if this will help, but Microdem (http://www.nadn.navy.mil/Users/oceano/pguth/website/microdem.htm) works directly with elevation data (in a variety of formats), displays it many different ways, and exports it directly as a GE overlay. There's a bit of a learning curve, but if you work with elevation data a lot it's really worth the effort (and help can be found here (http://freegeographytools.com/)).

[thorpie]

I am working on a project to get the best assistance possible, using existing technology, from 1 litre of petrol over 1000 km.
One litre of petrol in a small engine will raise you and your bike 8000 metres vertically. To get assistance over 1000 km you need to drop at a consistent 0.8%. You drop at 1.6% your assistance is gone after 500 km. Travel on gradients much below 0.8% and you get no assistance. A 0.8% gradient going in the direction I want to go is what I need. It increases my speed by 5 km/hr, then I find short steep uphills to use the engine assistance on. Bike riding with no effort going uphill and 90% of riding down a gentle gradient.
Any slope greater than 0.8% provides two directions that drop at precisely 0.8%. I chose the closest to the direction I want to go. For each SRTM pixel I then color code. The code is how far off the direction that I want to travel that the pixel's best 0.8% gradient direction is. Red is going the exact direction I want, anticlockwise yellow is 60° off, green is 120° off, clockwise magenta is 60° off, blue is 120° off. We don't talk about cyan!
We restrict to whatever offset we want, 60° we show only between magenta through red to yellow. We then try to map routes through areas with lots of red. Eureka, supposedly, we have megametrelitre routes (assistance from 1 US. gallon over 2350 miles) using existing terrain.
Since I posted I adjusted a couple of things – I made the transparent pixels black by default rather than white. Then I made any transparent pixels that adjoin only one opaque pixel the same color. (This isn't any different than black, because the opaqueness fades in as the color does). Another adjustment has also alleviated the problem - I have made it so that you can chose how many pixels you calculate the slope's maximum gradient over. With only one pixel - 90 metres – it was too small a distance and I had a lot of pixelation. Now, for calculating the gradient, I can use the pixel 90, 180, 270 metres away, so I am getting larger swathes of similar color transiting slowly.
It is still problematic because the fade in on the yellows, from a the darkness underneath, makes it look green.
Kmz file showing two overlays for Melbourne, both heading into the city centre, one showing a 60° allowable offset the other a 15° offset. If you look closely at the green looking areas it is where yellow is fading in! There is also one small area overlay (10 * 90 metre pixels square) that I use for my testing that highlights it fairly well. This has no restriction on the angle so it shows lots of colors. The line with 3 dots is what I copy to my program to generate the bitmap and kml. The black dot is the “heading to” location..
Been using FreeImage for generating the overlays in VB6 (archaic, but simple) – it is absolutely brilliant!

[Appletom]

I need sharp transitions between the pixel colors, particularly between the transparent and the opaque. Is there any way to sharpen the rendering of overlays so that they don't fade in and out between pixels?
I think I'm understanding what you are trying to do. Do you want the graphic to look like this?

If so, you need to change the resolution of the png file - try making your squares 10x10 pixels. You might need to go up or down from there.

[thorpie]

I did as suggested, made a new bitmap a set factor larger. I copied over pixel by pixel rather than resizing (so I didn't end up with any artifacts from resizing methodologies)
A factor of 4 works wonderfully, even 2 works as well as expected. For some reason factors of 3 and 5 play up fiercely! All from the same one pixel size bitmap.
Using a factor of 4 increases the png file size by only 50%. I was concerned about how GE would handle large files (factor of 4 gives one file 3300 *2300). My GE Maximum Texture Size is 1024*1024, but it has no noticable depreciation.
Thank you immensely.