matplotlib-devel Mailing List for matplotlib

On 08/13/2010 12:30 PM, Benjamin Root wrote:
>
>
> On Fri, Aug 13, 2010 at 4:43 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     On 08/13/2010 10:35 AM, Benjamin Root wrote:
>      > On Thu, Aug 12, 2010 at 4:46 PM, Eric Firing <ef...@ha...
>     <mailto:ef...@ha...>
>      > <mailto:ef...@ha... <mailto:ef...@ha...>>> wrote:
>      >
>      >     On 08/12/2010 10:40 AM, Benjamin Root wrote:
>      >     [...]
>      > > >
>      > > > >>> mcolor.colorConvertor.to_rgba_array('none')
>      > > > array([], shape=(0, 4), dtype=float64)
>      > > >
>      > > > >>> mcolor.colorConvertor.to_rgba_array(['none'])
>      > > > array([[ 0.,  0.,  0.,  0.]])
>      > > >
>      > > > >>> mcolor.colorConvertor.to_rgba_array('r')
>      > > > array([[ 1.,  0.,  0.,  1.]])
>      > > >
>      > > > Should this be regarded as a bug?
>      > >
>      > >     Yes, 'none' should be handled uniformly by that method.
>      >       Thanks for
>      > >     tracking down actual source of the problem.  Fixing it there
>      >     is the
>      > >     right thing to do.
>      > >
>      > >     Eric
>      > >
>      > >
>      > > I am assuming that we would like this patched in the maintenance
>      >     branch,
>      > > too, right?  Also, because the doc and the output of the
>      > > .to_rgba_array() function is changing, should it be noted in the
>      >     changelog?
>      >
>      >     Yes, bugs should be squashed first in the maintenance branch, and
>      >     svnmerge should be used to propagate the change to the trunk.  If
>      >     to_rgba_array is not treating "none" and ["none"] the same
>     way, that is
>      >     a bug.
>      >
>      >     But... now I'm looking at the to_rgba_array method, and
>     wondering why it
>      >     is specifying that special case handling of "none".  The
>     present code
>      >     implementing that special case is mine, but I suspect I was just
>      >     maintaining legacy behavior, as Darren had added this special
>     case
>      >     explicitly to the docstring long before my code change.
>      >
>      >     So it is looking more complicated than I thought.  I suppose
>     the course
>      >     of action most consistent with the idea of a maintenance
>     branch and a
>      >     trunk would be to put the change in the trunk, since it is
>     changing the
>      >     documented behavior of a key method. Then the choices for the
>      >     maintenance branch would be to work around the behavior, as
>     in Ben
>      >     North's patch, or to do nothing.  If you work around it, I
>     think it will
>      >     require special attention to keep svnmerge from erroneously
>     adding the
>      >     workaround to the trunk the next time svnmerge is run.  So,
>     if you
>      >     choose to do that at all, I would suggest waiting until you
>     are sure how
>      >     to handle that svnmerge aspect; maybe it is documented.
>      >
>      >     Also, with the change to to_rgba_array in the trunk, you will
>     need to do
>      >     some exploration to figure out whether any other code will
>     need to be
>      >     changed to take advantage of it, or to allow for it.  (I may
>     have had a
>      >     reason for maintaining the bizarre legacy behavior the last
>     time I
>      >     changed the code in that method...)
>      >
>      >     Eric
>      >
>      >
>      > I have dug further about this.  I have found that the hist()
>     function,
>      > as well as the bar family of functions are impacted by this issue.
>      > However, for hist(), if you try passing in 'none' for color in
>     the old
>      > version, it errors out saying that it needs some color info.
>       With this
>      > corrected version, it doesn't error, but there are no lines drawn as
>      > well (I have to see if that is another bug).
>      >
>      > The other place where I can see how this fix might cause issues
>     is with
>      > regards to Collections and the classes that derive from that.
>      >
>      > While I certainly think that the current behavior of
>     to_rgba_array() is
>      > wrong, I am starting to get hesitant about changing this because
>     there
>      > might be some sort of fundamental difference between how the backends
>      > are treating "array([], shape=(0, 4), dtype=float64)" and "array([0.,
>      > 0., 0., 0.])".  The first is really easy to use as a "don't draw
>      > anything" whereas the latter isn't that obvious to the backends.
>      >
>      > A particular case where this might cause trouble is for graphics
>     formats
>      > that do not support transparencies.  Because "array([0., 0., 0.,
>     0.])"
>      > is fully transparent black, in formats like eps with a non-black
>      > background, the objects with this color will appear -- although,
>     it is
>      > already possible to do that with bar(..., color=['none']).
>
>     But the ps backend intercepts the 0-alpha value and interprets it as
>     "don't draw at all".  See the _draw_ps method:
>
>              mightstroke = (gc.get_linewidth() > 0.0 and
>                        (len(gc.get_rgb()) <= 3 or gc.get_rgb()[3] != 0.0))
>              stroke = stroke and mightstroke
>              fill = (fill and rgbFace is not None and
>                      (len(rgbFace) <= 3 or rgbFace[3] != 0.0))
>
>     Notice that both stroke and fill are checking for alpha != 0.0.
>
>
> Yeah, well, try out my attached script.  Then view the two files.
> Something is wrong...

Correct--good catch.  It looks I missed the patch draw method when I was 
reworking the handling of alpha.  Let me try to straighten that out in 
the next day or two.

Eric


>
> Ben Root

On Fri, Aug 13, 2010 at 4:43 PM, Eric Firing <ef...@ha...> wrote:

> On 08/13/2010 10:35 AM, Benjamin Root wrote:
> > On Thu, Aug 12, 2010 at 4:46 PM, Eric Firing <ef...@ha...
> > <mailto:ef...@ha...>> wrote:
> >
> >     On 08/12/2010 10:40 AM, Benjamin Root wrote:
> >     [...]
> >      > >
> >      > > >>> mcolor.colorConvertor.to_rgba_array('none')
> >      > > array([], shape=(0, 4), dtype=float64)
> >      > >
> >      > > >>> mcolor.colorConvertor.to_rgba_array(['none'])
> >      > > array([[ 0.,  0.,  0.,  0.]])
> >      > >
> >      > > >>> mcolor.colorConvertor.to_rgba_array('r')
> >      > > array([[ 1.,  0.,  0.,  1.]])
> >      > >
> >      > > Should this be regarded as a bug?
> >      >
> >      >     Yes, 'none' should be handled uniformly by that method.
> >       Thanks for
> >      >     tracking down actual source of the problem.  Fixing it there
> >     is the
> >      >     right thing to do.
> >      >
> >      >     Eric
> >      >
> >      >
> >      > I am assuming that we would like this patched in the maintenance
> >     branch,
> >      > too, right?  Also, because the doc and the output of the
> >      > .to_rgba_array() function is changing, should it be noted in the
> >     changelog?
> >
> >     Yes, bugs should be squashed first in the maintenance branch, and
> >     svnmerge should be used to propagate the change to the trunk.  If
> >     to_rgba_array is not treating "none" and ["none"] the same way, that
> is
> >     a bug.
> >
> >     But... now I'm looking at the to_rgba_array method, and wondering why
> it
> >     is specifying that special case handling of "none".  The present code
> >     implementing that special case is mine, but I suspect I was just
> >     maintaining legacy behavior, as Darren had added this special case
> >     explicitly to the docstring long before my code change.
> >
> >     So it is looking more complicated than I thought.  I suppose the
> course
> >     of action most consistent with the idea of a maintenance branch and a
> >     trunk would be to put the change in the trunk, since it is changing
> the
> >     documented behavior of a key method. Then the choices for the
> >     maintenance branch would be to work around the behavior, as in Ben
> >     North's patch, or to do nothing.  If you work around it, I think it
> will
> >     require special attention to keep svnmerge from erroneously adding
> the
> >     workaround to the trunk the next time svnmerge is run.  So, if you
> >     choose to do that at all, I would suggest waiting until you are sure
> how
> >     to handle that svnmerge aspect; maybe it is documented.
> >
> >     Also, with the change to to_rgba_array in the trunk, you will need to
> do
> >     some exploration to figure out whether any other code will need to be
> >     changed to take advantage of it, or to allow for it.  (I may have had
> a
> >     reason for maintaining the bizarre legacy behavior the last time I
> >     changed the code in that method...)
> >
> >     Eric
> >
> >
> > I have dug further about this.  I have found that the hist() function,
> > as well as the bar family of functions are impacted by this issue.
> > However, for hist(), if you try passing in 'none' for color in the old
> > version, it errors out saying that it needs some color info.  With this
> > corrected version, it doesn't error, but there are no lines drawn as
> > well (I have to see if that is another bug).
> >
> > The other place where I can see how this fix might cause issues is with
> > regards to Collections and the classes that derive from that.
> >
> > While I certainly think that the current behavior of to_rgba_array() is
> > wrong, I am starting to get hesitant about changing this because there
> > might be some sort of fundamental difference between how the backends
> > are treating "array([], shape=(0, 4), dtype=float64)" and "array([0.,
> > 0., 0., 0.])".  The first is really easy to use as a "don't draw
> > anything" whereas the latter isn't that obvious to the backends.
> >
> > A particular case where this might cause trouble is for graphics formats
> > that do not support transparencies.  Because "array([0., 0., 0., 0.])"
> > is fully transparent black, in formats like eps with a non-black
> > background, the objects with this color will appear -- although, it is
> > already possible to do that with bar(..., color=['none']).
>
> But the ps backend intercepts the 0-alpha value and interprets it as
> "don't draw at all".  See the _draw_ps method:
>
>         mightstroke = (gc.get_linewidth() > 0.0 and
>                   (len(gc.get_rgb()) <= 3 or gc.get_rgb()[3] != 0.0))
>         stroke = stroke and mightstroke
>         fill = (fill and rgbFace is not None and
>                 (len(rgbFace) <= 3 or rgbFace[3] != 0.0))
>
> Notice that both stroke and fill are checking for alpha != 0.0.
>

Yeah, well, try out my attached script.  Then view the two files.  Something
is wrong...

Ben Root

On 08/13/2010 10:35 AM, Benjamin Root wrote:
> On Thu, Aug 12, 2010 at 4:46 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     On 08/12/2010 10:40 AM, Benjamin Root wrote:
>     [...]
>      > >
>      > > >>> mcolor.colorConvertor.to_rgba_array('none')
>      > > array([], shape=(0, 4), dtype=float64)
>      > >
>      > > >>> mcolor.colorConvertor.to_rgba_array(['none'])
>      > > array([[ 0.,  0.,  0.,  0.]])
>      > >
>      > > >>> mcolor.colorConvertor.to_rgba_array('r')
>      > > array([[ 1.,  0.,  0.,  1.]])
>      > >
>      > > Should this be regarded as a bug?
>      >
>      >     Yes, 'none' should be handled uniformly by that method.
>       Thanks for
>      >     tracking down actual source of the problem.  Fixing it there
>     is the
>      >     right thing to do.
>      >
>      >     Eric
>      >
>      >
>      > I am assuming that we would like this patched in the maintenance
>     branch,
>      > too, right?  Also, because the doc and the output of the
>      > .to_rgba_array() function is changing, should it be noted in the
>     changelog?
>
>     Yes, bugs should be squashed first in the maintenance branch, and
>     svnmerge should be used to propagate the change to the trunk.  If
>     to_rgba_array is not treating "none" and ["none"] the same way, that is
>     a bug.
>
>     But... now I'm looking at the to_rgba_array method, and wondering why it
>     is specifying that special case handling of "none".  The present code
>     implementing that special case is mine, but I suspect I was just
>     maintaining legacy behavior, as Darren had added this special case
>     explicitly to the docstring long before my code change.
>
>     So it is looking more complicated than I thought.  I suppose the course
>     of action most consistent with the idea of a maintenance branch and a
>     trunk would be to put the change in the trunk, since it is changing the
>     documented behavior of a key method. Then the choices for the
>     maintenance branch would be to work around the behavior, as in Ben
>     North's patch, or to do nothing.  If you work around it, I think it will
>     require special attention to keep svnmerge from erroneously adding the
>     workaround to the trunk the next time svnmerge is run.  So, if you
>     choose to do that at all, I would suggest waiting until you are sure how
>     to handle that svnmerge aspect; maybe it is documented.
>
>     Also, with the change to to_rgba_array in the trunk, you will need to do
>     some exploration to figure out whether any other code will need to be
>     changed to take advantage of it, or to allow for it.  (I may have had a
>     reason for maintaining the bizarre legacy behavior the last time I
>     changed the code in that method...)
>
>     Eric
>
>
> I have dug further about this.  I have found that the hist() function,
> as well as the bar family of functions are impacted by this issue.
> However, for hist(), if you try passing in 'none' for color in the old
> version, it errors out saying that it needs some color info.  With this
> corrected version, it doesn't error, but there are no lines drawn as
> well (I have to see if that is another bug).
>
> The other place where I can see how this fix might cause issues is with
> regards to Collections and the classes that derive from that.
>
> While I certainly think that the current behavior of to_rgba_array() is
> wrong, I am starting to get hesitant about changing this because there
> might be some sort of fundamental difference between how the backends
> are treating "array([], shape=(0, 4), dtype=float64)" and "array([0.,
> 0., 0., 0.])".  The first is really easy to use as a "don't draw
> anything" whereas the latter isn't that obvious to the backends.
>
> A particular case where this might cause trouble is for graphics formats
> that do not support transparencies.  Because "array([0., 0., 0., 0.])"
> is fully transparent black, in formats like eps with a non-black
> background, the objects with this color will appear -- although, it is
> already possible to do that with bar(..., color=['none']).

But the ps backend intercepts the 0-alpha value and interprets it as 
"don't draw at all".  See the _draw_ps method:

         mightstroke = (gc.get_linewidth() > 0.0 and
                   (len(gc.get_rgb()) <= 3 or gc.get_rgb()[3] != 0.0))
         stroke = stroke and mightstroke
         fill = (fill and rgbFace is not None and
                 (len(rgbFace) <= 3 or rgbFace[3] != 0.0))

Notice that both stroke and fill are checking for alpha != 0.0.

All other major backends support alpha explicitly.

>
> What I think we have here is a need for a consistent way to indicate "I
> am never to be drawn" that fits in with the current paradigm of the rgba
> arrays.  Maybe nan in the alpha channel?

I think (95% confidence) that we have already settled on 0 in the alpha 
channel for that, (also zero-linewidth for lines should uniformly block 
drawing of a line) but perhaps had not done so the last time I worked on 
the to_rgba_array method.  But I agree that this needs to be checked in 
the backends, and collections also need to be checked for side-effects 
of the change.  My guess is it will be OK to make the change to 
to_rgba_array in the trunk.  It can be checked fairly well via 
backend_driver.py.

Eric

>
> Ben Root

On Thu, Aug 12, 2010 at 4:46 PM, Eric Firing <ef...@ha...> wrote:

> On 08/12/2010 10:40 AM, Benjamin Root wrote:
> [...]
> >      >
> >      > >>> mcolor.colorConvertor.to_rgba_array('none')
> >      > array([], shape=(0, 4), dtype=float64)
> >      >
> >      > >>> mcolor.colorConvertor.to_rgba_array(['none'])
> >      > array([[ 0.,  0.,  0.,  0.]])
> >      >
> >      > >>> mcolor.colorConvertor.to_rgba_array('r')
> >      > array([[ 1.,  0.,  0.,  1.]])
> >      >
> >      > Should this be regarded as a bug?
> >
> >     Yes, 'none' should be handled uniformly by that method.  Thanks for
> >     tracking down actual source of the problem.  Fixing it there is the
> >     right thing to do.
> >
> >     Eric
> >
> >
> > I am assuming that we would like this patched in the maintenance branch,
> > too, right?  Also, because the doc and the output of the
> > .to_rgba_array() function is changing, should it be noted in the
> changelog?
>
> Yes, bugs should be squashed first in the maintenance branch, and
> svnmerge should be used to propagate the change to the trunk.  If
> to_rgba_array is not treating "none" and ["none"] the same way, that is
> a bug.
>
> But... now I'm looking at the to_rgba_array method, and wondering why it
> is specifying that special case handling of "none".  The present code
> implementing that special case is mine, but I suspect I was just
> maintaining legacy behavior, as Darren had added this special case
> explicitly to the docstring long before my code change.
>

So it is looking more complicated than I thought.  I suppose the course
> of action most consistent with the idea of a maintenance branch and a
> trunk would be to put the change in the trunk, since it is changing the
> documented behavior of a key method. Then the choices for the
> maintenance branch would be to work around the behavior, as in Ben
> North's patch, or to do nothing.  If you work around it, I think it will
> require special attention to keep svnmerge from erroneously adding the
> workaround to the trunk the next time svnmerge is run.  So, if you
> choose to do that at all, I would suggest waiting until you are sure how
> to handle that svnmerge aspect; maybe it is documented.
>
> Also, with the change to to_rgba_array in the trunk, you will need to do
> some exploration to figure out whether any other code will need to be
> changed to take advantage of it, or to allow for it.  (I may have had a
> reason for maintaining the bizarre legacy behavior the last time I
> changed the code in that method...)
>
> Eric
>
>
I have dug further about this.  I have found that the hist() function, as
well as the bar family of functions are impacted by this issue.  However,
for hist(), if you try passing in 'none' for color in the old version, it
errors out saying that it needs some color info.  With this corrected
version, it doesn't error, but there are no lines drawn as well (I have to
see if that is another bug).

The other place where I can see how this fix might cause issues is with
regards to Collections and the classes that derive from that.

While I certainly think that the current behavior of to_rgba_array() is
wrong, I am starting to get hesitant about changing this because there might
be some sort of fundamental difference between how the backends are treating
"array([], shape=(0, 4), dtype=float64)" and "array([0., 0., 0., 0.])".  The
first is really easy to use as a "don't draw anything" whereas the latter
isn't that obvious to the backends.

A particular case where this might cause trouble is for graphics formats
that do not support transparencies.  Because "array([0., 0., 0., 0.])" is
fully transparent black, in formats like eps with a non-black background,
the objects with this color will appear -- although, it is already possible
to do that with bar(..., color=['none']).

What I think we have here is a need for a consistent way to indicate "I am
never to be drawn" that fits in with the current paradigm of the rgba
arrays.  Maybe nan in the alpha channel?

Ben Root

On Fri, Aug 13, 2010 at 1:34 PM, John Hunter <jd...@gm...> wrote:
> On Fri, Aug 13, 2010 at 1:26 PM, Benjamin Root <ben...@ou...> wrote:
>> Found it.  It is solid black.
>
> Not quite:
> In [95]: im = imread('/home/titan/johnh/Downloads/failed-diff-pcolormesh.png').ravel()
>
> In [96]: im.max()
> Out[96]: 0.039215688
>
> In [97]: im.min()
> Out[97]: 0.0
>

Probably we should increase the threshold as Eric suggested, but I
wonder if the different test results we are getting could be due to
PIL version.

In [6]: import Image

In [7]: Image.VERSION
Out[7]: '1.1.7'


JDH

On Fri, Aug 13, 2010 at 1:26 PM, Benjamin Root <ben...@ou...> wrote:
> Found it.  It is solid black.

Not quite:
In [95]: im = imread('/home/titan/johnh/Downloads/failed-diff-pcolormesh.png').ravel()

In [96]: im.max()
Out[96]: 0.039215688

In [97]: im.min()
Out[97]: 0.0

On Fri, Aug 13, 2010 at 12:53 PM, Benjamin Root <ben...@ou...> wrote:

> Where are the difference images saved to?  Or do I have to pass an option to
> matplotlib.test() to generate those?  I only have a directory

FYI, the code is in lib/matplotlib/testing/compare.py, and the diff
images on failure are placed in, for example,
./result_images/test_axes/failed-diff-pcolormesh.png

I am not seeing failures on an ubuntu linux box I just tested on.

JDH

On Fri, Aug 13, 2010 at 12:31 PM, Eric Firing <ef...@ha...> wrote:

> On 08/13/2010 07:20 AM, Benjamin Root wrote:
> > On Fri, Aug 13, 2010 at 12:11 PM, Eric Firing <ef...@ha...
> > <mailto:ef...@ha...>> wrote:
> >
> >     On 08/13/2010 06:20 AM, Benjamin Root wrote:
> >      >
> >      >
> >      > On Thu, Aug 12, 2010 at 3:58 PM, Eric Firing <ef...@ha...
> >     <mailto:ef...@ha...>
> >      > <mailto:ef...@ha... <mailto:ef...@ha...>>> wrote:
> >      >
> >      >     On 08/12/2010 09:56 AM, Benjamin Root wrote:
> >      >
> >      > > Btw, the current set of tests has a failure for testing
> pcolormesh.
> >      > > Wasn't there a change fairly recently to fix a problem with
> >      >     pcolormesh,
> >      > > so that the test image should now be updated?
> >      >
> >      >     Mike did update the images a couple weeks ago, and when I run
> >     the tests,
> >      >     I don't get that failure.  Is it possible that you have not
> >     done a clean
> >      >     rebuild and install since Mike's changes?
> >      >
> >      >     Eric
> >      >
> >      >
> >      > Visually, I can't see the difference between the expected and the
> >      > generated images, but the test system is reporting a RMS of
> >     116.512.  I
> >      > have tried completely clean installs of the trunk version of
> >      > matplotlib.  The same happens for completely clean installs of the
> >      > maintenance branch as well.
> >
> >     This may be a limitation of the test system, then.  I think that
> >     differences in external libraries can cause subtle output
> differences,
> >     triggering a false failure alarm.  Maybe the tolerance needs to be
> >     increased for this particular test.
> >
> >     Eric
> >
> >
> > Or maybe there is a bug in how it is calculating the differences?  I am
> > flipping back and forth between the images in eog and I can't figure out
> > what is different.
> Can you see it in the actual difference png?
>
> If it were a problem in calculating the difference, I would expect it to
> be consistent among systems and to show up in all image comparison tests.
>
> Eric
> >
> > Ben Root
>
>
Where are the difference images saved to?  Or do I have to pass an option to
matplotlib.test() to generate those?  I only have a directory
"result_images" with directories of expected and resulting images.

Ben Root

On 08/13/2010 07:20 AM, Benjamin Root wrote:
> On Fri, Aug 13, 2010 at 12:11 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     On 08/13/2010 06:20 AM, Benjamin Root wrote:
>      >
>      >
>      > On Thu, Aug 12, 2010 at 3:58 PM, Eric Firing <ef...@ha...
>     <mailto:ef...@ha...>
>      > <mailto:ef...@ha... <mailto:ef...@ha...>>> wrote:
>      >
>      >     On 08/12/2010 09:56 AM, Benjamin Root wrote:
>      >
>      > > Btw, the current set of tests has a failure for testing pcolormesh.
>      > > Wasn't there a change fairly recently to fix a problem with
>      >     pcolormesh,
>      > > so that the test image should now be updated?
>      >
>      >     Mike did update the images a couple weeks ago, and when I run
>     the tests,
>      >     I don't get that failure.  Is it possible that you have not
>     done a clean
>      >     rebuild and install since Mike's changes?
>      >
>      >     Eric
>      >
>      >
>      > Visually, I can't see the difference between the expected and the
>      > generated images, but the test system is reporting a RMS of
>     116.512.  I
>      > have tried completely clean installs of the trunk version of
>      > matplotlib.  The same happens for completely clean installs of the
>      > maintenance branch as well.
>
>     This may be a limitation of the test system, then.  I think that
>     differences in external libraries can cause subtle output differences,
>     triggering a false failure alarm.  Maybe the tolerance needs to be
>     increased for this particular test.
>
>     Eric
>
>
> Or maybe there is a bug in how it is calculating the differences?  I am
> flipping back and forth between the images in eog and I can't figure out
> what is different.
Can you see it in the actual difference png?

If it were a problem in calculating the difference, I would expect it to 
be consistent among systems and to show up in all image comparison tests.

Eric
>
> Ben Root

On Fri, Aug 13, 2010 at 12:11 PM, Eric Firing <ef...@ha...> wrote:

> On 08/13/2010 06:20 AM, Benjamin Root wrote:
> >
> >
> > On Thu, Aug 12, 2010 at 3:58 PM, Eric Firing <ef...@ha...
> > <mailto:ef...@ha...>> wrote:
> >
> >     On 08/12/2010 09:56 AM, Benjamin Root wrote:
> >
> >      > Btw, the current set of tests has a failure for testing
> pcolormesh.
> >      > Wasn't there a change fairly recently to fix a problem with
> >     pcolormesh,
> >      > so that the test image should now be updated?
> >
> >     Mike did update the images a couple weeks ago, and when I run the
> tests,
> >     I don't get that failure.  Is it possible that you have not done a
> clean
> >     rebuild and install since Mike's changes?
> >
> >     Eric
> >
> >
> > Visually, I can't see the difference between the expected and the
> > generated images, but the test system is reporting a RMS of 116.512.  I
> > have tried completely clean installs of the trunk version of
> > matplotlib.  The same happens for completely clean installs of the
> > maintenance branch as well.
>
> This may be a limitation of the test system, then.  I think that
> differences in external libraries can cause subtle output differences,
> triggering a false failure alarm.  Maybe the tolerance needs to be
> increased for this particular test.
>
> Eric
>
>
Or maybe there is a bug in how it is calculating the differences?  I am
flipping back and forth between the images in eog and I can't figure out
what is different.

Ben Root

On 08/13/2010 06:20 AM, Benjamin Root wrote:
>
>
> On Thu, Aug 12, 2010 at 3:58 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     On 08/12/2010 09:56 AM, Benjamin Root wrote:
>
>      > Btw, the current set of tests has a failure for testing pcolormesh.
>      > Wasn't there a change fairly recently to fix a problem with
>     pcolormesh,
>      > so that the test image should now be updated?
>
>     Mike did update the images a couple weeks ago, and when I run the tests,
>     I don't get that failure.  Is it possible that you have not done a clean
>     rebuild and install since Mike's changes?
>
>     Eric
>
>
> Visually, I can't see the difference between the expected and the
> generated images, but the test system is reporting a RMS of 116.512.  I
> have tried completely clean installs of the trunk version of
> matplotlib.  The same happens for completely clean installs of the
> maintenance branch as well.

This may be a limitation of the test system, then.  I think that 
differences in external libraries can cause subtle output differences, 
triggering a false failure alarm.  Maybe the tolerance needs to be 
increased for this particular test.

Eric

>
> Ben Root

On Thu, Aug 12, 2010 at 3:58 PM, Eric Firing <ef...@ha...> wrote:

> On 08/12/2010 09:56 AM, Benjamin Root wrote:
>
> > Btw, the current set of tests has a failure for testing pcolormesh.
> > Wasn't there a change fairly recently to fix a problem with pcolormesh,
> > so that the test image should now be updated?
>
> Mike did update the images a couple weeks ago, and when I run the tests,
> I don't get that failure.  Is it possible that you have not done a clean
> rebuild and install since Mike's changes?
>
> Eric
>
>
Visually, I can't see the difference between the expected and the generated
images, but the test system is reporting a RMS of 116.512.  I have tried
completely clean installs of the trunk version of matplotlib.  The same
happens for completely clean installs of the maintenance branch as well.

Ben Root