Personally, I like the state now better than a couple years ago, where it was a struggle to get Cairo.jl working because it was interacting with users' systems in weird ways. It admittedly takes much more harddrive space, sometimes to a silly extent. I'm not sure if it's technically possible to have weak binary dependencies, I think if Cairo the C library declares binary deps, we have to add them all (hence Pango, Fontconfig, etc. etc.).
By the way, we get very few installation issues nowadays. They usually have to do with either graphics drivers on Linux, or because people have somehow messed with their library load paths and pull in the wrong dylibs. From a maintainer's perspective it's nice not having to worry about all that too much.
Yeah the recipes are Plots.jl's strength. We will need more time to get there, I've always felt that the statefulness you get from having interactivity gets in the way of easy composability a bit. In Plots, you assemble one big plot description from recipes that then gets translated to a backend representation once. In Makie (currently) each plot object gets instantiated immediately, ready to go for interaction. But in the future, we might add a layer on top that builds full descriptions first, like Plots, then instantiates at once.
As a side note, package extensions in Julia 1.9 mean that any package can now in principle extend Makie without directly depending on it. That should remove one of the big blockers for adoption, as admittedly, Makie is a heavy dependency to take on.
I don't use it personally, but RCall.jl[1] is the main R interop package in Julia. You could call libraries that have no equivalent in Julia using that and write your own analyses in Julia instead.
I don't think we claim we are the only library that uses something like Observables, as you say there are others that do. VegaLite also uses a signal mechanism for interactivity, for example. Makie has been inspired by many libraries that came before (although I can't say that I knew echarts, specifically :) )
Every plotting library has something to offer, there are so many choices to make when building one that you can't cover everything. I envy the pure javascript libraries a little for their easy embedding in websites. But when you already do data work in Julia, especially with custom types and such, it's nice not having to move across a language barrier, and instead make use of Julia's multiple dispatch some more by using a native plotting library.
It's in a different category I would say. For the users, ggplot is mostly about the grammar idea, how you assemble plots from data, geoms, etc. Makie is on a lower level, where you create elements like axes, colorbars, legends etc. manually (with convenience methods, where applicable) and plot things like volume plots or line plots to the axes (like in matplotlib or Matlab for example, but with the whole Observables thing for interactivity). However, the packages AlgebraOfGraphics and TidierPlots are just using Makie's plotting infrastructure to layer a more descriptive plot-building engine on top. There should be nothing in principle that ggplot can plot that Makie really can't, because there are only so many 2D primitives, but Makie has a bunch of 3D stuff that you would not use ggplot for, I'm sure.
My biased view as a coauthor of Makie is that Makie's model is cool because you have a much easier time to combine low-level tinkering with high-level descriptive plots this way. I don't know if you've ever tried hacking the ggplot data structures for special use cases but they are more complex or inscrutable than in Makie, I would say.
Of course, ggplot2 has an amazing and mature ecosystem around it, our ecosystem will need time to fill gap after gap.
Improving the docs as a key point was one of my takeaways from MakieCon. It's pretty time-intensive to work on them as you can imagine, but I hope we'll be able to make the structure more clear and efficient in the future. There should definitely at least be docstrings for every exported struct and so on. But I also want newcomers to get started with less friction, so the explanations/tutorials/how-tos must improve.
This is an easy way for newcomers to help out, by the way, just give feedback on how starting out with the library went and what the main roadblocks were. The better we understand them, the more we can improve them.
I have a reverse corollary of this, which is: As I do/use things that are useful/interesting despite of their papercuts, then if I don't do/use something because of perceived "papercuts", they are probably not really the reason.
Examples are not recording music because my audio interface is a bit too laggy, or not taking photos because my camera lens is a tad blurry in the corners. The real reason is that I'm not motivated / inspired enough and like to blame the "papercuts" of my gear.
This is not only about things moving away from where they were, but also popup windows appearing above a thing you wanted to click on. You cannot always avoid that, so I think the solution is to ignore clicks on things that have recently (in the last 500ms or so) appeared or shifted.
What's kind of crazy is how the images tend to have similarities in small features that become very apparent when flipping back and forth between images, but which are not obvious per se.
For example, I flipped back and forth between Beatrix Potter and Paulus Potter. A rounded white bonnet in one picture becomes a couple of blossoms in the other. The roof of a house becomes some shadowy wall with plants in the other. Two flower pots are very similar, just with slightly different coloring.
It makes it more apparent that the algorithm etches the images out of noise, and if the seed is the same for two images with different prompts, you're likely to see traces of that noise represented differently but recognizable in both images.
The positioning seems very consistent, almost to the point where I wonder if that was part of the selection process to demonstrate the differences in style. There are only four per style, where the position of a subject could be a selection factor. Hard to tell if the position similarities are driven by the Stable Diffusion model or by the selection of representative images.
The composition and positioning come from the original seed. If the same seed is used, the same background image noise is applied for the initial image which is transformed into all the styles.
Thus the similarities you see would make sense if using also the same seed for the tests.
Yes, if you generate a bunch of images of waves or the sea, or other repeating patterns with the same seed, you can see how all the 'peeks and toughs' of those patterns line up in the same place.
incredible job! i was just showing my own experiments with sd to a friend and this just take the cake. thank you so much for mixing in that artist list!!
If you play with Stable Diffusion enough this behavior becomes very apparent. Changing the seeds will give different results, but even relatively significant changes in the prompt will still find similar themes or layouts.
Arguably it could be different from our experience. It could even be a superior and more efficient methodology then the things our brain uses to imagine things.
The blue woman in Sam Bosma's style looks strikingly similar to the one in Noah Bradley's style. They even have the same 3 patches of pink on their cheeks.
That is fascinating. I thought that bells had one or a couple dominant / loud frequencies that would mostly determine pitch, and the rest would just mix in to change the timbre but not the main percept. I always found the sound of melodies played with bells kind of uncomfortable because there is too much going on, too many different frequencies interfering with each other.
For literally centuries European bell tuning was all done by rule of thumb, with results varying from to sublime to abysmal. It was all finally figured out by Canon Simpson in 1895/6 who described the relationship between the 5 main components of a bell's strike note - the hum, prime, tierce, quint and nominal.
By the way, we get very few installation issues nowadays. They usually have to do with either graphics drivers on Linux, or because people have somehow messed with their library load paths and pull in the wrong dylibs. From a maintainer's perspective it's nice not having to worry about all that too much.