Re:Go, Colourspace, and All the RGB Colours in One Image
by alecrn on Sunday June 22, 2014 @08:52PM
(#7929694)
[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.
Re:Go, Colourspace, and All the RGB Colours in One Image
by Kapura on Monday June 23, 2014 @04:00AM
(#7930740)
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.
Re:Go, Colourspace, and All the RGB Colours in One Image
by phaedrus on Monday June 23, 2014 @11:33AM
(#7932481)
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.
Re:Go, Colourspace, and All the RGB Colours in One Image
by Kapura on Monday June 23, 2014 @02:59PM
(#7933781)
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.
Re:Go, Colourspace, and All the RGB Colours in One Image
by voidlogic on Sunday June 22, 2014 @06:42PM
(#7929465)
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.
Re:Go, Colourspace, and All the RGB Colours in One Image
by infimum on Monday June 23, 2014 @04:32AM
(#7930837)
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 (=
Re:Go, Colourspace, and All the RGB Colours in One Image
by voidlogic on Monday June 23, 2014 @12:21PM
(#7932760)
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.
Re:Go, Colourspace, and All the RGB Colours in One Image
by slagfart on Sunday June 22, 2014 @10:17PM
(#7929881)
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.
Re:Go, Colourspace, and All the RGB Colours in One Image
by Kapura on Monday June 23, 2014 @02:55AM
(#7930583)
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.
Re:Go, Colourspace, and All the RGB Colours in One Image
by yzzxy on Monday June 23, 2014 @02:32AM
(#7930528)
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.
Re:Go, Colourspace, and All the RGB Colours in One Image
by Kapura on Sunday June 22, 2014 @08:10PM
(#7929624)
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.
[1] http://corte.si/%2Fposts/code/hilbert/portrait/index.html
Unless I missed the reference to that somewhere in the post?
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.
[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...
I wonder though whether NumPy wouldn't have been a possible alternative.
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.
you're hurting ... technology.
(I can't do PDF.)