ok I’ve poked at the fundamentals a bit last night, and have an “interesting” issue.
Your PNG file is 16 bit grayscale, which will give awesome fine detail in the Z dimension.
But the support in javascript for PNG seems to mostly chop this back to 8 bits (I’m very new to the javacript world)… there are some kludgy ways around that which I’m investigating.
Do you know if your origin data was actually 16 bit, or is this a case where somewhere in your middle steps there was an 8->16 bit promotion but there isn’t actually 16 bit of information?
Also do you have any idea how deep you want your Z to be? 8 bit means steps of 0.1mm if your depth is 1"…
I just opened a QGIS PNG in Photoshop (couldn’t see how else to get bit depth reading). It shows as 16bit. So, assuming Photoshop doesn’t do a conversion upon opening, 16 bit is it from QGIS. I’m including that file here.
For what it’s worth, I found this in some USGS documentation about the seamless DEM of the US:
Distribution and Supporting File Formats
The seamless DEM shall be delivered in 32-bit floating point raster, ERDAS Imagine .img format, ArcGrid (.adf, .dat, .nit, .stk), and Gridfloat (.flt, .hdr) files (Library of Congress, 2015). The USGS may offer additional or alternative file formats for distribution in the future.
The item I sent yesterday is from that source. It’s a 1/3 arc (10 meter resolution) data set covering the entire country. The document I sent today is from another source (ALOS or SRTM via OpenTopography, both 1 arc, 30m). I can’t get a firm fix on bit depth for these, but I think they are ALOS=16 and SRTM=32. I most often use ALOS because the data tends to be cleaner, so the more recently sent file is probably from that source, and probably 16 bit from the beggining, not 8 to false 16.
small update; I figured out how to get the 16 bit data. Now I can go figure out how to do the plumbing into the rest of the system, but its plumbing not rocket science from here on out I think.
bad news: I had a set back and the approach I thought I had to get full 16 bit working isn’t (the library that was supposed to let this happen was more buggy than tequilla)
good news: I have the overall thing working, just use https://fenrus75.github.io/FenrusCNCtools/stl2nc/stl2nc.html and load a grayscale PNG file into it instead of an STL and it does the right thing. The precision in the Z direction is limited to 256 levels (haven’t quite given up on trying to fix that but for now this works)
The PNG file will try to fill the size of the stock you put in, the X/Y direction will fill up (but not stretch the image), the height of the PNG file will be scaled to the full Z that you put in the web form.
