convert c.eps d.jpg unreliable

[gros-jacques]

I have used "convert" in the past on a daily basis to automatically convert a large set of EPSF files to jpg format.
(this is part of the displayed data on a web site describing activity at our computing center).
One conversion command is of the form (UNIX style):

convert -density ${DENSITY} -antialias -colors 128 \
-background white -normalize -units PixelsPerInch \
-quality 100 \
c.eps d.jpg

where ${DENSITY} used to be the number 100
Another set of thumbnail sized pictures is produced from the same original
eps files.

This stopped working when we switched to a more recent version of 'convert'.
We presently have:

Version: ImageMagick 6.2.5 12/18/06 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2005 ImageMagick Studio LLC


The convert program works well with some densities, and not with others.
Some tested values were:

DENSITY = 30, 50, 60, 80, 101, 105, 110 working fine

DENSITY = 20, 72, 90, 99, 100 not working

When convert fails, we get a picture of sparse oblique dotted lines, when
the original pictures are either color pie-charts or bar-charts.

My older version of "convert" still works fine on my SGI O2 machine,
at any density, and on the same files that fail with the newer 'convert'. The old version is
Version: @(#)ImageMagick 5.4.1 12/01/01 Q:16 http://www.imagemagick.org
Copyright: Copyright (C) 2001 ImageMagick Studio

But now I need to do the conversions on a SGI Altix (Itanium2 processors), under
Linux version 2.6.16.27-0.6-default (geeko@buildhost) (gcc version 4.1.0 (SUSE Linux)) #1 SMP Wed Dec 13 09:34:50 UTC 2006

I tried changing the density a little bit, just to get the program to work, but
some values worked with some files and not with others. All the EPSF files (there are two varieties)
are created by the same program (developed locally), and are DSC Conforming.

The conversion can be done successfully with the current version of convert
if I first convert from eps to pdf, then to jpg, but then
I loose the BoundingBox information that is necessary for correct cropping of the final
jpg image (recall: this has to be done automatically). Even if I could make this conversion path work
for this particular application, I would much prefer to continue doing the conversions
directly (eps -> jpg), otherwise a lot of script lines would need to be rewritten and checked.

And it is nicer to have reliability.

May be I am not aware of some recent change that may impose new resctrictions on
the input images; do the image dimensions have to be multiples of 8 pixel units in both directions,
for example, to better suit the output format? If Yes, is there an way to tell convert
to add the missing pixels for us, so that I may always get a viewable picture?


Here are sample outputs from a bad, then a good 'convert' run using the
above command and the same input file:

frontal01 532% conv
density=40
"gs" -q -dBATCH -dSAFER -dMaxBitmap=500000000 -dNOPAUSE -dAlignToPixels=0
"-sDEVICE=bmpsep8" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-g179x143"
"-r40x40" "-sOutputFile=/tmp/magick-XXXWlpv1" "-f/tmp/magick-XXWfkS2B"
"-f/tmp/magic0rMWXq"/tmp/magick-XXXWlpv1 BMP 179x143 179x143+0+0 PseudoClass
256c 1e+02kb
c.eps PS 179x143 179x143+0+0 PseudoClass 256c 1e+02kb
c.eps=>d.jpg PS 179x143 179x143+0+0 PseudoClass 8c 5kb

--> bad, oblique stripes




frontal01 533% conv
density=50
"gs" -q -dBATCH -dSAFER -dMaxBitmap=500000000 -dNOPAUSE -dAlignToPixels=0
"-sDEVICE=bmpsep8" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-g224x179"
"-r50x50" "-sOutputFile=/tmp/magick-XX40e61O" "-f/tmp/magick-XXPSP6Se"
"-f/tmp/magicfv35ap"/tmp/magick-XX40e61O[0] BMP 224x179 224x179+0+0 PseudoClass
256c 2e+02kb
/tmp/magick-XX40e61O[1] BMP 224x179 224x179+0+0 PseudoClass 256c 2e+02kb
/tmp/magick-XX40e61O[2] BMP 224x179 224x179+0+0 PseudoClass 256c 2e+02kb
/tmp/magick-XX40e61O[3] BMP 224x179 224x179+0+0 PseudoClass 256c 2e+02kb
c.eps PS 224x179 224x179+0+0 DirectClass 2e+02kb
c.eps=>d.jpg PS 224x179 224x179+0+0 PseudoClass 100=>98c 3/0.000000/0.016007db
2e+01kb

-->Good

[magick]

Add -colorspace RGB just before your Postscript image name on the command line.

[gros-jacques]

Adding -colorspace RGB makes absolutely no difference in the screwed up output.

I don't know how to interpret this option. Does it refer to the destination file format (jpeg)?
I would have tought that jpeg (.jpg) implied RGB output color space.

[The input EPSF file does some of its work in RGB space, some of in it HSB space.
But I suppose this is irrelevant.]

[anthony]

try looking at the postscript using 'ghostscript' and see if it can handle it. if ghostscript can't handle it, IM certainally can't, as it uses ghostscript to do the dirty work.

[gros-jacques]

frontal01% gs c.eps
ESP Ghostscript 8.15 (2006-04-19)
Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved.
This software comes with NO WARRANTY: see the file COPYING for details.
Loading CenturySchL-Bold font from /usr/share/ghostscript/fonts/c059016l.pfb... 3284680 1954280 2243240 927005 3 done.
Loading NimbusSanL-Bold font from /usr/share/ghostscript/fonts/n019004l.pfb... 3417016 2070488 2243240 932618 3 done.
>>showpage, press <return> to continue<<


Works perfectly to display it.

gs -sDEVICE=bbox c.eps gives

%%BoundingBox: 146 218 465 472
%%HiResBoundingBox: 146.195996 218.195993 464.453986 471.149915

I will experiment more with gs output in jpeg format after I return from vacation, next week. I can't do more for now.

[gros-jacques]

Hello,

Here are the results of my recent experiments on this bug with 'gs', as you suggested:

Recall:

convert -density 71 c.eps d.jpg is OK
convert -density 72 c.eps d.jpg is BAD


I added the -verbose option to see the internal 'gs' options for the bad case:

"gs" -q -dBATCH -dSAFER -dMaxBitmap=500000000 -dNOPAUSE -dAlignToPixels=0 \
"-sDEVICE=bmpsep8" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-g323x258" \
"-r72x72" "-sOutputFile=/tmp/magick-XXEnRYkK" "-f/tmp/magick-XXgEel65" \
"-f/tmp/magicMg4Czo"/tmp/magick-XXEnRYkK BMP 323x258 323x258+0+0 PseudoClass 256c 3e+02kb
c.eps PS 323x258 323x258+0+0 PseudoClass 256c 3e+02kb
c.eps=>d.jpg PS 323x258 323x258+0+0 PseudoClass 256c 1e+01kb

Then I removed those options that prevented the command from displaying on screen,
and used only this subset:

"gs" -dMaxBitmap=500000000 -dAlignToPixels=0 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 \
"-g323x258" "-r72x72" c.eps
ESP Ghostscript 8.15 (2006-04-19)
Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved.
This software comes with NO WARRANTY: see the file COPYING for details.

**** Warning: Some of the BoundingBox for the EPS file will be clipped.
Use -dEPSCrop or -dEPSFitPage to avoid clipping.

Loading CenturySchL-Bold font from /usr/share/ghostscript/fonts/c059016l.pfb... 3309440 1973371 2218480 624091 3 done.
Loading NimbusSanL-Bold font from /usr/share/ghostscript/fonts/n019004l.pfb... 3417016 2085491 2218480 629704 3 done.
>>showpage, press <return> to continue<<

The output was ok except it was not cropped according to the EPS file BoundingBox. Following
the 'gs' suggestion, I added -dEPSCrop :

"gs" -dMaxBitmap=500000000 -dAlignToPixels=0 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 \
"-g323x258" "-r72x72" -dEPSCrop c.eps
ESP Ghostscript 8.15 (2006-04-19)
Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved.
This software comes with NO WARRANTY: see the file COPYING for details.
Loading CenturySchL-Bold font from /usr/share/ghostscript/fonts/c059016l.pfb... 3309440 1962420 2268000 970749 3 done.
Loading NimbusSanL-Bold font from /usr/share/ghostscript/fonts/n019004l.pfb... 3417016 2074476 2292760 566407 3 done.
>>showpage, press <return> to continue<<

With this, the output was perfect on screen.
(What should I add to the 'convert' commands above to get the same output?)
The problem would then be in the subsequent transformation to the intermediate
BMP format, or later.


One more note:

I get the same screwed up output if I ask for GIF output format,
but not if I use a conversion chain like this:
EPS->PDF->JPG
or
EPS->PDF->GIF
Those conversions are ok but do not crop the output to the desired EPS BoundingBox

[gros-jacques]

A sample postscript image c.eps (10KB) and its buggy jpg conversion c.jpg (12KB) are available in the
directory:

http://www.rqchp.qc.ca/.hiddenImageMagick/

The jpg was obtained with

convert -density 72 c.eps c.jpg

Recall that the same command with density 71 works perfectly
on the same eps file. If I download that particular c.eps file to my Mac at home, and open it,
the Mac converts it to pdf format, and displays it correctly.

Sorry about the long delay for my reply. I just had too many more important problems
on my back lately.

Jacques

[magick]

We converted your EPS image file with ImageMagick 6.3.4-6 and Ghostscript 8.15.4 and it worked fine:

• convert -density 72 c.eps c.jpg

[gros-jacques]

Good!

I suppose you do not produce ImageMagick binaries for Itanium2 processors, by any chance?
I asked my sysadmin to takeover from here and do the upgrades.

I am curious to know if you were able to reproduce the problem with older
versions of the codes; we have gs 8.15.3 and ImageMagick 6.2.5 12/18/06 Q16
Was the bug in gs or in convert? Was there a bug?

[undertruck]

gros-jacques, did you find solution to your problem?

I'm getting the exactly same problem. My server version 6.2.8.

All below produced same stripped garbage:

convert -verbose -density 300 test.pdf test.jpg
convert -verbose -density 300x300 test.pdf test.jpg
convert -verbose -density 300 -colorspace RGB test.pdf test.jpg
convert -verbose -density 300 -colorspace Gray test.pdf test.jpg
convert -verbose -density 300x300 -colorspace Gray test.pdf test.jpg


Only 'convert test.pdf test.jpg' worked but I want to use density switch. It works in my local version 6.5.6.

Thanks.