Hi, For a past few days I`m trying to apply color correction to my raster catalog but ... It is always a good practice to RTFM before trying to do something. So I did: Color balancing a raster catalog So before applying this on my actual data I created a simple raster catalog with just two raster datasets. Both of them were 8-bit and had 3 bands. So next thing I did was statistics and pyramid calculation. After this I was able successfully apply color balancing which gave me confidence that nothing wrong will happen when I`ll try to apply it on my production data. I was so wrong ... First some of the data had 16-bit pixel depth and all other 8-bit so I converted all to have 8-bits pixel depth. Then I used statistics calculation tool for the data - 10 hours of work and I`m ready to apply color correction: Color correction->Color balancing->Dodging balancing->Color grid->GO. When first step reached 33% - "Color correction requires each raster band to have a histogram... Use the Build Pyramids and Statistics geoprocessing tool to calculate statistics." Agh... what? I did this. How the hell it`s missing? Ok lets try this again... calculate statistics... yet another 10 hours passed. Color balance -> same error. Is this some kind of joke? Where is the information about which of the datasets is missing those statistics? Or should I check 2774 datasets by hand?
I found out that two images were corrupted (wierd colored lines on image). Interesting is the fact that arcgis calculates statistics for them but color correction fails. I`m not sure why two tools that are highly dependant can interpret data differently...
Recently, we are fully testing color balancing capability/ flexibility/ efficiency within Mosaic Dataset through the following scenario:
1. Batch 1 of 40 scenes (GeoEye-1) in one area are done (sensor model RPC, DEM, pansharpen, etc); define overview; build footprint (remove NoData); after 10 hrs the misssion failed (because of license disconnection), take another 20 hrs to build pyramids and statistics; and then do correction of the color; Finally, take hours to build overviews (6 levels), and publish it for the users to comment;
2. Batch 2 of 20 scenes (adjacent to the Batch 1) would be appended, two issues are coming:
A. How to do color correction of Batch 2 to match the color of Batch 1? Remove the previous to re-do it as a whole, or just build on the queried /new ones (reasonable, but no interface to do so)?
B. How to build overviews of Batch 2 to make overall overviews as a whole? Remove the previous to do it agian, just like old image services by Image Service Editor 9.3.1/10?
3. Batch 3 of 35 scenes (far away the above area) will be appended. Repeart the above steps?
In practice, stability, flexibilty and efficiency are highly required to update/append the existing image service.
On color matter, we give two technical criteria for users to focus: 1. overall image service should be 'color balanced', at least changed smoothly; and 2. this image service should show clear features (roads, tanks, buildings, etc) at full resolution. For pansharpened GeoEye, the full resolution is 1:1850.
On color correction, we are testing in one area with our own data of three sensors, where it is located at the range (E 50 00'-50 15' / N 26 00' - 27 00'). As a good benchmark from ESRI, we use the very-high-resolution image in Basemap (World Imagery) within ArcGIS Explorer 1500 from USGS as a reference point, which presents well-balanced color in this area. And also it gives well spatially-matched imagery mosaic on overlapping areas (open the attached *NMC AOI file).
During tests, what we are trying to do was to create three mosaic datasets with IKONOS (11 tiles), QuickBird (30 tiles), and GeoEye (48 tiles), which cover same area. The target is that we would have similar look and internally spatial-match mosaic image that ArcGIS Explorer 1500 demonstrates.
Very regrettably, after many trials with different combination of paramenters in 'color correction' tool (http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009t00000041000000.htm), we were not able to get similar 'color balanced' mosaic dataset from either IKONOS, QuickBird, or GeoEye. Mostly, each scence from 40 has different color (see the attached graphics, which is the best two), and also shows un-clear features (compared to USGS image or our own processed image by ERDAS). We are not sure if having done something wrong so that we couldn't reach this goal.
On color correction with ArcGIS 10 (SP1), we are using our own data (IKONOS, QuickBird, GeoEye) to test.
Considering better communication with you guys, we refer to an area with about 8,000 sqr KM, where a very-high-resolution image has been already served in Basemap (World Imagery) from ESRI. As a reference point, we think that this mosaic image (from USGS?) presents well-balanced color overall. And also it gives well spatially-matched imagery mosaic on overlapping areas (open the attached *NMF AOI file in ArcGIS Explorer 1500). On the location, you also can define it at the range (E 50 00'-50 15' / N 26 00' - 27 00').
During tests, what we were doing is separately to create three mosaic datasets with IKONOS 2008 (15 tiles), QuickBird 2009 (28 tiles), and GeoEye 2010 (43 tiles), which exactly cover the same area of AOI. The target is that we would produce three mosaic images, at least, having similar look & spatial-match on overlapping areas inside mosaic datasets that ArcGIS Explorer 1500 demonstrates. If succeeded and satisfied, we will merge them as single one mosaic dataset (with scale dependency) for customers and management to comment.
Very regrettably, after many trials with different combination of paramenters in 'color correction' tool (http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009t00000041000000.htm), so far, we are not able to get similar 'color balanced' mosaic dataset from either IKONOS, QuickBird, or GeoEye. In fact, each scence out of 43 GeoEye in mosaic image, mostly, has different color (see the attached graphics, which is the best adjacent two), and also shows un-clear features at full resolution (1:1850), compared to either USGS source or our own processed mosaic image by ERDAS / LPS.
It is worth to mention, during our tests, the 'spatial shifts' also couldn't be solved with only using sensor model RPC and DEM.
Inside each mosaic image, which is merged from different images acquired on different dates from same sensor, mojarity are well-matched, but sometimes we see spatial shifts on overlapping areas. Secondly, inside each mosaic image, it usually has significant internal shifts, corresponding to our surveying data (roads, buildings, etc) and spatially-rectified background images. The offsets with 3-10 m are very common for GeoEye. Finally, as a small example, the shifts in the overlapping images between different sensors in that area exist as well (See the attached. You can assume, the background Landsat was spatially rectified with surveying data, which means that the high-resolution image is required to correct in ArcGIS 10, in order to match references.)