16 bit elevation DTM to Photoshop

ai3dai3d Global Mapper UserPosts: 25Trusted User
edited November 2013 in Elevation Data
Hi

Is there a 16 bit greyscale heightmap format I can export from GM and open in Photoshop. I have tried everything over the years but had no great luck. btw Im using GM13.2 and PS CS3.

None of the Elevation Grid exported formats really work with PS (unless Im doing something wrong).

From the Raster formats
png give me 8 bit
geotiff comes in black, with no data
Ive tried the BIL (using the Elevation 16bits per sample option) and renaming to Raw. PS asks for a size and then displays as black.

Any ideas for get 16 bit to PS?

Comments

  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited December 2012
    What I think you want is the 16-bit GeoTIFF export. However you need to scale it to the range of 0 to 32767 to get a decent display I think as Global Mapper exports the actual elevation values and not rendered grayscale values. To do this go to the Alter Elevations tab of the Options dialog for the elevation layer and set the range to 32767 / ( max_elev - min_elev ) and then multiply the minimum elevation by that scale value and set the offset to the negative of that. For example if your layer goes from 150m to 1200m (a range of 1150m), set the scale to 28.49 and the offset to -4273.95. I think this will then scale your elevations from about 0 to about 32767, which should then give you a nice grayscale rendering in the GeoTIFF file for PS to use. At least if everything I just did off the top of my head is correct :)

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
  • EoghanQEoghanQ Global Mapper User Posts: 8
    edited November 2013
    Hi Mike,

    I'm having the same issue here, I need to export a 16bit grayscale image from Global Mapper, as I will be using it as a height map in Unity 3D. I'm finding many issues with this, and it's an issue we really need to sort here, so if you can help out it would be greatly appreciated.

    I'm having difficulty following your instructions you listed - can you provide clarification on how you reached the offset value? I'm not sure what you mean by "the negative of that", and I can't find the route from your example data to the offset value you reached (-4273.95).

    If you could spell out the equation clearer, I'd like to try and plug my own values in and try it out.

    Many thanks
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited November 2013
    The equations to use would be the following:

    scale = 32767 / ( max_elev - min_elev )

    offset = -( min_elev * scale )

    Using that should scale your data to the range of 0-32767 for use as a 16-bit grayscale.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Guru
    geohelp@bluemarblegeo.com
    Blue Marble Geographics for Coordinate Conversion, Image Reprojection and Vector Translation
  • tjhbtjhb Global Mapper User Posts: 454Trusted User
    edited November 2013
    I have been meaning to post about this for a while, because it took me a long time to figure it out, and I haven't seen it anywhere else.

    Here is my workflow, for taking elevation data into Photoshop for editing, and returning to elevation format. (I don't know about Unity 3D, I'm afraid, but I hope this might be helpful there too.)

    Exporting from Global Mapper to Photoshop in 16-bit greyscale mode is in my experience not very fruitful and I won't say any more about it for now.

    A better workflow (in my opinion) is to export from GM to 32-bit GeoTIFF, then convert to greyscale inside Photoshop. Here are the steps.

    Taking an easy case, with source elevations in the range [0, 4000].

    The 32-bit GeoTIFF exported by GM will contain raw numbers in that range. Photoshop can import and read this greyscale file, but it will display as (almost) entirely black and white, since Photoshop's own 32-bit floating-point representation uses the range [0, 1] to represent [black, white]. Initially, every pixel with a value over 1 is shown as white.

    To remap values in the range [0, 4000] to [0, 1] for Photoshop use, we don't just divide by 4000 (i.e. use linear scaling). Instead we need to use logarithmic scaling with base 2. This corresponds to the photographic image paradigm, where an EV (exposure value, ≈brightness) of n represents half as much light as an EV of n + 1.

    For elevation data, we are casting elevation (height) as brightness (light).So we want elevation of h to show as half as bright as an elevation of 2h, corresponding to exposure values of n and n + 1 respectively, as above.

    So to go from [0, 4000] to [0, 1] with logarithmic scaling to base two, we would first convert each value h to log2(h), then divide each value by the maximum result.

    My calculator doesn't do log2(), but logA(x) = logB(x) / logB(A) (change of base). So log2(4000) = log10(4000) / log10(2) (or ln(4000) / ln(2)), which is about 11.97. (4096 would give 12, being 2 ^ 12.) This is the "exposure range", in EV units, or f-stops, corresponding to a height range of [0, 4000].

    How to do this in Photoshop?

    First, before opening the GeoTIFF file, adjust Photoshop colour settings for working with this kind of "image". Open up Colour Settings, and set the Working Space for Grey images to Grey Gamma 2.2. I can't explain this requirement, but it is crucial for manipulating greyscale images in linear space, i.e. so that relative brightness relations will hold correctly. (Why is the correct gamma not 1.0? Something hard-coded in Photoshop math—or perhaps something mathematically obvious that I'm missing.)

    Now open the GeoTIFF in Photoshop and, if prompted, confirm the colour space as Grey Gamma 2.2.

    Now apply the logarithmic scaling so we see the elevations as greyscale, rather than just black and white. Here, exactly what we need is built in. Having calculated the exponent of 2 representing the maximum elevation in this particular image, 11.97, go to the View menu, and select 32-bit Preview Options. Enter -11.97 (NB negate the calculated value) into the Exposure box. Leave gamma (here) as 1.0.

    Check that you now see what you expect to see. All going well, it will look exactly as the DEM would look in GM, without colouring or shading. A raw height map, from black (zero) to white (maximum elevation).

    At this point, we haven't changed the underlying values in the image at all. (You can confirm this using the Info tool.) They are still in the range [0, 4000], but are being remapped to [0, 1] for display. There might be some cases where you would want to leave things this way during editing. (Not many, since many Photoshop filters and plugins don't handle 32-bit greyscale images.) In other cases it is just a useful check before changing the raw pixel values.

    Now convert to 16 bits, using the same scaling. Select Image | Mode | 16 bits / channel. Change the Method from Local Adaptation to Exposure and Gamma. Now we have the same two controls we had in the 32-bit Preview Options box, and (handily) Photoshop has pre-populated them with the values entered there. So just press OK.

    Now work on the image in 16-bit mode, or export for use in a third-party application, or whatever you need to do.

    If you need to get back to a GeoTIFF DEM, do almost exactly the same in reverse, but when converting from 16-bit to 32-bit, reverse the sign (to positive) in the Exposure box.

    [Added: To keep things simple, I didn't say anything about elevation ranges that don't begin at 0. To cut a long story short, the easiest way to process these is to apply an offset to the DEM in Global Mapper, before export to FP32 GeoTIFF.]

    Tim Baigent
  • tjhbtjhb Global Mapper User Posts: 454Trusted User
    edited November 2013
    [A further detail to add to the last section in brackets above (edit limit timed out).]

    There's not always a need to remap positive minima down to zero, but negative minima are problematic inside Photoshop since they are simply treated as zero (clipped). Negative values should therefore be offset.
  • EoghanQEoghanQ Global Mapper User Posts: 8
    edited November 2013
    Wow, fast response! :)

    Many thanks Mike and Tim, I'll test out both approaches and let you know how I get on.

    Best regards,
    Eoghan
  • EoghanQEoghanQ Global Mapper User Posts: 8
    edited November 2013
    The equations to use would be the following:

    scale = 32767 / ( max_elev - min_elev )

    offset = -( min_elev * scale )

    Using that should scale your data to the range of 0-32767 for use as a 16-bit grayscale.

    Hi Mike,

    Thanks for your help with this so far - I have been able to complete the equation and test it out.

    I've plugged these values in now, and am exporting a GeoTiff using the different settings available, but am receiving the same results in Photoshop - the range is not being scaled to fit the visible spectrum and the image appears mostly black.

    My terrain values are as follows:
    -20 (min) -> 760 (max)
    => my scale factor is (32767 / 780) = 42.01
    Power left at 1
    => my offset is -(42.01 x -20) = 840.18

    How do you export a Grayscale 16bit image? I see an option to export an 8-bit Grayscale, or Multiband 16bit. Do I just export a Multiband 16bit with 1band for a Grayscale image?

    Am I missing a checkbox somewhere to apply the new elevation values? On the GeoTiff export options there is an options to "Export at the Fixed Scale 1:<var>" - does this have any relevance?

    Thanks,
    Eoghan
  • EoghanQEoghanQ Global Mapper User Posts: 8
    edited November 2013
    tjhb wrote: »
    I have been meaning to post about this for a while, because it took me a long time to figure it out, and I haven't seen it anywhere else.

    ......

    Tim Baigent

    Thanks for the in-depth process Tim. I can see why it took a long time to figure out. Manually calculating log values seems unnecessarily complex for what should (in theory) be a simple export.

    I'll have to figure out how to correctly calculate logs to see if I can replicate your success (it's been a while since I did math of that magnitude).

    I'm also attacking this on the other end, in converting the 8bit grayscale image into a 16bit image to see if I have any success there. Hopefully one of the two approaches will yield results.

    Many thanks,
    Eoghan
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited November 2013
    Eoghan,

    You will want to export a 16-bit elevation GeoTIFF with File->Export->Export Elevation Data. That will create a 16-bit "grayscale" TIFF with the actual elevation values as the 16-bit value. After your adjustment to make the elevation go from 0 to 32767 it should scale to the 16-bit range when loaded in a non-terrain-aware application like Photoshop.

    Thanks,

    Mike
    Global Mapper Guru
    geohelp@bluemarblegeo.com
    Blue Marble Geographics for Coordinate Conversion, Image Reprojection and Vector Translation
  • tjhbtjhb Global Mapper User Posts: 454Trusted User
    edited November 2013
    Here are a couple of examples of the different results. Both are 16-bit greyscale height maps exported from Photoshop to PNG format.

    Both use the same SRTM 3spx source, with a height range of [-9, 1192].

    SRTM Int16 linear.png (below):
    Mike's scaling method applied in GM. Scale = 32768 / (1201) = 27.08099... Offset = -(-9 * scale) = 243.7289... Exported to 16-bit integer GeoTIFF DEM format. Opened in Photoshop (assigning grey gamma 2.2). Save as PNG.
    SRTM Int16 linear.png

    SRTM via FP32 log2.png(below):
    Exported from GM to 32-bit floating-point GeoTIFF DEM format. Opened in Photoshop (assigning grey gamma 2.2). 32-bit preview options: Exposure -10.2179(6)... stops. Convert to 16-bit (same exposure). Save as PNG.
    SRTM via FP32 log2.png

    The main difference is obvious: linear scaling (GIS paradigm), versus log2 scaling (image paradigm, elevation -> brightness).

    Which model you need depends on which paradigm you need to work in. Or just how you want your height map to look. (I realise I'm begging a question here, which I'll come back to.)

    Notes:
    For Mike's method, a maximum value of 32768 is used rather than 32767, since that is the value Photoshop uses for white in 16-bit mode. (Since 16-bit values in Photoshop are unsigned, they could go all the way to 65535, but values above 32768 are left unused to increase processing speed—headroom for bitshifts instead of real math—and also so that the value range can have a true midpoint.)

    I didn't offset the -9 to zero in my method. It doesn't make a significant difference for the example but I normally would (though here the negative values are data faults).
  • tjhbtjhb Global Mapper User Posts: 454Trusted User
    edited November 2013
    The question I begged above is: after import to Photoshop, can you adjust the 16-bit greyscale image, exported with Mike's linear scaling, so that it has the same brightness range (or encoding) as the FP32 import with log2 scaling? Can you make the first image match the second (assuming for the moment that you need or want to)?

    The answer, I'm afraid, is rather weak: I've never had any success with that. Partly or mainly because of idiosyncracies in Photoshop. I could never tell when an unexpected result was because of Photoshop's internal wiring or my simple lack of understanding. Yes, you can adjust gamma and/or exposure, so that the height map looks the way you'd wish or expect. But on what basis? When it looks roughly right, it's hard to know why. Bear in mind that in Photoshop a working gamma of 2.2 must be used to preserve linear relationships between height values (as noted in an earlier post, with no claim to an understanding why), though a linear gamma is the default after conversion to 32-bit. What about if you need to tell a client what brightness value represents what elevation? Or if you need to convert the height map back to a DEM format for GIS use, after editing? I also tended to experience noticable banding problems (quantization) after bringing 16-bit elevation values into Photoshop. It's likely that all of these problems could be solved. But for now, the method I outlined above does work, reliably and reversibly, and I do understand it (perhaps only just).
  • EoghanQEoghanQ Global Mapper User Posts: 8
    edited November 2013
    Thank Mike - I was exporting a Raster Image format GeoTiff, so using an Elevation Grid format GeoTif fixed that issue.

    Fantastic, that has opened a channel that I can get the data through now. :D

    A small oddity that I've found in processing it:
    In Photoshop, the image range is going from 0-127 instead of 0-256. I've used Photoshop's levels to rescale the range successfully, but it got me investigating. I doubled the altered elevation values to counter this, but the range then came through clamped at 127, with all values above this set at 127.

    This isn't a big issue - I'm getting half the available range for a 16bit image, but that's still twice that of the 8bit images I was using (if I understand the difference correctly) and fixes the problems I was having. I'm getting a lot of strange spikes around the edges of my terrain, but that's a different issue that I can investigate, or at the very least iron out in Unity.

    For now, a very big thank you Mike, for taking the time in helping to get over this hurdle. :D

    Best regards,
    Eoghan
  • EoghanQEoghanQ Global Mapper User Posts: 8
    edited November 2013
    Hi Tim,

    Thank you for such detailed and in-depth posts.

    I've run through your process - as I detailed in my last post, I was able to get the 16bit image out, but only with a range of 0-127 in Photoshop's histogram, implying I was only using half the available quality. I can use this, but it is creating some slight banding in the image, so I've run through your method of working with a 32 bit image.

    With the help of our resident coder here (thanks Colin!) I was able to figure out the log2 equation - I also found a handy online log base 2 calculator at miniwebtool dot com.

    Running through your process, I got a log base2 result of 14.999 for the range 0-32767. This made the image look fine in Photoshop, but on examining the Histogram, the overall balance of the image has changed.

    To highlight this, please see below a screengrab of the Histogram from the image I processed via 16bit & rescaled values:
    PShopHistogram-Correct_32767range.jpg
    This is the correct balance for the image, and cross referencing my final Terrain in Unity3D gives me the same values in Unity as it does in Global Mapper.

    After using my log Base2 value of -14.999 to process the 32bit image (and convert down to 16bit) the histogram appears as follows:
    PShopHistogram-Wrong_32767range.jpg
    This re-balancing raises the lower elevation values to bring the terrain closer to the mid-range values.

    I also reset the offset values back to my original range, which is -20 to 760m, or a range of 780. The log Base 2 value of 780 is 9.607. The resulting image was slightly different from the first:
    PShopHistogram-Wrong_780range.jpg

    These changes destroy the accuracy of the elevation data that we were using, rendering the height maps unusable. Were you able to maintain the integrity of your data through this process? Is there something else I'm missing?

    If you have any further observations, I would certainly be interested in seeing this through, but it is no longer a major issue for me, as I can work with the 16bit/2 quality data. If this is taking a lot of your time, feel free to leave your investigations there. I thank you for your time and efforts in detailing your obviously length investigation thus far.

    Many thanks,
    Eoghan
  • EoghanQEoghanQ Global Mapper User Posts: 8
    edited November 2013
    tjhb wrote: »
    The question I begged above is: after import to Photoshop, can you adjust the 16-bit greyscale image, exported with Mike's linear scaling, so that it has the same brightness range (or encoding) as the FP32 import with log2 scaling? Can you make the first image match the second (assuming for the moment that you need or want to)?

    Hi Tim,

    Apologies, I skipped over your question at the end of your post - but with my own testing, my question is the reverse of yours - can we make the second image match the first?

    From my tests, I found that the linear scaling from Mike's method would better preserve that elevation data. However, I see from the image you supplied that the result is somewhat dull - I'm guessing that if you look at Photoshop's Histogram, you will see that the range goes from 0 - 124; a similar result to what I found.

    I've tried moving the mid point of the input range (using Photoshop's Levels), but this isn't spacing the image in the same way that the log image is set up. I suspect this is because the Levels midpoint has a linear relationship with either end, while the log image has spaced the brightness out based on a curve of some kind.
  • tjhbtjhb Global Mapper User Posts: 454Trusted User
    edited November 2013
    Eoghan,

    This is very odd. What a good observation you've made (I mean about the apparently compressed range of the 16-bit images in Photoshop). A great idea to look closely at the histograms and to post images.

    Coming back to that below, but a couple of points to begin with.

    For the histograms you have posted for the elevations converted with 32-bit logarithmic scaling, what you show is exactly what I would expect, and in fact it helps to show why the process is useful, if you will be manipulating elevation as imagery.

    What you want is for the detail to be optimally spread over the visible, workable brightness range, so that you can see what you're doing, to maximize available detail, and to minimise data compression and quantization. (Which is several ways of saying the same thing.)

    But if that is not the objective, and in particular if you need to retain linear scaling for the next part of your workflow, then this method will not be very helpful. As I said at the outset, I don't know anything about Unity3D (or what you're going to be doing there). To repeat myself—
    Which model you need depends on which paradigm you need to work in.

    You say—
    cross referencing my final Terrain in Unity3D gives me the same [rescaled] values in Unity as it does in Global Mapper

    —and if this is an important objective in itself then logarithmic scaling is not a good choice for you. Mike's linear scaling method should be a better fit.

    In theory! But what you've noticed throws up a Nice Question.

    First, if you get a full range of values in Unity3D, matching the range of values seen in Global Mapper (after scaling), then perhaps the problem seen in Photoshop is irrelevant for you? I would have throught so.

    But there does seem to be a problem in Photoshop, when opening 16-bit greyscale images.

    I've tried it a few different ways, to confirm.

    If I use Mike's method to rescale elevations into the range [0, 32767] (or [0, 32768]), then after opening in Photoshop the values are compressed into the range [0, 16384], even though the range [0, 32768] is available. The Photoshop histogram uses the 8-bit scale, so as you say this corresponds to just [0, 128] rather than the full [0, 255].

    The problem is not with the output file. Opening it in Global Mapper, or in Manifold, shows the full output range.

    At first I wondered, is it because Photoshop expects values as UInt16, rather than signed Int16 as output by Global Mapper?

    But that doesn't seem to be the reason. I converted the GM output to UInt16 using gdal_translate, but the result is treated just the same by Photoshop, i.e. compressed into [0, 16384].

    I also tested doing the rescaling itself with gdal_translate (it has this function), with conversion to UInt16 at the same time, but again, the result in Photoshop was just the same.

    Why is Photoshop squashing everything into half the available range, when opening 16-bit integer images?

    Beats me, but it does show (thanks Eoghan!) another reason why I have previously had such a hard time trying to process elevation in Photoshop using 16-bit sources. I hadn't noticed the "automatic" compression before.

    This may be something to take up on the Photoshop forums.

    In the meantime, we have two possible workflows here, for different purposes.

    The 32-bit logarithmic method is good (best) for those who want to process imagery within Photoshop.

    The 16-bit method might not be useful for targetting Photoshop specifically, because of a problem (or at any rate some strangeness) in the way Photoshop opens 16-bit greyscale images. But it is likely to be perfectly good for targetting other applications.

    (I would still be very interested if you could confirm, Eoghan, whether you do see the full range of values in Unity3D, or whether you feel you're only working with half the dynamic range in that application as well.)
  • tjhbtjhb Global Mapper User Posts: 454Trusted User
    edited November 2013
    I think I can answer my own question about what is going on when Photoshop opens a 16-bit greyscale image.

    Namely: some really bad programming decisions, made long ago (when perhaps they had an excuse).

    Say you had the brilliant idea that, by not using the full 16-bit range (because nobody would ever use all that detail, and anyway, where would they get it from?), you could massively speed up image processing, even for computers that didn't have a costly 80287 coprocessor (or whatever it was then).

    That would have been a good idea at the time. (Referred to above, and detailed by a note in the Photoshop SDK.)

    How would you implement it?

    Well, it looks as though Adobe thought it safe to reason like this:

    (1) All 16-bit images outside Photoshop use the full unsigned 16-bit integer range, [0, 65535].

    (2) So we always need to convert from [0, 65535] to our internal [0, 32768] on opening, and do the reverse on saving.

    (3) The quickest and simplest way to do this is to left-shift (or right-shift) one place, then add (or subtract) one. There is slight loss of precision in doing this, but (a) there is spare data range in here anyway, and (b) it's worth it for speed.

    There are problems in the assumptions in (3), but again they probably made good sense at the time.

    The problem is the assumption in (1). Whatever were they thinking? Wouldn't it be better actually to check what the current range of values is, before doing the conversion? What if the current range already happens to be [0, 32768]? Then no conversion would be necessary, and, moreoever, compressing it to a smaller range would remove much more information than would be the case for a source image that used the full range.

    So point (2) is false.

    Well, maybe, again, these judgements were made at time when to scan a whole 16-bit image to find out its maximum values was unthinkably (or at least inconveniently) slow.

    Also, they were not thinking about images as data.

    Could it be fixed, without breaking established Photoshop practice? Well, that is a matter for the Photoshop forums.

    My guess here takes hints from this thread from last year on the Photoshop forums, which has a some overlap with this one:

    Adobe Community: trying to work on a 16bit grayscale image created from a DEM, shows up black no matter what I do
  • tjhbtjhb Global Mapper User Posts: 454Trusted User
    edited November 2013
    TDLR: 16-bit data imagery cannot be used with Adobe Photoshop. Use 32-bit mode instead.

    (But 32-bit mode means remapping data to the range [0, 1] whether temporarily or permanently. Which requires understanding gamma, a.k.a. logarithmic scaling, including idiosyncracies in the way Photoshop handles gamma internally.)
  • EoghanQEoghanQ Global Mapper User Posts: 8
    edited November 2013
    Hi Tim,

    Okay, there seems to be a clear outline of how these processes work now.

    Mike's process to rescale the elevation works perfectly - the problem lies with Photoshop.

    So: 16bit only works in Photoshop if you are comfortable rescaling the range - so essentially, the result is half of 16bit. This is not ideal, but retains linear scaling, and is still better than 8bit.

    32bit works if you are comfortable using logarithmic scaling to view the image, which breaks the linear relationship.

    To clarify my use for these image: In Unity 3D we are recreating real world environments using gaming technology based on accurate survey data. By using Global Mapper to process the original data, we are looking to create height maps for the terrain elevation - where the brightness value of the map specifies the exact height. For this reason, the linear scaling of the image is essential to re-create our terrain in Unity as closely as possible to the Global Mapper DEM.

    Unity requires heightmaps in RAW format, but we have had no success with the RAW formats exported from Global Mapper - taking an image (such as JPG) and converting it in Photoshop has been our best route before now. We will have to look into a different program to convert TIF to RAW which will hopefully retain the full 16bit range. If not through, Mike's linear scaling method is an improvement on what we have been doing up to now.

    Interestingly, 'Gimp', the free alternative to Photoshop has displays exactly the same half range bug as Photoshop! There must be some logic in how these programs are interpreting the images for them both to operate the same way.

    I am happy to put this issue to bed for now anyway - this fixes the problem I was having for the large part, even though it asks new questions of image formats. It gets results, and that's the main thing! :D
  • tjhbtjhb Global Mapper User Posts: 454Trusted User
    edited November 2013
    Eoghan,

    You've said you are happy to put this to bed (it's been a long process).

    But in case you (and others) are still reading, it occured to me how we can easily combine the processes described above, to export a DEM/DTM from Global Mapper, so that it can be opened in Photoshop, preserving the full dynamic range, and with linear scaling.

    (I.e., what you need to do for working in Unity3D, but avoiding the compression introduced by Photoshop on opening a 16-bit data image.)

    Here is the workflow.

    Open the source DEM in Global Mapper. (It doesn't matter whether the source uses 16-bit integer or 32-bit floating-point mode. GM uses floating-point math internally in both cases.)

    Now apply Mike's rescaling method, except that instead of rescaling to the range [0, 32767] (or 32768) for 16-bit integer output, scale directly to the range [0, 1] used by Photoshop for 32-bit floating point images.

    To do this, first open the Control Centre and open the Metadata panel to note the MIN ELEVATION and MAX ELEVATION values. I'll call these Z1 and Z2.

    Subtract Z1 from Z2 to find the elevation range R. Take 1 / R as the scaling value. Divide Z1 by R, then change sign, to find the offset.

    Example: for a surface with range [-9, 1192], the range R is 1201. The scaling value 1 / R is roughly 8.3263946711e-4, or 0.00083263946711 (Global Mapper can digest numbers in both formats). The offset is -(-9 / R), about 0.0074937552034.

    Open the Options panel for the elevation layer, go to the Alter Elevation Values tab and enter these Scale factor and Offset values. Hit OK. Here are the values filled in for the example above.
    Rescale.png

    (You can check that the elevations are now scaled in the range [0, 1] by re-opening the same dialog and tab and inspecting the new values for Valid Elevation Range. The Maximum should be 1, the Minimum very close to 0.)

    Now export to Elevation Grid Format, choose GeoTIFF, and under File Type choose Elevation (32 bit floating point samples).

    In Photoshop, before opening the result, open Colour Settings and set the Working Space for Grey images to Grey Gamma 2.2.

    Now open the GM export in Photoshop and, if prompted, confirm the colour space as Grey Gamma 2.2.

    There's no need to adjust 32-bit Preview Options, since we are in Photoshop's native 32-bit range. The full elevation range is visible, from full black to full white.

    Assuming you want to convert to 16-bit mode (rather than continue to work in 32-bit mode within Photoshop), select Image | Mode | 16 bits / channel. Change the Method from Local Adaptation to Exposure and Gamma. Leave Exposure as 0 and Gamma as 1 and press OK. Result below.
    Photoshop (16-bit).png

    Now work on the image in 16-bit greyscale mode, or export for use in a third-party application.

    (Much simpler than using logarithmic scaling.)

    Tim
  • tjhbtjhb Global Mapper User Posts: 454Trusted User
    edited November 2013
    [Added.]

    Bear with me (again), there are still two problems.

    (1) I need to check the correct gamma to use in Photoshop. I now suspect that 2.2 is wrong, and we need to use a custom gamma of 1.0 to keep data linear—in this case!—and to be able to round-trip it back to elevation.

    (2) There seems to be a problem displaying an unsigned 16-bit DEM in Global Mapper. Although the data type is correctly identified as UInt16, and the status bar shows all elevation values correctly, it seems the GM shader does not cope with values over 32767 (they all block to white—is it hard-wire to assume signed Int16?). This problem seems specific to GM. (Manifold, for example, both reads and shades the full range [0, 65535] correctly.)
  • tjhbtjhb Global Mapper User Posts: 454Trusted User
    edited November 2013
    (1) Yes, use gamma 1.0, not 2.2. Here is the correction to the workflow above (I'm sorry I can't edit the post any longer):

    [...]

    In Photoshop, before opening the result, open Colour Settings, and click the More Options button, if it is shown. (If Fewer Options is shown instead, you don't need to do this.) Under Working Spaces, click on the drop-down menu for Gray images, and select Custom Gamma... (A linear gamma of 1.0 is not built in.) Enter a name (e.g. "Gray Gamma 1.0") and enter 1.0 in the Gamma box. OK out of there.

    Now open the GM export in Photoshop and, if prompted, confirm the colour profile as to use the custom working gamma created above (e.g. Grey Gamma 1.0).

    [...]

    Sorry about that wrinkle. Using a gamma of 1.0 ensures linear scaling, and that the greyscale image can be rescaled back to a DEM.

    (2)
    Is the GM shading issue worth fixing Mike? (Heaven knows if you are still reading. Might need a separate thread.) It does seem to be a problem—though only a display problem, and I have nothing to suggest that it affects workflows in other software (such as Unity3D).
  • tjhbtjhb Global Mapper User Posts: 454Trusted User
    edited November 2013
    Screenshot in Photoshop, using gamma 1.0. (Eoghan will like this histogram better.)
    Photoshop (16-bit, gamma 1.0).png
Sign In or Register to comment.