imsave, image size

Hi,

today I bumped into a weird issue when including a PNG generated by
imsave into a LaTeX document via \includegraphics. pdftex's very own
Taco Hoekwater then noticed that the image is actually HUGE in what
the specified dimensions concern
<http://tug.org/pipermail/pdftex/2010-May/thread.html#8398>, and this
is exactly was causes the error too: The PNG declares an absurd
0.9906x0.9906 pixels per *inch*.

The image was produced by the following code:

============== *snip* ==============
import matplotlib.pyplot as plt
import numpy as np

from numpy.random import randn

data = np.clip(randn(250, 250), -1, 1)

plt.imsave( fname = 'test.png', arr=data )
============== *snap* ==============

Cheers,
Nico

It looks like the conversion from dots-per-inch (matplotlib's internal representation) to dots-per-meter (the unit defined in the PNG standard) was bogus. This should be fixed in SVN r8298.

Mike

Nico Schl�mer wrote:

···

Hi,

today I bumped into a weird issue when including a PNG generated by
imsave into a LaTeX document via \includegraphics. pdftex's very own
Taco Hoekwater then noticed that the image is actually HUGE in what
the specified dimensions concern
<http://tug.org/pipermail/pdftex/2010-May/thread.html#8398>, and this
is exactly was causes the error too: The PNG declares an absurd
0.9906x0.9906 pixels per *inch*.

The image was produced by the following code:

============== *snip* ==============
import matplotlib.pyplot as plt
import numpy as np

from numpy.random import randn

data = np.clip(randn(250, 250), -1, 1)

plt.imsave( fname = 'test.png', arr=data )
============== *snap* ==============

Cheers,
Nico

------------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
  
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Are you sure that's right? This doesn't look like a conversion to dots
per meter:

size_t dots_per_meter = dpi * 2.54 * 100.0

To my eyes, unit-wise, that looks like dots/inch * cm/inch * cm/m =
dots * m / inch**2. The original looks correct in regard to units to
me:

size_t dots_per_meter = dpi * 100 * (1 / 2.54) -> dots/inch * cm/m *
inch/cm -> dots/m

Am I missing something?

Ryan

···

On Thu, May 6, 2010 at 1:40 PM, Michael Droettboom <mdroe@...31...> wrote:

It looks like the conversion from dots-per-inch (matplotlib's internal
representation) to dots-per-meter (the unit defined in the PNG standard)
was bogus. This should be fixed in SVN r8298.

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

You're right. Thanks for the sanity check.

What's happening is that when using imsave is used, it generates a figure image with a dpi of 1 (to force 1 output pixel per input pixel), but this is sort of a hack. Let me see if I can find a way around this hack.

Mike

Ryan May wrote:

···

On Thu, May 6, 2010 at 1:40 PM, Michael Droettboom <mdroe@...31...> wrote:
  

It looks like the conversion from dots-per-inch (matplotlib's internal
representation) to dots-per-meter (the unit defined in the PNG standard)
was bogus. This should be fixed in SVN r8298.
    
Are you sure that's right? This doesn't look like a conversion to dots
per meter:

size_t dots_per_meter = dpi * 2.54 * 100.0

To my eyes, unit-wise, that looks like dots/inch * cm/inch * cm/m =
dots * m / inch**2. The original looks correct in regard to units to
me:

size_t dots_per_meter = dpi * 100 * (1 / 2.54) -> dots/inch * cm/m *
inch/cm -> dots/m

Am I missing something?

Ryan

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Ok, I have a better fix in SVN r8300. imsave now accepts a "dpi" kwarg (default of 100) to set the DPI metadata in the file.

Mike

Michael Droettboom wrote:

···

You're right. Thanks for the sanity check.

What's happening is that when using imsave is used, it generates a figure image with a dpi of 1 (to force 1 output pixel per input pixel), but this is sort of a hack. Let me see if I can find a way around this hack.

Mike

Ryan May wrote:
  

On Thu, May 6, 2010 at 1:40 PM, Michael Droettboom <mdroe@...31...> wrote:
  

It looks like the conversion from dots-per-inch (matplotlib's internal
representation) to dots-per-meter (the unit defined in the PNG standard)
was bogus. This should be fixed in SVN r8298.
    

Are you sure that's right? This doesn't look like a conversion to dots
per meter:

size_t dots_per_meter = dpi * 2.54 * 100.0

To my eyes, unit-wise, that looks like dots/inch * cm/inch * cm/m =
dots * m / inch**2. The original looks correct in regard to units to
me:

size_t dots_per_meter = dpi * 100 * (1 / 2.54) -> dots/inch * cm/m *
inch/cm -> dots/m

Am I missing something?

Ryan

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Just saw this thread and thought I should explain that this was indeed a hack by me which was aimed to do exactly what Michael said. I never thought there'd be any side effects from doing this - it's interesting that pdfLaTeX balks because it has never done so for me. Anyway, thanks Michael for addressing this.

Gary R.

Michael Droettboom wrote:

Ok, I have a better fix in SVN r8300. imsave now accepts a "dpi" kwarg (default of 100) to set the DPI metadata in the file.

Mike

Michael Droettboom wrote:

You're right. Thanks for the sanity check.

What's happening is that when using imsave is used, it generates a figure image with a dpi of 1 (to force 1 output pixel per input pixel), but this is sort of a hack. Let me see if I can find a way around this hack.

Mike

<snip>

No worries. I meant no offense by the word "hack": sometimes the simplest approach is the best, and obviously it worked just fine for a long time. It seems newer versions of pdflatex are starting to care about the dpi metadata...

Mike

Gary Ruben wrote:

···

Just saw this thread and thought I should explain that this was indeed a hack by me which was aimed to do exactly what Michael said. I never thought there'd be any side effects from doing this - it's interesting that pdfLaTeX balks because it has never done so for me. Anyway, thanks Michael for addressing this.

Gary R.

Michael Droettboom wrote:
  

Ok, I have a better fix in SVN r8300. imsave now accepts a "dpi" kwarg (default of 100) to set the DPI metadata in the file.

Mike

Michael Droettboom wrote:
    

You're right. Thanks for the sanity check.

What's happening is that when using imsave is used, it generates a figure image with a dpi of 1 (to force 1 output pixel per input pixel), but this is sort of a hack. Let me see if I can find a way around this hack.

Mike
      

<snip>

------------------------------------------------------------------------------

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
  
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA