JPEG not rendering larger than 608x512

[jmalczyk@…]

GD/Jpeg output fails at sizes larger than 608x512. GDAL/Jpeg output fails 
entirely (outputs scrambled images).

[sdlime]

Do you have a demo site or demo output?

Steve

[jmalczyk@…]

Sure. Here's a functional 8 bit PNG.

http://216.162.212.88/cgi-bin/mapserv.exe?
Request=GetMap&Version=1.1.1&map=mapfiles/trails-png-
12.map&SRS=EPSG:32612&BBox=501122.1944390828,4102022.063868984,505187.8905993499
,4105070.063868984&width=800&height=600&layers=DRG

....and a non-functional Jpeg using the GD driver.

http://216.162.212.88/cgi-bin/mapserv.exe?
Request=GetMap&Version=1.1.1&map=mapfiles/trails-jpeg-
12.map&SRS=EPSG:32612&BBox=501122.1944390828,4102022.063868984,505187.8905993499
,4105070.063868984&width=800&height=600&layers=DRG

....and a REALLY non-functional Jpeg using the GDAL driver.

http://216.162.212.88/cgi-bin/mapserv.exe?
Request=GetMap&Version=1.1.1&map=mapfiles/trails-GDALjpeg-
12.map&SRS=EPSG:32612&BBox=501122.1944390828,4102022.063868984,505187.8905993499
,4105070.063868984&width=800&height=600&layers=DRG

My mapserv -v output is...
MapServer version 4.2.0 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=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE

The binaries came from....
http://dl2.maptools.org/mapserver-4.2.0-win32-php4.3.4.zip

Thanks!
Jeremy

[sgillies@…]

As a check, I just drew a 1000 x 800 JPEG using mapscript 4.2.
No problem at all.

Trouble may be in maptool's libjpeg.

In fact, at the user's meeting during my workshop we experienced some problems
with bad JPEGs that were traced to another JPEG library which had been 
promoted ahead of mine on the system path :(

[jmalczyk@…]

This does seem to be a maptools libjpeg issue. The current 4.2 Win32 binary on 
the MapServer site is making functional jpegs for me too. Unfortunately it also 
has bug 729 in it, which affects me and is fixed in the 4.3 binary from 
maptools. 

[sgillies@…]

OK, let's close this one up since it's not a mapserver bug.
If the maptools site has a tracker, you may want to report
the issue there.

[dmorissette]

Maptools has a bugzilla, but MapServer binaries issue are better tracked here...
since it's MapServer.

I'll reopen and reassign to Assefa.

[sgillies@…]

OK, maybe I am being a bit picky :)

But I think it is good to distinguish between MapServer bugs that are a problem
with the code and binary distribution bugs that are not directly related to
the code.

The increasing number of different MapServer binaries (ms4w, OpenEV, hobu's 
python mapscript) are important ways of getting users to try the newest revisions
and find bugs.  If we agree that we will track binary issues as well as code
issues, should we create new components in Bugzilla?  

[dmorissette]

How do you know that this is not a problem/conflict with a specific option or
version of libjpeg that needs to be addressed in the code, in the makefiles, or
in the docs? My point is that it is possible somehow to produce a MapServer
binary on Windows that won't produce large JPEGS and we need to find out why to
avoid the problem in the future.

I have reclassed the bug as "build problem"

[dmorissette]

BTW, back to the intial problem report:

> GD/Jpeg output fails at sizes larger than 608x512. GDAL/Jpeg output fails 
> entirely (outputs scrambled images).

I suspect different versions of libjpeg are used in GDAL and in GD. Only one
instance of any library should be used in building MapServer, or any other
software for that matter.  

<rant>
Packages such as GDAL and PHP that come bundled with a bunch of libraries to
make it easier to build the package just make it too easy to fall into that trap
when we try to integrate them in a larger package such as MapServer.
</rant>

[assefa]

Just a note on the windows build on maptools : the GD library is build using the
GDAL libjpeg library. So GDAL, GD (and Mapserver) uses the same libjpeg from GDAL.

  

[fwarmerdam]

Assefa,

Does that mean I should be looking into this problem then?

[sgillies@…]

FWIW, I'm using boutell.com's bgd.dll 2.0.27.  Have linked mapserver against
it and can't reproduce the problem.

The distributors are not clear about which libjpeg version they are using, but
it's gotta be jpeg-6b.

[assefa]

Frank,

 I will try to do a couple of tests to see if using the jpeg library (jpeg-6b)
that I have to see if there are any diffrences. I will let you know of the results. 

[assefa]

Jeremy,

 Is it possible for you to send me your map file and the layer that is used in
the request. I could not reprduce the problem with my local test data.  

[jmalczyk@…]

mapfile for bug 746

[assefa]

Jeremey,

 I have tried your map file with the extents you provided and could produce a
valid jpeg file using mapserver 4.2.1 as weel as 4.3 binaries from maptool. (I
have tried sizes 600/600 and 800/800)
 Not really sure why you are having this problem if the binaries are comimg from
maptools.

 
I also had a  discussion on this with Perry from UMN who is building the windows
binaries over there. He seems to think that there might be some problems with
his recent builds. I am waiting on his tests.

 

[nacional@…]

Sorry I haven't worked on this in quite a while...  I haven't been able to
duplicate this problem since I recompiled MapServer 4.2.0--both with Assefa's GD
and with my own.

Jeremy, 
if you're still having this problem, have you replaced all your DLL's with the
most recent DLL's from MapTools.org?  Could there be older/duplicate DLL's
elsewhere in your system?

If you don't have this problem anymore, then this bug should probably be closed.

[fwarmerdam]

This has been inactive for quite a while, and I really can't see how this could
be a limitation in MapServer.  Closing.  Please re-open if it can be reproduced.