![]() |
![]() |
#46 |
Beta Tester
![]() ![]() |
![]() Quote:
|
![]() |
![]() |
Thanked by: |
![]() |
#47 |
ele2png user
|
![]() Quote:
Quote:
We exist! ![]() |
![]() |
![]() |
Thanked by: |
![]() |
#48 |
Addon Developer
![]() |
![]()
Found 2 issues:
- when maximizing the window, it appears to change its size to that of the screen, but it isn't positioned correctly. - the edit marker/pointer isn't that handy... could (at least) an option be added to choose between showing a center marker? That way we could know exactly which pixel is going to be edited. ---------- Post added at 05:21 PM ---------- Previous post was at 12:05 PM ---------- One suggestion: save the last path used to a texture folder, and also save the options in the Configure menu window. |
![]() |
![]() |
Thanked by: |
![]() |
#49 |
Orbiter Founder
![]() |
![]()
I have now implemented the PNG export/import functionality. I've uploaded a new trial version. The link is in the first post of this thread (I'll update this whenever new stuff is ready). Let me know if this works ok.
The PNG files are in 16-bit greyscale, so to modify them you need an editor which supports them. I'd suggest Gimp 2.10 or later. The metafiles contain some additional information to Face's format, to allow export/import of multi-tile mosaics. However the original format should still work for importing a single-tile image into the current tile. Let me know if there are any problems with this. Thanks for the suggestions - I'll work on them as soon as I get time. Quote:
Quote:
Quote:
|
![]() |
![]() |
Thanked by: |
![]() |
#50 |
Enthusiast !
|
![]()
The PNG export looks nice, I have no problem reading the file. And the .hdr file is nicely readable on Notepad++
Great work! I had a look here: http://wms.lroc.asu.edu/lroc/view_rd...C_DTM_APOLLO11 They offer geotiff as a file format, so perhaps that's a better option than FITS. And they also have high resolution surface images with 50cm resolution to go along with this. That's why surface import makes sense I think: http://wms.lroc.asu.edu/lroc/view_rdr/NAC_DTM_APOLLO11 Last edited by 4throck; 06-03-2019 at 09:36 AM. |
![]() |
![]() |
Thanked by: |
![]() |
#51 |
Beta Tester
![]() ![]() |
![]() Quote:
The vmin and vmax values are the height values that the PNG format's low and high colors represent. A vmin of -1000 means that black represents -1000 height units, a vmax of e.g 1000 means that white represents 1000 height units. Values in between are scaled accordingly. Scale and offset of the tile are then used to convert the height units into absolute meters, i.e. hU*scale+offset . In that way, the color value is a direct representation of the ELE format data point value. It seems like tileedit produces fixed scaled PNGs in the 16-bit grayscale mode, and according to my tests it starts with the lowest value as black, and from there 16-bit up to whatever meter value that would be. The values stored in vmin and vmax, though, only represent the internal range, not the picture range. Therefore, while the syntax might be compatible, the semantics for vmin/vmax are different, so that import/export across the two tools will fail. I'd suggest to offer a range option for the image creation. With this, the user can choose to use a nicer visual representation (auto-range) or a workable fixed range to have the possibility to compare color values across tiles. ---------- Post added at 17:21 ---------- Previous post was at 15:18 ---------- Small update: I've made some round-trips now, and it looks like ele2png is not so tolerant on vmin/vmax being serialized as double values. It should be, though, and that is something I will fix. In addition, the lat/lng values are serialized as radians instead of degrees, because it was not meant as input right from start. This is something that can also be fixed easily, but I don't know if it is worth the effort. Are those values inside the ELE format actually used anywhere? Another thought: should we unify the extension to *.png.hdr, or is it good to have them separated? "ele2png" creates *.png.meta currently. |
![]() |
![]() |
Thanked by: |
![]() |
#52 |
Orbiter Founder
![]() |
![]() Quote:
Quote:
Quote:
|
![]() |
![]() |
Thanked by: |
![]() |
#53 |
Beta Tester
![]() ![]() |
![]() Quote:
Quote:
Quote:
|
![]() |
![]() |
Thanked by: |
![]() |
#54 |
Orbiter Founder
![]() |
![]()
I have uploaded a new version (link in first post). This allows the user to specify the elevation data -> image value range manually during export. The vmin and vmax values in the metafile are now adjusted to hopefully comply with the discussion above.
Note that tileedit coverts the data in the elevation tiles to double on read, and only converts back to 16-bit values + scale + offset on write, so it is possible that a save would create a different file even if the physical values are unchanged (e.g. different offset, and correspondingly different 16-bit data). It does try to retain the scale, unless the 16-bit range would overflow. For now I have kept the lat and lng values in degrees. It makes it a bit easier to interpret. Would you be ok with changing the ele2png output accordingly? Since the values are not actually used so for, this shouldn't cause any backward compatibility problems. Let me know if this version now produces output that is compatible with ele2png. |
![]() |
![]() |
Thanked by: |
![]() |
#55 |
Enthusiast !
|
![]()
Thanks, the export is much better like this
![]() I tried to import some experimental elevation maps I created before (ex: Venus ) and I got a CTD. I guess that's because my terrain doesn't have all the levels, but they work in Orbiter... It would be interesting if TileEdit could generate and save empty elevation tiles (all pixels at zero meters) for planets that don't have them. Would be useful for cases were we only have local DEM coverage, or when global coverage is of very low resolution. |
![]() |
![]() |
Thanked by: |
![]() |
#56 |
Kourou CSG addon Developper
![]() |
![]() Quote:
![]() |
![]() |
![]() |
![]() |
#57 |
Beta Tester
![]() ![]() |
![]() Quote:
![]() I've changed the discussed aspect: https://www.orbiter-forum.com/showth...&postcount=209 |
![]() |
![]() |
Thanked by: |
![]() |
#58 |
Kourou CSG addon Developper
![]() |
![]()
I noticed just one thing:
My tiles for the (my) Kourou-CSG (French Guiana) area start at level 11 until level 19. So there is both the "compressed" tiles delivered with Orbiter and therefore my tiles in the "Surf+Mask+Elev+Elev_mod" folders. If I open "tileedit" everything goes well. But if I want to set the option "cache files only" I must be with tileedit displayed tiles level 11 to 19. (surf-tiles). If I am on a level 1 to 10 tile, I have a CTD. I think it's normal, since there are no tiles from level 1 to 10 in my "cache-files".... And no importance for Mask and Elev tuiles, even they are missing. It's only if Surf-tiles are missing. This is not very serious, but a message like "attention etc ..." instead of a CTD would be better? I do not know if it's possible ... Last edited by jacquesmomo; 06-05-2019 at 10:49 PM. |
![]() |
![]() |
![]() |
#59 |
Orbiter Founder
![]() |
![]()
New version uploaded:
Quote:
Quote:
Quote:
|
![]() |
![]() |
Thanked by: |
![]() |
|
Thread Tools | |
|
|
Quick Links | Need Help? |