Hello, we have recently generated two cached map services using the PNG8 format, and both services exhibit the same problem. There is unexpected transparency in the caches. Both caches are based on TIF imagery, and in both cases the original TIF images contain no transparency. When we generate the same caches using the MIXED, PNG24 or PNG32 formats, there is no transparency in the resulting caches, as expected. The unexpected transparency appears only for the PNG8 format.
The raw TIF-images for the two services have one major difference: For Service A they have 8-bit color depth and for Service B 24-bit color depth.
For service A (raw images have 8-bit color depth), it is my understanding that the raw TIF images and the resulting PNG8 images in the cache both use indexed color. After further analysis, it appears that the pixels with index value 1 in the raw images are always becoming transparent in the resulting cache. Can this somehow be changed? As far as we can tell, the raw TIF images don't have an alpha channel, but the resulting PNG8 images do. Why would this alpha channel be added to the cached images?
For Service B (raw images have 24-bit color depth), the transparent locations don't look pixels at all when viewed in ArcMap, but rather like tiny vector features that have details smaller than the size of individual pixels. We have no idea how to make sense of this. Is there any logical explanation for this?
We have read that, in general, changing the background color of the data frame (to an RGB-value that does not exist in the imagery) before publishing can fix these sorts of transparency problems, but that did not work for either of the services. The same pixels / tiny areas always become transparent in the resulting cached service, regardless of the background color prior to publishing.
We are extremely confused by these observations, and any assistence would be greatly appreciated. We just want to prevent this unexpected transparency from being introduced into the caches. If possible, it would be great if the transparency could somehow be removed from our existing caches without needing to generate the caches from scratch again.
Can you provide images from the raw imagery and the cache for the same area with the transparency. PNG will cache with a transparency, so if there are areas of no data it could cause an issue.
Two options I can see here to solve the issue:
1) Use JPEG for the cache format, as there is no transparency
2) Instead of changing the data frame colour, create a polygon with the same extent/boundary as the imagery, place it under the imagery in the table of contents, and change the colour to white (no outline). This will be read as "data" and will not allow for transparency to occur where the polygon exists.
Thank you for your prompt response! I don't think there are areas of no data, because the raw images are not transparent when viewed in ArcMap. But then again, I don't understand all the settings that would influence the display of no data values.
I can gladly provide the sample data if you would be willing to take a look at it. If so, where can I upload it?
Can you take a screen shot of the before (raw) and after (cache with transparency)? That should be enough to get an idea of what is happening.
Is there a reason you are using PNG8? Imagery will easily contain over 256 colours, meaning that PNG8 is probably not the best option for the tile format.
Also, according to this help Available map and image cache properties—Documentation (10.3 and 10.3.1) | ArcGIS for Server , it seems that if there is a pixel with NoData (probably hard to see by eyeing the imagery) it may cause the entire cache tile to be transparent.
"This setting determines what output image format the map service will use when it creates the tiles. Your choice of image format is important, because it determines the size on disk of the tiles, the image quality, and the ability to make the tile background transparent."
I used the term "imagery" loosely. Actually, the Images contain a very limited Color Palette (within the limitations of PNG8), and the format was chosen to save disk space for the generated cache.
Below is what the original raw images look like for Service A (viewed in ArcMap). I set the backgroung color to a very noticeable blue, so that we can see the transparent areas clearly (here there are none):
The resulting service then looks like this (in same ArcMap session with same blue background):
This service has the 8-bit Color depth. I used the Pixel Inspector in ArcMap and other Image editing software to verify that the pixel values of the areas that become transparent is 1. According to the Image editing software I'm using, the indexed Color with the index value 1 is "almost White" (254,254,254).
For Service B (original raw Images in 24-bit Color depth) the raw Images look like this:
And the resulting service Looks like this (with small transparent areas):
Now comes the most interesting part. As shown above, the transparent areas are very tiny. At first, I thought they were pixels, but they are actually smaller than the pixels in the imagery. When I zoom in to look at them in Detail, they actually look like vector features! (as shown below):
Is there any possible explanation for this? I definitely can't think of one!
My guess is that it probably has something to do with the number of colours supported.
Have you tried my suggestion for putting a polygon (covering the extent of the image) behind the image and changing the colour to white? This is what I use for situations like this. It should solve the issue.
I tried the suggestion for both services, and I really expected it to solve the problem, but unfortunately it didn't. The resulting services contain exactly the same transparent pixels / areas. It seems like the transparent areas in both services are somehow destined to become transparent no matter what I do!
I just wanted to write to thank you again for your help on Friday, and also to let you know that we found more information on this. We think the cause of the problem could be this known issue:
Based on this, we will probably just avoid using the PNG8 Format. I tested today, and the problem for Service A is fixed with PNG24 and PNG32. For Service B, the problem is fixed only with PNG32 (and not with PNG24). Apparently, PNG32 is generally recommended over PNG24 anyways, so I think we will just switch to PNG32 for both services. Our Caches will be bigger, but we won't have this unexpected transparency.