[Edit – This problem has been fixed in ArcGIS 10.3]
While working with our 16-bit land cover change data (see earlier GeoZone post) in Tiff format we noticed a problem using ArcGIS. The display doesn’t color the image properly. The problem has been reported to Esri and they’ve entered it as a bug to fix in a future release. Until then, I thought I ought to give you a workaround or two.
I’m going to use the C-CAP land cover change data to illustrate the problem. As Eric Morris talked about in his post, these data sets have 625 classes representing all the possible change combinations between two dates of land cover using a 25 class scheme. Most of the pixels are colored the same bluish-gray because most of them didn’t change.
Figure 1 is what the data should look like in the area of Charleston, SC. Figure 2 is what the data looks like when you first pull it into ArcGIS (version 10.2.0 in this case). Since Figure 2 has features you can recognize, you might not initially realize something is very wrong. That big yellow area in the upper left of the image looks like a lake and it is, though it’s pretty odd that it is yellow. However, if you were to do an identify on those lake pixels, you’d see that it is class 521 (water to water or no change) and should be that bluish-gray color. The identify output is in Figure 3 and you can see that it gets it all right.
So what’s the problem? It’s the display. Even though the identify tool is returning the right cell value and r,g,b, it is displaying the color for something else. Looking at the attribute table, it appears that it is coloring it as if the color table is shifted by two. Value 521 is colored as if it is value 519 (water changing to unconsolidated shore, which some of us would call beach). ArcGIS is reading everything correctly, but then colors it as if it subtracted 2 from all the values. A few other GIS/remote sensing packages were tried to see if this was some problem with how the Tiff was made (using GDAL), but the other packages displayed just fine.
If you’re getting the data from the Digital Coast Data Access Viewer (aka DAV), the easiest solution is to request an ERDAS Imagine file instead. ArcGIS has no problem with the Imagine files.
If you want or need to stick with a Tiff file, there is a way to do it, it just takes a few steps. You’re basically going to convert to a different bit-depth file and then convert back.
Copy the 16-bit data to a 32-bit Tiff using the Data Management Tools -> Raster -> Raster Dataset -> Copy Raster tool from ArcToolbox. The main thing is to set the Pixel Type to 32-bit unsigned. This is going to effectively strip the colormap because a 32-bit colormap would be 4 Gb in size, which is the limit for a baseline Tiff anyway. For our file, the result looks like Figure 5.
Now do the same thing in reverse, making a 16-bit unsigned raster Tiff from the 32-bit. This will leave you with the same thing you started with, except it has no colormap. It will look just the same as the 32-bit result from Step 1.
Under the symbology for the original 16-bit raster, export the colormap using the Colormap dropdown menu.
Make sure the new 16-bit version from Step 2 is not in the layers (remove it, not just uncheck it). This might not be strictly necessary, but it’s safer and I did have ArcGIS crash when I didn’t do that.
Rename the exported colormap to match the name of your new 16-bit raster. If you made new16bit.tif, the colormap should be named new16bit.clr in the same folder.
Add the new raster to Arc, it should now display correctly as shown in Figure 1.
While 16-bit thematic data in Tiff format isn’t common, it is disconcerting when it doesn’t display correctly. Almost all of the downloads of C-CAP change data since we changed our raster processor and were able to add them to the DAV system have been in Tiff format. I’m hoping these tips will give those folks a bit of help. With any luck, ESRI will get it fixed soon and this post won’t be needed.