Two billion pixels per hour
Zoom’em, pan’em, peruse’em. At the annual HGB Rundgang:
Wächterstraße 11, Leipzig
Thu 13 Feb 2014 6pm – midnight
Fri 14 Feb 2014 11am – 10pm
Sat 15 Feb 2014 11am – 10pm
Sun 16 Feb 2014 11am – 8pm
UPDATE: Friday 2pm, impressions
UPDATE: Saturday noon, 167,983 done, 94,251 to go!
UPDATE: And done. Almost 8GB.
First, let’s look at its shape’s consistency. The comic/page comes in a near square format and usually consists of a heading, 4 square panels, and the date. Sometimes it’s just 3 or 2 panels, one big panel, a list or… something. The early strips were black and white. This is what an average (literally) strip looks like:
I used a fairly simple technique (which I once thought I had invented, while it’s pretty much as old as photography), sometimes it’s called Eigenface (incorrectly – check the comments) - it’s basically a multiple exposure (of stuff that looks alike). Here’s a nice example (hover over the names on the bottom right).
The 4-panels-structure dominates, then there’s the headline at the top, the date at the bottom (where you can even see the space between month/day and year). While the colors cancel each other out (it’s not the early strips that cause the grayness), you can see a light skew: the left border isn’t really straight.
Let’s look at this through time:
Here, each image contains one fourth of the strips, i.e. the first 1200+ strips or 3 years in the top left corner, and so on, left-to-right, top-to-bottom.
It’s apparent now that the first years were black and white, and had no heading. The early color strips tended to pink/red/purple tones, and headlines seem to be yellow predominantly.
Again, but with more granularity/temporal resolution:
Here, each sample contains roughly 80 images – so it’s like favorite color of the season, i guess.
Now let’s look at all strips individually:
The strips are laid out following a hilbert curve. Other than a left-to-right-top-to-bottom text-like layout (with line-breaks), it preserves locality: a month is not a line, but a block. That’s why all the early strips sit in the upper left corner, and are followed by the bright colored in the upper right corner. The curve then turns to the bottom, to the left, and down again, before it ends in the bottom left corner (hilbert curves only come in specific “capacities”, and the 5106 strips fit uncomfortably between 4096 and 16384). It’s roughly this path:
The thinner & darker the line, the finer the resolution.
When I look at this data visualization I feel a little, well, uneasy. It’s a cold analysis of a work of art full of heart and warmth. It compresses over 5000 days of work into on neat graphic. Plus, I made a machine crawl your website and download all those handcrafted images…
But that’s just one way to look at it – I hope it rather is an awe-inspiring celebration of a masterpiece (these are heavy words), made with handcrafted scripts. And (image)magic(k).
So: Thank You & Sincere Apologies, James Kochalka!
A friend asked me to help her make a video, which was supposed to look like this:
A white square, then one black pixel appears, then another adjoining one, another one; repeat with white pixels as soon as the square’s black. Randomize, goto 10. A simple algorithm, a quick PHP script that would output a series of tiny PNGs. But as soon as I tried to convert the dozens of 5×5px images to a movie (picking the lossless FFV1 codec as intermediate format), and scaling it up with a nearest-neighbor/point filter (up to DVD size), something weird happened: colors appeared from nowhere, even though I was explicitly converting to grayscale.
I ran some more scripts, and it turned out that the colors depend on the scale factor. Here’s an animated gif where every frame was converted with a different scale factor. (take a close look at the edges, they’re more blurred in the beginning, as the scale factor was higher. Ignore the GIF artifacts — click to see the animation and beware, it’s strobey)
I wondered if there was a pattern, so I made a montage. The scale factor decreases left-ro-right, top-to-bottom.
I tried other combinations of codecs, scale factors and colors, to no success. This “problem” turned out to be limited (as far as I can tell, and remember – I did this some time ago) to
- really small files
- the nearest-neighbor/point filter
- the FFV1 codec
- an ancient version of MEncoder
I’m working on a project that utilizes vlc to stream video over http. It’s a pretty straightforward command, it works well & stable. Here’s what I receive:
The artifacts here are normal, it’s just P/B-frames before an I-frame/keyframe comes along (every 250 with h264 by default). They look even nicer, when there’s not much data (movement or noise, that is):
But as soon as I try to set the bitrate, it’s real glitches galore:
I tried Ubuntu’s 2.0.3, compiled 2.0.5 by myself, but the problem is still there. It’s either the low default bitrate (about 400kb/s, I think) – or a custom bitrate that is way over my bandwith, as the glitches go away at >1000kb/s.
solution workaround I settled on was to use x264 (by the venc parameter), which let’s you set your bitrate without fucking up your bits.
I ran Dawn of the Dead through a facial recogntion filter.