Ticket #1039 (closed defect: fixed)

Opened 9 years ago

Last modified 9 years ago

Interlaced png reference maps

Reported by: romoloman@… Owned by: warmerdam
Priority: high Milestone:
Component: MapServer CGI Version: 4.2
Severity: normal Keywords:
Cc:

Description

The reference maps get generated interlaced ignoring any setting for the png 
output type

How to reproduce:
a good example is also the workshop demo sample, by default in my setup
generates interlaced images,
I added this specific outputformat related to PNG in the itasca.map file.

OUTPUTFORMAT
   NAME png
   DRIVER "GD/PNG"
   MIMETYPE "image/png"
   IMAGEMODE RGB
   EXTENSION "png"
   FORMATOPTION "INTERLACE=OFF"
END

The main maps then get generated uninterlaced, the reference still get 
generated interlaced.
The original reference map from itasca is an uninterlaced png.
I get the same problem using the PHP/Mapscript interface.

Installation details:
mapserv -v
MapServer version 4.2.5 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP 
OUTPUT=PDF OUTPUT=SWF SUPPORTS=PROJ SUPPORTS=FREETYPE SUPPORTS=WMS_SERVER 
SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT INPUT=EPPL7 
INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE

ldd mapserv
linux-gate.so.1 =>  (0xffffe000)
libgd.so.2 => /usr/lib/libgd.so.2 (0x4002c000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4007c000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4009b000)
libpng.so.3 => /usr/lib/libpng.so.3 (0x40105000)
libz.so.1 => /lib/libz.so.1 (0x40133000)
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x40144000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40154000)
libpdf.so.5 => /usr/lib/libpdf.so.5 (0x40250000)
libproj.so.0 => /usr/lib/libproj.so.0 (0x4034e000)
libgdal.so.1 => /usr/lib/libgdal.so.1 (0x40382000)
libming.so => /usr/lib/libming.so (0x40695000)
libpq.so.3 => /usr/lib/libpq.so.3 (0x406d2000)
libcurl.so.2 => /usr/lib/libcurl.so.2 (0x406ed000)
libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x40718000)
libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x40748000)
libdl.so.2 => /lib/libdl.so.2 (0x40839000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4083c000)
libm.so.6 => /lib/tls/libm.so.6 (0x4084c000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4086e000)
libc.so.6 => /lib/tls/libc.so.6 (0x4092a000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40a3f000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x40a6a000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40a98000)
libodbc.so.1 => /usr/lib/libodbc.so.1 (0x40aa7000)
libjasper-1.701.so.1 => /usr/lib/libjasper-1.701.so.1 (0x40b07000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40b55000)
libkrb5.so.17 => /usr/lib/libkrb5.so.17 (0x40b5e000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40b99000)
libresolv.so.2 => /lib/libresolv.so.2 (0x40bca000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40bdc000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40bf1000)
libasn1.so.6 => /usr/lib/libasn1.so.6 (0x40c11000)
libroken.so.16 => /usr/lib/libroken.so.16 (0x40c38000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x40c48000)
libdb-4.2.so => /usr/lib/tls/libdb-4.2.so (0x40c4b000)

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 jpeg2000 gif jpeg png

gdlib-config  --all
GD library  2.0.33
includedir: /usr/include
cflags:     -I/usr/include
ldflags:      -L/usr/lib -Wl,-rpath,/usr/lib  -L/usr/X11R6/lib
libs:       -lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm
libdir:     /usr/lib
features:   GD_XPM GD_JPEG GD_FONTCONFIG GD_FREETYPE GD_PNG GD_GIF

Change History

Changed 9 years ago by romoloman@…

  • owner changed from sdlime to fwarmerdam
Assigned to Frank Warmerdam as requested by him

Changed 9 years ago by fwarmerdam

  • status changed from new to assigned

Changed 9 years ago by fwarmerdam

  • cc steve.lime@… added
OK, the basic problem is that images loaded from disk for reference maps
are placed in an imageObj with an outputformat created from scratch using
msCreateDefaultOutputFormat() with a driver of something like "GD/PNG". 

This outputFormatObj remains attached to the reference map image object through
it's life span, and is used when it is saved again. 

Amoung other things the current approach makes it impossible for the application
to control format options.  

The current approach will also likely result in a segfault in some cases,
such as greyscale jpeg files, or 24bit png files where the simplistic logic
gets an output format of the wrong configuration.  

I *think* the following changes should be made:
 o The REFERENCE object should have an optional IMAGETYPE parameter to 
   control the outputFormatObj used for the produced image. 
 o The msImageLoadGD() code should have smarter selection of the
   outputFormatObj, so that we don't end up assigning an outputFormatObj of
   an inappropriate condiguration for the organization of the imageObj data. 

I am adding Steve to see what he thinks of adding an imagetype style parameter
to the referenceObj. 

Changed 9 years ago by fwarmerdam

Dear Frank,
finally I understood what it's going on:

the image get correctly read, stored in memory and processed as uninterlaced
(supposed that the original reference map was uninterlaced), anyway things
are going to change when it's written:

in mapgd.c in the function msSaveImageGD at line 2549 we find

  if( strcasecmp("ON",msGetOutputFormatOption( format, "INTERLACE", "ON" ))
      == 0 )
      gdImageInterlace(img, 1);

but in the case of reference maps the format is set by a call to
msCreateDefaultOutputFormat(NULL, driver) at line 220 in the function
msImageLoadGDStream.
The msCreateDefaultOutputFormat being NULL the name of the map obviously
ignores the setting in the mapfile and does not set NOTHING for the
INTERLACE parameter, so when we arrive at save time
msGetOutputFormatOption( format, "INTERLACE", "ON" ) returns ON, being ON
the default when the format does not contains the "INTERLACE" parameter.
So in the case of reference maps they will be always saved in interlaced
mode at list in the case of png files.
A possible solution to solve (partially) the problem is to set the INTERLACE
parameter as the original image using the gdImageGetInterlaced() function.
the following diff seems to work for me:

--- mapgd.c~    2004-11-08 02:56:48.024356944 +0100
+++ mapgd.c     2004-11-08 02:56:48.025356780 +0100
@@ -225,7 +225,12 @@
     msSetError(MS_GDERR, "Unable to create default OUTPUTFORMAT definition
for driver '%s'.", "msImageLoadGDStream()", driver );
     return(NULL);
   }
-
/* set the interlace format option in accord to the original image format */
+  if (gdImageGetInterlaced(img)) {
+       msSetOutputFormatOption( image->format, "INTERLACE", "ON" );
+  } else {
+       msSetOutputFormatOption( image->format, "INTERLACE", "OFF" );
+  }
   return image;
 }

PLEASE NOTE:
This patch still does not solve the bug of  getting the image to obey the
OUTPUTFORMAT settings of the main map file but at least allows you to
control the format of the saved reference map.

Best regards,
Romolo Manfredini

Changed 9 years ago by fwarmerdam

  • status changed from assigned to closed
  • resolution set to fixed
Romolo, 

While your patch does not completely resolve the underlying issue to my
satisfaction, it does certain improve things a bit and I have applied it. 

...

I have also applied an additional patch to ensure that if you load a 24bit 
PNG file, that the format assigned will have a compatible imagemode.  I 
have briefly tested. 

So currently you can essentially control the format of the reference map that
will be rendered by MapServer by setting up the mode of the input reference
map appropriately.  It might, in theory, be nice to be able to select an
outputFormatObj in the referenceObj, but I don't consider that critical for
resolution of this bug.  So I am now closing the bug. 

Changed 9 years ago by sdlime

Should controlling the output format be "standard" for all ancillary images 
(e.g. scalebar, image legends and reference maps)? Seems like it to me.

Steve

Changed 9 years ago by fwarmerdam

I think that would be desirable, though it is hard for me to judge how
useful that degree of control really is. 


Note: See TracTickets for help on using tickets.