Made the inline download method a part of the iplot call.
You can initiate it by setting the parameter download_image to True, and providing details about the format, height, width and filename.
Issue right now is that the plots will download each time the notebook is restarted using this method.

Note: This can be applied to other methods later on, could also put the script injection into another function similar to get_plotlyjs

The previous method allowed you to download the plot that was most recently plotted and this wouldn't run when the notebook was rerun.

Demo of the functionality (for Issue #483):

Right now have I have two ways of downloading the plot:

The first way involves adding a few keyword arguments to existing plot and iplot functions, indicating whether or not an image should be downloaded.

• Inline Methods (offline.plot)
  plot_download
• Inline Methods (offline.iplot)
  iplot_download
• The second method will download the image of the most recent plot displayed in your ipython notebook. This will be a new function, and no other existing code/methods will be changed, compared to the previous method.

(offline.download_notebook_image)
notebook_image_download

@jackparmer @cldougl @chriddyp
Which do you think would be the best method for this functionality? Also let me know of any issues/suggestions you guys have regarding these implementations.

You can also find some notebooks to test the functionality here:
https://github.com/yankev/testing/tree/master/offline_download_image

Note: This will only wok in Firefox, the fix for Chrome will come when this fix get's released.

Hey @yankev -
Nice! This looks cool!
I like the explicitness of the first option. Its a single step to get an image for a plot. And I don't have to remember the name of a new function.
I'd also suggest:

• Change download_image kwarg to image
• Don't necessarily have to include a filetype (defaults to PNG) or filename (defaults to plot_image.xyz)
• Once this works, add a Save images offline section here https://plot.ly/python/static-image-export/ and comb back through the StackOverflow and community.plot.ly Q's about this

We may want to print a message also in Jupyter notebook:

For higher resolution images and more export options, try Plotly's online image export server.

I'm worried we're going to get a lot of complaints that the client-side image export is not sufficiently fully featured, because folks don't realize we have also have a full-blown server just for image export.

@theengineear
Changes:
I moved the warnings into the confirm prompt. Also created a function to return the script strings. Also using the single image parameter vs both image and format.

Addressing some concerns:
I think the one second sleep time and now the confirmation box should allow for enough time for the plot to render on screen, and thus downloadImage shouldn't return a blank image. I've tested on some fairly "complicated" plots, and it seems to work. Though there is no guarantee on this one.

I have the condition to check whether the page is loaded before injecting the download script, so on page reloads/re-opening the notebook, the confirm and download prompts shouldn't show up.

I have the condition to check whether the page is loaded before injecting the download script, so on page reloads/re-opening the notebook, the confirm and download prompts shouldn't show up.

Sweet!

Taking a peek right now.

Great! Let's do it! 💃 after you've considered my comments.

@theengineear k, should be good. I put in a neat check to find the the name of the caller of get_image_download_script (reference: http://stackoverflow.com/a/900413/5557105).

@yankev sorry to be a party 💩-er, but I think you should stick with the more straight-forward implementation for inferring who called the function.

If it makes you feel better, you could use no_reload_confirm=True or something instead of iplot vs plot. I think your caller='iplot' implementation was just fine though 😉

@theengineear k seems to be in working shape. Let me know if there's anything else.

Beep, boop, 💃. Nice work!

@theengineear thanks man! This was a super messy one, so many avoidable errors. Thanks for reviewing it!