I have two images which I try to include in tex (greater context: trying to convert ipython notebook to tex which also has output images). I find a weird scaling problem. Both images are comparatively similar, only one is little lower. The lower one is scaled too low, lower than its normal size, while other one is scaled fully.

This is without any size specification. Below is the code. I have also given the separate links to images so one could MWE.




Below is the output (pdf): enter image description here

I initially thought it would be something to do with ipython (in fact it messes up with includegraphics width), so I isolated using above code, and thus individually also, my first shorter image is treated badly. Why is it so? :(

To isolate further, I also tried the same in online IDE but still same output. Please check it here

Here are the 2 images for you also to try:
1. Problematic png image
2. Normal png image

Afaik, image is not a problem as they appear correctly on notebook. Why tex shrinks the former image is the question to be tackled.

Constraint: I could add a custom width to adjust this misbehaving images but I do not want to do that (its normal sized in the notebook) mainly because ipython has redefined includegraphcis and I do not want to mess with that. Probably if max image size restriction if any there for this latex issue needed, I could try to make my script generating the problematic image to keep it of that or within that size.

Update: First doubt: I rechecked document properties again as hinted in comments, and find that the problematic image's size in cm are low compared to other image's size in cm. I have created a ticket for tikzmagic on that as well, here. however, currently tikzmagic does not support altering size in cm afaik, so looking forward if anything could be done from tex side.

  • 2
    This is certainly related to the output size of you png files. If you specify an option, such as [width=5cm] to your includegraphics calls, both pictures should have the same width. To get a more accurate sizing, I guess you should setup things in python matplotlib surely can handle this.
    – BambOo
    Commented Sep 27, 2018 at 9:02
  • The problematic image was generated using tikz. But where is this file size issue documented? 5cm is specific to this issue or do we have any guidance on this? In tikz for now, I have option to give only pixels Commented Sep 27, 2018 at 9:04
  • I have updated here both general and tex from ipython behaviours. Ipython redefines width for images (though I have explicitly used them in example to illustrate the end effect), so even without ipython change, the image is still small, because of its original size somehow? If so, what to do to correct without having to supply any additional options (as that creates error due to conflict with ipython redefinition) Commented Sep 27, 2018 at 9:12
  • How exactly are you generating these PNGs? Tikz does not produce PNG, so where do they come from.
    – daleif
    Commented Sep 27, 2018 at 9:20
  • 1
    the natural size of a bitmap depends on the number of pixels and (preferably) on the bitmap-specified resolution, otherwise a default resolution will be used, You need to check what properties those files have. (Incidentally for including tikz into pdf png is not a great format:-) Commented Sep 27, 2018 at 10:11

1 Answer 1


Interesting formats

The 12kb web version reports as 32bit 14.1 x 5.4 cm; 5.56 x 2.11 inches (suggesting 72dpi) but presents itself correctly by default as 10.58 x 4.02 cm 24bit with only 726 unique colours

The 24kb "problem" file is double the above file size because it uses 64bits per pixel (unusual wasteful in itself & unclear as to why) It also claims to be HR 300dpi x 300 dpi thus presents itself as 3.39 x 1.29 cm 24bit with only 738 unique colours.

1) PNG default should be 96dpi (suitable for screen or web rendering) you only get scalar problems setting different unless its needed for other printers reasons.

2) using 64bits per pixel on graphics that at worst need 24bpp (in this case even 4bpp would be overkill) is nearly tripling storage requirement and likely tripling compilation time and most importantly if published without correction then tripling the decompression time times the number of readers.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .