This is another little demonstration of my Image->RGB info tool. The effect is very subtle in this case and I removed the slap function.
For the technically interested here is how the picture-to-pixelinfo thing works:
Problem 1: Flash can load JPEGs, but you can not read out the RGB value of a pixel at location x/y.
Workaround: Extract the RGB information with a tool like GD on the server and load this data to the flash file by one of the possible methods: XML, loadVars or loadMovie.
Problem 2: Image data gets huge pretty quickly - a 20x20 picture has 400 pixels, a 200x200 has alrady 40000 pixels. One RGB pixel consist of three 8-bit values which, if you (could) use the full ASCII code would fit into three chars which means 200x200x3 = 120000 chars. Unfortunately if you want to use XML or loadVars you cannot use the full ASCII code, as some chars have special functions, like "&" or the null. this means you have to send the data differently, for example in the usual color notation hex code #aabbcc. Makes it in optimum case 200x200x6=240000 chars, but this case means that you would send the whole information in one big string and have flash do the parsing. Uh Uh... With Flash's rank as "Slowest String Parsing Application In The Known Universe" that's not a good idea. So maybe split the data into smaller chunks already on the server, perhaps into scanlines. (First I should mention that using XML is definitely not an option, the markup overhead, plus the parsing makes it pretty useless in our case.) Okay let's try - each line gets stored in a variable, variable name as short as possible L0=aabbccdd22333444... to L199=1235634334455... - do not forget to count the "=" and the "&" in the querystring - well it's about 1000 extra chars. This could work, but is it the best we can get? No. In comes the
LoadMovie Method: The ideal method would be a file that contains an array with all image data. No need to parse anything, highly compacted, with fast-access data. And that's exactly what we'll do: we create an swf on the server that contains only actionscript, actually only one line: data=[123123132,23452456235,1234143132,35345234346345,...] this is our image information. The numbers are 32 bit values, as flash internally stores all numbers this way and if you would use 24 bit you loose 8 bit for each number. This creates a little more calculation on readout as you will need some bit shifting, but it saves you 40000 chars. To create the swf is easier than it sounds. You just need to create a basic file with the editor, and check out the P-code that it creates with a hex-editor or tools like Buraks ASV. Then you should check out the open-swf specifications for certain bytes that have to be set correct. That's almost all.
Optimizations: For most cases it is not necessary to have to 100% exact image data. That's why I almost saved another 2/3rd by creating a kind of PNG format, with a color table. This means you only have 256 different colors, but you only need 1 byte per pixel, plus 256*3 Bytes for the color table. But you can get it even smaller if you only need the data for Flash MX - simply add GZip compression. I was amazed how easy that is. In PHP you just use the command "gzcompress" on the whole movie (without the header and the filesize info) and are ready to go.
Where is the sourcecode? Well, the reason why I did not put up the sources yet is that I used an advanced version where I add the image itself to the file. Therefore I used parts from Stefan Schüßler's FlashWriter Toolkit v1.02. Unfortunately I do not find the non-picture version anymore (I'm a chaotic overwriter-programmer) and I haven't asked Stefan for his permission yet.Posted at September 08, 2002 02:42 PM | Further reading