There is a very geeky discussion about C64-graphics over at CSDb, which is strangely annoying and fascinating at the same time. It is essentially an argument about what a C64-image ‘is’, or perhaps more correctly, how it should be represented at CSDb. Is it the raw pixel data, or is it the way the image looks on an old CRT TV-screen?
From a data-materialist perspective, the image is archived most correctly as pixel data. Nobody in the thread disagrees with this. The discussion concerns the screen shot, and whether it should be modified to look like it does on a CRT-screen (by re-constructing a ‘correct’ palette and using a TV-emulation). It is a question of what is the most ‘accurate’ representation of the image.
By STE’86
STE, a commercial pixel artist from the 80s who was active in the demoscene-ish universe Compunet, wants CSDb to “let me display my work in the manner and spirit it WAS created in. and let ME be the judge of that being as how i actually did it 25 years ago and may indeed have some recollection of what it looked like”. His idea of the image is a construction of e.g. two things: memories and screens. The way he remembers the image is not necessarily what was actually on the screen. Even if it was, his CRT-screen was different from those of others. Furthermore, his PC/Mac-screen might show graphics a bit different compared to your screen. Nevertheless, his point is that an archive such as CSDb should not modify the images in anyway, because for one it’ll be a huge problem to update it as the emulator improves.
The problem is that some images need some kind of filter/emulation, because they rely on the blending that PAL-artefacts create. In short, C64-graphics looks different on modern ultra-sharp screens. Bogost describes the inaccuracies of emulators in terms of texture, afterimage, color bleed & noise. These can be vital aspects for pixel artists who work with CRT-screens, of course.
By Joe
What’s funny is how the technical discussions runs into a little halt half-way through the thread. It’s discussed if we can actually tell the difference between palette-issues and TV-emulation. In fact, the cause of the whole thread is revealed to have been an anti-alias issue in Firefox that was interpreted as a case of TV-emulation. For me, this is a little reminder to not get too stuck in technical details that, when it really comes down to it, is not something we are aware of anyway. In another way, it’s a reminder of what makes demoscene forums great!?<
CHIPFLIP 
July 22, 2010 at 7:58 pm |
There was indeed something odd with that specific thread. A disturbance in the geek-force perhaps.
I hated it, but could not stop myself from reading it.
March 9, 2011 at 11:58 am |
[…] This exploration of materials is something else than all those low res things around in streets. Making pixel-art with spray cans and stencils live, from scratch, is a demanding task. I met a guy in St Petersburg who made his own software that transformed a pixel image into 4 stencils, so that each pixel would stand out from the next. In 8-bit systems it is common that pixels are affected by their neighbours – either because of the graphic mode that limits the amount of colours in an area, or by the bleeding of the CRT-screens. […]
May 6, 2012 at 8:13 am |
[…] in a very different experience from watching it in, for example, laser. Still, it is not all clear which is the most accurate representation: clear non-emulated pixels on a modern screen, or CRT-mangled images on a […]
July 16, 2013 at 2:31 pm |
[…] The pixel is a metafor much like the atom is (see this). It’s useful for many purposes, but it’s a model that doesn’t reveal the whole story. The same pixel looks different depending on context. It’s changed by the screen’s colour calibration, aspect ratio and settings, and it looks different on a CRT, beamer and retina screen. The data of an image is not the same as the light it produces. […]