Go, Colourspace, and All the RGB Colours in One Image | Hacker News Reader

Go, Colourspace, and All the RGB Colours in One Image

medium.com

93 pointsKapura26 comments

[1] is a similar project someone else did, where he used a space-filling curve (Hilbert's curve, specifically) to plot all the RGB colors in one image, and have nearby colors be similar.

[1] http://corte.si/%2Fposts/code/hilbert/portrait/index.html

There's an entire community dedicated to this: http://www.allrgb.com

Unless I missed the reference to that somewhere in the post?

Hey all, I've gone ahead and updated the targeting algorithm to reduce the darkness bias described in the article. It has been updated to reflect this, with before and after pictures.

Have you thought of inverting the function? It's a one-to-one mapping, so it should be invertible. Use the same algorithm, but pick a place in R,G,B space as the seed location and search in concentric circles (instead of spheres/shells) in the X,Y space.

I'm not certain what you're trying to say. When you talk about "the function," I'm assuming you're referring to the nearest unused colour function, which, while it is a one-to-one mapping is also a) a function from colour 3space to colour 3space (input is a targeted RGB point, output is a valid, unused RGB point) and b) it is also dependent on the state of the colour space i.e. the function is of the form (r0, g0, b0, colourspace) -> (r, g, b) + the colour space is modified to indicate that (r, g, b) has been used.

All of the dealings with the X, Y space (the image) are separate from the colour searching algorithm. There is a function to approximate the target colour of an unfilled pixel in X, Y by averaging the values of its neighbours, but that value is then used as input to the above-described search function.

I could simply be misunderstanding what you're trying to say.

I'm curious how much of the authors Go speedup was Go's typically faster single threaded execution or if it was from using Go's easy multi-threading primitives. Of course I imagine it was some ratio of both, but I'm curious about it.

I recently had a similar project [0] and wrote the first version in Java. In some cases it took almost an hour to render a simple 6 bit per color channel image. After that I rewrote it in Go and got it down to ~120s. I think this is mainly due to the fact that the Java version lays way to heavy on OO and does a lot of dynamic memory stuff and the rewritten Go version uses simply 2 (or 3) large arrays. I think in our case it wasn't a raw performance thing but rather the fact that go's proximity to C made us code smarter (=

[0]https://github.com/31415us/olga basically a straight up copy/reimplementation of joco's [1] response to [2] [1]http://joco.name/2014/03/02/all-rgb-colors-in-one-image/ [2]http://codegolf.stackexchange.com/questions/22144/images-wit...

That is true, while it often using more memory the same code in Java is usually faster than the same code in Go. The thing is- as you aptly pointed out, the idiomatic Go solution is not the same code and is often lighter and faster.

Whew! Took about 12 minutes on my 2010 MacBook Pro

All RGB photos: https://github.com/fogleman/AllRGB

Looks so much nicer than plain RGB cube.

I wonder though whether NumPy wouldn't have been a possible alternative.

I'm more amazed that this kid is unemployed! Someone who can code, with a college degree, possessing communications skills and some initiative, sitting around bored. 'Murica.

Unemployment is quite high. Chances are, he would have to compete for any position with people who are more experienced.

Seriously. I'd be very interested in offering him a job.

Well, college has only been out for at most a month. He's probably in a transition phase or still doing the interview process. It's also possible he's not a coder by trade.

Well, it's not so surprising. I don't live in a tech hub (yet), I have relatively little professional dev experience, almost no side projects, and my resume didn't wasn't very professional looking until relatively recently. Not that I'm complaining; I've been wanting to take on this project since I saw Joco's original posting.

Um, Jaypeg?

Did I miss a terminology change somewhere? Is the author being ironic?

That's going to right beside "solider", "bro" and "rouge" as words that make me cringe when I see them.

Listen, it's really simple. You've got your Jaypegs, which are lossy but small file size. Then you've got your Pings, which are lossless but really large. But you also have Jiffs, which can be animated.

Don't forget the Targets, and the Tiffs

And the Bimps and Pisds..

(I can't do PDF.)

The Eggses. The Bats. The shhhhhs.

Padoof.

That's a paedofile, Shirley. Don't get too close.

ohgod. please. stop.

you're hurting ... technology.

What's wrong with 'rouge'?

Rouge Angles of Satin

Reply on news.ycombinator.com