Skip to content

Properly minimize the rasterized layers #5815

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

Merged
merged 3 commits into from
Jan 9, 2016

Conversation

mdboom
Copy link
Member

@mdboom mdboom commented Jan 8, 2016

Fixes #5814.

mdboom added 2 commits January 8, 2016 12:39
The creation of the bounding box of actual image content is wrong.
@mdboom mdboom added this to the Critical bugfix release (1.5.1) milestone Jan 8, 2016
@mdboom
Copy link
Member Author

mdboom commented Jan 8, 2016

@tacaswell: Your discretion whether to put this on 1.5.1rc or 1.5.2...

r.x2 = std::max(r.x2 + 1, (int)width);
r.y2 = std::max(r.y2 + 1, (int)height);
r.x2 = std::min(r.x2 + 1, (int)width);
r.y2 = std::min(r.y2 + 1, (int)height);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

weird, I can't find when these lines were introduced. Git blame said they were last touched during the CXX refactor, but when I go to that commit, I can't find these lines anywhere...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It used to be called tostring_rgba_minimized. And actually it looks like it used to have this fix, which got transferred incorrectly in the C++ refactor:

       // Expand the bounds by 1 pixel on all sides
        xmin = std::max(0, xmin - 1);
        ymin = std::max(0, ymin - 1);
        xmax = std::min(xmax, (int)width);
        ymax = std::min(ymax, (int)height);

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's with the plus 1's and minus 1's?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The +1 makes sense to me. The -1 I'm not sure, but it's been there forever.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nah, neither of them make sense to me. Instead, I think the -1 shouldn't be there for x1/y1, and instead of +1 on x2/y2, it should be -1 on width/height. Note, I am not entirely certain if the subsequent code assumes 0 or 1-based indexing. I presume it is 0-based.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's zero-based. The range is like a Python slice, where the lower value is inclusive and the upper value is exclusive. Hence the need for +1 on the upper values.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, so the -1's doesn't make sense at all.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, except for the original comment saying that it is trying to expand the bounds on all sides, but doesn't say why

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah -- we could take the -1's out and see what happens to the test suite. Now that we're not doing fuzzy testing, we shouldn't know pretty quickly if it has negative consequences.

@WeatherGod
Copy link
Member

hmm, the failure on 2.7 looks spurious, but it isn't one of the usual suspects (one of the stix tests). Restarted anyway.

@WeatherGod
Copy link
Member

And Travis failed again, but on a completely different test this time. Restarted.

@WeatherGod
Copy link
Member

Hmm, no failures in the Travis tests. Weird, but ok... waiting for appveyor.

@WeatherGod
Copy link
Member

I think this should go into 1.5.1 since it fixes a pretty bad error, but I'll let @tacaswell decide if it is worth putting out a rc2 for.

@tacaswell
Copy link
Member

👍 to putting this in 1.5.1 👎 on needing an rc2.

@efiring
Copy link
Member

efiring commented Jan 8, 2016

On 2016/01/08 9:45 AM, Thomas A Caswell wrote:

👍 to putting this in 1.5.1 👎 on needing an rc2.

Agreed!

@WeatherGod
Copy link
Member

appveyor failed with weird errors. I don't think I have the ability to restart them.

tacaswell added a commit that referenced this pull request Jan 9, 2016
Properly minimize the rasterized layers
@tacaswell tacaswell merged commit 90455d8 into matplotlib:master Jan 9, 2016
tacaswell added a commit to tacaswell/matplotlib that referenced this pull request Jan 9, 2016
…layer

Properly minimize the rasterized layers
Conflicts:
	lib/matplotlib/tests/test_image.py

One too-many tests where cherry-picked
tacaswell added a commit to tacaswell/matplotlib that referenced this pull request Jan 9, 2016
…layer

Properly minimize the rasterized layers
Conflicts:
	lib/matplotlib/tests/test_image.py

One too-many tests were cherry-picked
tacaswell added a commit that referenced this pull request Jan 10, 2016
Merge pull request #5815 from mdboom/fix-minimizing-raster-layer
@tacaswell
Copy link
Member

backported via PR + 2 commits as ac8cfb3 in #5817

@tomspur
Copy link
Contributor

tomspur commented Jan 12, 2016

With the current master, I get 4 failures and git bisect blames the latest commit in this pull request.
One example is matplotlib.testing.decorators.test_surface3d.test and the difference of the expected and generated picture looks like:
surface3d_svg-failed-diff
It seems the right end side of the image is not cropped correctly.

The other failing tests are:

  • matplotlib.tests.test_streamplot.test_colormap
  • matplotlib.tests.test_image.test_rasterize_dpi
  • matplotlib.tests.test_bbox_tight.test_bbox_inches_tight_raster

The following "patch" would fix the first two failing tests, but the other two tests are not 100% identical and still fail:

diff --git a/src/_backend_agg.cpp b/src/_backend_agg.cpp
index e472156..3b9742a 100644
--- a/src/_backend_agg.cpp
+++ b/src/_backend_agg.cpp
@@ -210,10 +210,10 @@ agg::rect_i RendererAgg::get_content_extents()
         }
     }

-    r.x1 = std::max(0, r.x1);
-    r.y1 = std::max(0, r.y1);
-    r.x2 = std::min(r.x2 + 1, (int)width);
-    r.y2 = std::min(r.y2 + 1, (int)height);
+    r.x1 = std::max(0, r.x1 - 1);
+    r.y1 = std::max(0, r.y1 - 1);
+    r.x2 = std::min(r.x2 + 2, (int)width);
+    r.y2 = std::min(r.y2 + 2, (int)height);

     return r;
 }

Do you know, why/how this test could fail here (on Fedora), but not on travis? What else could I do to help debugging this?

@tacaswell
Copy link
Member

Is this before or after #5834 went in?

Which formats are failing? If it is all svg, part of the issue may be the rasterization via inkscape.

@tomspur
Copy link
Contributor

tomspur commented Jan 12, 2016

The latest commit from #5834 (and the whole v1.5.x branch) seems to work just fine.
Yet, the problem is in the master branch and all failing tests are indeed svg.

@tacaswell
Copy link
Member

Oh, we need to merge 1.5.x back into master.

On Tue, Jan 12, 2016 at 5:42 PM Thomas Spura notifications@github.com
wrote:

The latest commit from #5834
#5834 (and the whole
v1.5.x branch) seems to work just fine.
Yet, the problem is in the master branch and all failing tests are indeed
svg.


Reply to this email directly or view it on GitHub
#5815 (comment)
.

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

Successfully merging this pull request may close these issues.

5 participants