[Tex/LaTex] Is it ImageMagick’s fault or pdflatex’s that some JPEGs aren’t working


pdflatex (as well as lualatex and xelatex) cannot process (some) JPEG images which were created by my ImageMagick.

I'm on OSX Mavericks, using ImageMagick v6.9.0-0 Q16 x86_64 provided via MacPorts.

My LaTeX version installed is this:

$ latex --version
 pdfTeX 3.14159265-2.6-1.40.15 (TeX Live 2014/MacPorts 2014_8)
 kpathsea version 6.2.0
 Compiled with libpng 1.6.17; using libpng 1.6.17
 Compiled with zlib 1.2.8; using zlib 1.2.8
 Compiled with poppler version 0.32.0

I've tried to construct a minimal working example so everybody can reproduce the problem. If you can't, please tell which exact version of IM and LaTeX you run.


Here are two JPEGs, both created by ImageMagick.

The left one isn't working, the right one is: (see update below the images!)


Update: Imgur hosting seems to strip some metadata, so the files aren't any longer in their original state. Please use this link on GoogleDrive to a mini-tarball. It contains the original JPEGs.

I used these commands to create them:

$ convert wizard:              wiz-standard.jpg   # (left image) 
$ convert wizard: -density 300 wiz-300densi.jpg   # (right image)

Data points about the two JPEGs

Here are a few data points about their differences.

File sizes

$ ls -l wiz-300densi.jpg wiz-standard.jpg 
 -rw-r--r--  1 kp  staff  62177  7 Mai 12:09 wiz-300densi.jpg
 -rw-r--r--  1 kp  staff  62177  7 Mai 12:09 wiz-standard.jpg

As you can see, exactly same file sizes.

Pixel dimensions

$ identify wiz-300densi.jpg wiz-standard.jpg
  wiz-300densi.jpg    JPEG 480x640 480x640+0+0 8-bit sRGB 62.2KB 0.000u 0:00.000
  wiz-standard.jpg[1] JPEG 480x640 480x640+0+0 8-bit sRGB 62.2KB 0.000u 0:00.000

As you can see, exactly identical image dimensions.

Pixel/Color differences

$ for i in $(compare -list metric); do 
>     echo -n " Metric  $i :  "; 
>     compare -metric $i wiz-300densi.jpg wiz-standard.jpg null: ; 
>     echo; 
>  done

 Metric  AE    :  0
 Metric  Fuzz  :  0 (0)
 Metric  MAE   :  0 (0)
 Metric  MEPP  :  0 (0, 0)
 Metric  MSE   :  0 (0)
 Metric  NCC   :  1
 Metric  PAE   :  0 (0)
 Metric  PHASH :  0
 Metric  PSNR  :  inf
 Metric  RMSE  :  0 (0)

As you can see, comparing the color values of every single pixel does not yield any differences according to every single available metric.

Image metadata

$ identify -verbose wiz-300densi.jpg > wiz-300densi.log
$ identify -verbose wiz-standard.jpg > wiz-standard.log

$ sdiff -sbB wiz-densi300.log wiz-standard.log
  Image: wiz-300densi.jpg                    | Image: wiz-standard.jpg
    Resolution: 300x300                      <
    Print size: 1.6x2.13333                  <
      date:create: 2015-05-07T12:09:45+02:00 |     date:create: 2015-05-07T12:09:20+02:00
      date:modify: 2015-05-07T12:09:45+02:00 |     date:modify: 2015-05-07T12:09:20+02:00
      filename: wiz-300densi.jpg             |     filename: wiz-standard.jpg

Here is the first difference: the "not-working" JPEG does no contain any hint in its metadata about the prefered resolution it wants to be be rendered on an output device.

$ exiftool wiz-standard.jpg | grep Resolution
    Resolution Unit                 : inches
    X Resolution                    : 1
    Y Resolution                    : 1

$ exiftool wiz-300densi.jpg | grep Resolution
    Resolution Unit                 : inches
    X Resolution                    : 300
    Y Resolution                    : 300

Exiftool also reports a difference: However, it reports not an empty value (like identify -verbose did for the "not-working" JPEG), but a value of 1. I don't know if this is really in the file's data, or if exiftool just assumes and reports this value in leu of a missing metadata entry.

LaTeX code (MWE)

Here is my LaTeX code:





pdflatex run + output

Running pdflatex on it yields these messages:

This is pdfTeX, Version 3.14159265-2.6-1.40.15 (TeX Live 2014/MacPorts 2014_8) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
LaTeX2e <2014/05/01>
Babel <3.9k> and hyphenation patterns for 50 languages loaded.
Document Class: article 2007/10/19 v1.4h Standard LaTeX document class
(./mini.aux) (/opt/local/share/texmf-texlive/tex/context/base/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
) (/opt/local/share/texmf-texlive/tex/generic/oberdiek/pdftexcmds.sty

pdfTeX warning: pdflatex: arithmetic: number too big

pdfTeX warning: pdflatex: arithmetic: number too big
<./wiz-standard.jpg, id=1, --32768.0pt x 0.0pt> <use ./wiz-standard.jpg>
[1{/opt/local/var/db/texmf/fonts/map/pdftex/updmap/pdftex.map} <./wiz-standard.
jpg>] (./mini.aux) )</opt/local/share/texmf-texlive/fonts/type1/public/amsfonts
Output written on mini.pdf (1 page, 70603 bytes).
Transcript written on mini.log.

So from the MWE-LaTeX above, pdflatex at least did generate an output PDF of 70 KiBytes, while giving some warnings, but…

Empty (white) page

…but the PDF only shows an "empty", white page. (I'll not show a screenshot of it, though 🙂

pdfimages reports an embedded image in this PDF:

$ pdfimages -list mini.pdf
 page   num  type   width height color comp bpc  enc interp  object ID x-ppi y-ppi size ratio
    1     0 image     480   640  rgb     3   8  jpeg   no         1  0     2     2 60.7K 6.7%

It can even extract the JPEG again from the PDF, and it is in its original shape:

$  pdfimages -j  mini.pdf mini---

$ ls -ltar mini----000.jpg wiz-standard.jpg 
 -rw-r--r--  1 kp  staff  62177  7 Mai 12:09 wiz-standard.jpg
 -rw-r--r--  1 kp  staff  62177  8 Mai 02:09 mini----000.jpg

Note, that in other cases, with a non-minimal TeX file I also experience a different pdflatex message, and the run doesn't complete and no PDF is created at all (not even an empty page):

pdflatex with errors (not just warnings) on non-MWE LaTeX

pdfTeX warning: pdflatex: arithmetic: number too big

pdfTeX warning: pdflatex: arithmetic: number too big
<./wiz-standard.jpg, id=4, --32768.0pt x 0.0pt>

! Package graphics Error: Division by 0.
See the graphics package documentation for explanation.

Type  H <return>  for immediate help.
l.63 \includegraphics{./wiz-standard.jpg}

Note the Division by 0.-message…

lualatex not completing run with the MWE from above

I also tried lualatex. This reports a slightly different message:

LuaTeX warning: arithmetic: number too big

LuaTeX warning: arithmetic: number too big
! Dimension too large.
<recently read> \dimen@ 

l.8 \includegraphics{./wiz-standard.jpg}


No PDF is created by lualatex, not even an empty page.

xelatex not completing run with the MWE from above

These are xelatex's messages on the MWE:

! Dimension too large.
<to be read again> 
l.8 \includegraphics{./wiz-standard.jpg}


No PDF is created by xelatex, not even an empty page.


Be aware, that the alternative JPEG, which contains the resolution hints, is successfully embedded and a PDF is created by either of the {pdf,lua,xe}latex commands.

My questions are:

  1. Can you reproduce this problem with your versions of LaTeX and of ImageMagick?
  2. Why are {pdf,lua,xe}latex relying on some metadata inside a JPEG so much, that it even kills itself when this metadata is wrong (or missing) instead of simply just using the real raster pixel data which is there?
  3. Isn't that a bug in the respective components (even if we accept that the JPEG itself may be "buggy") ?!?

Update 1:

(In response to comment by Mike Renfro…)

My non-MWE LaTeX code contains this snippet:

% Redefine \includegraphics so that, unless explicit options are
% given, the image width will not exceed the width of the page.
% Images get their normal width if they fit onto the page, but
% are scaled down if they would overflow the margins.

So this should take care of the scaling, no?

Update 2:

The images I linked to originally have been stripped of metadata and are no longer in their original shape.

Here is a link on GoogleDrive to a mini-tarball containing the original JPEGs.

Update 3

I forgot to mention: I had also tested with

$ convert wizard: -density 1 wiz-001densi.jpg

So the resulting file does include the respective metadata, and

  • exiftool reports {X,Y} Resolution : 1, and
  • identify -verbose reports Resolution: 1x1.

(This is already mentioned in my previous postings to the ImageMagick forums as well as to the Pandoc forum.)

So this fact somehow contradicts the some speculations given in some of the answers below…

(In order to resolve the question wether the JPEG itself is buggy, I also reported this issue in the appropriate ImageMagick forum).

(Update: Just saw a new message on the ImageMagick "Bugs" forum by Dirk Lemstra saying: "I just committed a patch to our SVN repository to make sure that the default density units is set to 0 (unknown) instead of 1 (pixels per inch).")

Best Answer

As it happens I stumbled upon the same problem last week and the next version of LuaTeX will detect these images and issue a warning:

LuaTeX warning (file wiz-standard.jpg): The image specifies an unusual resolution of 1dpi by 1dpi. 

pdfTeX/luaTeX read jpegs bytewise (no exif involved) and images of these kind really specify a resolution of 1dpi by 1dpi (see the JFIF spec, page 5). This typically gives images that are too large for TeX to handle (see \maxdimen; the limit would be around 200 x 200 pixels). wiz-standard.jpg has 480x640 pixels, so TeX thinks you want to include an image that's 480inx640in - that's way too large.