I have a retina MacBook Pro, and I've noticed that several of the images in IPython need to be updated to higher resolution so that they don't look bad. What I've noticed so far:
The icons in the notebook, including the reload icon on the dashboard and all the toolbar icons in the notebook itself
The IPython icon in the header of the qtconsole
The IPython icon itself from the qtconsole (Note that Mac OS X supports extremely high resolution application icons)
The IPython icon in the quit screen in the qtconsole
The default resolution for inline plots in both the qtconsole and the notebook is too low (this one is probably the most important).
The favicon for the notebook.
Note that you'll need to use Safari to test the notebook, as Chrome doesn't fully support retina graphics yet (Chrome Canary supports retina graphics, but not retina favicons).
This is only based on my little knowledge. Likely there are images and such for features that I don't know about that also need to be updated.
On non-retina Macs, you can test this by using Quartz Debug to increase the scaling to 2x.
Sorry if this seems low priority, but you really have to use a retina device to see just how bad non-retina things look.
The default resolution of plots is also the easiest to deal with, since it's just matplotlib rcParams, and 2x values are completely inappropriate for everyone else. So I don't think that one is going to change for at least the years it takes for pixel-doubled displays to become relatively common.
Well I imagine that retina displays will be much less than relatively common before the low res plots annoy enough people to get you guys to change it :)
I know almost nothing about the code, so I could be wrong here, but I think for the notebook and qtconsole you may need to update something from upstream, if it exists (or in the case of qt, perhaps just wait for an upstream update the supports retina rendering). But again, this is just from a cursory glance at the code, so I could be wrong.
The favicon obviously you have complete control over.
Well I imagine that retina displays will be much less than relatively common before the low res plots annoy enough people to get you guys to change it
But that's the issue - people with exotic environments need to use non-default config, and that config is trivial right now. Until that becomes standard, it makes no sense to change the defaults.
Mostly just a big waste of data. If you want bigger figures, set the figure size to be bigger. One line of config, or one call at runtime. It makes no sense to change defaults to serve a tiny minority to the detriment of everyone else.
I have a retina MacBook Pro, and I've noticed that several of the images in IPython need to be updated to higher resolution so that they don't look bad. What I've noticed so far:
The icons in the notebook, including the reload icon on the dashboard and all the toolbar icons in the notebook itself
Except for IPython notebook , we depend on jQuery for all that.
(maybe they'll switch to a custom font for icon like github does...)
The IPython icon in the header of the qtconsole
The IPython icon itself from the qtconsole (Note that Mac OS X supports extremely high resolution application icons)
The IPython icon in the quit screen in the qtconsole
I can't make much higher resolution than a SVG..we'll have to wait for Qt Update.
I think the only .icns we have (for notebook file icons in 0.14 dev) are 1024x1024
The default resolution for inline plots in both the qtconsole and the notebook is too low (this one is probably the most important).
The favicon for the notebook.
Note that you'll need to use Safari to test the notebook, as Chrome doesn't fully support retina graphics yet (Chrome Canary supports retina graphics, but not retina favicons).
(maybe they'll switch to a custom font for icon like github does...)
Quite a few of the icons are already in unicode.
You are not up to date with your stable version of chrome, it's still hidden in the page ...
Ah. I stopped using the stable version and started using Canary every since I got my new Mac, because I couldn't stand the low res graphics (or the alternative, which is using Safari). And anyway, you still need Canary for the high-res pdf viewer.
I think the only .icns we have (for notebook file icons in 0.14 dev) are 1024x1024
The largest notebook icon that I see (in docs/resources/) appears to only be 512 x 512.
Have fun with your hi-res screen.
Yes, it's pretty awesome, except you notice every low-res graphic on everything (hence my opening this issue).
So I guess the only thing that can actually be done here is the favicon.
I have been unable to figure out how to fix this through config.
The dpi setting of the figure seems to have no effect on the inline-rendered plot.
Compare 72 dpi
with 600 dpi
From web search, I found someone saying that the inline PNG display is hard-coded at 72 dpi to match the qtconsole settings here, and I've found old ipython code that confirms this.
However, I can't find current code that would make this true.
Setting the backend rendering to SVG definitely works, but I'd like to be able to plot millions of points, so that's not a scalable solution.
Please let me know how I can help improve this area.
Looking at low-res graphics on a retina is strangely annoying!
P.S. If anyone has any knowledge of why qtconsole is limited to 72dpi, I'd love to hear it! It looks like crap...
The inline backend sets some of these values at load time (including DPI), since the matplotlib defaults don't work well in the notebook/qtconsole. You can change these overrides to whatever you want in your config files, e.g.:
P.S. If anyone has any knowledge of why qtconsole is limited to 72dpi, I'd love to hear it! It looks like crap...
I don't know that it is limited. This DPI number is totally specific to matplotlib figures, and if I recall it was chosen so that switching between SVG/PNG doesn't change the size of figures in the QtConsole (the notebook didn't even exist when this code was written!)
If Qt supports 2x rendering, then by all means, proceed with pull requests.
Sorry for being thick here, but is there a way to automatically scale down the size of the displayed figure?
With greater DPI it displays proportionally bigger.
PNGs do have a DPI field in their header, but I think browsers simply ignore it (almost everything does). It's also possible that matplotlib doesn't even write this header, given how rarely viewers actually pay any attention.
To display a 2x PNG, you can send it as HTML instead of raw PNG data.
Here's a notebook that hopefully demonstrates how to display 2x figs with IPython. Can you let me know if that looks right?
Yes. There's a noticeable difference between the first plot and the later ones. They appear the same size (except for the one that is supposed to be bigger).
@piti118 are you still working on this? It was next on my todo list, so I can probably get it done fairly quickly. Or I can just do the 'add metadata support' to the display formatters step from my IPEP, which is the more sensitive and pervasive part, and then leave the task of using that logic to get 2x matplotlib figures to you.
I think it's better to leave the core part to you (I do have partial implementation which I could get it done when i'm free.). I like the plan your propose I can do DPR part.
Sounds good - I'll have a PR for the metadata stuff this afternoon, and you can base the matplotlib work on that. I know it can be uncomfortable to work on the bits deep inside IPython.
It's the same in the notebook too, actually, but at least the browser antialiases it.
Probably this is SymPy's fault, because we probably don't specify a bound for the picture, so it just shows it at the normal resolution. How do you specify a bound for the image, so that we can just provide a high resolution version and have it scaled down? (sorry, I didn't actually write the SymPy code, so maybe @Thisch should look here too)
Ah, I was only thinking of the notebook. I don't think we have any plan to do retina enhancements to the qtconsole, most of which limitations I think are really those of Qt itself.
As for images coming from sympy, the main thing is that we have exposed the ability to specify the display size of images. If sympy wants 2x display, it will have to use this - it is not going to be automatic.
Where is the sympy code for image-based output? Does it use _repr_png_? If so, reprs can now return a tuple of the raw data and the metadata, so if you want display size to be other than the natural size, you would do:
Since this is LaTeX, we could also probably display a vector graphic, assuming it is supported everywhere on the pipeline. I think the issue is that LaTeX does well with formats like pdf and dvi and browsers do well with formats like svg. Maybe @Thisch has an idea.
Activity
asmeurer commented on Aug 1, 2012
Another thing to note: Safari apparently smooths out low resolution graphics (i.e., the toolbar buttons) and Chrome does not.
minrk commented on Aug 2, 2012
The default resolution of plots is also the easiest to deal with, since it's just matplotlib rcParams, and 2x values are completely inappropriate for everyone else. So I don't think that one is going to change for at least the years it takes for pixel-doubled displays to become relatively common.
I expect a Pull Request with 2x assets :)
asmeurer commented on Aug 2, 2012
Well I imagine that retina displays will be much less than relatively common before the low res plots annoy enough people to get you guys to change it :)
I know almost nothing about the code, so I could be wrong here, but I think for the notebook and qtconsole you may need to update something from upstream, if it exists (or in the case of qt, perhaps just wait for an upstream update the supports retina rendering). But again, this is just from a cursory glance at the code, so I could be wrong.
The favicon obviously you have complete control over.
minrk commented on Aug 2, 2012
But that's the issue - people with exotic environments need to use non-default config, and that config is trivial right now. Until that becomes standard, it makes no sense to change the defaults.
asmeurer commented on Aug 2, 2012
I wonder if it would be possible to change it dynamically. Is it possible to determine if a monitor is using 2x assets with javascript?
Is the issue that rendering plots with double resolution would be computationally expensive?
minrk commented on Aug 2, 2012
Mostly just a big waste of data. If you want bigger figures, set the figure size to be bigger. One line of config, or one call at runtime. It makes no sense to change defaults to serve a tiny minority to the detriment of everyone else.
Carreau commented on Aug 2, 2012
Except for IPython notebook , we depend on jQuery for all that.
(maybe they'll switch to a custom font for icon like github does...)
I can't make much higher resolution than a SVG..we'll have to wait for Qt Update.
I think the only .icns we have (for notebook file icons in 0.14 dev) are 1024x1024
You are not up to date with your stable version of chrome, [it's still hidden in the page](http://chrome.blogspot.fr/2012/07/new-senses-for-web.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+blogspot/Egta+(Google+Chrome+Blog) ...
If you want to make a PR that fixes some of that...
Have fun with your hi-res screen.
asmeurer commented on Aug 2, 2012
Quite a few of the icons are already in unicode.
Ah. I stopped using the stable version and started using Canary every since I got my new Mac, because I couldn't stand the low res graphics (or the alternative, which is using Safari). And anyway, you still need Canary for the high-res pdf viewer.
The largest notebook icon that I see (in docs/resources/) appears to only be 512 x 512.
Yes, it's pretty awesome, except you notice every low-res graphic on everything (hence my opening this issue).
So I guess the only thing that can actually be done here is the favicon.
sergeyk commented on Aug 8, 2012
I have been unable to figure out how to fix this through config.

The dpi setting of the figure seems to have no effect on the inline-rendered plot.
Compare 72 dpi
with 600 dpi
From web search, I found someone saying that the inline PNG display is hard-coded at 72 dpi to match the qtconsole settings here, and I've found old ipython code that confirms this.
However, I can't find current code that would make this true.
Setting the backend rendering to SVG definitely works, but I'd like to be able to plot millions of points, so that's not a scalable solution.
Please let me know how I can help improve this area.
Looking at low-res graphics on a retina is strangely annoying!
P.S. If anyone has any knowledge of why qtconsole is limited to 72dpi, I'd love to hear it! It looks like crap...
minrk commented on Aug 8, 2012
DPI is just matplotlib config:
The inline backend sets some of these values at load time (including DPI), since the matplotlib defaults don't work well in the notebook/qtconsole. You can change these overrides to whatever you want in your config files, e.g.:
or change the matplotlib rc directly at any time.
I don't know that it is limited. This DPI number is totally specific to matplotlib figures, and if I recall it was chosen so that switching between SVG/PNG doesn't change the size of figures in the QtConsole (the notebook didn't even exist when this code was written!)
If Qt supports 2x rendering, then by all means, proceed with pull requests.
sergeyk commented on Aug 8, 2012
Sorry for being thick here, but is there a way to automatically scale down the size of the displayed figure?
With greater DPI it displays proportionally bigger.
minrk commented on Aug 9, 2012
PNGs do have a DPI field in their header, but I think browsers simply ignore it (almost everything does). It's also possible that matplotlib doesn't even write this header, given how rarely viewers actually pay any attention.
To display a 2x PNG, you can send it as HTML instead of raw PNG data.
Here's a notebook that hopefully demonstrates how to display 2x figs with IPython. Can you let me know if that looks right?
the source
asmeurer commented on Aug 9, 2012
Looks good to me.
minrk commented on Aug 9, 2012
Thanks, the 2x figures actually look sharper? I don't want to deal with
logging in/out to test with HiDPI mode.
asmeurer commented on Aug 9, 2012
Yes. There's a noticeable difference between the first plot and the later ones. They appear the same size (except for the one that is supposed to be bigger).
37 remaining items
minrk commented on Apr 16, 2013
@piti118 are you still working on this? It was next on my todo list, so I can probably get it done fairly quickly. Or I can just do the 'add metadata support' to the display formatters step from my IPEP, which is the more sensitive and pervasive part, and then leave the task of using that logic to get 2x matplotlib figures to you.
piti118 commented on Apr 16, 2013
I think it's better to leave the core part to you (I do have partial implementation which I could get it done when i'm free.). I like the plan your propose I can do DPR part.
minrk commented on Apr 16, 2013
Sounds good - I'll have a PR for the metadata stuff this afternoon, and you can base the matplotlib work on that. I know it can be uncomfortable to work on the bits deep inside IPython.
minrk commented on Jul 4, 2013
closed by #3381.
asmeurer commented on Jul 4, 2013
Images still look bad in the qtconsole. Take for example
in the development version of SymPy (make sure you have LaTeX installed). I increased the resolution, but that just made the image bigger :(
asmeurer commented on Jul 4, 2013
It's the same in the notebook too, actually, but at least the browser antialiases it.
Probably this is SymPy's fault, because we probably don't specify a bound for the picture, so it just shows it at the normal resolution. How do you specify a bound for the image, so that we can just provide a high resolution version and have it scaled down? (sorry, I didn't actually write the SymPy code, so maybe @Thisch should look here too)
minrk commented on Jul 4, 2013
Ah, I was only thinking of the notebook. I don't think we have any plan to do retina enhancements to the qtconsole, most of which limitations I think are really those of Qt itself.
As for images coming from sympy, the main thing is that we have exposed the ability to specify the display size of images. If sympy wants 2x display, it will have to use this - it is not going to be automatic.
asmeurer commented on Jul 4, 2013
What is that API? All I see are changes to Image.
asmeurer commented on Jul 4, 2013
And regarding retina qtconsole, could we at least have an open issue for it?
minrk commented on Jul 4, 2013
Where is the sympy code for image-based output? Does it use _repr_png_? If so, reprs can now return a tuple of the raw data and the metadata, so if you want display size to be other than the natural size, you would do:
Sure, #3537.
asmeurer commented on Jul 4, 2013
https://github.com/sympy/sympy/blob/master/sympy/interactive/printing.py#L130 (comments on any part of that file welcome, actually). The resolution is set at https://github.com/sympy/sympy/blob/master/sympy/interactive/printing.py#L45. I'd like to make that twice as large and scale it down, so that it is always its current size but high resolution on a retina screen.
asmeurer commented on Jul 4, 2013
Since this is LaTeX, we could also probably display a vector graphic, assuming it is supported everywhere on the pipeline. I think the issue is that LaTeX does well with formats like pdf and dvi and browsers do well with formats like svg. Maybe @Thisch has an idea.
use display instead of send_figure in inline backend hooks
Merge pull request ipython#2271 from minrk/display_send_figure