matplotlib-devel Mailing List for matplotlib

I'm stumped. It looks like the code (and even the inputs to 
draw_text_image) are virtually identical, modulo the differences between 
Agg 2.3 and 2.4. Maybe the change is in Agg, and 2.4 is theoretically 
more correct? We can always experiment with different kernels and 
parameters until finding one that looks right.
Cheers,
Mike
John Hunter wrote:
> On Fri, Apr 25, 2008 at 1:08 PM, Michael Droettboom <md...@st...> wrote:
> 
>> They don't look non-antialiased to me (in your attachment or a file I
>> generated locally). Remember, the rotation happens in raster (not vector)
>> space, because that was the path of least resistance, but is a bit of a
>> hack.
>>
>> The difference is that the trunk appears slightly darker than 0.91.x. (And
>> 0.90.x, if I recall correctly, didn't support non-90 degree rotations of
>> text at all). 0.91.x is using spline36 interpolation, trunk is using
>> spline16. I *think* I changed it because I thought spline16 looked slightly
>> cleaner (though technically less accurate), and of course is faster, but I'm
>> not sure anymore -- SVN blame isn't helping me remember. It could have just
>> been the example I was using at the time looked better.
>>
>> In any case, you should be able to change this line in
>> _backend_agg.cpp:2197
>>
>> filter.calculate(agg::image_filter_spline16());
>>
>> to any of the interpolation kernels that Agg offers, and experiment until
>> you find something suitable.
>> 
>
> Hmm, I tried setting the interpolation back to what it is on the
> branch, but this doesn't explain it. If you run
>
> t = text(0.5, 0.5, 'hi mom', fontsize=20)
> t.set_rotation(30); draw()
>
> and save the results from the trunk and the branch (using
> agg::image_filter_spline36) on both, it appears (as you say) that the
> font weight is darker for rotated text, but not for non-rotated text.
>
> JDH
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Fri, Apr 25, 2008 at 1:08 PM, Michael Droettboom <md...@st...> wrote:
> They don't look non-antialiased to me (in your attachment or a file I
> generated locally). Remember, the rotation happens in raster (not vector)
> space, because that was the path of least resistance, but is a bit of a
> hack.
>
> The difference is that the trunk appears slightly darker than 0.91.x. (And
> 0.90.x, if I recall correctly, didn't support non-90 degree rotations of
> text at all). 0.91.x is using spline36 interpolation, trunk is using
> spline16. I *think* I changed it because I thought spline16 looked slightly
> cleaner (though technically less accurate), and of course is faster, but I'm
> not sure anymore -- SVN blame isn't helping me remember. It could have just
> been the example I was using at the time looked better.
>
> In any case, you should be able to change this line in
> _backend_agg.cpp:2197
>
> filter.calculate(agg::image_filter_spline16());
>
> to any of the interpolation kernels that Agg offers, and experiment until
> you find something suitable.
Hmm, I tried setting the interpolation back to what it is on the
branch, but this doesn't explain it. If you run
t = text(0.5, 0.5, 'hi mom', fontsize=20)
t.set_rotation(30); draw()
and save the results from the trunk and the branch (using
agg::image_filter_spline36) on both, it appears (as you say) that the
font weight is darker for rotated text, but not for non-rotated text.
JDH

They don't look non-antialiased to me (in your attachment or a file I 
generated locally). Remember, the rotation happens in raster (not 
vector) space, because that was the path of least resistance, but is a 
bit of a hack.
The difference is that the trunk appears slightly darker than 0.91.x. 
(And 0.90.x, if I recall correctly, didn't support non-90 degree 
rotations of text at all). 0.91.x is using spline36 interpolation, 
trunk is using spline16. I *think* I changed it because I thought 
spline16 looked slightly cleaner (though technically less accurate), and 
of course is faster, but I'm not sure anymore -- SVN blame isn't helping 
me remember. It could have just been the example I was using at the 
time looked better.
In any case, you should be able to change this line in _backend_agg.cpp:2197
 filter.calculate(agg::image_filter_spline16());
to any of the interpolation kernels that Agg offers, and experiment 
until you find something suitable.
Cheers,
Mike
John Hunter wrote:
> On the trunk, it appears that font anti-aliasing is turned off on
> rotated text, as in this example:
>
> n [26]: import datetime
>
> In [27]: dt = datetime.date.today()
>
> In [28]: dates = [dt-datetime.timedelta(days=i) for i in range(10)]
>
> In [29]: plot(dates, range(10))
> Out[29]: [<matplotlib.lines.Line2D object at 0x98f96ac>]
>
> # after rotation the fonts are pixelated
> In [34]: gcf().autofmt_xdate ()
>
> In [35]: draw()
> 
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save 100ドル. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On the trunk, it appears that font anti-aliasing is turned off on
rotated text, as in this example:
n [26]: import datetime
In [27]: dt = datetime.date.today()
In [28]: dates = [dt-datetime.timedelta(days=i) for i in range(10)]
In [29]: plot(dates, range(10))
Out[29]: [<matplotlib.lines.Line2D object at 0x98f96ac>]
# after rotation the fonts are pixelated
In [34]: gcf().autofmt_xdate ()
In [35]: draw()

On Thursday 24 April 2008 10:45:33 pm John Hunter wrote:
> On Thu, Apr 24, 2008 at 9:23 PM, Darren Dale <dar...@co...> 
wrote:
> > I have been developing a data acquisition and analysis program for my
> > lab, and we are actually in the process of using it it this week and next
> > to run experiments with our visiting scientists. I've been running
> > matplotlib from svn for as long as I can remember and hadn't anticipated
> > trouble. I guess I just wasn't reading the dev list closely enough since
> > I rely on the trunk for daily use.
>
> I can appreciate that you are in production mode and have very little
>
> of any time for distraction, but if you get a minute try:
> > svn co http://svn.scipy.org/svn/numpy/trunk numpy
> > cd numpy/
> > python setup.py build
> > sudo python setup.py install
>
> Make sure you "rm -rf build" your mpl build dir and get a clean mpl
> rebuild afterward. I would be very surprised if you encounter any
> troubles. The numpy folks have been doing a tremendous amount of
> work to get svn ready for a 1.1 release, and you owe it to yourself to
> be on the latest.
I think I'm up and running. I'm not sure that the gentoo's lapack and blas 
were recognized, but thats because gentoo does some non standard naming of 
the f77blas. Also, there were a few changes I had to make for my project to 
work with numpy-svn, related to the behavior of ndarray.flat. Hopefully none 
of the other tools I depend on will have much trouble with numpy-1.1.

On Thu, Apr 24, 2008 at 9:23 PM, Darren Dale <dar...@co...> wrote:
> I have been developing a data acquisition and analysis program for my lab, and
> we are actually in the process of using it it this week and next to run
> experiments with our visiting scientists. I've been running matplotlib from
> svn for as long as I can remember and hadn't anticipated trouble. I guess I
> just wasn't reading the dev list closely enough since I rely on the trunk for
> daily use.
I can appreciate that you are in production mode and have very little
of any time for distraction, but if you get a minute try:
 > svn co http://svn.scipy.org/svn/numpy/trunk numpy
 > cd numpy/
 > python setup.py build
 > sudo python setup.py install
Make sure you "rm -rf build" your mpl build dir and get a clean mpl
rebuild afterward. I would be very surprised if you encounter any
troubles. The numpy folks have been doing a tremendous amount of
work to get svn ready for a 1.1 release, and you owe it to yourself to
be on the latest.
JDH

On Thursday 24 April 2008 09:48:18 pm John Hunter wrote:
> On Thu, Apr 24, 2008 at 5:03 PM, Eric Firing <ef...@ha...> wrote:
> > Darren,
> >
> > It is open for discussion. Here are some factors:
> >
> > 1) In my experience, numpy is easy to build from source--easier than
> > matplotlib.
>
> This is my view too -- if you rely on or can build svn mpl, I seen no
> reason why you can't also rely on/build svn numpy since it is a much
> easier build. If mpl builds, numpy svn is pretty much guaranteed to
> build on any platform.
>
> If I am missing something Darren, please let me know, but in my
> regular workflow, I pretty much assume I can bild svn ipython, numpy
> and mpl, and hopefully scipy.
I have been developing a data acquisition and analysis program for my lab, and 
we are actually in the process of using it it this week and next to run 
experiments with our visiting scientists. I've been running matplotlib from 
svn for as long as I can remember and hadn't anticipated trouble. I guess I 
just wasn't reading the dev list closely enough since I rely on the trunk for 
daily use.
Maybe we should consider cutting a transitional prelease at some point before 
additional big changes are made, so those of us who have already transitioned 
our code to the new codebase have a reference build we can install when we 
run into trouble on the trunk?

On Thu, Apr 24, 2008 at 5:03 PM, Eric Firing <ef...@ha...> wrote:
> Darren,
>
> It is open for discussion. Here are some factors:
>
> 1) In my experience, numpy is easy to build from source--easier than
> matplotlib.
This is my view too -- if you rely on or can build svn mpl, I seen no
reason why you can't also rely on/build svn numpy since it is a much
easier build. If mpl builds, numpy svn is pretty much guaranteed to
build on any platform.
If I am missing something Darren, please let me know, but in my
regular workflow, I pretty much assume I can bild svn ipython, numpy
and mpl, and hopefully scipy.
JDH