Is it possible to work in those files? I need to alter areas for a project, but in PS it's only a hard B/W image. Unless converted to 16-bit, but then it doesn't give me the right altitudes when imported in TG.
As a workaround I mask certain areas out and add new heights, but I hope for an easier solution.
Any ideas?
Is it a USGS DEM data set? If so the ArcGIS conversion tool supposedly outputs 32bit float tiff.
https://pro.arcgis.com/en/pro-app/tool-reference/conversion/dem-to-raster.htm
I really don't know. It's a 32-bit floating point tif and looks like attached. Merely seeking a way to be able to copy-paste or draw altitudes and import properly in TG.
I'm not sure that's been a practical use of high range filetypes. For example I don't know of any image software yet that really handles full-range let alone edit it without dropping to half-range. It's a compositing image format or w/e.
What if you import it in TG, then export it out of TG in a more suitable format which you can edit?
You could then even paint your changes in a separate layer and only use that layer as heightfield import and merge with the original 32-bit you imported.
Export is an idea, indeed. Haven't thought of that yet. Thanks.
IMHO OpenExr is the way to go when dealing with these files - it's a great format and you can load it as a heightfield or displacement map and, as you mention, preserves the height information in the map.
If your original file is 32bit tiff I'd convert it to OpenExr and use that, as Tangled Universe suggests you can re-export from TG from the heightfield node.
You can do this in Photoshop, but although PS will edit the file in 32bit, it will export it as 16bit half float, (at least it does in CS6, though AFAIK that hasn't changed) There's a free PS Plugin called EXR-IO that will save to full 32bit float:
https://www.exr-io.com/
Quote from: Dune on August 23, 2019, 01:49:48 AMit's only a hard B/W image
Only because you're seeing values over 1, just add an Exposure Adjustment layer and drag the exposure down and you can non destructively see your terrain. You can then work in PS with the file, though it has to be said PS is still a bit crap at editing 32bit, and your options are limited.
Quote from: Dune on August 23, 2019, 01:49:48 AMUnless converted to 16-bit, but then it doesn't give me the right altitudes when imported in TG.
I think you chose one of the tone-mapping options when converting to 16bit in PS - that will normalise the values.
I love that Terragen can output "full range" EXRs for heightfields, other progs like World Machine and Gaea normalise their EXRs and you have to figure out the vertical scaling to get it to work in TG
Quote from: digitalguru on August 23, 2019, 01:08:00 PMother progs like World Machine and Gaea normalise their EXRs and you have to figure out the vertical scaling to get it to work in TG
There's settings for that xD
Gaea can export it's exact height and load in TG the same. Someone awhile back did a share with default export which causes the normalizing and thus a stout import into TG. Gaea also now has meter scales.
If it's USGS data (sure looks like it is, it's of Earth), like i said, you can just use ArcGIS Conversion tool to convert it to a normal float tiff, and just edit in Photoshop. Really no real reason to go from Tiff to OpenEXR to Tiff or whatever. Cool TG can do that, though.
Quote from: WAS on August 23, 2019, 01:17:03 PMGaea can export it's exact height and load in TG the same. Someone awhile back did a share with default export which causes the normalizing and thus a stout import into TG. Gaea also now has meter scales.
Would interested to know what that setting is :) - I noticed in the latest version OpenExr has reverted to 16bit.
Quote from: digitalguru on August 23, 2019, 01:22:36 PMQuote from: WAS on August 23, 2019, 01:17:03 PMGaea can export it's exact height and load in TG the same. Someone awhile back did a share with default export which causes the normalizing and thus a stout import into TG. Gaea also now has meter scales.
Would interested to know what that setting is :) - I noticed in the latest version OpenExr has reverted to 16bit.
They're having some... continuity problems... I guess. Lol Lots of people are mad about 16bit-looking banded geometry in the software, and exporting. Not sure what's going on. Though OpenEXR is still marked for 32bit in documentation.
Quote from: WAS on August 23, 2019, 01:32:17 PMQuote from: digitalguru on August 23, 2019, 01:22:36 PMQuote from: WAS on August 23, 2019, 01:17:03 PMGaea can export it's exact height and load in TG the same. Someone awhile back did a share with default export which causes the normalizing and thus a stout import into TG. Gaea also now has meter scales.
Would interested to know what that setting is :) - I noticed in the latest version OpenExr has reverted to 16bit.
They're having some... continuity problems... I guess. Lol Lots of people are mad about 16bit-looking banded geometry in the software, and exporting. Not sure what's going on. Though OpenEXR is still marked for 32bit in documentation.
16-bit looking banded, serious??
I was kind of thinking of acquiring a license, but I don't want to run into stupid simple issues like these. That kind of stuff simply must work. Period.
Quote from: Tangled-Universe on August 23, 2019, 03:17:18 PMQuote from: WAS on August 23, 2019, 01:32:17 PMQuote from: digitalguru on August 23, 2019, 01:22:36 PMQuote from: WAS on August 23, 2019, 01:17:03 PMGaea can export it's exact height and load in TG the same. Someone awhile back did a share with default export which causes the normalizing and thus a stout import into TG. Gaea also now has meter scales.
Would interested to know what that setting is :) - I noticed in the latest version OpenExr has reverted to 16bit.
They're having some... continuity problems... I guess. Lol Lots of people are mad about 16bit-looking banded geometry in the software, and exporting. Not sure what's going on. Though OpenEXR is still marked for 32bit in documentation.
16-bit looking banded, serious??
I was kind of thinking of acquiring a license, but I don't want to run into stupid simple issues like these. That kind of stuff simply must work. Period.
I think it may have to do with the linear/parallel processing or something (I remember Dax mentioning this) and was avoidable, though than someone pointed out it's present in even the default blank projects mountain in soft areas, so yeah I'm not sure. Though I would assume it's going to be fix. There is a lot of rewrites going on that introduce bugs, but they are very quick at rolling out fixes on top of progress of the software.
Quote from: Tangled-Universe on August 23, 2019, 03:17:18 PMI was kind of thinking of acquiring a license, but I don't want to run into stupid simple issues like these. That kind of stuff simply must work. Period.
It is interesting software and has potential I think, but it's not there yet. The Build Manager in particular seems to change on every update and is the main reason I haven't used it for a major project yet.
It never has had 32bit out in any of the versions I've looked at and when I reported it as a bug, the next version re-labelled it as 16bit :).
However I got a reply from Quadspinner that a non-normalised output for OpenExr (like Terragen) was in the backlog and would be implemented in the near future. Hoping 32bit could be part of that update.
Quote from: digitalguru on August 23, 2019, 03:48:23 PMIt never has had 32bit out in any of the versions I've looked at and when I reported it as a bug, the next version re-labelled it as 16bit (http://www.planetside.co.uk/forums/Smileys/fugue/smiley.png).
Huh. It (was) been right there in their documentation since I've been referring to it. "OpenEXR (32bit)" Though I notice the entire export doc page I had bookmarked doesn't exist anymore... Gives a 404 page.
Does this work for you? https://quadspinner.com/Gaea/Export
Nope.
Quote from: digitalguru on August 23, 2019, 01:08:00 PMOnly because you're seeing values over 1, just add an Exposure Adjustment layer and drag the exposure down and you can non destructively see your terrain. You can then work in PS with the file, though it has to be said PS is still a bit crap at editing 32bit, and your options are limited.
I just want to highlight this quote because as far as I am aware it is *the* fix that's necessary for minimal disruption of workflow. No need to switch to EXR, etc., the data is probably already there in the file it just needs to be adjusted for *display*. So using an adjustment layer allows you to *temporarily* adjust the exposure so you can see what you're doing. Give it a try and let us know if it works on these files.
- Oshyan
Thanks guys. Especially indeed that advice from digitalguru sounds like the way to go.
Really though, and why the tool exists... if you're editing DEM data, usually USGS, you should just convert to a normal float TIFF.
This topic was about working in a 32-bit DEM. Obviously just converting to a conventional floating point would be the easily to handle, across applications.
Super simple.
In most cases they are basically float TIFFs. The issue lies in how the how the values are represented (i.e. what "scale" or unit and how that translates to numerical values), and then how your image editor interprets that for display. Height data represented as actual meter values will be interpreted very oddly by an image editor that is expecting to see high dynamic range float image data from an HDR capture or something. For example it's the difference between a value of say 567 (for meters) vs. a value of 0.23092035898923 (for a single channel color value, 0-1). The application expects a 0-1 value for a floating point image but sees 567, well, it's going to show that as pure white.
Converting to a different format won't help either, unless that format also applies some kind of data/image transform, i.e. remaps the data, or if the viewing/editing application for some reason interprets and displays that format differently. And only certain limited kinds of transforms will maintain the correct characteristics of the height values, so you ideally want to do that non-destructively, which is what the Photoshop Adjustment Layers do.
Using an Adjustment Layer will probably allow you to see the data more clearly, if not entirely "correctly". The limitations one may then run into are due to Photoshop's limited 32 bit-capable toolset, which would be an issue no matter the format, as long as the data were 32bit/channel. Depending on the level of editing needed, the available tools may be sufficient (you *can* at least paint). If not, GIMP has a version that apparently can work more comprehensively with 32 bit data, so that's something to consider. Or more dedicated heightfield editors, of which there are few that have painting capabilities that are reasonably sophisticated. Leveller was one such option, I believe.
- Oshyan
I did a bit of an interweb search and found this program: Affinity Photo
https://affinity.serif.com/en-gb/photo/
Downloaded a 10 day trial, and on playing with it for half an hour am very impressed :)
Loaded up a 32-bit OpenExr and seems to edit with a full range of tools, in particular Dodge and Burn work (which don't in Photoshop) which is what you want if you need to make height adjustments.
It even has a handy 32-bit preview tab which can adjust the exposure so you can see your terrain data easily.
The only caveat (on a quick play with it) is that it doesn't like 32 bit tiffs (has only 16 bit options) so you'd have to convert to OpenExr with the Photoshop method mentioned earlier or an export out from Terragen. Saves out to full 32-bit OpenExr and loads in TG just fine.
Reasonably priced too, one time purchase for about the cost of two months Adobe subscription.
Edit:
Did a quick screencap:
https://www.dropbox.com/s/kt1g4jsw6wdjuqr/affinity_01.mp4?dl=0
Ah nice! I was aware of Affinity Photo just as a photographer, and that it had some notable improvements over Photoshop. But I hadn't thought of it for this kind of utility. You're right that the toolset seems much more applicable to terrain editing. The limitation with 32 bit TIFFs is odd though. I wonder if that could be reported as a bug or opened as a feature request with them...
- Oshyan
Yes, it's a nice find :) Still have to play around with it, but it feels very usable and seems to share a lot of similarities with Photoshop (hope Adobe don't think of taking any action ), but is a lot less fussy For most of the work I'd usually do in Photoshop, it could be a good successor. In fact I only have used Photoshop and Premiere CS6 and I've switched over to Davinci Resolve for editing/grading, so maybe I can be Adobe free soon!
Quote from: Oshyan on August 24, 2019, 12:33:24 PMThe limitation with 32 bit Tiffs is odd though. I wonder if that could be reported as a bug or opened as a feature request with them...
Agreed, it's not a bug though, the export options for tif only go up to 16bit. I remember years ago when we rendered out to tifs! But OpenExr has more or less taken over especially in regards to 32bit output.
p.s. I forgot about Picturenaut for conversions, it's been around for a while and hasn't been updated for years, but it's a very lightweight and free prog and will easily do any 32bit tif/hdr/exr conversions:
http://www.hdrlabs.com/picturenaut/
Thanks a lot, digitalguru. Affinity is something to keep in mind, though this time I will probably get away with some basic handling in Photoshop with your adjustment layer idea.
Another question regarding DEM. I have cut out a crop of a global DEM, but that is of course an equirectangular image, spanning the whole globe. So the crop is stretched somehow, which I noticed when overlaying stitched satelite images from the web. The crop is near Sinai, so pretty much near the equator, which makes it easier to de-stretch it, but do any of you have any experience with the amount? Looks like 20% width decrease will do, but I'm sure there is a mathematical calculation under the equirectangularity.
You could use the georeferencing feature to map it to lat-long coordinates. Georeferencing will automatically undo any distortion you see, as long as you input coordinates that are reasonably accurate for the corners of the crop.
Thanks Matt, sounds good, and I'll certainly keep that in mind, now need to find the coordinates. In the meantime I think another solution would be to project a 'normal' satelite image and squeeze the dem and stretched satelite image over that until it sort of fits. Latter is probably easier as I located the Sinai on the North Pole for easier working.
Working at the top of the planet shouldn't be a reason to avoid georefencing. Georeferenced DEMs and satellite images are repositioned to the origin in a typical Terragen georeferenced workflow. You just need to enter a center point into the Planet's "lat long at apex" parameter.
https://planetside.co.uk/wiki/index.php?title=Geog_Heightfield_Load
Thanks Matt!