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

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

Comments

Projects
None yet
4 participants
@fperez
Member

fperez commented Oct 29, 2011

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)

@fperez fperez referenced this issue Oct 29, 2011

Merged

%config magic #923

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Oct 29, 2011

Member

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

Member

fperez commented Oct 29, 2011

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

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Oct 29, 2011

Member

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.

Member

minrk commented Oct 29, 2011

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.

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Oct 29, 2011

Member

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.

Member

fperez commented Oct 29, 2011

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.

@takluyver

This comment has been minimized.

Show comment
Hide comment
@takluyver

takluyver Oct 29, 2011

Member

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?

Member

takluyver commented Oct 29, 2011

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?

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Oct 29, 2011

Member

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.

Member

fperez commented Oct 29, 2011

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.

@ccordoba12

This comment has been minimized.

Show comment
Hide comment
@ccordoba12

ccordoba12 Nov 4, 2011

Contributor

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

Contributor

ccordoba12 commented Nov 4, 2011

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

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Nov 4, 2011

Member

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.

Member

minrk commented Nov 4, 2011

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.

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Nov 11, 2011

Member

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.

Member

fperez commented Nov 11, 2011

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.

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Nov 11, 2011

Member

Sounds good to me.

Member

minrk commented Nov 11, 2011

Sounds good to me.

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Nov 17, 2011

Member

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.

Member

minrk commented Nov 17, 2011

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment