Bug#737003: conversion to pdf silently fails for big paper formats

2014-01-29 Thread chrysn
Package: imagemagick
Version: 8:6.7.7.10-7
Severity: normal
File: /usr/bin/convert

when using `convert` to create a pdf file from a pixel graphic, and the
resulting pdf is physically larger than 90pts, `convert` fails
silently by outputting an empty letter-sized pdf.

admittedly, creating 300m large pdf files is usually not intended, but
can easily happen when taking high-res images (think stitched panoramas,
18000x3000px can be realistic there) and converting them to pdf with the
default resolution (`convert DSC_1234-DSC1249.jpg
DSC_1234-DSC1249.pdf`). for an easier to reproduce setup, try this:

$ convert -size 100x100 xc:white small.png
$ convert small.png -density 0.007 small.pdf
$ pdfinfo small.pdf
[...]
Page size:  612 x 792 pts (letter)
[...]

at resolution 0.008dpi, instead it gives

Page size:  90 x 90 pts

which is expected.

if this is a limitation of the output format, please have convert exit
with an error (and ideally a message that suggests using a higher
`-density`).


as a workaround, mechanisms that deal with converting images
automatically can set high pixel densities (but must not go too hight,
because:

$ convert small.png -density 8000 small.pdf
$ pdfinfo small.pdf
[...]
Page size:  612 x 792 pts (letter)
[...]

)

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages imagemagick depends on:
ii  hicolor-icon-theme  0.13-1
ii  libbz2-1.0  1.0.6-5
ii  libc6   2.17-97
ii  libfontconfig1  2.11.0-2
ii  libfreetype62.5.2-1
ii  libglib2.0-02.38.0-1
ii  libgomp14.8.2-14
ii  libice6 2:1.0.8-2
ii  libjpeg88d-2
ii  liblcms2-2  2.2+git20110628-2.3+b1
ii  liblqr-1-0  0.4.1-2
ii  libltdl72.4.2-1.6
ii  liblzma55.1.1alpha+20120614-2
ii  libmagickcore5  8:6.7.7.10-7
ii  libmagickwand5  8:6.7.7.10-7
ii  libsm6  2:1.2.1-2
ii  libtiff54.0.3-7
ii  libx11-62:1.6.2-1
ii  libxext62:1.3.2-1
ii  libxt6  1:1.1.4-1
ii  zlib1g  1:1.2.8.dfsg-1

Versions of packages imagemagick recommends:
ii  ghostscript   9.05~dfsg-8+b1
ii  libmagickcore5-extra  8:6.7.7.10-7
ii  netpbm2:10.0-15+b2
ii  ufraw-batch   0.19.2-2

Versions of packages imagemagick suggests:
pn  autotracenone
ii  cups-bsd [lpr]   1.7.1-2
ii  curl 7.34.0-1
pn  enscript none
ii  ffmpeg   6:0.8.8-1
ii  gimp 2.8.6-1
ii  gnuplot  4.6.4-1
pn  gradsnone
ii  groff-base   1.22.2-4
pn  hp2xxnone
pn  html2ps  none
pn  imagemagick-doc  none
pn  libwmf-bin   none
ii  mplayer  2:1.0~rc4.dfsg1+svn34540-1+b2
pn  povray   none
pn  radiance none
ii  sane-utils   1.0.24-1.1+b1
ii  texlive-binaries [texlive-base-bin]  2013.20130729.30972-2+b2
ii  transfig 1:3.2.5.e-1
ii  xdg-utils1.1.0~rc1+git20111210-7

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: Digital signature


Bug#737003: conversion to pdf silently fails for big paper formats

2014-01-29 Thread Vincent Fourmond
  Hello,

On Wed, Jan 29, 2014 at 9:54 AM, chrysn chr...@fsfe.org wrote:
 admittedly, creating 300m large pdf files is usually not intended, but
 can easily happen when taking high-res images (think stitched panoramas,
 18000x3000px can be realistic there) and converting them to pdf with the
 default resolution (`convert DSC_1234-DSC1249.jpg
 DSC_1234-DSC1249.pdf`). for an easier to reproduce setup, try this:

  Default resolution is 1 postcript point for 1 pixel. Hence you need
an image of width or height 900 000. Even with a camera taking
pictures of width 10 000 (ie a 80 MPixel camera), you still need 90 of
those stitched horizontally to have problems ! I don't see how this
could arise in real life. Maybe just a warning could do ?

  Cheers,

  Vincent


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#737003: conversion to pdf silently fails for big paper formats

2014-01-29 Thread Christian M . Amsüss
On Wed, Jan 29, 2014 at 01:26:04PM +0100, Vincent Fourmond wrote:
   Default resolution is 1 postcript point for 1 pixel. Hence you need
 an image of width or height 900 000. Even with a camera taking
 pictures of width 10 000 (ie a 80 MPixel camera), you still need 90 of
 those stitched horizontally to have problems ! I don't see how this
 could arise in real life.

the images i have at hand don't have resolutions set in the image
explicitly (would they be evaluated at all?), but give these results:

$ exiftool infile.jpg
[...]
X Resolution: 1
Y Resolution: 1
Resolution Unit : None
Software: Hugin 2013.0.0.4692917e7a55
[...]
Image Size  : 12032x3013
$ convert infile.jpg outfile.pdf
$ pdfinfo outfile.pdf
[...]
Producer:   ImageMagick 6.7.7-10 2013-12-22 Q16 http://www.imagemagick.org
[...]
Page size:  866304 x 216936 pts

i don't know if a jpg's resolution can be any more unspecified than by
unsetting the unit. ([1] suggests there isn't; if there is, let me know
and i'll try to get hugin to export a properly undefined resolution).

the math of this implies 72pts per pixel (1 pixel per inch if i'm not
mistaken), which makes the critical size achievable with common cameras
and 360° panoramas.

[1] http://www.fileformat.info/format/jpeg/egff.htm

 Maybe just a warning could do ?

i don't know in which situation such a warning could be more useful than
an error (for these purposes, i'd call everythin an error that makes the
program return nonzero), but even a warning would be an enhancement.

thanks for considering the issue
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: Digital signature