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.
Preparation
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:
\documentclass[]{article}
\usepackage{graphicx}
\begin{document}
\begin{figure}[htbp]
\centering
\includegraphics{./wiz-standard.jpg}
\end{figure}
\end{document}
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
(./mini.tex
LaTeX2e <2014/05/01>
Babel <3.9k> and hyphenation patterns for 50 languages loaded.
(/opt/local/share/texmf-texlive/tex/latex/base/article.cls
Document Class: article 2007/10/19 v1.4h Standard LaTeX document class
(/opt/local/share/texmf-texlive/tex/latex/base/size10.clo))
(/opt/local/share/texmf-texlive/tex/latex/graphics/graphicx.sty
(/opt/local/share/texmf-texlive/tex/latex/graphics/keyval.sty)
(/opt/local/share/texmf-texlive/tex/latex/graphics/graphics.sty
(/opt/local/share/texmf-texlive/tex/latex/graphics/trig.sty)
(/opt/local/share/texmf-texlive/tex/latex/latexconfig/graphics.cfg)
(/opt/local/share/texmf-texlive/tex/latex/pdftex-def/pdftex.def
(/opt/local/share/texmf-texlive/tex/generic/oberdiek/infwarerr.sty)
(/opt/local/share/texmf-texlive/tex/generic/oberdiek/ltxcmds.sty))))
(./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
(/opt/local/share/texmf-texlive/tex/generic/oberdiek/ifluatex.sty)
(/opt/local/share/texmf-texlive/tex/generic/oberdiek/ifpdf.sty))
(/opt/local/share/texmf-texlive/tex/latex/oberdiek/epstopdf-base.sty
(/opt/local/share/texmf-texlive/tex/latex/oberdiek/grfext.sty
(/opt/local/share/texmf-texlive/tex/generic/oberdiek/kvdefinekeys.sty))
(/opt/local/share/texmf-texlive/tex/latex/oberdiek/kvoptions.sty
(/opt/local/share/texmf-texlive/tex/generic/oberdiek/kvsetkeys.sty
(/opt/local/share/texmf-texlive/tex/generic/oberdiek/etexcmds.sty)))
(/opt/local/share/texmf-texlive/tex/latex/latexconfig/epstopdf-sys.cfg))
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
/cm/cmr10.pfb>
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>
b
l.8 \includegraphics{./wiz-standard.jpg}
?
No PDF is created by xelatex, not even an empty page.
Questions
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:
- Can you reproduce this problem with your versions of LaTeX and of ImageMagick?
- Why are
{pdf,lua,xe}latexrelying 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? - 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:
\usepackage{graphicx}
% 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.
\makeatletter
\def\ScaleIfNeeded{%
\ifdim\Gin@nat@width>\linewidth
\linewidth
\else
\Gin@nat@width
\fi
}
\makeatother
\let\Oldincludegraphics\includegraphics
{%
\catcode`\@=11\relax%
\gdef\includegraphics{\@ifnextchar[{\Oldincludegraphics}{\Oldincludegraphics[width=\ScaleIfNeeded]}}%
}%
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
exiftoolreports{X,Y} Resolution : 1, andidentify -verbosereportsResolution: 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:
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.