Project Orbiter texture tree tools (OT3)

[JMW]

When I have time I'll try to convert some larger areas sourced from here:
https://eol.jsc.nasa.gov/SearchPhotos/ShowQueryResults-ResponsiveImageGallery.pl?results=148007248430401

Bing does have some good detailed imagery at low level, but might be a bit finicky to copy.
https://www.arcgis.com/home/webmap/viewer.html?webmap=8651e4d585654f6b955564efe44d04e5

Using this, I was able to produce this result: http://snoopie.at/face/beta/heathSurf.zip

Nice result Face, though I didn't understand the explanation because of my lack of research/tech.
Yes, the "holes" occur.
I'll have a look at 4throck's case. Does it give a solution ?
Thank you so much !

 

[Face]

I've fixed the bug in the -i feature: http://snoopie.at/face/beta/ot3.zip .

Now the integration run should not show the strange artifacts anymore, and come up with the same result I showed before (but of course without having to split the input file).

Now I'll check that stacking thing...

 

[4throck]

Managed to convert some global terrain to png tiles.
Using Javascript + canvas to split images browser based and download the parts...
Not the best solution since I can't write to folders but it works.

Then used ele2png to get the elevation files.

Here's Mercury with a test 1024x512 elevation:


It seems OK, but I don't get the range parameter.
My pngs are 8 bit, so is scale a multiplication? Meaning scale 0,10 will get altitudes in 0 to 2560 meters range?

 

[Face]

It seems OK, but I don't get the range parameter.
My pngs are 8 bit, so is scale a multiplication? Meaning scale 0,10 will get altitudes in 0 to 2560 meters range?

The range parameter is not taken into account while converting from PNG to ELEV (yet). It only defines the mapping of elevation point value to color value while converting from ELEV to PNG.

If you start with a PNG from scratch, the PNG does not contain the metadata that is needed for complete ELEV information (scale, min/max/mean, lon/lat, type, etc.). Therefore, ele2png produces default information:

• The minimal color value is mapped to -32768
• The maximal color value is mapped to +32767
• The value scale is 1.0
• The value offset is 0.0
• The elevation type is -16, i.e. 16-bit signed values are stored
• Padding is 1
• Min/max/mean values are calculated from actual values
• Lon/lat range values are calculated according to tile path, or set to zero if the path is not a valid texture tree path
• Colormap is dynamically guessed

The last point means, that with RGB PNGs for each color value the system first checks if it is a valid OT3 16-bit LUT color (the rainbow palette posted before), and if not, it calculates the distance to all LUT color and all grayscale values. The least distance value is then taken.
If it is grayscale already, it simply uses the grayscale value.


In other words: if you import from scratch, your color value is mapped to 16-bit signed, making black -32768m and white +32767m.


However, you can then make round-trips to change the scaling. Let's say your PNG black value is -10m and white is 100m. You first convert it to ELEV, getting black as -32km and white as +32km. This you convert to PNG again, with range parameter -r0 (for fixed maximum values), creating a RGB 8-Bit PNG with OT3 16-bit LUT colormap, where the deep blue value is -32km and the cyan value is +32km. This PNG will also contain the metadata in the PNG comment section. E.g. GIMP can edit this section, where you can change the first two parameters (vmin and vmax) to -10 and +100.
If such a PNG is then converted to ELEV again, the color deep blue (that was black in the original) is -10 and cyan (that was white in the original) is +100.


You could do the round-trip with -g option to get 16-bit grayscale, too, but then you'd have to use a picture manipulation tool that can use 16-bit color space (which e.g. GIMP can't do <V3).

 

[4throck]

Got it !

I'd like to try and saving to the 8bit RGB LUT from the browser.
I can to that manipulation for each tile as I save them, avoiding having to manipulate huge images. So it will be full global grayscale map image » split elev LUT tiles downloaded out.

How can I convert a given pixel value to the LUT ?

Can you share some conversion formulas?
I can try to guess "HSV-Hue/Intensity LUT" but no point in that if it can be exact.

(as before, if the info was posted I apologize)

 

[Face]

How can I convert a given pixel value to the LUT ?

Can you share some conversion formulas?
I can try to guess "HSV-Hue/Intensity LUT" but no point in that if it can be exact.

The appropriate function is this:

#define OT3LUTSIZE	226*59*5

bool S16toR8G8B8(short int value, int min, int max, png_bytep rgb)
{
	double v=value;
	bool result=true;
	if (v<min)
	{
		v=min;
		result=false;
	}
	if (v>max)
	{
		v=max;
		result=false;
	}
	int val=(int)((v-min)/(max-min)*OT3LUTSIZE); //Spread to 16-bit LUT
	if (val<0)
	{
		val=0;
		result=false;
	}
	if (val>OT3LUTSIZE)
	{
		val=OT3LUTSIZE;
		result=false;
	}
	int cat=val/(226*59);
	int run=val%(226*59);
	val=run/59;
	int block=-29+run%59;
	if ((val%2)>0) block=-block;
	int negval=226-val;
	int upper=block<0?0xFF+block:0xFF;
	int lower=block>0?0x00+block:0x00;
	val+=block>0?block:0;
	negval+=block>0?block:0;
	switch(cat)
	{
	case 0:	//Blue, red plus
		rgb[0]=val;
		rgb[1]=lower;
		rgb[2]=upper;
		break;
	case 1: //Magenta, blue minus
		rgb[0]=upper;
		rgb[1]=lower;
		rgb[2]=negval;
		break;
	case 2: //Red, green plus
		rgb[0]=upper;
		rgb[1]=val;
		rgb[2]=lower;
		break;
	case 3: //Yellow, red minus
		rgb[0]=negval;
		rgb[1]=upper;
		rgb[2]=lower;
		break;
	case 4: //Green, blue plus
		rgb[0]=lower;
		rgb[1]=upper;
		rgb[2]=val;
		break;
	default: //Cyan, green minus
		rgb[0]=lower;
		rgb[1]=negval;
		rgb[2]=upper;
		break;
	}
	return result;
}

short int value is the input data value. int min and int max are the range values. Fixed range (-r0) is -32km to +32km, dynamic range (no -r option) is the min/max of all values in the tile. png_bytep rgb is a simple pointer to a png_byte array. These bytes are 8-bit and correspond to the RGB value (in that order).

As you can see the mapping is a modified Hue edge-walking algorithm on the (shifted and truncated) HSV-colormap path, with added intensity-modifying blocks to increase bit precision. The later is seen as "ripples" in the LUT colortable I've already posted here.

---------- Post added at 17:53 ---------- Previous post was at 17:47 ----------

I'd like to try and saving to the 8bit RGB LUT from the browser.

What about 16-bit grayscale, BTW? Can you do that directly from the browser?

 

[4throck]

Thanks for code! :thumbup:

I'm using HTML5 canvas because it handles large images quite well.
Also, the canvas methods are the only way I managed to handle the 256 » 259 overlap thing (by defining a larger copy window and offsetting origin).

But canvas only saves in 8bit RGBA, sorry.

I understand the advantage of using 16bit values, and that's why I'll try the LUT. But I'm not worried about input until I can output!

 

[llarian]

... snipped ...

You could do the round-trip with -g option to get 16-bit grayscale, too, but then you'd have to use a picture manipulation tool that can use 16-bit color space (which e.g. GIMP can't do <V3).

Face, can Krita handle the manipulation?

 

[Face]

Face, can Krita handle the manipulation?

Didn't know about it, but I will check.

---------- Post added at 09:34 ---------- Previous post was at 09:03 ----------

Krita can load, properly display and save 16-bit grayscale PNG, but it loses the metadata in the process. Therefore, round-trips are not possible with it, at least not with the version 3.0.1.1 .

I could perhaps implement support to export (and implicitly import) the metadata as simple text-file. Then you could create a elevation editing workflow with Krita and 16-bit grayscales, too.

 

[llarian]

Thanks for the thought. It would be nice if you have the time but I would rather see treeman working 100% first. great effort, BTW. Still working through it myself to see how it all comes together ... especially for a Mars scene I'm still working on.

 

[Face]

It would be nice if you have the time but I would rather see treeman working 100% first.

Hehe. I'm afraid that you will never see any feature going in anymore, if we go with that strategy. What is 100%, anyway?

But of course there is a core point in there that is certainly important: OT3 should follow the roadmap instead of concentrating on nice-to-haves.

Given that the base import feature is less important to the community than initially anticipated, I think giving time to ele2png (which is just as important for base developers as texture import now) is not a problem.

 

[4throck]

100% is working as expected (whatever that is) :hmm:

For treeman I'd say that fixing the stacking / alpha issues would do it.
Even if for some tile levels it's a bit redundant, there are fictional bases (islands) that use many levels.

------------------------

I managed to convert the 4096x2048 elevation into Orbiter
That's the maximum my browser based tile splitter will do, but still over the original data resolution.
The result is here [ame="http://www.orbithangar.com/searchid.php?ID=7026"]Mercury surface and heightmap tiles for Orbiter 2016[/ame] not as good as the Moon or Mars datasets but still enjoyable I think.

A big thank you to Face for the OT3 tools that made it possible!

 

[Face]

A big thank you to Face for the OT3 tools that made it possible!

I'm glad it helped. :thumbup:

I see you worked with 16-bit grayscale in the end?

 

[4throck]

Yes, I converted the png tiles to 16bit externally, adjusting the levels to get the elevation range I need. No data loss since the original was only 8bits. Not that elegant but works and is a fast solution.
Then elev2png only needs to do a pure 1:1 conversion.

 

[mike-c]

digging a hole in Kazachstan

:tiphat:

Just made my very first Airport (in ver. 2010). With treeman and 1 Minute it was 2016-ready, whow!
:thumbup::thankyou:

Then i thought about a little terraforming

well... ugly and with stiching errors, obviously i cannot handle a Paintbrush right, anyway this is Level 17 and the workflow

ele2png ....\Textures\Earth Elev \17\2006\11074.png -r 60:120 -vv
ele2png ....\Textures\Earth Elev \17\2006\11074.elv -r 60:120 -vv
ele2png ....\Textures\Earth Elev \17\2006\11074.png -r 60:120 -vv

is straight ahead. Level 16 and 15 at least i had to prepare too. Tiledit had shown the correct numbering to me.

Loc: [URL="https://tools.wmflabs.org/geohack/geohack.php?pagename=Gagarin%27s_Start&params=45_55_13_N_63_20_32_E_"]https://tools.wmflabs.org/geohack/geohack.php?pagename=Gagarin%27s_Start&params=45_55_13_N_63_20_32_E_[/URL]

(why nothing falls into the pit, i do not yet know, maybe because the corresponding suface-tile is not there)

Next time one tile will be temporarily decorated with (LUT).elv for calibration.

Only for testing i applied the launchpad from

http://orbithangar.com/searchid.php?ID=5971

,
which results:

The following zip is not for actual Installation, but contains the png's, i used and the result of cycling.
View attachment lc1-2016.zip
Other developers surely can make better color-gradients for sloping the terrain.

@Igel:
After flattening the Terrain and with that hole at least an existing Baikonur-launchpad could be 2016-ready very quick.

 

[JMW]

Hi Face
Any joy with the "stacking thing" .
I've tried any number of variations this end (in my limited fashion) but still suffer the zooming holes thing.

I've fixed the bug in the -i feature: http://snoopie.at/face/beta/ot3.zip .

Now I'll check that stacking thing...

 

[Face]

Hi Face
Any joy with the "stacking thing" .
I've tried any number of variations this end (in my limited fashion) but still suffer the zooming holes thing.

Didn't start yet. RL and such, you know.

 

[JMW]

No problem mate, RL is the biggest problem I have too. :bailout:

 

[marcogavazzeni]

I tried ele2png but does not work ... what did I do wrong?

C:\Users\Sergio\Desktop\ot3

C:\Users\Sergio\Desktop\orbiterBETA\Textures\Earth\Elev\13\000124

:sos::sos::sos:

 

[Face]

I tried ele2png but does not work ... what did I do wrong?

You didn't understand the usage line. It says:

Usage: ele2png <Planet-tree-root> <Layer> [<Source>] [<Options>]

Mind the spaces between <Planet-tree-root>, <Layer> and [<Source>].

You simply entered:

ele2png C:\Users\Sergio\Desktop\orbiterBETA\Textures\Earth\Elev\13\000124\000691.elv

which would be equivalent to something like:

ele2png <path>

As you can see, you gave it only one argument (a path), when the program says that its usage is with at least two arguments (a planet root and a layer).

In your path, the planet tree root is C:\Users\Sergio\Desktop\orbiterBETA\Textures\Earth . This is close to the example that you've got in the usage description for the argument <planet-tree-root>.
The tree layer you are interested in is elevation, so the second argument is Elev. For that argument, the available options are also listed in the usage description.
The third argument is the source you want, and the usage description gives an example for that, too ("e.g. \05\000000\000000.elv or \05\000000\000000.png"). In your case, that argument would be \13\000124\000691.elv .

So to summarize, the proper usage would be:

ele2png C:\Users\Sergio\Desktop\orbiterBETA\Textures\Earth Elev \13\000124\000691.elv

Again, mind the spaces. One neat trick is to simply use tab completion, then overwrite the "\" after the planet name with a space and insert a space after the layer name.