The algorithm for a perfectly balanced photo gallery • Hacker News Board

Re: The algorithm for a perfectly balanced photo gallery

#61

Post by phoboslab » Mon, Aug 12, 2013, 3:49 PM UTC

andrewingram wrote: post #27

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 :)

[1] http://phoboslab.org/files/grid-solver/demo/

Re: The algorithm for a perfectly balanced photo gallery

#62

Post by zodiac » Mon, Aug 12, 2013, 4:02 PM UTC

nkuttler wrote: post #42

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..)

I think it's so that they can use css media queries. Here's a list of pros and cons for div background vs img tags: http://stackoverflow.com/questions/492809/when-to-use-img-vs...

Re: The algorithm for a perfectly balanced photo gallery

#63

Post by robotmay » Mon, Aug 12, 2013, 4:05 PM UTC

andrewingram wrote: post #27

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?

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.

Re: The algorithm for a perfectly balanced photo gallery

#64

Post by wicknicks » Mon, Aug 12, 2013, 4:14 PM UTC

quarterto wrote: post #6

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…

Congrats!

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.

edit: I'm using Firefox v22 on Xubuntu.

Re: The algorithm for a perfectly balanced photo gallery

#65

Post by aestra » Mon, Aug 12, 2013, 4:15 PM UTC

FreeFull wrote: post #22

quarterto wrote: post #6

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…

I end up with some of the photos ending up behind other photos. Firefox 23 here.

Same in Firefox 22. Scrolling seems broken, and removing the "find on page" part of Firefox clears all the images.

Re: The algorithm for a perfectly balanced photo gallery

#66

Post by joebo » Mon, Aug 12, 2013, 4:17 PM UTC

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.

Re: The algorithm for a perfectly balanced photo gallery

#67

Post by glogla » Mon, Aug 12, 2013, 4:22 PM UTC

Is there some kind of static gallery generation software that can do something like this?

Re: The algorithm for a perfectly balanced photo gallery

#68

Post by alariccole » Mon, Aug 12, 2013, 4:22 PM UTC

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.

Re: The algorithm for a perfectly balanced photo gallery

#69

Post by jmathai » Mon, Aug 12, 2013, 4:24 PM UTC

EGreg wrote: post #55

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.

Re: The algorithm for a perfectly balanced photo gallery

#70

Post by ionforce » Mon, Aug 12, 2013, 4:29 PM UTC

joebo wrote: post #66

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.

Well it would have to be some sort of flexible time constraint. Otherwise the photos are already ordered.