# Puget sound heightmap discription

Show 80 post(s) from this thread on one page
Page 1 of 2 12 Last
• 09-14-2011
fleurdelys77
Puget sound heightmap discription
hi everyone,

Could anyone explain to me what this discription of the puget sound heightmap data means :
"In the full-resolution elevation image, inter-pixel spacing is 10 meters and each 16-bit pixel unit (0 to 65535) corresponds to 0.1 meter. The pixel value 0 corresponds to a base elevation of 0 meters. The lower-resolution elevation maps have been subsampled to 40 meter and 160 meter horizontal resolution. "
I have found this discription in : Model : Puget Sound

• 09-14-2011
Salem
> inter-pixel spacing is 10 meters
Meaning that you have 100 samples per KM
Or 10,000 samples per square KM

> each 16-bit pixel unit (0 to 65535) corresponds to 0.1 meter. The pixel value 0 corresponds to a base elevation of 0 meters
So 0 is 0, 10 is 1 metre, 100 is 10m, 1000 is 100m etc etc
It's good up to 6553.5 metres, but it would overflow of the worlds highest mountains.
• 09-14-2011
fleurdelys77
In fact I want to creat a terrain using this heightmap sois the description means that when I read the height value from the heightmap I'll subdivided by 400 (to scale it) :
"The lower-resolution elevation maps have been subsampled to 40 meter" so 10 value in the heightmap = 1 meters and 1 unit in opengl = 40 meters
so a height unit in opengl = the height value in the heightmap /400.
And for horizontal "160 meter horizontal resolution." using the same methode I'll scale x and z by subdivid it by 16

Please correct me if I'm wrong
• 09-14-2011
Salem
It seems as if you've got the right idea.
So long as you convert the linear and height to the same units, you should be OK.
• 09-14-2011
fleurdelys77
Thank you so much Salem .... but I think that this Puget sound heightmap will drive me crazy :tongue: ... I have read in the data discription that the pixels are stored in 16 bits that means I have to use unsigned short (2 bytes) to read 1 pixel .... So far I'm using libpng to read the height data so I should only handle 8 bits because the function png_read_image() take only png_bytep .... My program works but I feel that I lose some data since I read it as 1 BYTE when it is stored as (2 BYTE)...

Is there a solution for that

Thank you so much in advance
• 09-14-2011
Salem
Quote:

Data is obtained from The United States Geological Survey (USGS), made available by The University of Washington. The dataset provided here is a subset extracted by the paper authors from the original dataset, which can be found here.

It would seem that the original data (as described) is at the end this this dead link.

It's going to be hard to reconstruct height information from those images, since the "image" has been lit from the north-west. South-east facing slopes are a lot darker than NW slopes.

You can use libpng to read the pixels, and see what RGB value each one has, but apart from differentiating "red-ness", "green-ness" and "blue-ness" as approximations for elevation, I'm not sure what else to suggest.

Perhaps more digging around the USGS/WU websites to see if the data has moved rather than gone.
• 09-14-2011
fleurdelys77
Quote:

"You can use libpng to read the pixels, and see what RGB value each one has, but apart from differentiating "red-ness", "green-ness" and "blue-ness" as approximations for elevation, I'm not sure what else to suggest."
But the heightmap is grayscale :confused:
• 09-14-2011
Salem
Sorry! - yes (clicks on the other images)

So you still get RGB pixel values, but being a grey-scale, all the pixels have equal RGB.
So I guess you just take say red, and this gives you 0 to 255 (seemed more like 190-ish) for the height.
• 09-14-2011
fleurdelys77
Quote:

So I guess you just take say red, and this gives you 0 to 255 (seemed more like 190-ish) for the height.
But the value are stored between 0 - 65535 ............. I'm so confused )'
• 09-14-2011
Salem
libpng 1.2.5 manual
Quote:

bit_depth - holds the bit depth of one of the
image channels.
(valid values are 1, 2, 4, 8, 16
and depend also on the
bits (sBIT) below).
color_type - describes which color/alpha
channels are present.
PNG_COLOR_TYPE_GRAY
(bit depths 1, 2, 4, 8, 16)
PNG_COLOR_TYPE_GRAY_ALPHA
(bit depths 8, 16)
PNG_COLOR_TYPE_PALETTE
(bit depths 1, 2, 4, 8)
PNG_COLOR_TYPE_RGB
(bit_depths 8, 16)
PNG_COLOR_TYPE_RGB_ALPHA
(bit_depths 8, 16)

So which of these parameters do you have?
Is it PNG_COLOR_TYPE_GRAY, 16-bit ?
• 09-14-2011
VirtualAce
To get the height of the pixel you convert it to pure greyscale from 0 to 255 and then use a multiplier to get the heights. To get it to greyscale you simply reverse the color equation for the various contributions of red, green, and blue or you can shift everything if you are not too concerned about color equation accuracy.
• 09-15-2011
MWAAAHAAA
Quote:

Originally Posted by VirtualAce
To get the height of the pixel you convert it to pure greyscale from 0 to 255 and then use a multiplier to get the heights. To get it to greyscale you simply reverse the color equation for the various contributions of red, green, and blue or you can shift everything if you are not too concerned about color equation accuracy.

Except that if he converts it to 8-bits, then he will lose a lot of resolution in z-value.
• 09-15-2011
fleurdelys77
Thank you friends for your replies .... actually it's PNG_COLOR_TYPE_GRAY, 16-bit and I convert it to 8 bits by using the function png_set_strip_16 (png_ptr); and as MWAAAHAAA said I'll lose a lot of resolution even if I'll multiplify .... so is there a solution for that ?
• 09-15-2011
Salem
So if it is 16-bit grey, then you're good to go with data "as is"?
0x0000 is pure black, and sea-level
0xFFFF is pure white, and the top of the highest peak (if your peak is 6553.5 metres).

Or is the next problem the PNG interlacing, giving you some weird answers?
But if you've allocated enough memory, then png_read_image() should do the whole thing, and give you a block of memory full of the 16-bit grey-scale.

Do you have any code for this step?
• 09-15-2011
fleurdelys77
here is my code :

Code:

struct Heightmap
{
int width;
int length;
unsigned short *height;
};

unsigned short  *row_pointers = NULL;
...................................
....................................(After some initialisation and test)

/*Handle only 8 bits beside 16 bits (I omit it )*/
//if (bit_depth == 16)
//png_set_strip_16 (png_ptr);

/* allocate memory for storing pixel data */
Map.height = (unsigned short *)malloc (sizeof (unsigned short)*Map.width*Map.length*Map.internalFormat);

/* Setup a pointer array.  Each one points at the begening of a row. */
row_pointers = (unsigned short *)malloc (sizeof (unsigned short ) * Map.length);

for (i = 0; i < Map.length; ++i){
#if 1
row_pointers[i] = (unsigned short )(Map.height +((Map.length - (i + 1)) * Map.width * Map.internalFormat));
#else
row_pointers[i] = (unsigned short )(Map.height + (Map.width * i * Map.internalFormat));
#endif
}

/* Read pixel data using row pointers */
png_read_image (png_ptr, row_pointers); // I got a problem here
}

when running png_read_image function I got an error " impossible to convert unsigned short to png_bytep "
What should I do ???
Show 80 post(s) from this thread on one page
Page 1 of 2 12 Last