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):
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"
:: 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
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.