Since I'm a CS theory person, I can offer some theoretical improvements on the running time and make the problem even more general...
Instead of minimize the linear difference of partition, we might want to minimize the standard deviation, or basically any convex function, and still do it in the same time bound.
One can reduce this problem to find a k-edge path of minimum weight on a complete DAG. The naive algorithm will run in O(kn^2), but we can improve the running time to O(kn) by realize the weight on this DAG has the Monge property. This is very practical to implement.
In this application, k is very large. n is just a constant multiple of k. We can use a theoretically better algorithm that takes n2^O(sqrt(log n loglog n)) time. (this is almost O(n^(3/2))). I doubt it will ever be implemented with speed comparible to the O(kn) solution. See http://www.cs.ust.hk/mjg_lib/bibs/DPSu/DPSu.Files/sdarticle_...
I shall post a solution tomorrow since I'm currently touring NYC with my gf...
You can buy underwater / splash bags for cameras that are basically very thick zip-lock bags. They're much cheaper and lighter than a true (rigid) underwater photography enclosure, but they're basically airtight above water and will keep the dust off your gear. You won't be able to change lenses, however, and zooming might be difficult or impossible, so you'd probably be limited to just putting on a 24mm lens and shooting that all the time.
I just implemented pretty much the same thing from scratch for my wedding gallery¹.
For each row, it tries 3-10 images, sums their aspect ratios, divides the total row width by the sum to get a candidate height, then picks the height that's closest to the average of the existing rows.
To make things look a bit nicer, it rejects candidate rows with the same number of images as the last row.
I might release the code on Github if I can make it modular enough. Currently it depends on jQuery but that's really only for element creation.
I actually have the opposite problem on https://www.photographer.io/en/photographs/explore. I liken it to the idea of rows vs. columns; Flickr and this are organised in rows, and Photographer.io/Pinterest etc are in columns. I've had people put their votes in for both, so I'm not sure which is the best option really. And I certainly don't think I've got it right as it is at the moment.
Their design is just fantastic - especially with the latest update which added better Stations support. When it was first released it was wicked snappy and kind of slowed way down for a while and got annoying - agreed.
In the past month or two, though, it's gotten damn responsive (for me at least). Give it another shot if you haven't used it recently.
Actually, you're right! It's the same picture, scaled down to around 500x500 and with a heavy gaussian blur applied to it. The trick is to have a subtle grain effect over it to eliminate gradient artifacts.
It looks nice (much like Google Image results) but IMO it's not "equally distributed". For example, an image that has dimensions 800x531 gets ~2.3x the space as one with dimensions 531x800. That arbitrarily incentivizes/rewards landscape photos w.r.t. portraits. "Equally-distributed" would probably require an algorithm that works mosaically (without row constraints) and couldn't achieve "taking up all the space available [in a rectangular region]".
This works well when the photos are not time sequential. I find it harder to follow the story when the photos are ordered by the partition fit instead of the time taken. It would be neat to optionally incorporate time into the algorithm.
Maybe I'm missing the point but why is this an achievement? I've seen Google images do this for years (from the backend, sends the users viewport dimensions and then automatically calculates the optimum filling). For years (Warning NSFW!) vusker.com has been doing this client-side in their thumbnail and gallery view. Plus look at the vertically stacked posts from Pinterest.
It seems more a marketing ploy to get attention to the great service chromatic.io is providing?
This looks like a pretty slick, mobile-compatible photo gallery, but without the code it isn't very useful. They talk about Chromatic like a real product, but "free web service" basically means "demo".
I would love for the code to be released, something similar and selfhosted with a simple static backend (or my favorite: Kirby) would live on any low end box. Please consider selling the design and assets on Themeforest.
"Remember the days in college when you learned all about the big Oh!'s and re-implemented all these sort-algorithms for the hundredth time? If you are a web developer like me, chances are you never had to touch a single one of these algorithms ever again." +1
It's a good start, but when the window is shrunk, the result isn't as impressive.
This is why I always preferred vertical masonry. Sites such as VKontakte, Google Image Search, and the recent Flickr app tile things horizontally, but this sometimes means you have to crop the images to fit into your masonry. Not so with vertical masonry, which you can just resize to have constant width.
Since when it is ok to suppose visitors know to click the escape key to go back. And where is the link to go up to the gallery. I had to mess with the url or I was gone for a long back button session. Morevoer it is very slow.
Just to add some negativeness to the generaly positive comments here.
By "go back" i'm assuming you're referring to closing a full-size image. I've found three ways they can do this. They can press ESC. Click the image itself. Or click in the negative space surrounding the image excluding the "Previous" and "Next" regions.
Doesn't really seem like a huge issue since there are multiple ways to accomplish the objective, though I suppose a small "X" could be added if you wanted a visual cue.
You're being a little harsh here. I think he was actually trying to impart the idea that it's worthwhile to have a foundation in CS, even if you don't necessarily work on deep algorithmic code every day. He drew on some (perhaps foggily remembered) CS background to successfully solve a problem, so why knock him?
I've studied this a great deal, and developed a custom masonry type layout to mitigate the row/column bias. I believe it is a much more balanced layout than the article shows. Using it in Imagist, a paid app. Open to a few beta testers for iOS 7 as well, if you want to judge for yourself.
I too made something similar recently. I decided to use dynamic programming. This way it's easy to ensure that you don't end up with a half row at the end. It also doesn't require changes to the ordering of the images.
I made something similar a while back to generate backgrounds on a music website. I took a different approach, and it's not as clean. If anyone is interested to see a different attempt, take a look at the JS.
Anyone else in this thread think that this blog post covers a painfully trivial calculation problem? What's next - someone's going to write a full blog post to explain to me how to perfectly toast my toast using these visual sensor things that seem to be built into my head (eyes)?
Interestingly when I load up their demo gallery at: http://www.chromatic.io/FQrLQsb and click on one of the images to enlarge it, then click again to drop back into the gallery view, the gallery breaks horribly (about 1/3 of the images vanish).
Bug reports can only be as useful as the people who receive them. Try zooming with any browser; you'd expect it to, hum, zoom, but what actually happens is that after zooming, the pictures get resized again, so no matter how you zoom, it always looks the same.