TwoBillionPixelsPerHour_Samples14-05-28_12 Camera / Interface

HGB Rundgang 2014

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

good morning

cleaning team

last night: party party

party… flip off?

checking the camera, because…

…my auto-exposure algorithm broke. I think it could not keep up with the light conditions this sunny morning, so boom! Resonance disaster!!

UPDATE: Saturday noon, 167,983 done, 94,251 to go!

this time, the lights went off at night (that black blob)

The morning. There’s still some problems with the automatic exposure, but the frequency is way lower – the extremes (under-/overexposed) are maybe 15min apart.

Sweepin’

Flash / focusing light hacks. Highly welcome.

Spotty attendance.

UPDATE: And done. Almost 8GB.

this is one third of the original's resolution; aliasing/pixels deliberate

dod_tribuene

An in-game photograph of the north tribune of the former/demolished swimming stadium at the Sportforum Leipzig

american-elf_hilbert_h7.cropped-1200

data-visualizing American Elf

As James Kochalka’s daily diary comic American Elf ended on 2012/12/31 after 14 years and at least 5106 strips. I wondered about its visual evolution.

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.

Conclusion?

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!

I guess there is no pattern

upscaling glitch disco floor

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 guess there is no pattern

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
vlc-http-stream-glitches_wingdings.crop

vlc http stream glitches

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.

The 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.

Luma Relief Hyperbolic Hyper-Hyperbola facial recognition VS zombies This is what your "reflection" looks like.