Skip to content
This repository

Decide the default image format for inline figures: SVG or PNG? #944

Closed
fperez opened this Issue October 29, 2011 · 10 comments

4 participants

Fernando Perez Min RK Thomas Kluyver Carlos Cordoba
Fernando Perez
Owner

Pros of PNG:

  • rendering is all done by matplotlib, so no issues with client-side rendering (the Qt SVG renderer doesn't support path clipping, for example, so it shows lines outside of the figure axes in zoomed figures).

Cons of PNG:

  • xhtml save with images only works with svg
  • it's a bitmap, not vector format, so image resolution is limited to that of the original render.

My suggestion would be for to make SVG the default from now on, but for the qt console to manually set kernels it starts to use png to avoid the clipping bug. If users do want SVG in the qt console, they can configure it themselves (which means that the qt console would need to set it to PNG only if the user hasn't set it)

Fernando Perez
Owner

@minrk, we can pick up here the format discussion from #923.

Min RK
Owner

PNG is also generally more predictable - SVG renderers in browsers are definitely better than Qt's (which is quite bad), but they are not perfect, nor are they reliably identical to each other.

There is also the option of sending multiple versions at the same time. This is obviously duplication of data, and increased network traffic, but it would allow better embedding of figures, especially in the notebook, where the right answer could be any of PNG/PDF/SVG/etc. for export, while the display format should be something else. This is already true for Qt, where PNG is definitely the right display format, but having SVG around as well would mean that the XHTML export would still work.

Fernando Perez
Owner

Sending multiple copies is a good idea, as long as it's completely optional: the added overhead can be truly significant, as it's not just sending more data, it's also calling two completely separate rendering passes in MPL, which can be expensive.

Thomas Kluyver
Collaborator

I remember at some point there was discussion about some way of having interactive, zoomable & slidable versions of graphs embedded. I take it that's still something for the future?

Fernando Perez
Owner

Most certainly!!! The two 'big things' on the notebook plans are full/clean reST/sphinx integration and interactive widgets. In fact, we'd like to go beyond plots and have something akin to Sage's @interact but with a model more closely based on Traits and our own display protocols. But that's a larger job, so it's quite likely that someone will add as an intermediate step support for matplotlib pan/zoom interactivity and basic event handling, with a full architecture for arbitrary widgets in the future.

Carlos Cordoba

The html5 matplotlib backend would be perfect for this, @takluyver. Would it be too hard to have integrated with the notebook?

Min RK
Owner

Yes, that would indeed be very cool. We would need to figure some things out, because, for instance, it cannot be guaranteed that the browser can have a direct connection to the kernel, so we would have to relay the websocket connection through the notebook server.

Fernando Perez
Owner

I've made some tests with more complex figures (large networkx directed graphs visualized with FancyArrow patches) and I'm finding that the SVG quality isn't really up to par. So it seems to me the best course of action would be to just leave PNG as our default, the way it is now.

Given the new %config magic makes it so easy to change this for users on a per-notebook basis, by simply putting

%config InlineBackend.figure_format = 'svg'

I don't think we need to do anything else.

If nobody disagrees in a day or so, I'll close this issue leaving PNG as our default the way it is now.

Min RK
Owner
Min RK
Owner

Closing this as resolved, as suggested by @fperez above. PNG is more reliable and better behaved, and switching to SVG is easy enough with the new %config magic.

Min RK minrk closed this November 17, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.