[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.
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 (=
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.
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.
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.
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.
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