4

I'm creating slopeshade images from a DEM. What I'm doing is:

gdaldem slope -alg Horn -s 1 -compute_edges -co BIGTIFF=YES in.tif /vsistdout/ | \
    gdaldem color-relief -co BIGTIFF=YES -co TILED=YES -co COMPRESS=LZW /vsistdin/ slope.txt out.tif

but the file generated has 4 bands, RGBA, while I actually need only one. I tried further filtering with:

gdal_translate -co BIGTIFF=YES -co TILED=YES -co COMPRESS=LZW -b 1 out.tif out_1band.tif

but gdalinfo says band 1 is red, not gray, as the output of gdaldem hillshade:

Band 1 Block=256x256 Type=Byte, ColorInterp=Red   vs
Band 1 Block=256x256 Type=Byte, ColorInterp=Gray

This confirms the fact that gdal can generate the file I want, just not with the tool I'm using.

For info, I'm using mapnik to render this, and it's treating the file as if it were pure white (while qGIS properly renders it as geryscale; maybe the bug is in mapnik?). mapnik handles the 1band hillshade file with no problem.

I could do more fine grained things in Python if needed, bur I have no idea how to start.

Is there a simple way to do this?

8
  • Why not stay with the RGB if it works? Because the dataset I'm using is huge (worldwide) but I don't have much resources in terms of disk space and memory. Feb 2, 2018 at 18:30
  • Could you explain what is the benefit of your method compared with the hillshade mode? Color-relief is obviously designed to give a colored result which means that some tricks or post-processing will be needed.
    – user30184
    Feb 2, 2018 at 19:23
  • 1
    If the problem is in changing the color interpretation from red to gray you can use gdal_edit for that.
    – user30184
    Feb 2, 2018 at 19:38
  • 1
    I would try with undefined. Your single band red image is a bit weird if not buggy. The metadata seems to be in GDAL metadata tag Tag 42112: <GDALMetadata> <Item name="COLORINTERP" sample="0" role="colorinterp">Red</Item> You can get rid of it if you write a baseline tiff but then you lose also georeferencing.
    – user30184
    Feb 2, 2018 at 21:26
  • 2
    A GDAL developer has obviously seen this discussion and made some improvements to gdal_edit trac.osgeo.org/gdal/changeset/41385 and gdal_translate trac.osgeo.org/gdal/changeset/41386
    – user30184
    Feb 3, 2018 at 17:05

2 Answers 2

4

Given a grayscale conversion algorithm, gdal_calc is able to convert an RGB(A) GeoTIFF to a grayscale one (Credits to Jukka Rahkonen). For instance:

gdal_calc.py -R input.tif --R_band=1 -G input.tif --G_band=2 -B input.tif --B_band=3 --outfile=result.tif --calc="R*0.2989+G*0.5870+B*0.1140"

We can choose among different grayscale conversion algorithms (Source: http://www.tannerhelland.com/3643/grayscale-image-algorithm-vb6/), replacing only the formula:

Average

--calc="(R+G+B)/3"

Image processors (Photoshop, GIMP)

--calc="R*0.3+G*0.59+B*0.11"

BT.709 recommendation (ITU-R)

--calc="R*0.2126+G*0.7152+B*0.0722"

BT.601 recommendation

--calc="R*0.299+G*0.587+B*0.114"

Desaturation

--calc="(maximum(maximum(R,G),B)+minimum(minimum(R,G),B))/2"

Minimum decomposition

--calc="minimum(minimum(R,G),B)"

Maximum decomposition

--calc="maximum(maximum(R,G),B)"

etc.

1
  • Just a warning/note that if the output already exists and it's multi-band, and you don't specify --overwrite, then this will retain the multiple bands.
    – Josh
    Jun 7, 2023 at 8:39
1

The solution is not yet released, but if you're like me, you can compile it yourself.

I asked the same question in the #gdal IRC channel and Even Rouault hacked a little in the source code and:

https://github.com/OSGeo/gdal/commit/75488db0f4931f14721afa4f6ef3f06c7be31916

So now I can do gdal_edit.py -colorinterp_1 gray foo.tif and that's it. As per Even, this will be released in gdal-2.3 in the near future.

2
  • This changes the metadata color interpretation hint for the specified band(s) but does not collapse a 3 or more band image into a single band image. So it's useful and good to know (+1 for that) but doesn't address everything in the Q. Jan 17, 2022 at 22:54
  • But I think the OP has had the same issue I had: one grayscale TIFF with 3-4 bands (RGB[A]), when actually one is enough (after all, all the bands have exactly the same info if it's really gray scale). I think my original issue (and probably OP's) was that one of gdal's tools (probably gdaldem slope or hillshade) produces such a TIFF. Feb 7, 2022 at 17:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.