4

I get the following error when uploading my GeoTIFF to Mapbox:

Only 8 bit TIFFs are supported

My GeoTIFFs are 16 bit unsigned.

I need to convert them to 8 bit.

I've been georeferencing images in ArcMap and exporting them, then they somehow become 16 bit unsigned.

I'd prefer a solution in QGIS, but if ArcMap has an easier solution, that's okay.

So you can help me make sure it works, here's a temporary link to my GeoTIFF:

https://drive.google.com/uc?export=download&id=1k5GGqrYofShdXjI2LzFWH3BeFpNsuOQy

Vince
  • 20,017
  • 15
  • 45
  • 64
nittyjee
  • 465
  • 5
  • 14
  • Does your GeoTIFF use the whole range for 16 bit unsigned (0 to 65535)? You can use translate with -ot BYTE but if your data is higher than 255 it will be truncated to 255 leaving you with an almost totally white raster. If you are in this situation you can use gdal_calc (or the QGIS raster calculator) to divide the GeoTIFF by 255 with -ot BYTE to scale the values back to the appropriate range. – Michael Stimson Mar 12 '20 at 06:40
  • 2
    On reviewing the image linked I used the command gdal_translate -of gtiff -ot byte and it worked just fine, the upper 8 bits don't appear to be used as the Esri statistics min: 20 max: 255 mean:172.44 show. https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/gdal/rasterconversion.html#translate-convert-format is worth a look. As for why they become 16 bits it may have something to do with the NoData setting as 'Promote' - your raster has a nodata value of 256 so it's promoted to 16 bit but it depends on how you exported the rasters if that had any effect. – Michael Stimson Mar 12 '20 at 06:48
  • 2
    If upper bits are used then you can run gdal_translate with the -scale option. – user30184 Mar 12 '20 at 07:31
  • 1
    If you tell ArcGIS to use a 16-bit value for NODATA, you have requested a 16-bit image. – Vince Mar 12 '20 at 11:42

1 Answers1

7

It looks like there is a consensus on the cause and fix for your rasters. 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 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.

You can fix the raster in GDAL using QGIS Raster::Translate if you're not comfortable with command line. 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):

ArcGIS Desktop raster properties

From the raster statistics (blue arrow) I can see that only the lower 255 is used which alludes to promotion by ArcGIS. 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

As 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

Which will create a composite RGB image from bands (-b) 1, 2 and 3. As user30184 has mentioned, if the statistics show that the legitimate values exceed the range for a byte you can use the -scale option taking the statistics min and max, in this example the full range of 0 to 65535 for an unsigned int16 and scaling to 0 to 255:

GDAL_Translate -of GTIFF -ot BYTE -scale 0 65535 0 255 c:\your\path\original_castello.tif c:\your\output\path\modified_filename.tif

With the GeoTIFF format I have found that the NoData value need not exist or even be possible to exist in the data type, the C API shows that the SetNoDataValue takes a double (64 bit floating point) as its argument and there are no overloads making it possible to set a nodata value of INF (infinity) or NAN (not a number) or remove the value entirely.

I have found a theoretical workaround for your specific case with GDAL. I say theoretical as the help docs (Related thread, GDAL calc for nodata as 0, Building a VRT stack, Buld stack and GDAL Edit) say that this should work but my numpy is incompatible with the most recent version of GDAL and I can't just upgrade without risking breaking something:

SET   InRaster="C:\your path\with\spaces\original_castello.tif"
SET  OutRaster="C:\your path\with\spaces\Modified_castello.tif"
SET   TempName=%TEMP%\^TempRaster%RANDOM%
SET  Temp3band=%TempName%.tif
SET  Temp4band=%TempName%.vrt
SET Temp_Band4=%TempName%_B4.tif
SET Temp_Alpha=%TempName%_Alpha.tif

:: Extract the first 3 bands as bytes to RGB raster
GDAL_Translate -of GTIFF -b 1 -b 2 -b 3 -OT Byte %InRaster% %Temp3band%

:: Extract the 4th band as UINT16
GDAL_Translate -of GTIFF -b 4 %InRaster% %Temp_Band4%

:: Unset the NoData value or GDAL_Calc will just ignore the out of range values
GDAL_Edit.py -unsetnodata %Temp_Band4%

:: Calcualte a new band with 255 and 0 where the band was nodata
GDAL_CALC.py -A %Temp_Band4% --outfile=%Temp_Alpha% --calc="(A==255)*255" --type=Byte

:: Restack the images
GDALBuildVRT %Temp4band% -separate %Temp3band% %Temp_Alpha%

:: Convert the stack to a single raster then set the band color labels
GDAL_Translate -of GTIFF %Temp4band% %OutRaster%
GDAL_Edit.py -colorinterp_1 red -colorinterp_2 green -colorinterp_3 blue -colorinterp_4 alpha %OutRaster%

:: Clean up
DEL %Temp4band%
DEL %Temp3band%
DEL %Temp_Alpha%
DEL %Temp_Band4%

Most of these steps work but it is the GDAL_Edit.py that is having issues and it's important to the process to clear the NoData value or set it to something outside the range of the raster or the 256 values in the 4th band will be ignored.

Michael Stimson
  • 25,566
  • 2
  • 35
  • 74
  • Michael - Incredible, thank you. One thing though - the background is all white, I need it to be transparent like it was. How do I do that? – nittyjee Mar 13 '20 at 05:23
  • Also - could you remove the periods I added at the end of your answer? I edited your comment to just remove a space in one of the commands, and it said I had to add at least 6 characters, so I added periods, then tried to make another edit to delete them, now it's not letting me. Kind of funny, sorry about that :/ – nittyjee Mar 13 '20 at 05:31
  • 1
    That is more problematic, on looking at your 4th band it seems there is two values 256 and 255 - 256 is nodata, 255 is opaque in an RGBA file.. I'll see what I can come up with. – Michael Stimson Mar 13 '20 at 05:31
  • Unfortunately it's the end of my working week so I won't be back till monday UTC+10 – Michael Stimson Mar 13 '20 at 05:38
  • Thanks Michael, this is amazing. When you get back, let me know if you have a solution if you're able and willing. – nittyjee Mar 13 '20 at 05:49
  • 1
    I have put in a possible workaround. This would be easier in ArcGIS but only if you have a spatial analyst license. It would be easier to script this in GDAL with python or arcpy, if you want to try a python solution please ask a new question and reference this thread - the answer is a bit too long already. – Michael Stimson Mar 16 '20 at 02:09