Menu
▾
▴
matplotlib-users
|
From: Bill D. <wjd...@at...> - 2007-10-07 14:43:37
|
There appears to be a problem with .png files that matplotlib creates. Some programs (like GIMP <http://www.gimp.org/> and xv) <http://www.trilon.com/xv/> do not identify them as png files and cannot display them. -- Bill wjd...@at... Gentoo Linux X86_64 2.6.20-gentoo-r8 Reclaim Your Inbox with http://www.mozilla.org/products/thunderbird/ All things cometh to he who waiteth as long as he who waiteth worketh like hell while he waiteth. |
|
From: Wayne E. H. <wh...@pa...> - 2007-10-07 15:34:17
|
Bill: I do not have that problem using mpl-0.90.1 or svn which I checked out and installed yesterday. I have gimp-2.2.17 and have no problems opening them on my linux system or my two XP systems at work. The issue I do find is that when I specify the DPI in the savefig command, it does not properly get encoded into the png, although the size of the graphic is set accordingly. So maybe that is a clue to what's happening to you. You are saving them as "something.png", right ? Wayne Bill Dandreta wrote: > There appears to be a problem with .png files that matplotlib creates. > Some programs (like GIMP <http://www.gimp.org/> and xv) > <http://www.trilon.com/xv/> do not identify them as png files and > cannot display them. > |
|
From: Bill D. <wjd...@at...> - 2007-10-07 17:49:41
|
Wayne E. Harlan wrote: > Bill: > > I do not have that problem using mpl-0.90.1 or svn which I checked out > and installed yesterday. I have gimp-2.2.17 and have no problems > opening them on my linux system or my two XP systems at work. The > issue I do find is that when I specify the DPI in the savefig command, > it does not properly get encoded into the png, although the size of > the graphic is set accordingly. So maybe that is a clue to what's > happening to you. You are saving them as "something.png", right ? > I discovered the problem, xv and gimp were compiled without png support. Thanks for your input. -- Bill wjd...@at... Gentoo Linux X86_64 2.6.20-gentoo-r8 Reclaim Your Inbox with http://www.mozilla.org/products/thunderbird/ All things cometh to he who waiteth as long as he who waiteth worketh like hell while he waiteth. |
|
From: Eric F. <ef...@ha...> - 2007-10-07 21:16:14
|
Bill Dandreta wrote: > There appears to be a problem with .png files that matplotlib creates. > Some programs (like GIMP <http://www.gimp.org/> and xv) > <http://www.trilon.com/xv/> do not identify them as png files and cannot > display them. Would you be more specific, please? I can't reproduce the problem. I don't have xv, but on my ubuntu feisty machine the "file" command and gimp both recognize mpl-generated png files (using Agg backend). Do you have mpl-generated png files that are recognized by some display programs but not by gimp and xv? If so, what are the programs that recognize them? What version of mpl was used, and what backend? Please provide an example. Eric |
|
From: Bill D. <wjd...@at...> - 2007-10-07 21:22:52
|
Eric Firing wrote: > Bill Dandreta wrote: >> There appears to be a problem with .png files that matplotlib >> creates. Some programs (like GIMP <http://www.gimp.org/> and xv) >> <http://www.trilon.com/xv/> do not identify them as png files and >> cannot display them. > > Would you be more specific, please? I can't reproduce the problem. I > don't have xv, but on my ubuntu feisty machine the "file" command and > gimp both recognize mpl-generated png files (using Agg backend). > > Do you have mpl-generated png files that are recognized by some > display programs but not by gimp and xv? If so, what are the programs > that recognize them? What version of mpl was used, and what backend? > Please provide an example. I resolved the problem. It was unrelated to mpl. xv and gimp were complied w/o png support. Recompiling with png support resolved the problem. -- Bill wjd...@at... Gentoo Linux X86_64 2.6.20-gentoo-r8 Reclaim Your Inbox with http://www.mozilla.org/products/thunderbird/ All things cometh to he who waiteth as long as he who waiteth worketh like hell while he waiteth. |
|
From: Wayne E. H. <wh...@pa...> - 2007-10-08 00:06:28
|
I would like to follow up on my first response to Bill. It probably should be a new thread, but I'll start here. When png files are saved with a DPI=300 argument, and I open them in the Gimp, the dpi is only 72 (default ?). As I understand it, the dpi setting in the graphics file tells the application opening it how big to display it. When I use savefig with a DPI=300 and the plot figure I am saving was created with figsize=(6,4.5) I expect the figure to open in word or swriter at the size I specified (6" by 4.5") with the appropriate number of pixels. However, at present, that does not happen. The number of pixels in the figure is correct but I have to resize it manually to get the right size. Can this be fixed ? Thanks, Wayne Bill Dandreta wrote: > I resolved the problem. It was unrelated to mpl. xv and gimp were > complied w/o png support. Recompiling with png support resolved the problem. > > |
|
From: Michael D. <md...@st...> - 2007-10-08 12:17:57
|
I'll look into this. I actually made a similar fix on another project I used to work on... It should be theoretically possible, barring any roadblocks from how matplotlib is doing things. Cheers, Mike Wayne E. Harlan wrote: > I would like to follow up on my first response to Bill. It probably > should be a new thread, but I'll start here. When png files are saved > with a DPI=300 argument, and I open them in the Gimp, the dpi is only 72 > (default ?). As I understand it, the dpi setting in the graphics file > tells the application opening it how big to display it. When I use > savefig with a DPI=300 and the plot figure I am saving was created with > figsize=(6,4.5) I expect the figure to open in word or swriter at the > size I specified (6" by 4.5") with the appropriate number of pixels. > However, at present, that does not happen. The number of pixels in the > figure is correct but I have to resize it manually to get the right > size. Can this be fixed ? > > Thanks, > > Wayne > > Bill Dandreta wrote: >> I resolved the problem. It was unrelated to mpl. xv and gimp were >> complied w/o png support. Recompiling with png support resolved the problem. >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
|
From: Michael D. <md...@st...> - 2007-10-08 14:16:12
|
Hmmm. I'm very surprised that this change could cause that. All it does is add an additional metadata chunk to the PNG file, which shouldn't have any affect on the image data itself. simple_plot.py works fine for me in GIMP 2.0.5 both before and after this change. Can you verify that this plot was working before the change to save the resolution in the PNG file? If so, can you send me the source for your plot and the PNG file? Also, what version of libpng are you using? (pkg-config --version libpng should display this on most recent Linux distros). Cheers, Mike Wayne E. Harlan wrote: > Not quite. The figure opens at the correct size in the gimp but all I > see is background - no plot stuff. > > Wayne > > Michael Droettboom wrote: >> This is now added in SVN, and only for the Agg backend(s). It won't >> work with some of the other ways to save PNG files, such as Gdk, Wx >> (non-Agg) and Cairo. If anyone was any thoughts about how to support >> saving the resolution in those backends, please share. >> >> Also note that resolution is saved in "dots per meter" in PNG files, >> so rounding error makes things slightly off -- for instance, 100 dpi >> is shows up as 99.999998 dpi in the GIMP. >> >> Cheers, >> Mike >> >> Michael Droettboom wrote: >>> I'll look into this. I actually made a similar fix on another >>> project I used to work on... It should be theoretically possible, >>> barring any roadblocks from how matplotlib is doing things. >>> >>> Cheers, >>> Mike >>> >>> Wayne E. Harlan wrote: >>>> I would like to follow up on my first response to Bill. It probably >>>> should be a new thread, but I'll start here. When png files are >>>> saved with a DPI=300 argument, and I open them in the Gimp, the dpi >>>> is only 72 (default ?). As I understand it, the dpi setting in the >>>> graphics file tells the application opening it how big to display >>>> it. When I use savefig with a DPI=300 and the plot figure I am >>>> saving was created with figsize=(6,4.5) I expect the figure to open >>>> in word or swriter at the size I specified (6" by 4.5") with the >>>> appropriate number of pixels. However, at present, that does not >>>> happen. The number of pixels in the figure is correct but I have to >>>> resize it manually to get the right size. Can this be fixed ? >>>> >>>> Thanks, >>>> >>>> Wayne >>>> >>>> Bill Dandreta wrote: >>>>> I resolved the problem. It was unrelated to mpl. xv and gimp were >>>>> complied w/o png support. Recompiling with png support resolved the >>>>> problem. >>>>> >>>>> >>>> ------------------------------------------------------------------------- >>>> >>>> This SF.net email is sponsored by: Splunk Inc. >>>> Still grepping through log files to find problems? Stop. >>>> Now Search log events and configuration files using AJAX and a browser. >>>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>>> _______________________________________________ >>>> Matplotlib-users mailing list >>>> Mat...@li... >>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >>> >> -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
|
From: Wayne E. H. <wh...@pa...> - 2007-10-09 02:02:53
|
Michael: I tried a complete checkout for comparison (3929). In the meantime, my libpng is 1.2.18 (installed from source as is everything - this is an LFS/BLFS system.) Yes, the plot was working before the change and I can send you some png's from that if you need to see them, or I can backtrack to 0.90.1 and repeat this. Please bear in mind that the plot displays (and always has) quite correctly on screen - it's just the saved file that consists of just background. I have attached the script, the resulting png and a saved screenshot from the Gimp. Attachments are gzipped. Wayne Michael Droettboom wrote: > Hmmm. I'm very surprised that this change could cause that. All it > does is add an additional metadata chunk to the PNG file, which > shouldn't have any affect on the image data itself. simple_plot.py > works fine for me in GIMP 2.0.5 both before and after this change. Can > you verify that this plot was working before the change to save the > resolution in the PNG file? If so, can you send me the source for your > plot and the PNG file? Also, what version of libpng are you using? > (pkg-config --version libpng should display this on most recent Linux > distros). > |
|
From: Michael D. <md...@st...> - 2007-10-09 12:47:36
|
Unfortunately, I'm not able to reproduce this here with the .py you attached. Both SVN r3926 (before the PNG resolution change) and SVN r3927 (after the PNG resolution change) work for me. Are you comparing those two SVN revisions, or SVN vs. 0.90.1? I can confirm that the PNG you attached is all white and fully transparent. Just for information, my machine (RHEL4) has libpng 1.2.7. Can you send a copy of your matplotlibrc? Also, can you save out a .raw image? (If you rename it to foo.rgba, you can display these images with the ImageMagick command "display -size 1800x1200 -depth 8 foo.rgba") That would help determine whether the problem is in the PNG-writing code or something higher up. Cheers, Mike Wayne E. Harlan wrote: > Michael: > > I tried a complete checkout for comparison (3929). In the meantime, my > libpng is 1.2.18 (installed from source as is everything - this is an > LFS/BLFS system.) Yes, the plot was working before the change and I can > send you some png's from that if you need to see them, or I can > backtrack to 0.90.1 and repeat this. Please bear in mind that the plot > displays (and always has) quite correctly on screen - it's just the > saved file that consists of just background. I have attached the > script, the resulting png and a saved screenshot from the Gimp. > Attachments are gzipped. > > Wayne > > Michael Droettboom wrote: >> Hmmm. I'm very surprised that this change could cause that. All it >> does is add an additional metadata chunk to the PNG file, which >> shouldn't have any affect on the image data itself. simple_plot.py >> works fine for me in GIMP 2.0.5 both before and after this change. >> Can you verify that this plot was working before the change to save >> the resolution in the PNG file? If so, can you send me the source for >> your plot and the PNG file? Also, what version of libpng are you >> using? (pkg-config --version libpng should display this on most recent >> Linux distros). >> -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
|
From: Michael D. <md...@st...> - 2007-10-10 12:17:58
|
Great! Glad to know I wasn't going crazy ;) Cheers, Mike Wayne E. Harlan wrote: > By the time I did the update it was at 3931 but it works just fine. I > inserted the 6"x8" picture into swriter and it shows up at 6"x8". > Thank you very much ! > > Wayne > > Michael Droettboom wrote: >> Wayne E. Harlan wrote: >>> Michael: >>> >>> Both r3927 and r3929 resulted in the smaller png file that's just >>> transparent background. >> >> The point of interest is r3926, before this change. r3927 and r3929 >> are identical on the trunk. >> >> It turns out there was a peculiarity with how image files are saved in >> the GtkAgg backend that was triggering this bug. That should now be >> fixed in r3930. Please try that and let me know how that works for you. >> >>> It's roughly 20% of the size of the file I get with the latest >>> release, 0.90.1, which opens fine (but has the wrong dpi). That >>> tells me that on my system, some stuff just isn't getting written to >>> the file. I have attached my matplotlibrc and will read the docs to >>> see how to save a raw image and attach that, too. I don't have >>> ImageMagick, but can download and compile it later today. I tried a >>> 300 dpi jpg with r3929 and the image saves OK but has the wrong dpi >>> (72). The .raw image is also attached. It was over 17 MB so I >>> bzipped it. I'm surprised it ended up at 700 bytes ! >> >> That raw file is fully white and transparent also. >> >> Hope that helps, >> Mike >> >>> Wayne >>> >>> Michael Droettboom wrote: >>>> Unfortunately, I'm not able to reproduce this here with the .py you >>>> attached. Both SVN r3926 (before the PNG resolution change) and SVN >>>> r3927 (after the PNG resolution change) work for me. Are you >>>> comparing those two SVN revisions, or SVN vs. 0.90.1? >>>> >>>> I can confirm that the PNG you attached is all white and fully >>>> transparent. >>>> >>>> Just for information, my machine (RHEL4) has libpng 1.2.7. >>>> >>>> Can you send a copy of your matplotlibrc? Also, can you save out a >>>> .raw image? (If you rename it to foo.rgba, you can display these >>>> images with the ImageMagick command "display -size 1800x1200 -depth >>>> 8 foo.rgba") That would help determine whether the problem is in the >>>> PNG-writing code or something higher up. >>>> >>>> Cheers, >>>> Mike >>>> >>>> Wayne E. Harlan wrote: >>>>> Michael: >>>>> >>>>> I tried a complete checkout for comparison (3929). In the >>>>> meantime, my libpng is 1.2.18 (installed from source as is >>>>> everything - this is an LFS/BLFS system.) Yes, the plot was >>>>> working before the change and I can send you some png's from that >>>>> if you need to see them, or I can backtrack to 0.90.1 and repeat >>>>> this. Please bear in mind that the plot displays (and always has) >>>>> quite correctly on screen - it's just the saved file that consists >>>>> of just background. I have attached the script, the resulting png >>>>> and a saved screenshot from the Gimp. Attachments are gzipped. >>>>> >>>>> Wayne >>>>> >>>>> Michael Droettboom wrote: >>>>>> Hmmm. I'm very surprised that this change could cause that. All >>>>>> it does is add an additional metadata chunk to the PNG file, which >>>>>> shouldn't have any affect on the image data itself. >>>>>> simple_plot.py works fine for me in GIMP 2.0.5 both before and >>>>>> after this change. Can you verify that this plot was working >>>>>> before the change to save the resolution in the PNG file? If so, >>>>>> can you send me the source for your plot and the PNG file? Also, >>>>>> what version of libpng are you using? (pkg-config --version libpng >>>>>> should display this on most recent Linux distros). >>>>>> >>>> >> -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
|
From: Michael D. <md...@st...> - 2007-10-08 12:51:19
|
This is now added in SVN, and only for the Agg backend(s). It won't work with some of the other ways to save PNG files, such as Gdk, Wx (non-Agg) and Cairo. If anyone was any thoughts about how to support saving the resolution in those backends, please share. Also note that resolution is saved in "dots per meter" in PNG files, so rounding error makes things slightly off -- for instance, 100 dpi is shows up as 99.999998 dpi in the GIMP. Cheers, Mike Michael Droettboom wrote: > I'll look into this. I actually made a similar fix on another project I > used to work on... It should be theoretically possible, barring any > roadblocks from how matplotlib is doing things. > > Cheers, > Mike > > Wayne E. Harlan wrote: >> I would like to follow up on my first response to Bill. It probably >> should be a new thread, but I'll start here. When png files are saved >> with a DPI=300 argument, and I open them in the Gimp, the dpi is only 72 >> (default ?). As I understand it, the dpi setting in the graphics file >> tells the application opening it how big to display it. When I use >> savefig with a DPI=300 and the plot figure I am saving was created with >> figsize=(6,4.5) I expect the figure to open in word or swriter at the >> size I specified (6" by 4.5") with the appropriate number of pixels. >> However, at present, that does not happen. The number of pixels in the >> figure is correct but I have to resize it manually to get the right >> size. Can this be fixed ? >> >> Thanks, >> >> Wayne >> >> Bill Dandreta wrote: >>> I resolved the problem. It was unrelated to mpl. xv and gimp were >>> complied w/o png support. Recompiling with png support resolved the problem. >>> >>> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> Matplotlib-users mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
|
From: Bill D. <wjd...@at...> - 2007-10-08 13:44:03
|
Wayne E. Harlan wrote: > I would like to follow up on my first response to Bill. It probably > should be a new thread, but I'll start here. When png files are saved > with a DPI=300 argument, and I open them in the Gimp, the dpi is only 72 > (default ?). As I understand it, the dpi setting in the graphics file > tells the application opening it how big to display it. When I use > savefig with a DPI=300 and the plot figure I am saving was created with > figsize=(6,4.5) I expect the figure to open in word or swriter at the > size I specified (6" by 4.5") with the appropriate number of pixels. > However, at present, that does not happen. The number of pixels in the > figure is correct but I have to resize it manually to get the right > size. Can this be fixed ? This info may or may not be useful. If I save a plot with savefig() without specifying a figsize, sometimes the figure gets clipped. What gets saved is the portion of the image that show() displays. I determined experimentally that figsize=(13,10) causes show() to open the image at full screen size and so far using that size saves an unclipped image. -- Bill wjd...@at... Gentoo Linux X86_64 2.6.20-gentoo-r8 Reclaim Your Inbox with http://www.mozilla.org/products/thunderbird/ All things cometh to he who waiteth as long as he who waiteth worketh like hell while he waiteth. |
|
From: Michael D. <md...@st...> - 2007-10-08 14:09:39
|
Bill Dandreta wrote: > Wayne E. Harlan wrote: >> I would like to follow up on my first response to Bill. It probably >> should be a new thread, but I'll start here. When png files are saved >> with a DPI=300 argument, and I open them in the Gimp, the dpi is only 72 >> (default ?). As I understand it, the dpi setting in the graphics file >> tells the application opening it how big to display it. When I use >> savefig with a DPI=300 and the plot figure I am saving was created with >> figsize=(6,4.5) I expect the figure to open in word or swriter at the >> size I specified (6" by 4.5") with the appropriate number of pixels. >> However, at present, that does not happen. The number of pixels in the >> figure is correct but I have to resize it manually to get the right >> size. Can this be fixed ? > This info may or may not be useful. If I save a plot with savefig() > without specifying a figsize, sometimes the figure gets clipped. What > gets saved is the portion of the image that show() displays. I > determined experimentally that figsize=(13,10) causes show() to open the > image at full screen size and so far using that size saves an unclipped > image. Is this with 0.90.1 or a SVN version? What backend are you using? Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
|
From: Bill D. <wjd...@at...> - 2007-10-08 14:27:42
|
Michael Droettboom wrote:
> Bill Dandreta wrote:
>> This info may or may not be useful. If I save a plot with savefig()
>> without specifying a figsize, sometimes the figure gets clipped. What
>> gets saved is the portion of the image that show() displays. I
>> determined experimentally that figsize=(13,10) causes show() to open the
>> image at full screen size and so far using that size saves an unclipped
>> image.
>
> Is this with 0.90.1 or a SVN version? What backend are you using?
dev-python/matplotlib
Installed versions: 0.90.1 (01:40:48 06/08/07) (doc examples gtk tk)
dev-lang/python
Installed versions: 2.4.4-r5 (2.4) (19:12:16 09/23/07) (berkdb
-bootstrap -build doc examples gdbm ipv6 ncurses -nocxx -nothreads
readline ssl tk -ucs2)
$ pkg-config --version libpng
0.21
~/.matplotlib/matplotlibrc:
backend : GTKAgg
numerix : numpy
units : True
--
Bill
wjd...@at...
Gentoo Linux X86_64 2.6.20-gentoo-r8
Reclaim Your Inbox with http://www.mozilla.org/products/thunderbird/
All things cometh to he who waiteth as long as he who waiteth worketh like hell while he waiteth.
|
|
From: Wayne E. H. <wh...@pa...> - 2007-10-08 14:10:15
|
Not quite. The figure opens at the correct size in the gimp but all I see is background - no plot stuff. Wayne Michael Droettboom wrote: > This is now added in SVN, and only for the Agg backend(s). It won't > work with some of the other ways to save PNG files, such as Gdk, Wx > (non-Agg) and Cairo. If anyone was any thoughts about how to support > saving the resolution in those backends, please share. > > Also note that resolution is saved in "dots per meter" in PNG files, > so rounding error makes things slightly off -- for instance, 100 dpi > is shows up as 99.999998 dpi in the GIMP. > > Cheers, > Mike > > Michael Droettboom wrote: >> I'll look into this. I actually made a similar fix on another >> project I used to work on... It should be theoretically possible, >> barring any roadblocks from how matplotlib is doing things. >> >> Cheers, >> Mike >> >> Wayne E. Harlan wrote: >>> I would like to follow up on my first response to Bill. It probably >>> should be a new thread, but I'll start here. When png files are >>> saved with a DPI=300 argument, and I open them in the Gimp, the dpi >>> is only 72 (default ?). As I understand it, the dpi setting in the >>> graphics file tells the application opening it how big to display >>> it. When I use savefig with a DPI=300 and the plot figure I am >>> saving was created with figsize=(6,4.5) I expect the figure to open >>> in word or swriter at the size I specified (6" by 4.5") with the >>> appropriate number of pixels. However, at present, that does not >>> happen. The number of pixels in the figure is correct but I have to >>> resize it manually to get the right size. Can this be fixed ? >>> >>> Thanks, >>> >>> Wayne >>> >>> Bill Dandreta wrote: >>>> I resolved the problem. It was unrelated to mpl. xv and gimp were >>>> complied w/o png support. Recompiling with png support resolved the >>>> problem. >>>> >>>> >>> ------------------------------------------------------------------------- >>> >>> This SF.net email is sponsored by: Splunk Inc. >>> Still grepping through log files to find problems? Stop. >>> Now Search log events and configuration files using AJAX and a browser. >>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>> _______________________________________________ >>> Matplotlib-users mailing list >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> > |
Thanks for helping keep SourceForge clean.
X