![pixelstick images 8 bit pixelstick images 8 bit](https://static.hawaiicamera.com/product_image/image/2502/product_page_1435005589000_IMG_495466.jpg)
Using GDAL_Translate if you specify the output type (-ot) as BYTE that utility will reduce values outside the range 0 to 255 to the maximum value of 255, as there are no values higher than 255 it is safe to do so: GDAL_Translate -of GTIFF -ot BYTE c:\your\path\original_castello.tif c:\your\output\path\modified_filename.tifĪs your 4th band is redundant you could safely do GDAL_Translate -of GTIFF -ot BYTE -b 1 -b 2 - b 3 c:\your\path\original_castello.tif c:\your\output\path\modified_filename.tif The options that are important are -ot BYTE and perhaps band management -b 1 -b 2 -b 3 as your fourth band is all 255 which seems kind of redundant Your input raster is 4 bands (red arrow) of 16 bit (green arrow) with a band nodata of 256 for each band (purple arrow):įrom the raster statistics (blue arrow) I can see that only the lower 255 is used which alludes to promotion by ArcGIS. You can fix the raster in GDAL using QGIS Raster::Translate if you're not comfortable with command line. It is fairly common to set an RGBA nodata value to 256 for an 8 bit raster as the no value part is handled by the alpha band, unfortunately when these get processed in ArcGIS it increases the number of bits so that the raster can actually contain the nodata value. For the benefit of users in the future experiencing the same issue, it is likely that your export from ArcGIS ( Copy Raster?) has promoted your NoData, which can happen if the NoData was set out of range or not set prior to exporting. It looks like there is a consensus on the cause and fix for your rasters.