matplotlib-users Mailing List for matplotlib (Page 3)

On 2011年10月24日, Paul Ivanov wrote:
>>  Would you like a copy of kidsn.afm?
> sure. let's take a look.
StartFontMetrics 2.0
Comment Kids-Normal
Comment Copyright (c) 1992 Corel Corporation. All Rights Reserved.
Comment Creation Date: Mon Jun 15 12:00:00 1992
Comment UniqueID 5029202
Comment VMUsage 20000 20000
FontName Kids-Normal
FullName Kids Normal
FamilyName Kids
Weight Normal
ItalicAngle 0
IsFixedPitch false
FontBBox -188 -268 1227 980
Underline Position -100
Underline Thickness 50
Version 001.00
Notice Copyright (c) 1992 Corel Corporation. All Rights Reserved.
EncodingScheme StandardEncoding
CapHeight 811
XHeight 590
Ascender 742
Descender -193
StartCharMetrics 210
C 32 ; WX 225 ; N space ; B 0 0 0 0 ;
C 33 ; WX 225 ; N exclam ; B 53 0 207 752 ;
C 34 ; WX 262 ; N quotedbl ; B 64 506 246 730 ;
C 35 ; WX 773 ; N numbersign ; B 6 14 715 752 ;
C 36 ; WX 631 ; N dollar ; B -21 -94 537 824 ;
C 37 ; WX 807 ; N percent ; B 31 -27 746 756 ;
C 38 ; WX 770 ; N ampersand ; B 10 -68 709 777 ;
C 39 ; WX 270 ; N quoteright ; B 57 436 240 760 ;
C 40 ; WX 383 ; N parenleft ; B 55 -123 328 746 ;
C 41 ; WX 391 ; N parenright ; B 0 -145 287 725 ;
C 42 ; WX 348 ; N asterisk ; B 68 469 326 740 ;
C 43 ; WX 615 ; N plus ; B 41 43 559 547 ;
C 44 ; WX 270 ; N comma ; B 72 -166 225 111 ;
C 45 ; WX 305 ; N hyphen ; B 25 264 277 344 ;
C 46 ; WX 199 ; N period ; B 88 -47 213 107 ;
C 47 ; WX 363 ; N slash ; B 47 -115 324 727 ;
C 48 ; WX 588 ; N zero ; B -8 8 535 721 ;
C 49 ; WX 297 ; N one ; B 137 16 270 764 ;
C 50 ; WX 633 ; N two ; B 18 -20 561 742 ;
C 51 ; WX 492 ; N three ; B 43 -21 439 695 ;
C 52 ; WX 537 ; N four ; B 6 10 496 721 ;
C 53 ; WX 625 ; N five ; B 0 8 557 814 ;
C 54 ; WX 604 ; N six ; B 16 -6 529 742 ;
C 55 ; WX 494 ; N seven ; B 64 -8 459 746 ;
C 56 ; WX 605 ; N eight ; B 61 -14 533 758 ;
C 57 ; WX 549 ; N nine ; B 29 -90 508 760 ;
C 58 ; WX 186 ; N colon ; B 88 -47 232 525 ;
C 59 ; WX 229 ; N semicolon ; B 72 -166 232 525 ;
C 60 ; WX 605 ; N less ; B 37 6 551 555 ;
C 61 ; WX 574 ; N equal ; B 59 164 533 441 ;
C 62 ; WX 582 ; N greater ; B 33 23 547 568 ;
C 63 ; WX 582 ; N question ; B 66 -47 555 744 ;
C 64 ; WX 1033 ; N at ; B 20 -6 887 787 ;
C 65 ; WX 799 ; N A ; B 27 10 730 742 ;
C 66 ; WX 664 ; N B ; B 27 -47 551 744 ;
C 67 ; WX 795 ; N C ; B 27 -25 717 773 ;
C 68 ; WX 816 ; N D ; B -2 -49 703 764 ;
C 69 ; WX 549 ; N E ; B 45 -86 508 715 ;
C 70 ; WX 563 ; N F ; B 51 -21 516 773 ;
C 71 ; WX 916 ; N G ; B 20 0 807 795 ;
C 72 ; WX 768 ; N H ; B -16 -33 672 811 ;
C 73 ; WX 496 ; N I ; B -88 -6 342 738 ;
C 74 ; WX 453 ; N J ; B -4 4 408 766 ;
C 75 ; WX 607 ; N K ; B 51 -84 541 717 ;
C 76 ; WX 535 ; N L ; B 25 -8 494 717 ;
C 77 ; WX 869 ; N M ; B 66 -105 813 787 ;
C 78 ; WX 766 ; N N ; B 59 8 729 799 ;
C 79 ; WX 844 ; N O ; B 33 23 783 830 ;
C 80 ; WX 580 ; N P ; B -21 -12 504 777 ;
C 81 ; WX 895 ; N Q ; B 20 -68 803 740 ;
C 82 ; WX 586 ; N R ; B 35 -37 549 764 ;
C 83 ; WX 635 ; N S ; B -41 -12 533 770 ;
C 84 ; WX 605 ; N T ; B -45 27 482 836 ;
C 85 ; WX 631 ; N U ; B 23 -20 596 797 ;
C 86 ; WX 732 ; N V ; B 25 -18 678 734 ;
C 87 ; WX 947 ; N W ; B 12 -37 877 725 ;
C 88 ; WX 656 ; N X ; B 0 -72 588 740 ;
C 89 ; WX 596 ; N Y ; B 43 0 545 762 ;
C 90 ; WX 713 ; N Z ; B -49 6 594 750 ;
C 91 ; WX 430 ; N bracketleft ; B 47 -107 395 760 ;
C 92 ; WX 527 ; N backslash ; B 98 -18 484 768 ;
C 93 ; WX 342 ; N bracketright ; B -23 -123 271 756 ;
C 94 ; WX 574 ; N asciicircum ; B 16 293 535 775 ;
C 95 ; WX 590 ; N underscore ; B -27 -127 514 -25 ;
C 96 ; WX 262 ; N quoteleft ; B 45 434 229 760 ;
C 97 ; WX 684 ; N a ; B 31 -43 633 539 ;
C 98 ; WX 711 ; N b ; B 0 0 629 879 ;
C 99 ; WX 771 ; N c ; B 21 -23 676 576 ;
C 100 ; WX 672 ; N d ; B 59 29 631 826 ;
C 101 ; WX 688 ; N e ; B 25 -63 629 559 ;
C 102 ; WX 416 ; N f ; B 6 -35 363 779 ;
C 103 ; WX 658 ; N g ; B 25 -213 607 650 ;
C 104 ; WX 604 ; N h ; B 23 6 549 799 ;
C 105 ; WX 193 ; N i ; B 10 43 174 773 ;
C 106 ; WX 424 ; N j ; B -104 -201 238 758 ;
C 107 ; WX 521 ; N k ; B 47 -4 473 775 ;
C 108 ; WX 230 ; N l ; B 49 4 211 764 ;
C 109 ; WX 949 ; N m ; B 10 23 875 600 ;
C 110 ; WX 627 ; N n ; B 10 0 553 557 ;
C 111 ; WX 688 ; N o ; B 39 -4 615 555 ;
C 112 ; WX 660 ; N p ; B 27 -203 617 561 ;
C 113 ; WX 742 ; N q ; B 92 -229 693 549 ;
C 114 ; WX 400 ; N r ; B 33 2 367 586 ;
C 115 ; WX 500 ; N s ; B -47 -14 406 580 ;
C 116 ; WX 406 ; N t ; B -14 37 352 809 ;
C 117 ; WX 570 ; N u ; B 72 -51 541 566 ;
C 118 ; WX 605 ; N v ; B -4 -14 543 574 ;
C 119 ; WX 896 ; N w ; B 16 -18 832 582 ;
C 120 ; WX 525 ; N x ; B 27 49 480 590 ;
C 121 ; WX 578 ; N y ; B 12 -193 520 547 ;
C 122 ; WX 561 ; N z ; B -63 -47 443 553 ;
C 123 ; WX 303 ; N braceleft ; B 20 -63 264 760 ;
C 124 ; WX 393 ; N bar ; B 277 -45 375 693 ;
C 125 ; WX 273 ; N braceright ; B 55 -68 244 707 ;
C 126 ; WX 586 ; N asciitilde ; B 39 219 531 408 ;
C 127 ; WX 262 ; N ; B 64 506 246 730 ;
C 128 ; WX 324 ; N grave ; B 63 615 301 785 ;
C 129 ; WX 475 ; N circumflex ; B 92 607 438 750 ;
C 130 ; WX 393 ; N tilde ; B 68 617 361 723 ;
C 131 ; WX 193 ; N dotlessi ; B 10 43 172 572 ;
C 132 ; WX 592 ; N florin ; B 111 -186 547 779 ;
C 133 ; WX 418 ; N quotedblleft ; B -14 463 326 773 ;
C 134 ; WX 424 ; N quotedblright ; B 63 479 404 789 ;
C 135 ; WX 223 ; N guilsinglleft ; B 8 129 195 480 ;
C 136 ; WX 238 ; N guilsinglright ; B 29 137 221 490 ;
C 137 ; WX 518 ; N fi ; B 4 10 467 758 ;
C 138 ; WX 541 ; N fl ; B 4 4 490 764 ;
C 139 ; WX 518 ; N dagger ; B 29 -121 477 748 ;
C 140 ; WX 518 ; N daggerdbl ; B 29 -121 477 748 ;
C 141 ; WX 594 ; N endash ; B -12 227 516 361 ;
C 142 ; WX 232 ; N bullet ; B 111 145 457 498 ;
C 143 ; WX 455 ; N breve ; B 66 637 408 801 ;
C 144 ; WX 441 ; N quotedblbase ; B 72 -168 418 143 ;
C 145 ; WX 914 ; N ellipsis ; B 94 -2 857 143 ;
C 146 ; WX 1326 ; N perthousand ; B 45 -14 1227 768 ;
C 147 ; WX 953 ; N trademark ; B 84 305 900 791 ;
C 161 ; WX 240 ; N exclamdown ; B 59 -150 221 625 ;
C 162 ; WX 535 ; N cent ; B 25 18 488 693 ;
C 163 ; WX 656 ; N sterling ; B -16 8 557 750 ;
C 164 ; WX 650 ; N currency ; B 18 78 586 688 ;
C 165 ; WX 580 ; N yen ; B 39 0 545 773 ;
C 166 ; WX 406 ; N brokenbar ; B 275 -8 389 736 ;
C 167 ; WX 635 ; N section ; B 12 -137 576 801 ;
C 168 ; WX 457 ; N dieresis ; B 68 600 422 760 ;
C 169 ; WX 949 ; N copyright ; B 0 41 766 822 ;
C 170 ; WX 365 ; N ordfeminine ; B 14 311 338 771 ;
C 171 ; WX 445 ; N guillemotleft ; B 4 137 406 488 ;
C 172 ; WX 666 ; N logicalnot ; B 23 152 625 475 ;
C 173 ; WX 1010 ; N emdash ; B 47 232 943 402 ;
C 174 ; WX 949 ; N registered ; B 0 -20 766 762 ;
C 176 ; WX 311 ; N ring ; B 68 615 275 832 ;
C 177 ; WX 586 ; N plusminus ; B 12 -21 539 646 ;
C 178 ; WX 342 ; N twosuperior ; B 8 420 309 813 ;
C 179 ; WX 316 ; N threesuperior ; B 21 477 281 875 ;
C 180 ; WX 330 ; N acute ; B 78 619 297 775 ;
C 181 ; WX 568 ; N mu ; B 47 -225 537 535 ;
C 182 ; WX 662 ; N paragraph ; B 20 -117 621 781 ;
C 183 ; WX 523 ; N periodcentered ; B 64 234 207 389 ;
C 184 ; WX 266 ; N cedilla ; B 55 -268 252 6 ;
C 185 ; WX 223 ; N onesuperior ; B 109 498 201 875 ;
C 186 ; WX 396 ; N ordmasculine ; B 25 318 346 770 ;
C 187 ; WX 484 ; N guillemotright ; B 21 164 449 500 ;
C 188 ; WX 822 ; N onequarter ; B 105 -43 771 730 ;
C 189 ; WX 836 ; N onehalf ; B 117 -12 783 760 ;
C 190 ; WX 799 ; N threequarters ; B 21 -25 752 754 ;
C 191 ; WX 568 ; N questiondown ; B 45 -227 533 564 ;
C 192 ; WX 799 ; N Agrave ; B -156 5 374 380 ;
C 193 ; WX 799 ; N Aacute ; B -151 5 374 380 ;
C 194 ; WX 799 ; N Acircumflex ; B -101 5 374 380 ;
C 195 ; WX 799 ; N Atilde ; B -111 5 374 380 ;
C 196 ; WX 799 ; N Adieresis ; B -82 5 374 380 ;
C 197 ; WX 799 ; N Aring ; B -153 5 374 380 ;
C 198 ; WX 967 ; N AE ; B 90 -29 902 777 ;
C 199 ; WX 824 ; N Ccedilla ; B 27 -219 742 773 ;
C 200 ; WX 549 ; N Egrave ; B -101 -44 260 366 ;
C 201 ; WX 549 ; N Eacute ; B -52 -44 260 366 ;
C 202 ; WX 549 ; N Ecircumflex ; B 2 -44 260 366 ;
C 203 ; WX 549 ; N Edieresis ; B -10 -44 260 366 ;
C 204 ; WX 496 ; N Igrave ; B -45 -3 218 378 ;
C 205 ; WX 496 ; N Iacute ; B -45 -3 216 378 ;
C 206 ; WX 496 ; N Icircumflex ; B -45 -3 351 378 ;
C 207 ; WX 496 ; N Idieresis ; B -45 -3 329 378 ;
C 208 ; WX 816 ; N Eth ; B -2 -49 703 764 ;
C 209 ; WX 766 ; N Ntilde ; B -35 -21 693 914 ;
C 210 ; WX 844 ; N Ograve ; B 16 -53 799 977 ;
C 211 ; WX 844 ; N Oacute ; B 16 -53 799 967 ;
C 212 ; WX 844 ; N Ocircumflex ; B 16 -53 799 951 ;
C 213 ; WX 844 ; N Otilde ; B 16 -53 799 924 ;
C 214 ; WX 844 ; N Odieresis ; B 16 -53 799 941 ;
C 215 ; WX 1178 ; N OE ; B 6 -14 1100 807 ;
C 216 ; WX 826 ; N Oslash ; B 47 -33 783 848 ;
C 217 ; WX 631 ; N Ugrave ; B 16 -72 611 969 ;
C 218 ; WX 631 ; N Uacute ; B 16 -72 611 957 ;
C 219 ; WX 660 ; N Ucircumflex ; B 16 -72 611 932 ;
C 220 ; WX 631 ; N Udieresis ; B 12 -10 305 408 ;
C 221 ; WX 596 ; N Yacute ; B -181 0 279 390 ;
C 222 ; WX 584 ; N Thorn ; B -33 4 504 941 ;
C 223 ; WX 678 ; N germandbls ; B 70 -68 615 775 ;
C 224 ; WX 684 ; N agrave ; B 0 -10 633 775 ;
C 225 ; WX 699 ; N aacute ; B 0 -4 633 771 ;
C 226 ; WX 682 ; N acircumflex ; B 10 -27 643 748 ;
C 227 ; WX 682 ; N atilde ; B 10 -27 643 721 ;
C 228 ; WX 682 ; N adieresis ; B 10 -27 643 758 ;
C 229 ; WX 682 ; N aring ; B 10 -33 643 799 ;
C 230 ; WX 1121 ; N ae ; B 33 -25 1055 574 ;
C 231 ; WX 754 ; N ccedilla ; B 25 -223 658 582 ;
C 232 ; WX 684 ; N egrave ; B 10 -47 639 775 ;
C 233 ; WX 684 ; N eacute ; B 10 -47 639 766 ;
C 234 ; WX 684 ; N ecircumflex ; B 10 -47 639 730 ;
C 235 ; WX 684 ; N edieresis ; B 10 -47 639 740 ;
C 236 ; WX 412 ; N igrave ; B -86 -25 215 760 ;
C 237 ; WX 395 ; N iacute ; B -104 -21 193 785 ;
C 238 ; WX 557 ; N icircumflex ; B -188 -21 250 744 ;
C 239 ; WX 551 ; N idieresis ; B -156 -21 266 766 ;
C 240 ; WX 824 ; N eth ; B 39 12 768 826 ;
C 241 ; WX 619 ; N ntilde ; B 16 -21 568 709 ;
C 242 ; WX 703 ; N ograve ; B 16 -35 631 750 ;
C 243 ; WX 703 ; N oacute ; B 16 -25 631 766 ;
C 244 ; WX 725 ; N ocircumflex ; B 16 -25 631 734 ;
C 245 ; WX 703 ; N otilde ; B 16 -39 631 684 ;
C 246 ; WX 703 ; N odieresis ; B 16 -39 631 721 ;
C 247 ; WX 1119 ; N oe ; B 43 -29 1047 549 ;
C 248 ; WX 639 ; N oslash ; B 33 -21 605 615 ;
C 249 ; WX 600 ; N ugrave ; B 16 -72 557 771 ;
C 250 ; WX 600 ; N uacute ; B 16 -72 557 770 ;
C 251 ; WX 600 ; N ucircumflex ; B 16 -72 557 744 ;
C 252 ; WX 600 ; N udieresis ; B 16 -72 557 729 ;
C 253 ; WX 602 ; N yacute ; B 16 -215 535 641 ;
C 254 ; WX 691 ; N thorn ; B 49 -205 648 703 ;
C 255 ; WX 578 ; N ydieresis ; B 6 -99 266 416 ;
EndCharMetrics
StartKernData
StartKernPairs 0
EndKernPairs
EndKernData
StartComposites 0
EndComposites
EndFontMetrics
> What about the .afm that ships with matplotlib which also caused problems
> - did you verify that the one you have is the same as the one under
> version control in matplotlib?
 Well, the source file came from the matplotlib Web site, so I assume that
it/they are OK. The SlackBuild script essentially re-packages the download
as a Slackware package so it can be managed more easily and consistently
with other packages.
Rich

On Mon, Oct 24, 2011 at 6:35 AM, Rich Shepard <rsh...@ap...> wrote:
>  Would you like a copy of kidsn.afm?
sure. let's take a look.
What about the .afm that ships with matplotlib which also caused
problems - did you verify that the one you have is the same as the one
under version control in matplotlib?
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

On 2011年10月23日, Paul Ivanov wrote:
> Change my request to add 'sys.stderr.write(fh.name)' before the 'while 1:'
> in _parse_char_metrics - just so we don't have any buffering issues. The
> last file you see printed there will be the one that's causing the issue.
> You can then try removing it, or sending it back to the list (or both) so
> we can see what happened.
Paul,
 The last file printed before the traceback is
/usr/share/fonts/atmfonts/kidsm.afm. When I mv that to Xkidsn.afm it still
shows up. I'm also seeing the same error in a number of other atmfonts. Some
in /usr/X11/lib/X11/fonts/atmfonts, which is a soft link to
/usr/share/fonts/atmfonts, and other errors in the soft links in
~/.fonts/atmfonts.
 Would you like a copy of kidsn.afm?
Thanks,
Rich

Thanks Jeff!
On Thu, Oct 20, 2011 at 1:16 PM, Jeff Whitaker <js...@fa...> wrote:
> On 10/19/11 4:37 PM, questions anon wrote:
>
> thank you, I am not quite sure how to 'draw' the shapefile
>
> from matplotlib.collections import LineCollection
> ax = plt.gca() # get current axes instance
> # 'DSE_REGIONS' instance variable created by readshapefile method call.
> lines = LineCollection(map.DSE_REGIONS)
> ax.add_collection(lines)
>
> -Jeff
>
>
> but making those changes and removing the shapefile has sped the
> processing up considerably!
> Thank you for your help
>
> On Wed, Oct 19, 2011 at 11:42 PM, Jeff Whitaker <js...@fa...>wrote:
>
>> On 10/18/11 8:55 PM, questions anon wrote:
>>
>> Thanks Jeff, that certainly speeds it up! But when I take them out of the
>> loop and place them elsewhere they are no longer added to the map.
>> Is there someway I can call them in the loop but still get it to run
>> quickly?
>> Thanks
>>
>>
>> Just the Basemap instance creation and the transformation of coordinates
>> to projection space should be hoisted out of the loop
>>
>>
>> map =
>> Basemap(projection='merc',llcrnrlat=-40,urcrnrlat=-33,
>>
>> llcrnrlon=139.0,urcrnrlon=151.0,lat_ts=0,resolution='i')
>> x,y=map(*N.meshgrid(LON,LAT))
>>
>> you can leave the other statements in.
>>
>> If you still have memory issues, bring the readshapefile call out, and
>> draw the shapes whose coordinates are stored in the instance variable
>> map.DSE_REGIONS manually in the loop.
>>
>> -Jeff
>>
>>
>> On Fri, Oct 14, 2011 at 10:54 PM, Jeff Whitaker <js...@fa...>wrote:
>>
>> On 10/12/11 8:20 PM, questions anon wrote:
>>
>> Hi All,
>> I keep receiving a memory error when processing many netcdf files. I
>> assumed it had something to do with how I loop things and maybe needed to
>> close things off properly but I recently received an error that made me
>> think it might be because of matplotlib.
>>
>> In the code below I am looping through a bunch of netcdf files (each file
>> is hourly data for one month) and within each netcdf file I am outputting a
>> *png file every three hours. This works for one netcdf file (therefore one
>> month) but when it begins to process the next netcdf file I receive a memory
>> error (see below). Since I have tidied some of my code up it seems to
>> process partly into the second file but then I still receive the memory
>> error.
>> I have tried a few suggestions such as:
>> -Combining the dataset using MFDataset (using NETCDF4) is not an option
>> because the files do not have unlimited dimension.
>> - gc.collect() but that just results in a *GEOS_ERROR: bad allocation
>> error*.
>> -only open LAT and LON once (which worked)
>>
>> System Details:
>> Python 2.7.2 |EPD 7.1-2 (32-bit)| (default, Jul 3 2011, 15:13:59) [MSC
>> v.1500 32 bit (Intel)] on win32
>>
>> Any feedback will be greatly appreciated as I seem to keep ending up with
>> memory errors when working with netcdf files this even happens if I am using
>> a much better computer.
>>
>> *Most recent error: *
>> Traceback (most recent call last):
>> File "C:\plot_netcdf_merc_multiplot_across_multifolders_TSFC.py", line
>> 78, in <module>
>> plt.savefig((os.path.join(outputfolder,
>> 'TSFC'+date_string+'UTC.png')))
>> File "C:\Python27\lib\site-packages\matplotlib\pyplot.py", line 363, in
>> savefig
>> return fig.savefig(*args, **kwargs)
>> File "C:\Python27\lib\site-packages\matplotlib\figure.py", line 1084, in
>> savefig
>> self.canvas.print_figure(*args, **kwargs)
>> File
>> "C:\Python27\lib\site-packages\matplotlib\backends\backend_wxagg.py", line
>> 100, in print_figure
>> FigureCanvasAgg.print_figure(self, filename, *args, **kwargs)
>> File "C:\Python27\lib\site-packages\matplotlib\backend_bases.py", line
>> 1923, in print_figure
>> **kwargs)
>> File "C:\Python27\lib\site-packages\matplotlib\backends\backend_agg.py",
>> line 438, in print_png
>> FigureCanvasAgg.draw(self)
>> File "C:\Python27\lib\site-packages\matplotlib\backends\backend_agg.py",
>> line 393, in draw
>> self.renderer = self.get_renderer()
>> File "C:\Python27\lib\site-packages\matplotlib\backends\backend_agg.py",
>> line 404, in get_renderer
>> self.renderer = RendererAgg(w, h, self.figure.dpi)
>> File "C:\Python27\lib\site-packages\matplotlib\backends\backend_agg.py",
>> line 59, in __init__
>> self._renderer = _RendererAgg(int(width), int(height), dpi,
>> debug=False)
>> RuntimeError: Could not allocate memory for image
>>
>> *Error when I added gc.collect()*
>> GEOS_ERROR: bad allocation
>>
>> *Old error (before adding gc.collect() )*
>> *Traceback (most recent call last):
>> File
>> "d:/plot_netcdf_merc_multiplot_across_multifolders__memoryerror.py", line
>> 44, in <module>
>> TSFC=ncfile.variables['T_SFC'][1::3]
>> File "netCDF4.pyx", line 2473, in netCDF4.Variable.__getitem__
>> (netCDF4.c:23094)
>> MemoryError*
>>
>>
>>
>> from netCDF4 import Dataset
>> import numpy as N
>> import matplotlib.pyplot as plt
>> from mpl_toolkits.basemap import Basemap
>> from netcdftime import utime
>> from datetime import datetime
>> import os
>> import gc
>>
>>
>> shapefile1="E:/
>>
>> griddeddatasamples/GIS/DSE_REGIONS"
>> MainFolder=r"E:/griddeddatasamples/GriddedData/InputsforValidation/T_SFC/"
>> OutputFolder=r"E:/griddeddatasamples/GriddedData/OutputsforValidation"
>> fileforlatlon=Dataset("E:/griddeddatasamples/GriddedData/InputsforValidation/T_SFC/TSFC_1974_01/IDZ00026_VIC_ADFD_T_SFC.nc",
>> 'r+', 'NETCDF4')
>> LAT=fileforlatlon.variables['latitude'][:]
>> LON=fileforlatlon.variables['longitude'][:]
>>
>> for (path, dirs, files) in os.walk(MainFolder):
>> for dir in dirs:
>> print dir
>> path=path+'/'
>> for ncfile in files:
>> if ncfile[-3:]=='.nc':
>> print "dealing with ncfiles:", ncfile
>> ncfile=os.path.join(path,ncfile)
>> ncfile=Dataset(ncfile, 'r+', 'NETCDF4')
>> TSFC=ncfile.variables['T_SFC'][1::3]
>> TIME=ncfile.variables['time'][1::3]
>> ncfile.close()
>> gc.collect()
>>
>> for TSFC, TIME in zip((TSFC[:]),(TIME[:])):
>> cdftime=utime('seconds since 1970年01月01日 00:00:00')
>> ncfiletime=cdftime.num2date(TIME)
>> print ncfiletime
>> timestr=str(ncfiletime)
>> d = datetime.strptime(timestr, '%Y-%m-%d %H:%M:%S')
>> date_string = d.strftime('%Y%m%d_%H%M')
>>
>> map =
>> Basemap(projection='merc',llcrnrlat=-40,urcrnrlat=-33,
>>
>> llcrnrlon=139.0,urcrnrlon=151.0,lat_ts=0,resolution='i')
>> x,y=map(*N.meshgrid(LON,LAT))
>> map.drawcoastlines(linewidth=0.5)
>> map.readshapefile(shapefile1, 'DSE_REGIONS')
>> map.drawstates()
>>
>> plt.title('Surface temperature at %s UTC'%ncfiletime)
>> ticks=[-5,0,5,10,15,20,25,30,35,40,45,50]
>> CS = map.contourf(x,y,TSFC, ticks, cmap=plt.cm.jet)
>> l,b,w,h =0.1,0.1,0.8,0.8
>> cax = plt.axes([l+w+0.025, b, 0.025, h], )
>> cbar=plt.colorbar(CS, cax=cax, drawedges=True)
>>
>> plt.savefig((os.path.join(OutputFolder,
>> 'TSFC'+date_string+'UTC.png')))
>> plt.close()
>> gc.collect()
>>
>>
>> Try moving these lines
>>
>>
>> map =
>> Basemap(projection='merc',llcrnrlat=-40,urcrnrlat=-33,
>>
>> llcrnrlon=139.0,urcrnrlon=151.0,lat_ts=0,resolution='i')
>> x,y=map(*N.meshgrid(LON,LAT))
>> map.drawcoastlines(linewidth=0.5)
>> map.readshapefile(shapefile1, 'DSE_REGIONS')
>> map.drawstates()
>>
>> out of the loop.
>>
>> -Jeff
>>
>>
>>
>>
>
>

Would it possible to update the matplotlib page on pypi.python.org to 1.1?
Otherwise, by default easy_install and pip currently install 1.0.1.
Thank you,
--
Félix-Antoine Fortin

On Sat, Oct 22, 2011 at 7:54 AM, Rich Shepard <rsh...@ap...> wrote:
> On 2011年10月21日, Paul Ivanov wrote:
>  I will certainly add diagnostic code requested by you, Ben, and anyone
> else and report the results when trying to run the model. I do need to fix
> this and have no idea what's behind the problem.
The traceback is due to a nonprinting character being included in one
of the fonts on your system - we just need to figure out which one.
Change my request to add 'sys.stderr.write(fh.name)' before the 'while
1:' in
_parse_char_metrics - just so we don't have any buffering issues. The
last file you see printed there will be the one that's causing the
issue. You can then try removing it, or sending it back to the list
(or both) so we can see what happened.
The other issue you're seeing ("unknown keyword in AFM header") is
also likely caused by bad font files.
>From your error log that Ben forwarded to the list - I'm a bit
suspicious that two of the errors came from an afm file that ships
with matplotlib, in particular matplotlib-error-trace.txt starts off
with:
 FILENAME:
 /usr/lib/python2.6/site-packages/matplotlib/mpl-data/fonts/afm/pagko8a.afm
 Found an unknown keyword in AFM header (was Underline)
 Found an unknown keyword in AFM header (was Underline)
This shouldn't be the case, as I can verify that the keywords aren't
just Underline - they are as follows:
 $ grep Under matplotlib/mpl-data/fonts/afm/pagko8a.afm
 UnderlinePosition -100
 UnderlineThickness 50
and that particular file has not been change in matplotlib since
February of 2007
So my wild guess is that something changed your afm files. Can you
check that your pagko8a.afm matches the one in
https://raw.github.com/matplotlib/matplotlib/master/lib/matplotlib/mpl-data/fonts/afm/pagko8a.afm
- and if they don't match, check that using the original pagko8a.afm
makes at least that error go away?
As another possible solution (maybe this is already done, but worth a
potshot), you could try switching USE_FONTCONFIG to True in
font_manager.py as per the docstring there:
Experimental support is included for using `fontconfig` on Unix
variant platforms (Linux, OS X, Solaris). To enable it, set the
constant ``USE_FONTCONFIG`` in this file to ``True``. Fontconfig has
the advantage that it is the standard way to look up fonts on X11
platforms, so if a font is installed, it is much more likely to be
found.)
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

Yarr. Sorry for the noise. Just needed to install the freetype headers :|
apt-get install libfreetype6-dev
--
Jake Biesinger
Graduate Student
Xie Lab, UC Irvine
On Sat, Oct 22, 2011 at 11:40 PM, Jacob Biesinger
<jak...@gm...>wrote:
> Hi!
>
> Trying to upgrade my matplotlib to use the new 3d plotting tools.
>
> $ sudo pip install -U matplotlib
> ...
> building 'matplotlib.ft2font' extension
>
> creating build/temp.linux-x86_64-2.7
>
> creating build/temp.linux-x86_64-2.7/src
>
> creating build/temp.linux-x86_64-2.7/CXX
>
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MP
> L_ARRAY_API -DPYCXX_ISO_CPP_LIB=1
> -I/usr/lib/pymodules/python2.7/numpy/core/include -I/usr/local/include
> -I/usr/inclu
> de -I. -I/usr/lib/pymodules/python2.7/numpy/core/include/freetype2
> -I/usr/local/include/freetype2 -I/usr/include/free
> type2 -I./freetype2 -I/usr/include/python2.7 -c src/ft2font.cpp -o
> build/temp.linux-x86_64-2.7/src/ft2font.o
>
> cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
> Ada/C/ObjC but not for C++
>
> In file included from src/ft2font.cpp:1:0:
>
> src/ft2font.h:14:22: fatal error: ft2build.h: No such file or director
>
>
> and it looks like the file really is missing...
> $ find build/ -name *ft2build*
> $ ls build/matplotlib/src/
> agg_py_path_iterator.h _backend_gdk.c _gtkagg.cpp mplutils.cpp
> path_cleanup.h _tkagg.cpp
> agg_py_transforms.cpp backend_gdk.c _image.cpp mplutils.h
> path_converters.h _ttconv.cpp
> agg_py_transforms.h cntr.c _image.h numerix.h
> _path.cpp _windowing.cpp
> _backend_agg.cpp ft2font.cpp _macosx.m nxutils.c
> _png.cpp _wxagg.cpp
> _backend_agg.h ft2font.h MPL_isnan.h path_cleanup.cpp
> _subprocess.c
>
>
> Perhaps someone forgot to hg add a file?
>
> --
> Jake Biesinger
> Graduate Student
> Xie Lab, UC Irvine
>
>

Hi!
Trying to upgrade my matplotlib to use the new 3d plotting tools.
$ sudo pip install -U matplotlib
...
building 'matplotlib.ft2font' extension
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/src
creating build/temp.linux-x86_64-2.7/CXX
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MP
L_ARRAY_API -DPYCXX_ISO_CPP_LIB=1
-I/usr/lib/pymodules/python2.7/numpy/core/include -I/usr/local/include
-I/usr/inclu
de -I. -I/usr/lib/pymodules/python2.7/numpy/core/include/freetype2
-I/usr/local/include/freetype2 -I/usr/include/free
type2 -I./freetype2 -I/usr/include/python2.7 -c src/ft2font.cpp -o
build/temp.linux-x86_64-2.7/src/ft2font.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
Ada/C/ObjC but not for C++
In file included from src/ft2font.cpp:1:0:
src/ft2font.h:14:22: fatal error: ft2build.h: No such file or director
and it looks like the file really is missing...
$ find build/ -name *ft2build*
$ ls build/matplotlib/src/
agg_py_path_iterator.h _backend_gdk.c _gtkagg.cpp mplutils.cpp
 path_cleanup.h _tkagg.cpp
agg_py_transforms.cpp backend_gdk.c _image.cpp mplutils.h
 path_converters.h _ttconv.cpp
agg_py_transforms.h cntr.c _image.h numerix.h
_path.cpp _windowing.cpp
_backend_agg.cpp ft2font.cpp _macosx.m nxutils.c
_png.cpp _wxagg.cpp
_backend_agg.h ft2font.h MPL_isnan.h path_cleanup.cpp
 _subprocess.c
Perhaps someone forgot to hg add a file?
--
Jake Biesinger
Graduate Student
Xie Lab, UC Irvine

Michael:
I commented on the patch here:
https://github.com/matplotlib/matplotlib/issues/545
In short...it works!

2011年10月21日 Friedrich Romstedt <fri...@gm...>:
> I will try to dig out that emails.
Did that, the email I meant dates back to 10 November 2010! Here's the snippet:
<snippet>
(Ben Root):
> I am curious, could this approach you have done be generalized to any sort
> of color transformation? Admittedly, a gray mode is probably the most
> common request, but what if someone wants a different transformation? Maybe
> even apply a filter that would produce sepia colors, or high-contrast
> colors, or a different grayscale transform? Heck, I could imagine a use
> where a user might want to do a color substitution?
Oh Yes, this is *ealily* possible. The new framework in the
ColorConverter class just uses a filter function, if we want to see it
like that, already. It's just the apply_rc_gray_setting() function or
sth like that. If you want to, you can try to add the functionality.
But we should discuss beforehand how to design it. There are several
possibilites. In fact, I like this filter function quite a lot!
1) Hardcoding other filters in ColorConverter (what a decent name!),
and switching them on or off
2) Inserting filters as functions on runtime into the ColorConverter
instance, some hooking mechanism
3) Providing a dedicated Filter class, that can be fed to
set_filter() instead of set_gray(). This I like best.
I will, when i find some time, first implement the propagation of gray
settings by allowing objects in set_gray(). Might be a good time to
rename it to set_filter() right away, or maybe not do it, if
set_gray() goes in, and expects a bool, it might break compat when
changing the argument spec later. So later set_gray() would just call
set_filter() or add_filter() or whatever.
</snippet>
So the filter idea was Ben's idea. I still like idea (3) for the
design best. I will check if it is possible to inject the filter code
into the renderer framework, since all colour settings arguments
somewhen flow into a call into the renderer. Pro: No rcParams
addition necessary, no modification of the peculiar colors.py
ColorConverter framework necessary, just leaving those things
untouched and hence no worries and headaches about them. No disabling
of higher-level caching and at the same time negligible small impact
if there is no filter active. Con: I don't know yet if it works. I
vaguely remember there were some problems when I checked that
possibility last time (with pixmaps or something like that). I think
I will find out soon enough.
Eric, Ben, do you think we should go off-list with this now? I would
prefer on-list now. There might be people following but not
responding.
Friedrich

On 10/22/2011 06:46 AM, Steve Butcher wrote:
> All,
>
> On my iMac at work running 10.6.8, I did a brew-based installation of
> Python 2.7.2. I used pip to install scipy, numpy and then matplotlib.
> The last didn't work right so I scoured the internets to find out what
> to do. The first solution I found suggested doing a git clone of the
> repository and running python setup.py build then python setup.py
> install. That worked just great.
>
> At home, I tried the same thing on my MBP running 10.6.8. When I got to
> the compile matplotlib step, the fix from above didn't work. So I
> started trying other solutions I had found. Many of them "worked",
> however, when I went to run this simple script:
>
> import matplotlib.pylab as plt
> from scipy.stats import norm
>
> I got this error:
>
> Traceback (most recent call last):
> File "plot.py", line 1, in <module>
> import matplotlib.pylab as plt
> File
> "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/pylab.py",
> line 221, in <module>
> from matplotlib import mpl # pulls in most modules
> File
> "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/mpl.py",
> line 2, in <module>
> from matplotlib import axis
> File
> "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/axis.py",
> line 10, in <module>
> import matplotlib.font_manager as font_manager
> File
> "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/font_manager.py",
> line 1323, in <module>
> _rebuild()
> File
> "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/font_manager.py",
> line 1273, in _rebuild
> fontManager = FontManager()
> File
> "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/font_manager.py",
> line 997, in __init__
> self.afmlist = createFontList(self.afmfiles, fontext='afm')
> File
> "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/font_manager.py",
> line 565, in createFontList
> prop = afmFontProperty(fpath, font)
> File
> "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/font_manager.py",
> line 501, in afmFontProperty
> weight = weight_as_number(font.get_weight().lower())
> File
> "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/afm.py",
> line 464, in get_weight
> return self._header['Weight']
> KeyError: 'Weight'
>
> Googling did not reveal a single occurrence of this error reported anywhere.
>
> And so I would move on to the next instructions for compilation
> including the original make.osx instructions...and while the
> compilations succeeded, I still got the same error. Finally I decided to
> try the Enthought completely pre-compiled and packaged installation.
> Same problem.
>
> I'm at a loss. I even completely erased my /usr/local/ directory so that
> everything would be consistently installed via Homebrew. But no matter
> what I do, I end up with the same problem.
>
> I'm considering that something is wrong with my Snow Leopard
> installation and perhaps (reluctantly) upgrading to Lion, something I
> haven't really felt compelled to do. I'm hoping that there is a setting
> that I neglected.
>
> Ideas?
Given that the error is appearing in afm.py, and that it is independent 
of the python and matplotlib installations, my guess is that there is a 
bad afm font file somewhere on your system--in which case, it is not 
clear that upgrading to Lion would help. There is another thread on the 
mailing list right now about a possibly similar problem. Fonts and Macs 
are outside my domain, but with that caveat, I suggest that instead of 
"upgrading" you try comparing the the collection of fonts on your work 
machine to that on your home machine. Maybe something you installed on 
your home machine included a bad font file that mpl is finding.
Eric
>
> Thanks,
> Steve
>
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

All,
On my iMac at work running 10.6.8, I did a brew-based installation of Python 2.7.2. I used pip to install scipy, numpy and then matplotlib. The last didn't work right so I scoured the internets to find out what to do. The first solution I found suggested doing a git clone of the repository and running python setup.py build then python setup.py install. That worked just great.
At home, I tried the same thing on my MBP running 10.6.8. When I got to the compile matplotlib step, the fix from above didn't work. So I started trying other solutions I had found. Many of them "worked", however, when I went to run this simple script:
import matplotlib.pylab as plt
from scipy.stats import norm
I got this error:
Traceback (most recent call last):
 File "plot.py", line 1, in <module>
  import matplotlib.pylab as plt
 File "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/pylab.py", line 221, in <module>
  from matplotlib import mpl # pulls in most modules
 File "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/mpl.py", line 2, in <module>
  from matplotlib import axis
 File "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/axis.py", line 10, in <module>
  import matplotlib.font_manager as font_manager
 File "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/font_manager.py", line 1323, in <module>
  _rebuild()
 File "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/font_manager.py", line 1273, in _rebuild
  fontManager = FontManager()
 File "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/font_manager.py", line 997, in __init__
  self.afmlist = createFontList(self.afmfiles, fontext='afm')
 File "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/font_manager.py", line 565, in createFontList
  prop = afmFontProperty(fpath, font)
 File "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/font_manager.py", line 501, in afmFontProperty
  weight = weight_as_number(font.get_weight().lower())
 File "/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-macosx-10.4-x86_64.egg/matplotlib/afm.py", line 464, in get_weight
  return self._header['Weight']
KeyError: 'Weight'
Googling did not reveal a single occurrence of this error reported anywhere.
And so I would move on to the next instructions for compilation including the original make.osx instructions...and while the compilations succeeded, I still got the same error. Finally I decided to try the Enthought completely pre-compiled and packaged installation. Same problem.
I'm at a loss. I even completely erased my /usr/local/ directory so that everything would be consistently installed via Homebrew. But no matter what I do, I end up with the same problem.
I'm considering that something is wrong with my Snow Leopard installation and perhaps (reluctantly) upgrading to Lion, something I haven't really felt compelled to do. I'm hoping that there is a setting that I neglected.
Ideas? 
Thanks,
Steve

On 2011年10月21日, Paul Ivanov wrote:
> Is there a particular reason you just upgraded to a version of matplotlib
> that is almost 2 years old now? Matplotlib 1.1.0 was released a few weeks
> ago,
Paul,
 Yes, the reason was 0.99.1.2 was on the SlackBuilds.org site, so I didn't
check to see if it was the current version.
> ... so it's strange that you did not upgrade to it, or at least to 1.0.1,
> which came out in January.
 I just did: 1.1.0 is now installed, but I still have the same problem
trying to run my model.
> I'm not certain that the issue you're running into has been fixed, but
> there have certainly been lots of changes. I also want to make sure that
> there isn't some stale pointer to an old version of matplotlib out there -
> so can you let us know what procedure you used to do the upgrade?
 I modified the matplotlib.SlackBuild script to remove the old patch and
the non-existant file names INTERACTIVE and KNOWN_BUGS. It built and
upgraded just fine.
 Ben's been helping by asking for information that might assist in
isolating the source of the problem. Since I am now using version 1.1.0 I'll
resend the error report.
 There are multiple lines reading:
Found an unknown keyword in AFM header (was Underline)
followed by the traceback:
Traceback (most recent call last):
 File "./eikos.py", line 6, in <module>
 from modelPage import modModel
 File "/home/rshepard/development/trunk/modelPage.py", line 9, in <module>
 from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg as
FigureCanvas
 File
"/usr/lib/python2.6/site-packages/matplotlib/backends/backend_wxagg.py",
line 20, in <module>
 from matplotlib.figure import Figure
 File "/usr/lib/python2.6/site-packages/matplotlib/figure.py", line 18, in
<module>
 from axes import Axes, SubplotBase, subplot_class_factory
 File "/usr/lib/python2.6/site-packages/matplotlib/axes.py", line 14, in
<module>
 import matplotlib.axis as maxis
 File "/usr/lib/python2.6/site-packages/matplotlib/axis.py", line 10, in
<module>
 import matplotlib.font_manager as font_manager
 File "/usr/lib/python2.6/site-packages/matplotlib/font_manager.py", line
1323, in <module>
 _rebuild()
 File "/usr/lib/python2.6/site-packages/matplotlib/font_manager.py", line
1273, in _rebuild
 fontManager = FontManager()
 File "/usr/lib/python2.6/site-packages/matplotlib/font_manager.py", line
997, in __init__
 self.afmlist = createFontList(self.afmfiles, fontext='afm')
 File "/usr/lib/python2.6/site-packages/matplotlib/font_manager.py", line
559, in createFontList
 font = afm.AFM(fh)
 File "/usr/lib/python2.6/site-packages/matplotlib/afm.py", line 304, in
__init__
 parse_afm(fh)
 File "/usr/lib/python2.6/site-packages/matplotlib/afm.py", line 292, in
parse_afm
 dcmetrics_ascii, dcmetrics_name = _parse_char_metrics(fh)
 File "/usr/lib/python2.6/site-packages/matplotlib/afm.py", line 176, in
_parse_char_metrics
 name = vals[2].split()[1]
IndexError: list index out of range
 I will certainly add diagnostic code requested by you, Ben, and anyone
else and report the results when trying to run the model. I do need to fix
this and have no idea what's behind the problem.
Thanks,
Rich

I want to do some corrections and alterations to my last mail, because
it troubles me.
2011年10月21日 Friedrich Romstedt <fri...@gm...>:
> I believe the one and only solution would, if thought thru completely,
> unveil that we need functional approach to get better results. In
> matplotlib, each type of structure is an object of a class, which is
> not callable mostly, and this means, you have to formulate each
> alteration explicitly. It's not easy in this frame of thinking to get
> the flexibility we in fact want - this might be the reason why mpl is
> so monolithic with all its different kind of Artist objects ... with
> the counterparts in the Renderer objects and so on.
I in fact think the "one and only" solution is a very dangerous deceit.
There might be some advantages of a functional approach, but there are
also severe drawbacks, for instance, that you get rubbish tracebacks
if something goes wrong.
This I just wanted to say to prevent piping errors.
Friedrich

FILENAME:
/usr/lib/python2.6/site-packages/matplotlib/mpl-data/fonts/afm/pagko8a.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /usr/share/fonts/ISO8859-2/Type1/afm/gatsm___.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /home/rshepard/.fonts/atmfonts/swzlighi.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /usr/share/fonts/atmfonts/vogueb.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /home/rshepard/.fonts/atmfonts/cottagen.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /usr/share/fonts/atmfonts/centoldi.afm
FILENAME: /usr/share/fonts/culmus/NachlieliCLM-Light.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /usr/share/fonts/atmfonts/amhersti.afm
FILENAME: /usr/share/fonts/local/n021004l.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /home/rshepard/.fonts/atmfonts/casprofn.afm
FILENAME: /usr/share/fonts/local/bchr.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /usr/share/fonts/atmfonts/lithon.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /home/rshepard/.fonts/atmfonts/bangkokn.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /usr/share/fonts/atmfonts/scottn.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /usr/share/fonts/Type1/l047016t.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /home/rshepard/.fonts/Type1/n019003l.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /home/rshepard/.fonts/Type1/c059036l.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /home/rshepard/.fonts/atmfonts/cosmic2n.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /usr/share/fonts/atmfonts/expon.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /home/rshepard/.fonts/culmus/AharoniCLM-Bold.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /usr/share/fonts/Type1/n019064l.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /home/rshepard/.fonts/Type1/UTBI____.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /usr/share/fonts/local/n019024l.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /usr/share/fonts/atmfonts/liquidn.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /home/rshepard/.fonts/culmus/NachlieliCLM-LightOblique.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)
FILENAME: /home/rshepard/.fonts/atmfonts/bravon.afm
Found an unknown keyword in AFM header (was Underline)
Found an unknown keyword in AFM header (was Underline)

On Mon, Oct 17, 2011 at 3:59 PM, Rich Shepard <rsh...@ap...> wrote:
> On 2011年10月17日, Benjamin Root wrote:
>
>> I only need the last line printed by that print statement. I want to see
>> how the parsing failed.
>
> Ben,
>
>  Here are the last 3:
>
> Line: C 125 ; WX 273 ; N braceright ; B 55 -68 244 707 ;
> Line: C 126 ; WX 586 ; N asciitilde ; B 39 219 531 408 ;
> Line: C 127 ; WX 262 ; N ; B 64 506 246 730 ;
>
>  I see there's no character in the last line. Isn't that interesting!
What's weirder, is that 127 is a control character (Delete), and not
meant to be a printable character.
Maybe you already figured this out in following up with Ben, but if
not, can you 'print fh.name' before the while 1: in
_parse_char_metrics so we find out which .afm file is the culrpit
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

On Friday, October 21, 2011, Benjamin Root <ben...@ou...> wrote:
>
>
> On Friday, October 21, 2011, Paul Ivanov <piv...@gm...> wrote:
>> Hi Rich,
>>
>> On Mon, Oct 17, 2011 at 10:57 AM, Rich Shepard <rsh...@ap...>
wrote:
>>> After a long hiatus I'm again working on an application and just
upgraded
>>> matplotlib from 0.98.5.2 to 0.99.1.2.
>>
>> Is there a particular reason you just upgraded to a version of
>> matplotlib that is almost 2 years old now? Matplotlib 1.1.0 was
>> released a few weeks ago, so it's strange that you did not upgrade to
>> it, or at least to 1.0.1, which came out in January. I'm not certain
>> that the issue you're running into has been fixed, but there have
>> certainly been lots of changes. I also want to make sure that there
>> isn't some stale pointer to an old version of matplotlib out there -
>> so can you let us know what procedure you used to do the upgrade?
>>
>> best,
>
> Paul,
>
> Apparently, a bunch of the back-n-forth between myself and the OR went
off-list. The problem is with the AFM font files packaged with mpl. afm.py
is doing the correct thing by failing to parse an invalid line. However, I
don't know much about AFM files and where they come from package-wise to
know where to file a bug report.
>
> Cheers,
> Ben Root
Oops, sorry, I meant to say AFM files *not* packaged with mpl.
Ben Root

On Friday, October 21, 2011, Paul Ivanov <piv...@gm...> wrote:
> Hi Rich,
>
> On Mon, Oct 17, 2011 at 10:57 AM, Rich Shepard <rsh...@ap...>
wrote:
>> After a long hiatus I'm again working on an application and just
upgraded
>> matplotlib from 0.98.5.2 to 0.99.1.2.
>
> Is there a particular reason you just upgraded to a version of
> matplotlib that is almost 2 years old now? Matplotlib 1.1.0 was
> released a few weeks ago, so it's strange that you did not upgrade to
> it, or at least to 1.0.1, which came out in January. I'm not certain
> that the issue you're running into has been fixed, but there have
> certainly been lots of changes. I also want to make sure that there
> isn't some stale pointer to an old version of matplotlib out there -
> so can you let us know what procedure you used to do the upgrade?
>
> best,
Paul,
Apparently, a bunch of the back-n-forth between myself and the OR went
off-list. The problem is with the AFM font files packaged with mpl. afm.py
is doing the correct thing by failing to parse an invalid line. However, I
don't know much about AFM files and where they come from package-wise to
know where to file a bug report.
Cheers,
Ben Root

Hi Rich,
On Mon, Oct 17, 2011 at 10:57 AM, Rich Shepard <rsh...@ap...> wrote:
>  After a long hiatus I'm again working on an application and just upgraded
> matplotlib from 0.98.5.2 to 0.99.1.2.
Is there a particular reason you just upgraded to a version of
matplotlib that is almost 2 years old now? Matplotlib 1.1.0 was
released a few weeks ago, so it's strange that you did not upgrade to
it, or at least to 1.0.1, which came out in January. I'm not certain
that the issue you're running into has been fixed, but there have
certainly been lots of changes. I also want to make sure that there
isn't some stale pointer to an old version of matplotlib out there -
so can you let us know what procedure you used to do the upgrade?
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

> Thanks for clarifying. I understand what you're saying now. I think
> what we want to do is store the unmultiplied alpha as a "canonical"
> version of the image, and premultiply a copy (or use some C++ iterator
> magic to avoid the copy) right before sending it off to Agg. Then the
> alpha can be fully "tweakable" at runtime.
Just for my understanding of the design approach of matplotlib in
general, is it implicitly assumed that once pixels have been passed to
agg, they are destined for the renderer? No other possible use? And
the life span is short? I'm just not very familiar with where _image
is used throughout the rest of the code, if at all.
As far as the iterator magic, the kicker is that it would have to take
place inside of agg; it cannot be on the mpl side;
So if I'm understanding correctly,
 1) create a copy of the image within resize()
 2) premultiply the alpha on the copy
 3) let agg do its work, returning its result in a new pixmap
(resized) that is premultiplied.
 4) toss the extra copy made in (1)
 5) in each individual backend's renderer, right before the pixels
are rendered, unmultiply the alpha if necessary (as is the case with
wxagg).
I also remember you making mention of saving pngs above, I suppose
there would have to be an unmultiply there as well.
i've done some grepping through the code, and don't see that these
filter routines are used anywhere except specifically in this resize()
function. I can fully understand the desire to comply with agg's
spec, but I'm still not convinced that a small patch to agg isn't
appropriate here. It's a little odiferous, but won't be hard to
maintain given that agg is a very slowly changing library (last
release 2006?). Or maybe treat patching agg as short term solution.
Looking through the filter algorithms too, it looks like exactly the
same ops are done to each channel (RGBA) separately. So (it appears
as if, to my untrained eye) that the algorithms are applicable
regardless of whether or not the alphas are premultiplied. Further,
removing the clip will have very minimal impact on "proper" usage of
agg (i.e. sending in premultiplied alpha).
> I'll try to tackle this problem, as well as the problem that set_alpha
> simply doesn't work, at the same time when I get a chance (or patches
> are always welcome, of course :).
I have a patch, but you don't like it :D
But seriously, I'll take a more careful look at what it would take to
implement items 1-5 above; it might not be so bad, but I'm
uncomfortable dealing with the "underbelly" of matplotlib, as I'm not
familiar with either mpl's design nor the general subject of graphics.

I have a simple fix for this on this branch:
https://github.com/mdboom/matplotlib/tree/slow_update
It's sort of the simplest thing that could work. It caches the last 
results of "_update_ticks" and only updates them if the view limits or 
axis position have changed. It also invalidates this cache upon 
changing the set of ticks etc.
It makes things considerably faster -- it still has to draw all of the 
elements of the plot every time. Fixing that would require a lot more 
low-level replumbing (matplotlib doesn't currently do region-based 
updating etc.).
Mike
On 10/20/2011 11:17 PM, John Gu wrote:
> Thanks. Is there a place where these sorts of issues can be submitted 
> for review / fixes? I'm totally willing to take a look at possible 
> solutions if someone points me in the right direction. Thanks.
>
> On Thu, Oct 20, 2011 at 10:52 PM, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
>
> On 10/20/2011 03:47 PM, John Gu wrote:
> > Hello,
> >
> > I'm using version 1.0.1 of matplotlib on a linux machine. uname -a
> > returns the following: Linux jgulinux 2.6.35.14-95.fc14.x86_64
> #1 SMP
> > Tue Aug 16 21:01:58 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux.
> >
> > [jgu@jgulinux ~/.matplotlib]$ cat matplotlibrc
> > backend : TkAgg
> > interactive : True
> >
> > Program that reproduces the problem (run in ipython):
> >
> > x = arange(1000)
> > y = x
> >
> > f = figure(1)
> > for ia in xrange(5):
> > for ib in xrange(5):
> > ax = subplot(5,5,ia*5+ib+1, navigate=True)
> > ax.plot(x,y)
> >
> > If we now tried to interactively navigate through any single
> subplot of
> > the figure, it is extremely slow. Not sure if this is a
> configuration
> > error on my side?
>
> No, and it is not backend-dependent, either. And it does not even
> require that all of the plots have data--it is the same if only
> the last
> subplot has data. A little experimentation indicates that all the
> ticks
> and tick labels on the other subplots are slowing down the interaction
> with the one subplot being navigated.
>
> ax.tick_params(labelbottom=False, labelleft=False)
> ax.tick_params(left=False, right=False, top=False,
> bottom=False)
>
> Insert the above to turn off ticks and tick labels, and it speeds up
> nicely. That's not a solution, I realize.
>
> I knew that slowness in the tick and tick label generation was a major
> bottleneck in subplot creation, but I did not realize that it had such
> an effect on interactive manipulation of a single subplot.
>
> Eric
>
> >
> > John
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Friday, October 21, 2011, Michael Droettboom <md...@st...> wrote:
> On 10/21/2011 09:49 AM, Daniel Hyams wrote:
>> All sounds reasonable Mike; I do agree that patching the agg source
>> code is not that desirable; I was operating under the (incorrect)
>> assumption that most, if not all, backends used straight alpha.
>>
>> I'll certainly test the patch tonight, but I can only test it under
>> wxAgg reasonably, which is one of the backends that expects straight
>> alpha as far as I know.
>>
>> The "loss in picture detail" comment was just discomfort with the fact
>> that once the alphas are premultiplied in, there is not an exact
>> reverse transformation to get your original color back. In googling
>> around to better explain here, I found this, which is a much more in
>> depth and better explanation than what I would have come up with:
>>
>> http://www.quasimondo.com/archives/000665.php
>>
>> The crux is here:
>>
>>> An example: when you set the alpha value of a pixel to 16 all color
values will be multiplied with
>>> a factor of 16/256 = 0.0625. So a gray pixel of 128 will become 128 *
0.0625 = 8, a darker pixel
>>> of 64 will become 64 * 0.0625 = 4. But a slightly lighter pixel of maybe
67 will become 67 *
>>> 0.0625 = 4.1875 - yet there are no decimals in integer pixels which
means it will also become
>>> 4. The effect that you will get posterization - setting your alpha
channel to 8 means that you
>>> also reduce your color channels to 8 levels, this means instead =
256*256*256 different colors
>>> you will end up with a maximum of 8*8*8 = 512 different colors.
>> One might argue that the loss of color information is not that
>> crucial, because for very low alpha (where the problem is most
>> pronounced), the image is almost invisible anyway... so it won't
>> matter. That's true, but what if I want to (for whatever reason) take
>> the image's pixels again, before draw, and boost the alpha up again?
>> What I'll get is a posterized mess. So, I'm still of the opinion that
>> patching agg in this situation might be the best solution to this.
>> This way, straight alphas are used throughout, and for backends that
>> require premultiplied alpha, the alpha can be premultiplied in at the
>> latest possible moment.
>
> Thanks for clarifying. I understand what you're saying now. I think
> what we want to do is store the unmultiplied alpha as a "canonical"
> version of the image, and premultiply a copy (or use some C++ iterator
> magic to avoid the copy) right before sending it off to Agg. Then the
> alpha can be fully "tweakable" at runtime.
>
> I'll try to tackle this problem, as well as the problem that set_alpha
> simply doesn't work, at the same time when I get a chance (or patches
> are always welcome, of course :).
>
> Mike
Mike,
This idea is sort of along the same vein of the idea that I have been having
for unifying the colors framework and allowing for transforms to be
performed upon access of the colors. If you think about it, the issue of
different backends wanting different information can be dealt with by having
a transform that returns pre multiplied alphas and another that returns
straight alphas. The backends can then solely the desired transform that it
expects.
I guess the question is whether the transformation step should be
generalized at the python level, or specialized down at the python/c++
boundary.
I really wish I had more time this semester to try and come up with a proof
of concept.
Ben Root
P.S. - I had also noticed alpha-blending issues before (and asked about it),
but I ended up convincing myself (apparently wrongly) that it was correct.

On 10/21/2011 09:49 AM, Daniel Hyams wrote:
> All sounds reasonable Mike; I do agree that patching the agg source
> code is not that desirable; I was operating under the (incorrect)
> assumption that most, if not all, backends used straight alpha.
>
> I'll certainly test the patch tonight, but I can only test it under
> wxAgg reasonably, which is one of the backends that expects straight
> alpha as far as I know.
>
> The "loss in picture detail" comment was just discomfort with the fact
> that once the alphas are premultiplied in, there is not an exact
> reverse transformation to get your original color back. In googling
> around to better explain here, I found this, which is a much more in
> depth and better explanation than what I would have come up with:
>
> http://www.quasimondo.com/archives/000665.php
>
> The crux is here:
>
>> An example: when you set the alpha value of a pixel to 16 all color values will be multiplied with
>> a factor of 16/256 = 0.0625. So a gray pixel of 128 will become 128 * 0.0625 = 8, a darker pixel
>> of 64 will become 64 * 0.0625 = 4. But a slightly lighter pixel of maybe 67 will become 67 *
>> 0.0625 = 4.1875 - yet there are no decimals in integer pixels which means it will also become
>> 4. The effect that you will get posterization - setting your alpha channel to 8 means that you
>> also reduce your color channels to 8 levels, this means instead = 256*256*256 different colors
>> you will end up with a maximum of 8*8*8 = 512 different colors.
> One might argue that the loss of color information is not that
> crucial, because for very low alpha (where the problem is most
> pronounced), the image is almost invisible anyway... so it won't
> matter. That's true, but what if I want to (for whatever reason) take
> the image's pixels again, before draw, and boost the alpha up again?
> What I'll get is a posterized mess. So, I'm still of the opinion that
> patching agg in this situation might be the best solution to this.
> This way, straight alphas are used throughout, and for backends that
> require premultiplied alpha, the alpha can be premultiplied in at the
> latest possible moment.
Thanks for clarifying. I understand what you're saying now. I think 
what we want to do is store the unmultiplied alpha as a "canonical" 
version of the image, and premultiply a copy (or use some C++ iterator 
magic to avoid the copy) right before sending it off to Agg. Then the 
alpha can be fully "tweakable" at runtime.
I'll try to tackle this problem, as well as the problem that set_alpha 
simply doesn't work, at the same time when I get a chance (or patches 
are always welcome, of course :).
Mike
> Thanks for all of the help with this Mike,
>
> Daniel
>
> On Fri, Oct 21, 2011 at 9:31 AM, Michael Droettboom<md...@st...> wrote:
>> Thanks for looking into this deeper.
>>
>> Agg requires image buffers to be premultiplied, as described in the third
>> bullet point here. (It's not exactly clear, to say the least, but that's
>> what I take it to mean, and also from reading the code).
>>
>> http://www.antigrain.com/news/release_notes/v22.agdoc.html
>>
>> The bug is that in _image.cpp the input buffers are not declared as
>> premultiplied in _image.cpp. Arguably it is a bug that agg doesn't reject
>> filtering unmultiplied images, since the note states that the assumption is
>> that they are premultiplied by the time they get to the filters.
>>
>> I have attached a patch that fixes this. Would you mind testing it and let
>> me know how it works for you?
>>
>> On 10/20/2011 10:29 PM, Daniel Hyams wrote:
>>> I've looked all over the place through both the Python and C code, and
>>> I don't see any premultiplication of alphas at any stage before the
>>> pixels are passed off to agg, and neither can I find any place where
>>> the alphas are "unmultiplied" on the way back from agg to the backend
>>> for rendering.
>> matplotlib's support for alpha blending of images is basically by accident,
>> so it's not surprising the details aren't right.
>>
>> I think it is a bug that after reading images in we don't premultiply them
>> before sending them to Agg. That bug has existed for a long time in
>> matplotlib because no one is really using alpha images a great deal.
>> (Masked images, yes, but that implies alpha is strictly 0 or 255 and thus
>> these issues don't come into play.)
>>
>> Unmultiplying is not always necessary. Many of the GUI backends also expect
>> premultiplied alpha (Qt for example). However, there is certainly a bug in
>> writing PNG files (where the file format specifies unmultiplied).
>>
>>> It's very possible that I missed it, but I would have to miss it in
>>> two places (premultiply and the unmultiply). It looks to me like the
>>> output from agg ends up getting passed on directly to the renderer,
>>> which as far as I know, just uses straight alpha. The WxAgg renderer,
>>> for example, just creates a wx.Bitmap out of the pixels and blits it.
>>> Which means that any image going through agg's filters will not be
>>> correct if it has any pixels with alpha != 0 or != 255.
>>>
>>> [Using PIL images because they are simple to talk about...but the PIL
>>> image could alternatively be an image.py image]
>>>
>>> As far as I can tell, the image pixels current go through a pipeline
>>> like the following:
>>>
>>> [1] PIL Image -> _image image -> agg operations -> modified and/or
>>> resized _image image -> renderer
>>>
>>> If agg expects premultiplied alpha, the procedure should look something
>>> like:
>>>
>>> [2] PIL Image -> _image image -> premultiply alphas ->agg options ->
>>> unmultiply alphas -> modified and/or resized _image image -> renderer
>>>
>>> I personally don't like pipeline [2] because picture detail is lost in
>>> the "unmultiply alphas" stage. Better to use straight alpha all the
>>> way through.
>> I think what needed is:
>>
>> [3] PIL Image (or _png.cpp) -> premultiply alphas -> _image image -> agg
>> options ->
>> -> modified and/or resized _image image -> renderer -> (unmultiply
>> alphas)? -> GUI library
>>
>> That is -- all image data should be kept premultiplied internally in all
>> buffers for efficiency and because this is what Agg is designed for.
>>
>> Can you explain what you mean by "picture detail is lost in the unmultiply
>> alphas stage". There is the usual problem that by premultiplying you lose
>> any color data where alpha = 0 (and you lose resolution everywhere else, but
>> not resolution you can actually see after compositing).
>>> So long as matplotlib is using only a subset of agg algorithms that
>>> work no matter whether the alphas are premultiplied or not, I would
>>> think that the most reasonable route was the one that I took; to
>>> always pass straight alphas (sticking with pipeline [1]), and modify
>>> the agg source slightly to fit matplotlib's approach (i.e., remove the
>>> clipping there).
>> I'd be really wary of modifying agg like this. Those things become hard to
>> maintain. I think this instead a bug in matplotlib and should be fixed
>> there.
>>
>> I've put an issue in the issue tracker here:
>>
>> https://github.com/matplotlib/matplotlib/issues/545
>>
>> Cheers,
>> Mike
>>
>>> I hope that I'm not way off base (I have a sneaking feeling that I am
>>> :O ), and hope this helps. I've verified on both Linux and Windows
>>> that removing the alpha-clip lines from agg_span_image_filter_rgba.h,
>>> rebuilding matplotlib, and replacing _image.so/_image.pyd and
>>> _backend_agg.so/_backend_agg.pyd does the trick (along with passing
>>> straight alphas). So far, I've seen no ill effects on any of my
>>> plots, but I'm also not in a position to run the pixel-by-pixel
>>> comparison matplotlib tests.
>>>
>>>
>>> On Wed, Oct 19, 2011 at 7:26 PM, Daniel Hyams<dh...@gm...> wrote:
>>>> There has to be something else in play here. I'll try to keep this
>>>> short, but the summary is this: I can get the transparency to look
>>>> right, but only if 1) I put "straight" alpha in image, not
>>>> premultiplied, and 2) I hack agg to remove specificially every
>>>> instance of the lines of code that you refer to above.
>>>>
>>>> Why this is, I don't know. Hopefully I'm still misusing something.
>>>> However, it behaves as if the clipping of alpha in the agg library is
>>>> corrupting the alpha channel. I also submit that I could have broken
>>>> some other transparency capabilities of matplotlib, because I don't
>>>> know what other routines use what I hacked....I did check a few
>>>> transparent polygons and such though, and everything seemed to be
>>>> fine.
>>>>
>>>> I know that the agg library has been around for quite a long time, so
>>>> that also means that such a basic bug is unlikely.
>>>>
>>>> I've reattached the (slightly modified) script that reproduces the
>>>> problem, along with a sample image that it uses. The only change to
>>>> the script is right at the top, where a different image is read, a
>>>> quick statement is placed to add an alpha channel if there is not
>>>> already one, and I'm attempting to use premultiplied alphas. I've
>>>> also attached a screenshot of the output. Notice that in this case,
>>>> both "transparent" images look wrong.
>>>>
>>>> Now, if I 1) hack agg to remove the alpha clipping, and 2) modify the
>>>> one line in the attached python script so that I use straight alpha,
>>>> everything looks right. Specifically, I removed every instance of the
>>>> code below from xxxx, rebuilt all of the matplotlib .so's, and
>>>> specifically replaced _image.so and _backend_agg.so in my matplotlib
>>>> distribution.
>>>>
>>>> if(fg[order_type::A]> base_mask) fg[order_type::A]
>>>> = base_mask;
>>>> if(fg[order_type::R]> fg[order_type::A])
>>>> fg[order_type::R] = fg[order_type::A];
>>>> if(fg[order_type::G]> fg[order_type::A])
>>>> fg[order_type::G] = fg[order_type::A];
>>>> if(fg[order_type::B]> fg[order_type::A])
>>>> fg[order_type::B] = fg[order_type::A];
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Oct 19, 2011 at 2:34 PM, Daniel Hyams<dh...@gm...> wrote:
>>>>> Ah, thanks so much Michael! That explanation helps a great deal; I
>>>>> was always considering things in "straight alpha" format, not even
>>>>> knowing that there was alternative.
>>>>>
>>>>> I'll play with this tonight; I don't see any problem getting the thing
>>>>> working, though, now that I know what agg expects to see...
>>>>>
>>>>> And yes, alpha support in the image class would be very helpful ;)
>>>>>
>>>>> On Wed, Oct 19, 2011 at 2:16 PM, Michael Droettboom<md...@st...>
>>>>> wrote:
>>>>>> You are right that Agg is doing the resizing here. Agg expects
>>>>>> premultiplied alpha. See [1] for information about what that means.
>>>>>>
>>>>>> [1] http://en.wikipedia.org/wiki/Alpha_compositing
>>>>>>
>>>>>> After Agg interpolates the pixel values, to prevent oversaturation it
>>>>>> truncates all values to be less than alpha (which makes sense if
>>>>>> everything
>>>>>> is assumed to be premultiplied alpha). Arguably, the bug here is that
>>>>>> nearest neighbor (which doesn't have to do any blending) doesn't
>>>>>> perform the
>>>>>> truncation step -- then both would look "wrong".
>>>>>>
>>>>>> It happens in this code snippet in span_image_filter_rgba: (base_mask
>>>>>> is
>>>>>> 255)
>>>>>>
>>>>>> if(fg[order_type::A]> base_mask)
>>>>>> fg[order_type::A]
>>>>>> = base_mask;
>>>>>> if(fg[order_type::R]> fg[order_type::A])
>>>>>> fg[order_type::R]
>>>>>> = fg[order_type::A];
>>>>>> if(fg[order_type::G]> fg[order_type::A])
>>>>>> fg[order_type::G]
>>>>>> = fg[order_type::A];
>>>>>> if(fg[order_type::B]> fg[order_type::A])
>>>>>> fg[order_type::B]
>>>>>> = fg[order_type::A];
>>>>>>
>>>>>> So, the solution to make a partially transparent image is to not do:
>>>>>>
>>>>>> pix[:,:,3] = 127
>>>>>>
>>>>>> but instead, do
>>>>>>
>>>>>> pix *= 0.5
>>>>>>
>>>>>> Of course, the real fix here is to support alpha blending properly in
>>>>>> the
>>>>>> image class, then the user wouldn't have to deal with such details. A
>>>>>> bug
>>>>>> should probably be filed in the matplotlib issue tracker for this.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>> On 10/19/2011 12:23 PM, Daniel Hyams wrote:
>>>>>>
>>>>>> [Sorry, I keep getting tripped up with HTML mail....resent in ascii,
>>>>>> and resaved one of the attachment png's to make it smaller.]
>>>>>>
>>>>>>
>>>>>> Example script attached (PIL required). Basically, if I impose a
>>>>>> specific value into an image's alpha channel and use any interpolation
>>>>>> scheme other than 'nearest', there appears gray all where the figure
>>>>>> didn't have any color to begin with. I've also attached a screenshot
>>>>>> of the output of the script on my machine.
>>>>>>
>>>>>> Hopefully I'm doing something wrongly?
>>>>>>
>>>>>> I chased the problem and managed to hack in a solution that fixes the
>>>>>> problem, but it's extremely inefficient...basically, in matplotlib's
>>>>>> image.py, routine BboxImage.make_image, you can create two images
>>>>>> there....one with no alpha channel (call it imRGB) and one with (call
>>>>>> it imRGBA). Go through all of the routine, doing exactly the same
>>>>>> things to both of the images *except* for the interpolation, which is
>>>>>> set to 'nearest' for imRGBA. Then, rip the colors out of imRGB, the
>>>>>> alpha channel off of imRGBA, and put them together....go through all
>>>>>> of the routine again with this composited image, and it works. I
>>>>>> know...I told you it was bad ;)
>>>>>>
>>>>>> The problem seems to be in the "resize" call in that routine...resize,
>>>>>> which calls into C code, does not appear to handle things correctly
>>>>>> when the alpha is anything other than 255's across the board. It
>>>>>> might be a problem in the agg routines, but hopefully it is just maybe
>>>>>> a misuse of the agg routines.
>>>>>>
>>>>>> The behavior seems to be backend independent as far as I could test (I
>>>>>> tried with wxagg and tk backends). I am using mpl 1.0.0 on Windows if
>>>>>> it matters.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Daniel Hyams
>>>>>> dh...@gm...
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> All the data continuously generated in your IT infrastructure contains
>>>>>> a
>>>>>> definitive record of customers, application performance, security
>>>>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>>>>> sense of it. Business sense. IT sense. Common sense.
>>>>>> http://p.sf.net/sfu/splunk-d2d-oct
>>>>>>
>>>>>> _______________________________________________
>>>>>> Matplotlib-users mailing list
>>>>>> Mat...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> The demand for IT networking professionals continues to grow, and the
>>>>>> demand for specialized networking skills is growing even more rapidly.
>>>>>> Take a complimentary Learning@Ciosco Self-Assessment and learn
>>>>>> about Cisco certifications, training, and career opportunities.
>>>>>> http://p.sf.net/sfu/cisco-dev2dev
>>>>>> _______________________________________________
>>>>>> Matplotlib-users mailing list
>>>>>> Mat...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Daniel Hyams
>>>>> dh...@gm...
>>>>
>>>> --
>>>> Daniel Hyams
>>>> dh...@gm...
>>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> The demand for IT networking professionals continues to grow, and the
>> demand for specialized networking skills is growing even more rapidly.
>> Take a complimentary Learning@Cisco Self-Assessment and learn
>> about Cisco certifications, training, and career opportunities.
>> http://p.sf.net/sfu/cisco-dev2dev
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>
>

Thanks.
The annotate function works. Does anybody knows a way to add some text
above or belove an arrow? Now I do it using text command and
coordinates for text. May be it possible to do directly with annotate
command?
Thanks.
Petro.

All sounds reasonable Mike; I do agree that patching the agg source
code is not that desirable; I was operating under the (incorrect)
assumption that most, if not all, backends used straight alpha.
I'll certainly test the patch tonight, but I can only test it under
wxAgg reasonably, which is one of the backends that expects straight
alpha as far as I know.
The "loss in picture detail" comment was just discomfort with the fact
that once the alphas are premultiplied in, there is not an exact
reverse transformation to get your original color back. In googling
around to better explain here, I found this, which is a much more in
depth and better explanation than what I would have come up with:
http://www.quasimondo.com/archives/000665.php
The crux is here:
>An example: when you set the alpha value of a pixel to 16 all color values will be multiplied with
>a factor of 16/256 = 0.0625. So a gray pixel of 128 will become 128 * 0.0625 = 8, a darker pixel
>of 64 will become 64 * 0.0625 = 4. But a slightly lighter pixel of maybe 67 will become 67 *
> 0.0625 = 4.1875 - yet there are no decimals in integer pixels which means it will also become
> 4. The effect that you will get posterization - setting your alpha channel to 8 means that you
> also reduce your color channels to 8 levels, this means instead = 256*256*256 different colors
> you will end up with a maximum of 8*8*8 = 512 different colors.
One might argue that the loss of color information is not that
crucial, because for very low alpha (where the problem is most
pronounced), the image is almost invisible anyway... so it won't
matter. That's true, but what if I want to (for whatever reason) take
the image's pixels again, before draw, and boost the alpha up again?
What I'll get is a posterized mess. So, I'm still of the opinion that
patching agg in this situation might be the best solution to this.
This way, straight alphas are used throughout, and for backends that
require premultiplied alpha, the alpha can be premultiplied in at the
latest possible moment.
Thanks for all of the help with this Mike,
Daniel
On Fri, Oct 21, 2011 at 9:31 AM, Michael Droettboom <md...@st...> wrote:
> Thanks for looking into this deeper.
>
> Agg requires image buffers to be premultiplied, as described in the third
> bullet point here. (It's not exactly clear, to say the least, but that's
> what I take it to mean, and also from reading the code).
>
> http://www.antigrain.com/news/release_notes/v22.agdoc.html
>
> The bug is that in _image.cpp the input buffers are not declared as
> premultiplied in _image.cpp. Arguably it is a bug that agg doesn't reject
> filtering unmultiplied images, since the note states that the assumption is
> that they are premultiplied by the time they get to the filters.
>
> I have attached a patch that fixes this. Would you mind testing it and let
> me know how it works for you?
>
> On 10/20/2011 10:29 PM, Daniel Hyams wrote:
>>
>> I've looked all over the place through both the Python and C code, and
>> I don't see any premultiplication of alphas at any stage before the
>> pixels are passed off to agg, and neither can I find any place where
>> the alphas are "unmultiplied" on the way back from agg to the backend
>> for rendering.
>
> matplotlib's support for alpha blending of images is basically by accident,
> so it's not surprising the details aren't right.
>
> I think it is a bug that after reading images in we don't premultiply them
> before sending them to Agg. That bug has existed for a long time in
> matplotlib because no one is really using alpha images a great deal.
> (Masked images, yes, but that implies alpha is strictly 0 or 255 and thus
> these issues don't come into play.)
>
> Unmultiplying is not always necessary. Many of the GUI backends also expect
> premultiplied alpha (Qt for example). However, there is certainly a bug in
> writing PNG files (where the file format specifies unmultiplied).
>
>> It's very possible that I missed it, but I would have to miss it in
>> two places (premultiply and the unmultiply). It looks to me like the
>> output from agg ends up getting passed on directly to the renderer,
>> which as far as I know, just uses straight alpha. The WxAgg renderer,
>> for example, just creates a wx.Bitmap out of the pixels and blits it.
>> Which means that any image going through agg's filters will not be
>> correct if it has any pixels with alpha != 0 or != 255.
>>
>> [Using PIL images because they are simple to talk about...but the PIL
>> image could alternatively be an image.py image]
>>
>> As far as I can tell, the image pixels current go through a pipeline
>> like the following:
>>
>> [1] PIL Image -> _image image -> agg operations -> modified and/or
>> resized _image image -> renderer
>>
>> If agg expects premultiplied alpha, the procedure should look something
>> like:
>>
>> [2] PIL Image -> _image image -> premultiply alphas ->agg options ->
>> unmultiply alphas -> modified and/or resized _image image -> renderer
>>
>> I personally don't like pipeline [2] because picture detail is lost in
>> the "unmultiply alphas" stage. Better to use straight alpha all the
>> way through.
>
> I think what needed is:
>
> [3] PIL Image (or _png.cpp) -> premultiply alphas -> _image image -> agg
> options ->
> -> modified and/or resized _image image -> renderer -> (unmultiply
> alphas)? -> GUI library
>
> That is -- all image data should be kept premultiplied internally in all
> buffers for efficiency and because this is what Agg is designed for.
>
> Can you explain what you mean by "picture detail is lost in the unmultiply
> alphas stage". There is the usual problem that by premultiplying you lose
> any color data where alpha = 0 (and you lose resolution everywhere else, but
> not resolution you can actually see after compositing).
>>
>> So long as matplotlib is using only a subset of agg algorithms that
>> work no matter whether the alphas are premultiplied or not, I would
>> think that the most reasonable route was the one that I took; to
>> always pass straight alphas (sticking with pipeline [1]), and modify
>> the agg source slightly to fit matplotlib's approach (i.e., remove the
>> clipping there).
>
> I'd be really wary of modifying agg like this. Those things become hard to
> maintain. I think this instead a bug in matplotlib and should be fixed
> there.
>
> I've put an issue in the issue tracker here:
>
> https://github.com/matplotlib/matplotlib/issues/545
>
> Cheers,
> Mike
>
>> I hope that I'm not way off base (I have a sneaking feeling that I am
>> :O ), and hope this helps. I've verified on both Linux and Windows
>> that removing the alpha-clip lines from agg_span_image_filter_rgba.h,
>> rebuilding matplotlib, and replacing _image.so/_image.pyd and
>> _backend_agg.so/_backend_agg.pyd does the trick (along with passing
>> straight alphas). So far, I've seen no ill effects on any of my
>> plots, but I'm also not in a position to run the pixel-by-pixel
>> comparison matplotlib tests.
>>
>>
>> On Wed, Oct 19, 2011 at 7:26 PM, Daniel Hyams<dh...@gm...> wrote:
>>>
>>> There has to be something else in play here. I'll try to keep this
>>> short, but the summary is this: I can get the transparency to look
>>> right, but only if 1) I put "straight" alpha in image, not
>>> premultiplied, and 2) I hack agg to remove specificially every
>>> instance of the lines of code that you refer to above.
>>>
>>> Why this is, I don't know. Hopefully I'm still misusing something.
>>> However, it behaves as if the clipping of alpha in the agg library is
>>> corrupting the alpha channel. I also submit that I could have broken
>>> some other transparency capabilities of matplotlib, because I don't
>>> know what other routines use what I hacked....I did check a few
>>> transparent polygons and such though, and everything seemed to be
>>> fine.
>>>
>>> I know that the agg library has been around for quite a long time, so
>>> that also means that such a basic bug is unlikely.
>>>
>>> I've reattached the (slightly modified) script that reproduces the
>>> problem, along with a sample image that it uses. The only change to
>>> the script is right at the top, where a different image is read, a
>>> quick statement is placed to add an alpha channel if there is not
>>> already one, and I'm attempting to use premultiplied alphas. I've
>>> also attached a screenshot of the output. Notice that in this case,
>>> both "transparent" images look wrong.
>>>
>>> Now, if I 1) hack agg to remove the alpha clipping, and 2) modify the
>>> one line in the attached python script so that I use straight alpha,
>>> everything looks right. Specifically, I removed every instance of the
>>> code below from xxxx, rebuilt all of the matplotlib .so's, and
>>> specifically replaced _image.so and _backend_agg.so in my matplotlib
>>> distribution.
>>>
>>>      if(fg[order_type::A]> base_mask)     fg[order_type::A]
>>> = base_mask;
>>>        if(fg[order_type::R]> fg[order_type::A])
>>> fg[order_type::R] = fg[order_type::A];
>>>        if(fg[order_type::G]> fg[order_type::A])
>>> fg[order_type::G] = fg[order_type::A];
>>>        if(fg[order_type::B]> fg[order_type::A])
>>> fg[order_type::B] = fg[order_type::A];
>>>
>>>
>>>
>>>
>>> On Wed, Oct 19, 2011 at 2:34 PM, Daniel Hyams<dh...@gm...> wrote:
>>>>
>>>> Ah, thanks so much Michael! That explanation helps a great deal; I
>>>> was always considering things in "straight alpha" format, not even
>>>> knowing that there was alternative.
>>>>
>>>> I'll play with this tonight; I don't see any problem getting the thing
>>>> working, though, now that I know what agg expects to see...
>>>>
>>>> And yes, alpha support in the image class would be very helpful ;)
>>>>
>>>> On Wed, Oct 19, 2011 at 2:16 PM, Michael Droettboom<md...@st...>
>>>> wrote:
>>>>>
>>>>> You are right that Agg is doing the resizing here. Agg expects
>>>>> premultiplied alpha. See [1] for information about what that means.
>>>>>
>>>>> [1] http://en.wikipedia.org/wiki/Alpha_compositing
>>>>>
>>>>> After Agg interpolates the pixel values, to prevent oversaturation it
>>>>> truncates all values to be less than alpha (which makes sense if
>>>>> everything
>>>>> is assumed to be premultiplied alpha). Arguably, the bug here is that
>>>>> nearest neighbor (which doesn't have to do any blending) doesn't
>>>>> perform the
>>>>> truncation step -- then both would look "wrong".
>>>>>
>>>>> It happens in this code snippet in span_image_filter_rgba: (base_mask
>>>>> is
>>>>> 255)
>>>>>
>>>>>         if(fg[order_type::A]> base_mask)
>>>>> fg[order_type::A]
>>>>> = base_mask;
>>>>>         if(fg[order_type::R]> fg[order_type::A])
>>>>> fg[order_type::R]
>>>>> = fg[order_type::A];
>>>>>         if(fg[order_type::G]> fg[order_type::A])
>>>>> fg[order_type::G]
>>>>> = fg[order_type::A];
>>>>>         if(fg[order_type::B]> fg[order_type::A])
>>>>> fg[order_type::B]
>>>>> = fg[order_type::A];
>>>>>
>>>>> So, the solution to make a partially transparent image is to not do:
>>>>>
>>>>>   pix[:,:,3] = 127
>>>>>
>>>>> but instead, do
>>>>>
>>>>>   pix *= 0.5
>>>>>
>>>>> Of course, the real fix here is to support alpha blending properly in
>>>>> the
>>>>> image class, then the user wouldn't have to deal with such details. A
>>>>> bug
>>>>> should probably be filed in the matplotlib issue tracker for this.
>>>>>
>>>>> Mike
>>>>>
>>>>> On 10/19/2011 12:23 PM, Daniel Hyams wrote:
>>>>>
>>>>> [Sorry, I keep getting tripped up with HTML mail....resent in ascii,
>>>>> and resaved one of the attachment png's to make it smaller.]
>>>>>
>>>>>
>>>>> Example script attached (PIL required). Basically, if I impose a
>>>>> specific value into an image's alpha channel and use any interpolation
>>>>> scheme other than 'nearest', there appears gray all where the figure
>>>>> didn't have any color to begin with.  I've also attached a screenshot
>>>>> of the output of the script on my machine.
>>>>>
>>>>> Hopefully I'm doing something wrongly?
>>>>>
>>>>> I chased the problem and managed to hack in a solution that fixes the
>>>>> problem, but it's extremely inefficient...basically, in matplotlib's
>>>>> image.py, routine BboxImage.make_image, you can create two images
>>>>> there....one with no alpha channel (call it imRGB) and one with (call
>>>>> it imRGBA). Go through all of the routine, doing exactly the same
>>>>> things to both of the images *except* for the interpolation, which is
>>>>> set to 'nearest' for imRGBA. Then, rip the colors out of imRGB, the
>>>>> alpha channel off of imRGBA, and put them together....go through all
>>>>> of the routine again with this composited image, and it works. I
>>>>> know...I told you it was bad ;)
>>>>>
>>>>> The problem seems to be in the "resize" call in that routine...resize,
>>>>> which calls into C code, does not appear to handle things correctly
>>>>> when the alpha is anything other than 255's across the board. It
>>>>> might be a problem in the agg routines, but hopefully it is just maybe
>>>>> a misuse of the agg routines.
>>>>>
>>>>> The behavior seems to be backend independent as far as I could test (I
>>>>> tried with wxagg and tk backends). I am using mpl 1.0.0 on Windows if
>>>>> it matters.
>>>>>
>>>>>
>>>>> --
>>>>> Daniel Hyams
>>>>> dh...@gm...
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> All the data continuously generated in your IT infrastructure contains
>>>>> a
>>>>> definitive record of customers, application performance, security
>>>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>>>> sense of it. Business sense. IT sense. Common sense.
>>>>> http://p.sf.net/sfu/splunk-d2d-oct
>>>>>
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> The demand for IT networking professionals continues to grow, and the
>>>>> demand for specialized networking skills is growing even more rapidly.
>>>>> Take a complimentary Learning@Ciosco Self-Assessment and learn
>>>>> about Cisco certifications, training, and career opportunities.
>>>>> http://p.sf.net/sfu/cisco-dev2dev
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Daniel Hyams
>>>> dh...@gm...
>>>
>>>
>>> --
>>> Daniel Hyams
>>> dh...@gm...
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
-- 
Daniel Hyams
dh...@gm...