How We Built a Cutting-Edge Color Search App
In this technical retrospective (2014), @mattangriffel shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Cloud & Mobile Era (2014–2019)
COMMUNITY SCORE ★ 43 points
TOTAL DISCUSSIONS 16 comments
This is really awesome. For anyone who wants a naive, poor man's implementation of this, I have an unfinished Ruby gem that's a good starting point for you: https://github.com/JoshSmith/kaleidoscope
Here's how I got it to work (cribbed from my own README):
TL;DR: I used k-means clustering to segment a database of images into color bins for quick searching.
Using imagemagick, I ran histograms on images and converted their top n most frequent colors into Lab* color space for an approximate representation of human vision.
Colors were then matched to a user-defined set of colors using Euclidean distance, i.e. a "bin". I could choose any array of RGB values of arbitrary length.
I then stored hexadecimal values of the image's original color and the matched color, along with the frequency of that color within the image (for sorting based on frequency) and the Euclidean distance (for sorting by tolerance).
Then finding images close to a certain color was as simple as Photo.all.with_color('#993399') and order by frequency and Euclidean distance. Here's a photo of the results: https://github-camo.global.ssl.fastly.net/89cc87ac84cd3a1d1223e8f9d560e65eb8447ef6/687474703a2f2f636c2e6c792f696d6167652f336e3243313631373069306b2f53637265656e25323053686f74253230323031332d30322d30352532306174253230362e35362e3434253230504d2e706e67
I might spend some time reverse-engineering Shutterstock's implementation, since it sounds way better than mine and clearly works at scale. But for my purposes, my own implementation worked just fine.
If you want help implementing it, feel free to reach out to me!
Reminds me of TinEye's multicolr demo [0] that searches through CC-licensed images on Flickr. Their multiple color feature was really nice (however they don't have shuttershock's keyword filtering.)
I wonder if anyone ever bought TinEye's color-search-engine-as-a-service [1]. The as-a-service model seems really awkward for something that requires so much integration, and this new shuttershock feature (developed from the ground up) seems to confirm this.
[0] http://labs.tineye.com/multicolr
[1] http://services.tineye.com/MulticolorEngine
Airliners.net had something similar since 2005.
http://www.airliners.net/similarity/
It was on Slashdot back then: http://tech.slashdot.org/story/05/05/04/2239224/searching-by-image-instead-of-keywords
I think the next step for them is to cluster by similar images. A green hue, for instance, shows a lot of similar-looking pictures of leaves—better to show one picture and have a "show similar images" feature to dig into a finer level of variance.
V. cool, though.
Is somebody thinking on applying this to a different stock photo model? I mean, I have heard shutterstock takes a big cut and pays very little to photographers. Nobody out there with these innovative ideas but with a business plan more friendly for photographers?