Hot answers tagged gdal-merge
While I don't know why GDAL provides this overlap in functionality, be sure to set the cache for gdalwarp to make it really fast: # assuming 3G of cache here: gdalwarp --config GDAL_CACHEMAX 3000 -wm 3000 $(list_of_tiffs) merged.tiff Be sure to not define more cache than having RAM on the machine.
gdal_merge.py is the correct tool to 'stack' your input images. Assuming that your first band has a valid color table you could use: gdal_merge.py -separate -pct -o output_file.tif file1.tif file2.tif file3.tif Note: The command has been reformatted with -o output_file.tif before the list of inputs. From the docs: -pct: Grab a pseudocolor table ...
The first way I can think of is to build a vrt, edit and translate: gdalbuildvrt -separate output.vrt file1.tif file2.tif file3.tif add the color interp tag where needed: ... <VRTRasterBand dataType="Byte" band="1"> <ColorInterp>Red</ColorInterp> <NoDataValue>255</NoDataValue> <ComplexSource> <SourceFilename ...
I ran across this mosaicing the True Marble imagery as well, though I used gdalbuildvrt and then gdal_translate. From memory, the recalcitrant tiffs are stored as a single band with a color table. Just convert them to 3 band RGB with gdal_translate: gdal_translate -expand rgb TrueMarble.250m.21600x21600.B4.tif TrueMarble.250m.21600x21600.B4.RGB.tif
I have a solution! It IS because of the old and infuriating GDAL upside-down export to GeoTiff (see my comments above)! Before anybody tells me that this has been fixed - I agree it does appear to be fixed but I was using a mixture of data converted with a older version of GDAL about 4 years ago and data I converted with the latest version of GDAL about 3 ...
Open MSYS (It should have been downloaded along if you used OSGeo4W utility to install qgis) cd (Change Directory) to your folder with your data. cd c:/(path to)/(my data)/ (Hint: pressing tab, autocompletes) one-line it: gdal_merge.py -o out.tif $(ls *.tif) out.tif -> is your output file, name it to whatever you want. $(ls *.tif) -> lists all the files ...
I would build a GDAL virtual image using (something like): gdalbuildvrt myimage.vrt images/*.tif and then tile that using either gdal2tiles or gdal_retile: gdal2tiles.py myimage.vrt outputDir or gdal_retile.py -tileIndex tileIndexName myimage.vrt
The chosen value is stored in the PhotometricInterpretation TIFF tag, which defines the color space, i.e. how to interpret the values of the bands. Example for a 3-band GeoTIFF defined as RGB: band 1 = red, band 2 = green, band 3 = blue. CMYK stands for the Cyan, Magenta, Yellow, blacK color space, etc.
Answering my own question: Those black pixels in the images represent a "NoData" value. If I tell the gdal merge code that pixels with a color value of 0 are "NoData," it can correctly stitch the images together. (The "NoData" value isn't necessarily set to 0, it can be any value not otherwise used in the image, but in the case of NAIP ortho images, it was ...
Yes, the two different version of GDAL_merge do behave differently. I ran into a similar problem (see this post), though yours appears to be a little different. Basically, I think that the more recent version is the one to trust. The reason it works differently is because thankfully it has been updated, so it should not be unbelievable.
Only top voted, non community-wiki answers of a minimum length are eligible