Closed Godisemo closed 8 years ago
Have you looked at Gadfly? It's supposed to be 'close' to ggplot2. To make this (ggplot2 as backend) happen, an efficient method to call R from julia would be needed.
... and seems to be existing with https://github.com/JuliaStats/RCall.jl
I currently use gadfly, but for publication quality plots I still prefer ggplot2. There seems to be a Julia to R package called Rif.jl, but I have never tried it.
På 25 april 2016 till 12:35:05, Andreas Lobinger (notifications@github.com) skrev:
Have you looked at Gadfly? It's supposed to be 'close' to ggplot2. To make this (ggplot2 as backend) happen, an efficient method to call R from julia would be needed.
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/tbreloff/Plots.jl/issues/201#issuecomment-214257532
Rcall seems to be the continuation of Rif.jl Just for curiosity, what is the publication quality difference between ggplot2 and Gadfly on the same plot? Could you do an example?
Yes the answer is that it could be made into a backend through RCall, but I'm not convinced that it's worth the effort.
I have a feeling that a big draw of ggplot2 is the style (or theme)... Background, grid lines color, etc.
I want thinking a couple weeks ago that it would be really nice to have a 'theme' keyword argument that would change many default values all at once to look like native matplotlib, ggplot2, etc. if this was available, I wonder if you would still care about calling into R.
Please post examples of what this backend enables so there's justification to the request.
On Apr 25, 2016, at 6:55 AM, Andreas Lobinger notifications@github.com wrote:
Rcall seems to be the continuation of Rif.jl Just for curiosity, what is the publication quality difference between ggplot2 and Gadfly on the same plot? Could you do an example?
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub
I do admit that ggplot2 is still and clearly the most visually pleasing plotting system out there. a couple of gr plots come close though.
ggplot2 has some great features for plotting spatial data (http://docs.ggplot2.org/current/geom_map.html), but maybe that should be its own issue.
I could try to make some examples of why I think ggplot makes better publication quality plots than for example gadfly, though I believe ggplot is considered to be the best plotting library by a wide audience for a lot of reasons.
As @tbreloff, my concern is also whether it would be worth the effort. Is the current workflow good enough? That is: getting simulation results or similar in julia, plotting with for example gadfly, and when time comes for publication export data and import to R and plot with ggplot.
I could try to make some examples of why I think ggplot makes better publication quality plots than for example gadfly
Please do. The thing is, if we can exactly recreate a ggplot2 plot without calling into R... why bother. If you give me a few examples to work with, I might be able to show you how to reproduce them in Plots (or at least it will give me direction to improve the package)
and when time comes for publication export data and import to R and plot with ggplot.
If this is required, I'd be a sad panda...
A preview of something I'm working on:
by allowing more fine-tuned control of individual plot colors, I could easily add a method like:
set_theme(:ggplot2)
which would update the default values for all these colors to produce the sort of look that you see above.
Currently I have "sub-background" values (for legend, inside the grid, and outside the grid) that default to :match
, which means they take the main background color unless overridden. Same for foreground colors (legend, axis marks, tick text, and borders).
Thoughts/ideas?
It should be very straightforward to add themes, and likely can be added on the fly by the user (as it would just be updating the dictionary holding default arguments).
Things needed for publications outside the theme issue:
Figure requirements/guidelines:
add_theme
/set_theme
are implemented. It was pretty simple. It'll only work right with the PyPlot backend, and only once I merge in the tb_pyplot
branch. Here's a sample:
See: 77c2d7d846f27246b3420f7eca942fbea5001560
Select font (i.e. PLoS ask for Arial, Times or Symbol... Setting Arial in ggplot2 isn't easy) Determine font size (i.e. PLoS ask for 8 to 12 points)
FYI... you can set font attributes using the Plots.Font
type:
That was easier than with ggplot2 ;)
I like where this issue is headed
How does this tie in with matplotlib's built-in styles or other packages that change the matplotlib rc parameters, such as seaborn? I've been trying to change the look of the outputs from Plots by doing something like
using Plots, PyCall
@pyimport matplotlib.style as style
style.use("bmh")
plot(...)
or
using Plots, PyCall
@pyimport seaborn as sns
plot(...)
sns.despine()
but not really having any luck.
It doesn't tie in with them. Plots doesn't really use the defaults of matplotlib, so something like seaborn that depends on setting the defaults won't work as expected. It's technically feasible that you could ask Plots to grab default values from matplotlib, but that doesn't seem like it's worth the trouble... I'd rather add a theme that all backends can use.
Makes sense for a meta-plotting package, I guess. It's a just a shame because I love using the API of Plots such much, but then wanted to go in and make tweaks to the plot before publication. Is there a way to instead tell Plots not to apply any styling at all so I can deal with that bit?
(Also, just realised that I can do @pyimport seaborn.apionly as sns
to get access to functions like despine()
that alter the plot object, while keeping the style unchanged)
make tweaks to the plot before publication
You can still call PyPlot functions if you want.
Is there a way to instead tell Plots not to apply any styling at all so I can deal with that bit?
This is a pretty slipperly slope, though I see the draw if you want to use something like seaborn for themes. I would prefer that anything you want is available from Plots, and otherwise you can update the plot after-the-fact directly through the backend.
If you're having trouble getting it looking the way you want, please post specific examples and I'll try to help. Bypassing only some of the Plots processing and method calls will likely be a tricky thing to get right...
After a little tinkering, I'm really impressed with how simple it is to just go and do things like turn off the grid directly through Plots without having to even touch PyPlot at all. Making themes that all backends can use is definitely the way to go :+1: I hit one little snag but I'll post it as a separate issue.
Should themes have a seperate "variety" keyword, or should they just be solarized1
, solarized2
etc?
My vote would probably be to have a main 'solarized' theme, and then 'solarized_xxx' which uses 'base = solarized'. (Assuming the themes share some attributes)
On Saturday, May 7, 2016, Patrick Kofod Mogensen notifications@github.com wrote:
Should themes have a seperate "variety" keyword, or should they just be solarized1, solarized2 etc?
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/tbreloff/Plots.jl/issues/201#issuecomment-217636611
I think I agree. For solarized for example, it makes sense to have a dark and light bright theme, but for others it might not.
Not sure if this has been mentioned before. but ggthemes is a pretty nice place to get inspiration
emphasis on inspiration. It's GPL-2 after all
Someone mentioned it (I thougt it was you?) Luckily the color definitions are often available at the sources, so I don't have to base it directly off of ggthemes, I just plan to use it to find the sources :) But thanks.
NOTE: tiff and other formats can be saved from the PyPlot's gui :)
Lots of good stuff in this issue, glad I found it. Is anyone actively working on themes, either original or reproductions of, e.g., the seaborn matplotlib themes? Is the thought that all themes will live in this package, or some separate one?
PlotThemes.jl
On Sunday, July 24, 2016, Chris Binz notifications@github.com wrote:
Lots of good stuff in this issue, glad I found it. Is anyone actively working on themes, either original or reproductions of, e.g., the seaborn matplotlib themes? Is the thought that all themes will live in this package, or some separate one?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tbreloff/Plots.jl/issues/201#issuecomment-234805378, or mute the thread https://github.com/notifications/unsubscribe-auth/AA492jJTdTcAxVvV2K5SvLSXONlgo-vMks5qY-DpgaJpZM4IOv2I .
Yes, that's PlotThemes.jl territory. Unfortunately I've had to snap back to reality and work on my thesis the past few months, so it's been standing entirely still. However, PRs are welcome. Though, I should resume work (on *.jl) relatively soon.
I need to add a "themes" page to the docs so that people know about this feature (and PlotThemes.jl)
Would it be hypothetically possible to add the R package ggplot2 as a backend? Compare with the julia package for pyplot. Which steps would be necessary to make this reality?