Skip to content

Restore special casing of grayscale images in PostScript backend. #12871

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
wants to merge 1 commit into from

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Nov 23, 2018

This divides the filesize by ~3 by not storing three identical channels
(e.g. compare the size of

imshow(np.random.rand(255, 255), cmap="gray")
gca().set_axis_off()
savefig("test.ps")

before and after the patch).

Looks like some kind of similar functionality was present before mpl2.0, though with some weird magic factors (https://github.com/matplotlib/matplotlib/pull/5718/files#diff-b465967f537465fec4960b152fa49cffL415), and I stumbled on some vestigial leftovers of it (https://github.com/matplotlib/matplotlib/pull/5718/files#diff-b465967f537465fec4960b152fa49cffL457 where the "image" command comes from)...

No hard numbers but I don't think the performance cost (on non-grayscale images) really matters as we're going to iterate through the array just after to serialize it anyways.

Probably the same thing can be done for the pdf backend -- see grayscale parameter of _writeImg.

PR Summary

PR Checklist

  • Has Pytest style unit tests
  • Code is Flake 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

This divides the filesize by ~3 by not storing three identical channels
(e.g. compare the size of
```
imshow(np.random.rand(255, 255), cmap="gray")
gca().set_axis_off()
savefig("test.ps")
```
before and after the patch).
@jklymak
Copy link
Member

jklymak commented Nov 23, 2018

Does this get tested somehow? Otherwise makes sense to me, unless the performance hit is significant, which I doubt as well...

@QuLogic
Copy link
Member

QuLogic commented Nov 24, 2018

Those factors are luminance conversions.

@anntzer
Copy link
Contributor Author

anntzer commented Nov 24, 2018

Gah, the obvious tests

@check_figures_equal(extensions=["eps"])
def test_grayscale_compression(fig_test, fig_ref):
    # Fully opaque, grayscale images are saved as single channel.  Compare
    # with a non-fully opaque image (by making the an all-white pixel
    # transparent...) which is saved as three different channels.
    t = np.arange(256, dtype="u1").reshape((16, 16))
    rgba = np.stack([t, t, t, np.ones_like(t, "u1") * 0xff], 2)
    fig_ref.subplots().imshow(rgba)
    rgba[-1, -1] = 0
    fig_test.subplots().imshow(rgba)

or

@check_figures_equal(extensions=["eps"])
def test_grayscale_compression(fig_test, fig_ref):
    # Fully opaque, grayscale images are saved as single channel.  Compare with
    # a non-fully opaque image which is saved as three different channels.
    test_data = np.arange(100).reshape((10, 10))
    fig_ref.subplots().imshow(test_data, cmap="gray")
    fig_test.subplots().imshow(test_data, cmap="gray", alpha=.5)

fail (visibly); I guess there's something about gamma correction being applied in one case and not the other by the renderer...

@anntzer anntzer self-assigned this Nov 26, 2018
@anntzer anntzer closed this Nov 26, 2018
@anntzer anntzer mentioned this pull request Sep 3, 2019
6 tasks
@anntzer anntzer deleted the ps-grayscale branch March 20, 2022 13:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants