It's great to see examples where code can be side-stepped in favour of a quick-n-dirty, 'designer'-type solution - different ways of thinking about the problem.
I have fond memories of my first years in the VFX industry being made a fool of by non-programmer effects artists who, by hooking together a few nodes in the industry-standard package Houdini, could in minutes recreate algorithms that took weeks for me to code the 'right' way, and in a couple more minutes interactively tweak the constants to get results which I would have taken even more weeks to derive 'scientifically'. It was a crash-course in the value of rapid-prototyping, but also in that particular case introduced me to new ways of thinking: Houdini presents a completely different view of geometry and image processing, which is thoroughly non-intuitive to the typical comp-sci graduate. Houdini taught me an (almost literally) orthogonal way of thinking about computer graphics problems.
The lessons are more general:
- rapid prototyping is not necessarily coding
- sometimes the non-technical, 'designer' approach is the more efficient one (not necessarily in this case - there is plenty of merit in both approaches)
- the more tools you learn, the more leverage you have - why not learn some of those design tools and learn a different way of thinking about things.
(This comment is inspired-by, not directed-at, the two dice portrait posts.)
I thought it was interesting to see a different solution to the same problem (see: http://news.ycombinator.com/item?id=3254392 ). The developer thinks "let's write some code!", but the designer thinks "let's use Photoshop!"…
Turns out Photoshop is even more powerful than what you'd think: I created an action to automate the whole process with any photo. You can download it here:
(By the way, little known fact: you can actually script Photoshop using Javascript. I once used this to automatically generate all letter tiles as separate images for a touchscreen keyboard based on a template)
Photoshop's scripting capabilities are pretty astonishing. I taught myself over lunch the other day. You can script in JavaScript, AppleScript, or VBScript and implement dialogs and UI panels.
It works exactly as you'd expect and scripts are quite lean (you don't need to do a bunch of setup).
If you reduce to 6 colours, then make a mosaic, you will get all different shades of grade. Mosaic will take (simplifying) an average of colours one tile covers.
Just an oversight. He says at the end of step three that "we have our image divided into 16px tiles colored with 6 shades of grey", but as you point out, if you count the number of shades in the image above, there are more than six.
I have fond memories of my first years in the VFX industry being made a fool of by non-programmer effects artists who, by hooking together a few nodes in the industry-standard package Houdini, could in minutes recreate algorithms that took weeks for me to code the 'right' way, and in a couple more minutes interactively tweak the constants to get results which I would have taken even more weeks to derive 'scientifically'. It was a crash-course in the value of rapid-prototyping, but also in that particular case introduced me to new ways of thinking: Houdini presents a completely different view of geometry and image processing, which is thoroughly non-intuitive to the typical comp-sci graduate. Houdini taught me an (almost literally) orthogonal way of thinking about computer graphics problems.
The lessons are more general: - rapid prototyping is not necessarily coding - sometimes the non-technical, 'designer' approach is the more efficient one (not necessarily in this case - there is plenty of merit in both approaches) - the more tools you learn, the more leverage you have - why not learn some of those design tools and learn a different way of thinking about things.
(This comment is inspired-by, not directed-at, the two dice portrait posts.)