[Mapserver-users] MapServer/gdal doesn't like Photoshop tiff

Pericles S. Nacionales nacional at cbs.umn.edu
Wed May 19 02:42:13 EDT 2004


This happens because photoshop doesn't support GeoTIFF images.  When you
open the GeoTIFF image in Photoshop and then save it again, you lose the
georeferencing.  What you can do to fix it is create what's called a
world file.  This is a small text file with the following lines (this is
only valid for the example 1.5 image):
0.00473306
0.0
0.0
-0.00473306
-97.3743368
49.415919

If you copy these lines to a text editor and save the file as
mod09a12003161_ugl_ll_8bit.tfw in the same directory where you have your
tiff image, your map should then work.  To explain the lines briefly:
line 1 represents the X dimension of your pixel (in map units)
I don't really know what lines 2 and 3 are (don't change it unless you
know what you're doing)
line 4 is the negative Y dimension of your pixel (it has to be negative)
line 5 is the upper left X coordinate of the image
line 6 is the upper left Y coordinate of the image

You can get these info if you have the GDAL utility program "gdalinfo". 
Go ahead and use photoshop to edit the images but make sure to get the
pixel dimensions and upper left coordinates of the image before doing
so.

Good luck!
-Perry

On Tue, 2004-05-18 at 23:00, Marvin Humphrey wrote:
> Greetings,
> 
> Problem:  I load the mapserver tutorial at 
> http://terrasip.gis.umn.edu/projects/tutorial/ .  I take the tiff 
> source used for example1-5.map, scp it off from the FreeBSD 4.9 box 
> running MapServer to a Mac OS X 10.3 box running Photoshop 7.0 and 
> resave it without editing.  After scp'ing it back, MapServer doesn't 
> process it anymore -- vector data displays when I load example1-5, but 
> raster data is missing, and the display happens fast enough to suggest 
> that MapServer is simply rejecting the file rather than misinterpreting 
> its contents on a pixel-by-pixel basis.
> (My eventual goal is to take other raster sources (specifically GLOBE 
> datafiles), turn them into tiffs and process them.  This 
> save-with-no-changes operation is for troubleshooting.)
> 
> I've been through debugging the conflict between the internal tiff 
> support and gdal.  (How about making --with-tiff and --with-gdal an 
> illegal compile combination?).  MapServer has been recompiled 
> --without-tiff.  Here's my config:
> 
> # ./mapserv40 -v
> MapServer version 4.0.2 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP 
> SUPPORTS=PROJ SUPPORTS=FREETYPE SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT 
> SUPPORTS=WFS_SERVER INPUT=EPPL7 INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE
> 
> gdal (version 1.2.0) has tiff support, since gtiff is in this list:
> 
> # gdal-config --formats
> gxf gtiff hfa aigrid aaigrid ceos ceos2 iso8211 xpm sdts raw dted mem 
> jdem envisat elas fit vrt usgsdem l1b nitf bmp pcidsk bsb gif jpeg png
> 
> tiffinfo has this to say about the original image from the tutorial...
> 
> # tiffinfo mod09a12003161_ugl_ll_8bit.tif
> mod09a12003161_ugl_ll_8bit.tif: Warning, unknown field with tag 33550 
> (0x830e) ignored.
> mod09a12003161_ugl_ll_8bit.tif: Warning, unknown field with tag 33922 
> (0x8482) ignored.
> mod09a12003161_ugl_ll_8bit.tif: Warning, unknown field with tag 34735 
> (0x87af) ignored.
> mod09a12003161_ugl_ll_8bit.tif: Warning, unknown field with tag 34737 
> (0x87b1) ignored.
> TIFF Directory at offset 0x1152f68
>    Image Width: 3480 Image Length: 1740
>    Resolution: 1, 1 (unitless)
>    Bits/Sample: 8
>    Sample Format: unsigned integer
>    Compression Scheme: None
>    Photometric Interpretation: RGB color
>    Software: "ERDAS IMAGINE"
>    Samples/Pixel: 3
>    Rows/Strip: 8
>    Planar Configuration: single image plane
> 
> ... and this to say about the copy...
> 
> # tiffinfo mod09a12003161_ugl_ll_8bit_mild.tif
> mod09a12003161_ugl_ll_8bit_mild.tif: Warning, unknown field with tag 
> 700 (0x2bc) ignored.
> mod09a12003161_ugl_ll_8bit_mild.tif: Warning, unknown field with tag 
> 34665 (0x8769) ignored.
> TIFF Directory at offset 0x8
>    Subfile Type: (0 = 0x0)
>    Image Width: 3480 Image Length: 1740
>    Resolution: 72, 72 pixels/inch
>    Bits/Sample: 8
>    Compression Scheme: None
>    Photometric Interpretation: RGB color
>    Date & Time: "2004:05:18 19:26:44"
>    Software: "Adobe Photoshop 7.0"
>    Samples/Pixel: 3
>    Rows/Strip: 1740
>    Planar Configuration: single image plane
>    Photoshop Data: <present>, 9182 bytes
> 
> What is it about the Photoshop tiff that MapServer or gdal doesn't 
> like?  It is an 8-bit-per-channel image, just like the original.  All 
> image-previews are disabled and ICC profile is not embedded (not that 
> any of that should matter).  Contrary to some reports I have unearthed 
> while googling the mail archives, MapServer does not require an 
> indexed-color 8-bit-per-pixel tiff -- because this original is a 
> straight-up 24-bit RGB (3-channel x 8-bits-per-channel = 24-bits-per 
> pixel) image! (I imagine that MapServer must choke on 
> 16-bit-per-channel images, like the 16-bit greyscale of GLOBE files, or 
> the 48-bit RGB files used in high-end scanning and image-manipulation.)
> 
>   The problem can't possibly be something as straightforward as 
> byte-order, can it?
> 
> -- Marvin Humphrey
> 
> _______________________________________________
> Mapserver-users mailing list
> Mapserver-users at lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-users
-- 
"He's no geek.His tan's too good." -Benjamin Choate




More information about the mapserver-users mailing list