Aerial Services has uncovered a new “issue” with ArcMap 10. Any 4-band TIFF imagery (RGB+IR) produced anytime in the past using Inpho Orthovista may display in ArcMap 10 with some pixels missing (Figure 1). It appears any pixel from the 4th image (or band) with a color value of “0” will display as null. This type of imagery has always displayed correctly in all previous versions of ArcMap. The actual cause of this problem is interesting.
Figure 1: Any 4-band TIFF imagery (RGB+IR) produced anytime in the past using Inpho Orthovista may display in ArcMap 10 with some pixels missing.
A TIFF image is an interesting data container. At its core it is a bucket that contains an orderly pile of pixels. Each pixel is assigned a color value. We often think of a TIFF file as a single “image”. But the TIFF “bucket” is designed to hold any number of images all neatly stacked on top of each other. A black and white TIFF image contains a single image where all the pixels have values ranging from 0-255. A pixel with value = 0 displays as midnight black. A pixel with value = 255 displays as pure white. Other values display as some mix of white and black. But a color TIFF image actually contains three copies of a single image: a RED image, a GREEN image, and a BLUE image. Each is neatly stacked inside the TIFF bucket. Each pixel in each image is assigned a similar value 0-255. However, applications that read TIFFs are instructed to display pixels in the RED image with value = 0 not as black but as pure red. Pixels with value = 255 are displayed as pure white. All other pixel values are displayed as some mix of red and white. Likewise for the BLUE and GREEN images are displayed similarly. When the application sends any three pixels (a red, green, and blue pixel) to a monitor, the monitor displays all three colors at that pixel location and we see on the monitor the intended mix of those three colors.
If any color can be displayed using a combination of colors specified in the first three images, then why would one ever want to put extra images (like a fourth image) inside a TIFF image? One really good reason is store additional “bands” like infrared. Another is for creating “masks”. A mask is something that covers or hides something else. When masks are found in image files, they are special “pixels” whose value tells the application to NOT display any pixels at that spot, or perhaps to change the display of that pixel. In Photoshop and other image editing programs, masks can be created to hide other layers. This is a very important capability in image editing programs and therefore, a very important special function of the 4th image. So if a pixel with value = 0 occurs in the 4th image, then any other pixel from the other images inside the TIFF bucket that fall in the same place will be hidden (not displayed) by the mask pixel. Store this away for a minute!
Further, every TIFF file has a header. This header contains a variety of “tags” which are really like variables with an assigned value. Tags tell the application reading the TIFF image lots of information about that image (or images). Tags are used to define how many images are in the TIFF file, the number of pixels in each image, how big each pixel is in ground units, where on earth each pixel should be placed, and a variety of other things. These tags are inserted into a TIFF header by the application creating the image. Some tags conform to TIFF standards and are generally understood by all applications that might display the image. Some tags do not conform to TIFF standards and may or may not be understood or used at all by an application displaying the image. No application has to understand every tag. But any application that understands the basic tags can properly display most TIFF images.
Therefore, if applications that read TIFF images are to play nicely together, it is important that the correct TIFF tags be included with the file and that their values are set appropriately. Remember, just because a tag can exist does not mean it always will exist in a given TIFF file. Whether it occurs in the TIFF header depends on the application used to create the TIFF image. And even if the tag is there, the application designer could not use it at all. This is always a choice made by the application designer. The user seldom has any control over this.
In fact, any image that contains more than three images should contain a tag called “SamplesPerPixel” which tells the application how many images there may be (three or higher). In addition, if there are more than three images then an additional tag called “ExtraSamples” should be specified giving an indication of the meaning of the additional images (the fourth, fifth, etc.). This tag is sometimes referred to the “mask tag”. In fact, if there is a fourth image and ExtraSamples is not specified or left “undefined”, then an application reading the TIFF may do unexpected things. It could see a fourth image and be instructed to display it like any other, or it may be instructed to treat it as an alpha mask.
In previous ESRI ArcMap versions (v9x and before) the application has always simply ignored this mask tag in the 4th image. Any pixel piled in the 4th image was just displayed according to its pixel value. But starting in ArcMap version 10, ESRI decided to begin reading this mask tag as it was designed. That would be the end of it, but as is often true in life, it isn’t that simple. For many years, a vast quantity of 4-band TIFF imagery has been produced across the planet that was created by a product from Inpho called Orthovista. In all or most of these images, Orthovista had not disabled the “mask” tag, but instead left it “undefined”.
Figure 2: Beautiful 4-band TIFF images created by Orthovista, may display with “holes” in them when viewed in ArcMap 10.
This has not been a problem before because ArcMap simply ignored the mask tag and treated the fourth image like any other, until now. Now ArcMap 10 reads this mask tag and when it is not there or is left “undefined” it treats the fourth image as an alpha mask. This means beautiful 4-band TIFF images created by Orthovista, may display with “holes” in them when viewed in ArcMap (Figure 2). What can be done to fix this problem?
One possibility is to consider how another application, GlobalMapper, handles this problem. GlobalMapper, a very popular geospatial application, displays existing Orthovista images without problems. Apparently it looks at the “undefined” mask tag and simply displays the fourth image as any other (i.e., no holes). Additionally, when GlobalMapper sees a tag that indicates the fourth image may be a mask, it asks the user when the file is opened how they want to treat that image, as a mask or not. This is a great way to handle this situation because it gives the user the final say. Hopefully, ESRI will provide a similar user choice in ArcMap 10 service pack 3 expected later this year.
Inpho is also addressing this problem in other ways. It is preparing a utility that fixes existing TIFFs and has a beta version of Orthovista that properly writes the ExtraSamples tag into the TIFF header to avoid the issue.
We can only hope in the future all software providers adhere to open standards and cooperate with each other to resolve user problems caused by their applications. We look forward to more compelling solutions from ESRI and Inpho.