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

[Marvin Humphrey]

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