# jpeg gets inserted in different size after saving, fbox still uses old size

I have a jpeg image which was created on OS X by scanning it using my HP Office Jet 8600. The original itself is not very large, and when I insert it using \includegraphics it shows up in a size which looks as the original size to me, everything fine.

Whenever I open the file and save it in OS X Preview, Gimp, Photoshop, .. (even without editing it), it is inserted very large. So I thought some metadata was removed, but I didn't find any related Exif information.

What's really strange is, that if I insert an fbox around the image, the fbox border is still the original (small) image size, while the image remains large.

Do you have any explanation for the strange behavior and any idea how I can get the modified image to be displayed as small as the original one?

Here is my source tex file (I'm using XeTeX 3.14159265-2.6-0.99991 (TeX Live 2014))

\documentclass[12pt,a4paper,DIV=16]{scrartcl}
\usepackage{graphicx}
\begin{document}
% b.jpeg is the original, b2.jpeg the saved one
\includegraphics{b.jpeg} \newpage
\includegraphics{b2.jpeg} \newpage
\fbox{\includegraphics{b2.jpeg}}
\end{document}


and this is how the result looks

As the problem might be a low-level binary problem with my files, I uploaded them externally:

After the comments of Christian Hupfer I upgrades my TeX distribution to MacTeX 2016, and the example works properly, but I still have problems with images:

There is another image, a.jpeg. It was created from the same scanner with the same settings. While it has similar dimensions, it is inserted very huge. So why do the pictures a.jpeg and b.jpeg differ in their display size even though their pixel size is quite similar?

• I can confirm that saving the b.jpeg file with gimp again produces a larger .jpg file but it's not larger in typesetting, however, i.e. the dimensions are the same. (Using TL 2016, with daily updates, on Linux, using xelatex) – user31729 Aug 28 '16 at 10:19
• Here's an image of the output: imgur.com/a/66Aez -- the image on the outmost right is a picture I generated from b.jpeg exported again with gimp. – user31729 Aug 28 '16 at 10:23
• Resaving jpegs is a bad idea even without making changes, asthe file is likely to get recompressed (you can check the filesize, which may even increase). jpegs are often a bad idea in the first place; this is a marginal case as it's close to a photo. All the relevant metadata looks the same, but did you upload the images to and image hosting site or a file hosting site -- I wouldn't trust the former not to "fix" things – Chris H Aug 31 '16 at 7:51
• The file command of my linux says density 600x600 for b.jpg and density 72x72 for a.jpg.... – Paul Gaborit Aug 31 '16 at 12:22
• @muffel I use the file standard command (v5.25). Here, density means resolution. – Paul Gaborit Aug 31 '16 at 16:42