Avoid creating alpha band when using gdalwarp

Question

I am using gdalwarp to reproject a greyscale GeoTiff tile from one projection to another so I can use it in a VRT. This is required as gdalbuildvrt won't accept files in multiple projections.

When I run gdalbuildvrt, I'm getting the error:

Warning 1: gdalbuildvrt does not support heterogeneous band numbers: expected 1, got 2. Skipping <filename>

If I run gdalinfo on the source image, it shows me the following band info:

  Band 1 Block=1000x2 Type=Float32, ColorInterp=Gray
  Min=442.516 Max=590.010
  Minimum=442.516, Maximum=590.010, Mean=493.853, StdDev=19.508
  NoData Value=-9999

Running gdalinfo on the destination image shows the following band info:

Band 1 Block=1055x1 Type=Float32, ColorInterp=Gray
Band 2 Block=1055x1 Type=Float32, ColorInterp=Alpha

However, I don't seem to be able to come up with options for gdalwarp so that it creates an output image with just the gray band, and no alpha band. The output file should have 1 band and a NoData value of -9999, just like the input file.

gdalwarp command lines I have tried include:

gdalwarp -t_srs EPSG:28356 -r cubic <srcFile> <destFile>
gdalwarp -t_srs EPSG:28356 -r cubic -dstalpha <srcFile> <destFile>
gdalwarp -t_srs EPSG:28356 -r cubic -srcnodata -9999 -dstnodata -9999 <srcFile> <destFile>

How to avoid gdalwarp converting to alpha band appears to be asking a similar question, but the one answer given appears to be essentially the same as my last command line above, which does not work.

Is there a way of converting a single-band greyscale GeoTiff from one projection to another without creating an alpha channel?

Sample input TIF file can be found at https://ozultimate.com/downloads/srcfile.tif. I am reprojecting from EPSG:28355 to EPSG:28356

I just tried gdalwarp -t_srs EPSG:28356 -r cubic srcfile.tif dstfile.tif and did not get an alpha band. You could try -b band https://gdal.org/programs/gdalwarp.html — user2856, Jul 12 '23 at 04:41
My bad. Looks like a system issue and not a GDAL issue. As described in the question, I ran gdalwarp several times using various command lines - but without deleting destfile.tif between each run. The Date Modified on destfile.tif was updated each time, and so I (incorrectly) assumed the file was being regenerated from scratch. But in fact, it just updates the file, leaving any alpha band in place. I should have been using the -overwrite option. So you are correct that gdalwarp -t_srs EPSG:28356 -r cubic srcfile.tif dstfile.tif seems to work. — Tom Brennan, Jul 12 '23 at 07:48
Ahhh... the inplace update. That's caught me out before. I reckon you should add that as an answer. — user2856, Jul 12 '23 at 07:51

score 2 · Answer 1 · answered Jul 12 '23 at 08:00

Root cause of my problem was that gdalwarp by default does an in place update.

If you want to overwrite previous destination files, you need to either delete them, or use the -overwrite option

As described in the question, I ran gdalwarp several times using various command lines - but without deleting dstfile.tif between each run. The Date Modified on dstfile.tif was updated each time, and so I (incorrectly) assumed the file was being regenerated from scratch. But in fact, gdalwarp just updates the file, leaving any alpha band in place. I should have been using the -overwrite option.

gdalwarp -t_srs EPSG:28356 -r cubic srcfile.tif dstfile.tif does actually work, as long as dstfile.tif does not exist.

However, if dstfile.tif exists, and already has an alpha band, then the updated file after running the above command will also have an alpha band.

Avoid creating alpha band when using gdalwarp

1 Answers1