Skip to content

Image comparison errors on Linux 32-bit #6604

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
matthew-brett opened this issue Jun 18, 2016 · 7 comments
Closed

Image comparison errors on Linux 32-bit #6604

matthew-brett opened this issue Jun 18, 2016 · 7 comments

Comments

@matthew-brett
Copy link
Contributor

I'm testing 32-bit manylinux wheels for matplotlib 2.0.0b1. I'm building with export MPLLOCALFREETYPE=1. All the tests are passing on 64-bit:

https://s3.amazonaws.com/archive.travis-ci.org/jobs/138543116/log.txt

But - I'm getting lots of small RMS image differences when testing the 32-bit wheel:

https://s3.amazonaws.com/archive.travis-ci.org/jobs/138543118/log.txt

I guess this is due to small differences in freetype results on 32- and 64-bit? Can y'all suggest a good way to work round this?

@tacaswell tacaswell added this to the 2.0 (style change major release) milestone Jun 20, 2016
@tacaswell
Copy link
Member

Can you get access to any of the output?

I do not think we regularly test on 32bit linux, but we do test on 32bit windows which pass.

The easiest way to work around this would be to add a global flag to the tests to set the error 'floor'.

@matthew-brett
Copy link
Contributor Author

Hmm - looking at the log - it seems that there are some differences that are pretty large.

I tried doing a minimal install and test into another Docker container, so:

docker run -ti --rm -v $PWD:/io f69m/ubuntu32:14.04 /bin/bash

Then:

source /io/test_mpl_32.sh

Where test_mpl_32.sh is:

apt-get update
apt-get install -y pkg-config git libpng-dev libz-dev
apt-get install -y python3-dev python3-numpy python3-pip
git clone https://github.com/matplotlib/matplotlib.git
export MPLLOCALFREETYPE=1
cd matplotlib
pip3 install -e .
pip3 install nose mock
python3 tests.py -sv >& test.log

Log and images at : http://nipy.bic.berkeley.edu/scipy_installers/tmp/

@tacaswell
Copy link
Member

Some of these failures look pretty cool:

image

Some of these looks like there are big solid regions where the difference in numerical errors between the 32bit and 64bit are flipping it from one bin to the next in the color mapping.

@QuLogic
Copy link
Member

QuLogic commented Jun 22, 2016

The worst tests are specgram:

  • test_axes/specgram_freqs_linear.png : 8.915
  • test_axes/specgram_freqs.png : 8.915
  • test_axes/specgram_magnitude_freqs_linear.png : 8.912
  • test_axes/specgram_magnitude_freqs.png : 8.912
  • test_axes/specgram_angle_freqs.png : 2.87

followed by two date/time things:

  • test_axes/date_timezone_x_and_y.png : 3.041
  • test_axes/single_date.png : 1.969

and the rest are less than 1.

@WeatherGod
Copy link
Member

I am not surprised about specgram failures, as that is highly sensitive to
numerical accuracy, and they were problematic ones when getting the 32-bit
Windows tests passing as well. So, I would be in favor of bumping the
tolerances for them.

The others... I don't know why they would be problematic.

On Tue, Jun 21, 2016 at 10:32 PM, Elliott Sales de Andrade <
notifications@github.com> wrote:

The worst tests are specgram:

  • test_axes/specgram_freqs_linear.png : 8.915
  • test_axes/specgram_freqs.png : 8.915
  • test_axes/specgram_magnitude_freqs_linear.png : 8.912
  • test_axes/specgram_magnitude_freqs.png : 8.912
  • test_axes/specgram_angle_freqs.png : 2.87 followed by two date/time
    things:
  • test_axes/date_timezone_x_and_y.png : 3.041
  • test_axes/single_date.png : 1.969 and the rest are less than 1.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#6604 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AARy-JKI_o5xDaxH2AqUa-EfxUjypq9kks5qOJ6jgaJpZM4I45Xz
.

@matthew-brett
Copy link
Contributor Author

Many failures still for 2.0.0b4 build : https://s3.amazonaws.com/archive.travis-ci.org/jobs/158666401/log.txt

@QuLogic QuLogic modified the milestones: 2.0.1 (next bug fix release), 2.0 (style change major release) Dec 7, 2016
@QuLogic QuLogic modified the milestones: 2.0.1 (next bug fix release), 2.0.2 (next bug fix release) May 3, 2017
@tacaswell tacaswell modified the milestones: 2.1.1 (next bug fix release), 2.2 (next feature release) Oct 9, 2017
@QuLogic
Copy link
Member

QuLogic commented Jun 3, 2021

As part of building Fedora packages, I introduced some tolerance for 32-bit builds, e.g., #17800. Tests pass there, so I think there's no need to keep this open.

@QuLogic QuLogic closed this as completed Jun 3, 2021
@story645 story645 removed this from the future releases milestone Oct 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants