Select to view content in your preferred language

Images placed wrong in image service

1692
3
12-08-2010 09:31 AM
PaulHuffman
Frequent Contributor
About a month ago, I created 6 images services for 6 tiles of 2006 NAIP jpg images in 9.3.1. Each service used around 500 jpg images. Now I see that in one service that four images are in the wrong place.  By displaying the ISDEF for the service, I was able to identify the names of the four problem images. The original jpgs map in ArcMap in the correct place.  As in the other jpgs in the directory that went into the service correctly, the problem jpgs have world files associated with them. But maybe the header information was bad.

I wondered if ArcMap uses the world file while Image server uses the header file or visa versa. 

I thought maybe there were four other images in the folder that had the the wrong world file coordinates, duplicating the world files of these four problem images.  I thought that I could use grep to search for files that have the same coordinates as one of the problem images. If I could find all the *.jgw files that have for example 1234 on line 5 and 5678 on line 6, maybe I would find a duplicate. However,
grep 1234 *.jgw| grep 5678

can only find files with 1234 and 5678 on the same lines.  Is there a sed trick that can do this?  

I tried exporting these photos to another format like img and even to another jpg.  These exported photos map in ArcMap in the correct position, but the color mapping has changed a little from the original jpgs.

I'm wondering what my next steps should be.  Isn't there a way to patch in new images to a image service to see if the image copies will straighten this out?  Should I try moving the four problem images out of the directory, leave the copies in the directory and make a new service?  How do I get the exported images to match the color mapping of the originals?
0 Kudos
3 Replies
PaulHuffman
Frequent Contributor
I had this idea that maybe some of the jpg world files had incorrect coordinates in them, duplicating the coordinates for the correctly placed photos. Using Linux, I searched the folder for any jgw file that contained the same coordinates as file 00084_00072.jgw which contains
                  1.50000000000000 
                   0.00000000000000 
                   0.00000000000000 
                  -1.50000000000000 
             1585152.75000000023283 
              516095.24999999953433 


with a for loop and a perl string:
 for i in *.jgw; do perl -lane '$m = 1 if $. == 5 && m/1585152/;print "$ARGV" if $m && $. == 6 && m/516095/;' $i; done


But I didn't find a duplicate. 

Therefore, I either need to keep looking for another reason that the photos are getting placed incorrectly, or the world files got hosed when they were copied over to the Windows ArcServer server.  Since I can't make a samba connect to that ArcServer server from Linux, I'll have to come up with a Windows way of looking for a duplicate world file.
0 Kudos
PeterBecker
Esri Regular Contributor
For both Mosaic Datasets and the older ISDefs, the georeferncing is determined at the point the data is added to the mosaic dataset or ISDef. In both methods you can define if the World file should be used or not. As you are using JPEG images there is no option except to user the world files. Is it possible that the world files have been changed since you added them to the ISDef?

It is not clear to me why you are looking for the duplicated .jgw files. The simplest way to find such duplicates is to re-create the ISDef (or mosaic dataset) and see the duplicates.

Concerning the pixel values changing: The values will not change if you copy rasters. The issue is potentially that when copying the rasters to another format statistics are being computed and by default ArcMap will stretch images that have stats and so you see different imagery. There is an option in arcmap to turn this off.

On a separate note related to file formats. I would generally recommend agains using JPEG images for such imagery unless the images are small (<5MB). The reason is that opening a JPEG file required the complete image to be decoded if the last pixel is to be viewed. On larger images this can slow things down. For larger images it is better to use TIF with JPEG compression. Such files are tiled allowing only parts of the image to be accessed.

I would also suggest you look into using the Mosaic Dataset available in V10. This will also provide the ability to quickly catalog the imagery and serve them up.
0 Kudos
PaulHuffman
Frequent Contributor
Each jpg is about 14 mb.  I don't like it but that's the way I got them from the 2006 NAIP effort in our state.  Since I have about 50000 of these, I wasn't eager to convert the file format. 

I just thought it was pretty clever of me to figure out a way to look for a duplicated jgw file.  But not clever enough, since I was only able to check my local copy on Linux, not where they sit on a Windows ArcServer.  Like they said in "Spinal Tap", "There's a thin line between clever and stupid".

On the ArcServer machine, I created an ArcMap look at all 500 jpgs. Took a long time and it's still difficult to tell if there's a jpg that is getting placed incorrectly. 

I'll try a new ISDEF next.

Want to get v10 soon!

Today I created a new image service from all the images in the directory, still in 9.3.1, and the new image service looks fine.  Don't know what happened the first time.
0 Kudos