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...
What is a complete DAG? Can I create one by just taking a complete graph, choosing an arbitrary ordering of the vertices, and assigning each edge a direction according to that ordering?
Edit: after reading the problem statement, yes, I can.
It like how it looks, but much like Flickr I dislike how it's biased towards landscape pictures. Some of my best photos are portrait, but they get overshadowed by the landscape ones.
I imagine the algorithm to cater to both is much harder, because you wouldn't be able to treat each row in isolation, can it actually be solved to a good standard?
Maybe something like my grid solver[1] would do. Thumb sizes must be chosen beforehand, but you could specify just 2 classes: one for portrait, one for landscape.
I haven't touched this code in almost 6 years now, so don't expect too much :)
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.
depending on the size and make up of the particulate our bodies are actually pretty damn good with removing most particulate, additionally because it is not a regular exposure it is now a smaller risk
Given that that article says that the supposedly-sealed lenses were also vulnerable, do you have advice on how one would successfully enclose a lens to protect it from the dust?
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.
There is waterproof casing (I mean for diving, not spray water), - I would hope that's enough? I don't know for sure though, so please don't take my word for it.
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.
Maybe Chromium is blocking the redirection to cloudfront, where the images are hosted? I had to tell Firefox's RequestPolicy, to let these requests pass...
The photos didn't appear correctly aligned though -- some 70-100px "whitespace" at the right edge of the screen. And resizing the screen removed all content.
What's just as impressive is the full size view of the image. The background brings the ambient colour of the photo to make it more immersive. Very nice!
That's an idea I've actually seen done but executed poorly many times.
What they got right this time is adding the shadow around the image making it easy to distinguish from the background, and blurring it so heavily that none of the detail is distracting.
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]".
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?
he writes an excellent example of why "all that computer sciency stuff" is usefull in day to day programming, yet still wants to take pride in his ignorance, like this is some strange sort of fluke.
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?
The demo [0] is pretty impressive. Photo sites like Instagram and 500px give a fixed ratio, while flikr does nothing quite appealing as this. Nice work.
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.
We do not change the order of the photos, we just try to find a good set of breaking points inside that order.
Actually, Chromatic tries to read the EXIF "DateTimeOriginal" information to sort the photos and falls back to the "LastModifiedDate" if the former doesn't work.
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.
Vertical masonry doesn't work well to communicate an ordered list of items. Photos are often just that...a story of an experience that happened chronologically.
The inability to read left to right on columnar data makes this really hard.
If something really happened chronologically, then perhaps it's acceptable to have a horizontal scrollbar, or not right-justify the right edge.
This particular algorithm seems to mix up the order of the photos in order to best fit them on a line, so it can hardly be said to show chronological order.
Given that clear textbook explanation and he decided to port a Python implementation instead of writing it from scratch? What a waste of an opportunity for a fun day at work...
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.
http://fangel.github.io/packing-images-in-a-grid/
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.
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).
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.
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.
Can sombody tell me why this uses the photos as background images for divs? It seems to me like this gallery could also use img tags (which is semantic, crawlable, yadda..)
Perhaps to avoid easily right clicking the image and saving it to your machine? I know it is still easily downloadable, but not so much for a lot of users.
Yes, we figured the page scrolls slow if there are too many photos in the DOM at the same time so the lazy-load-function also removes them when out of scope.
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)?
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.
i think i found the problem with the algorithm. sometimes it returns an empty row. the javascript version throws while the python version doesn't. i fixed it in my fork by just reducing the number of rows until it doesn't throw: https://github.com/jonathanong/linear-partition
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.
I posed it as a problem on daily haskell exercise http://dailyhaskellexercise.tumblr.com/post/58060450750/the-....
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...