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