Comments: Would be good if you could somehow define your own color pallette. Obviously you are limited in how much data you can encode in with your available Tweet length... so not sure how plausible that would be. Still kinda fun, just hard to make anything decent out of the available canvas size.
Storing everything in the URL is a feature I just rolled out today. The HN submission is in honour of that. You can of course post it without the http://pix.pe/? to twitter, paste that chunk of letters back in, and it will work. Here is an example of how that looked:
Neat! Suggestion: show a 'actual size' thumbnail of it. Those of us new to pixel art have trouble visualizing what it looks like shrunk down to actual pixels!
looks like each drawn pixel is being recorded in the URL, which means considering all the combinations + permutations of colors and pixels, you can draw (theoretically) the art just by modifying the URL! :) So maybe you can create a randomizer that creates a picture.... :)
I like the idea, and was secretly planning to do that eventually. And also I remember drawbang! I thought up the original "pixtweet" around the same time you first posted it to HN.
edit: in an older version I tried out compression. I quote from the pix.pe page:
It turns out generic compression of any kind is very rarely helpful below a certain message size. The size of the added overhead overtakes the characters saved. Only about 10% of pictures were RLE compressible, and even then, savings were tiny.
Pretty cool. Any chance you could include a 16x16 preview? You could even dynamically update it as the favicon (e.g., http://favris.info/) which is supported in Chrome/FF.
I love how smooth this is on mobile, regarding touching and dragging. I've been working on making UIs for simple art projects on mobile browsers and this will be great to learn from. The palette option is fantastic, it's cool to quickly see a drawing with different color renderings. Thanks for sharing!
I worked hard on it, but sadly it totally breaks on android and windows phone.
I hope to at some point remedy this though it is difficult, since I don't have access to testing on those easily.
If you are interested in this, I found hand.js which seems to do a good job of solving my problem.. I plan to use it eventually.
http://handjs.codeplex.com/
A friend of mine worked out that if you draw a picture, and leave "blank" space (which is rendered in text as underscores) then you can carefully replace the blanks with letters which appears as noise in the picture, but otherwise doesn't disturb what you drew.
I found the easter egg but I'm not sure what exactly it does. At first I thought it's one iteration of conways game of life but that's not it.
Enlighten me!
Oh!
well it's a failure mode. I have used an unconventional pixel order, in order to improve the look of failure modes. I use a hilbert curve.
When you enter in an amount of text that is not exactly 129 base64url characters, it takes out the non base64url characters, turns them into 0-7 numbers, and then 1-dimensionally stretches those until i get exactly 256 pixels- and lay those out along the hilbert curve.
You should look into using replacestate()[1] from History API[2] instead of changing the hash on each pixel change.
This will remove the problem of not been able to use the back-button to get to the previous page (instead of the previous pixel)
Thanks for the advice.
I use the backbutton as an undo stack. if you want to get back to where you were before then you can open pix.pe in a new tab I suppose.
Also, i would note that the backbutton is not per pixel. Each pixel event is filtered through a debouncer, so it actually only updates the url if you are inactive for about 200ms.
This just screams challenge to me. You have a 16*16, 8 colour image in 768 bits.
So the question is, how much can the format be changed to allow for a wider range of expressibility?
The obvious place to start is increasing the resolution by somehow reducing the bits per pixel.
768/(16x16) = 3 (current resolution makes 3 bits per pixel)
768/(17x17) = 2.657
768/(18x18) = 2.370
768/(19x19) = 2.127
768/(20x20) = 1.920
768/(21x21) = 1.741
768/(24x24) = 1.333
768/(26x26) = 1.136
768/(32x32) = 0.75
Of course, once you get a higher resolution with fewer bits you lose the ability to be able to make each individual pixel any colour you want. Once you go below 1 bit per pixel you lose the ability to refer to pixels individually altogether.
Most pixel artists would take some degree of hit though, in fact much of the beauty of pixel art is in massaging the restrictions.
You could quite easily support a 24x24 image in that form, but with only 3 cells across the colour restrictions would be a bit harsh.
My preference would be to try for 21x21 using 3x3 cells. Being restricted to only 2 colours per cell is much less of a problem when the cell size is small. A quick and easy approach would be a 2 byte per cell structure where the first byte defined the foreground an background colours and the second byte defined the pixels. That gets you a palette of 16 colours overall, any two in each cell. It is marginally over the required limit (21x21 at 1.778bpp) though, so would require a little more cleverness to eek out that extra little bit. dropping back to an 8 colour palette would do it easily, but 1.778 is so close to 1.741 that those bits can surely squeezed out from somewhere.
Thanks. It did occur to me that I could get pretty close to a black and white 32x32 picture by replacing the 8 colors with 8 patterns. You'd have to make impossible some patterns, but constraints breed creativity!
There's potential for extra data in the situation where the two colour attributes are the same. Possibly have a second compliment palette where
if A==B {
colourA:=pallette[A];
colourB:=compliment[A];
}
That allows for an extra set of colour pairs, to help out in unusual cases. You don't gain ability to set the bottom right pixel of each cell to the compliment colour, so even though it gives you another 16 colours to play with you get some interesting restrictions rewarding clever use.
58 comments
[ 4.8 ms ] story [ 125 ms ] threadhttp://pix.pe?Q_____________P5_J_PP_55J__P__________________...
http://pix.pe?Q_____________P5_J_PP_55J__P__________________...
http://pix.pe?E____H4___4ACSJSAKUJEYjk4AARAAA_AAk8gAISAA4_A4...
Mario from... Mario :
http://pix.pe/#http://pix.pe?O_____c7_bbbb2O0jk0222t1Otk2k__...
Mickey Mouse :
http://pix.pe/#http://pix.pe?QX4AJBAISH_____AAAB_JO-2JJAAAIA...
Attempt at something cool. Bonus points if you actually understand what it is.
http://pix.pe/?O____AH_________4_4_H4_____H_________________...
Comments: Would be good if you could somehow define your own color pallette. Obviously you are limited in how much data you can encode in with your available Tweet length... so not sure how plausible that would be. Still kinda fun, just hard to make anything decent out of the available canvas size.
https://en.wikipedia.org/wiki/Glider_(Conway%27s_Life)
And it is a glider, effortlessly walking across my digital screen.
In any other context this would probably be silly, but given the limitations... Beautifully done.
This is how sports work!
All urls on Twitter are shortened with t.co to 22/23 characters (depending on https) so the url is not a limit.
https://twitter.com/ZenSaiyuki/status/373400181338693632
Which is neat, and purist and all, but people didn't know what the "gibberish" was, so making it a link is a compelling improvement, it would seem :)
I was really inspired by the twitter image compression challenge http://stackoverflow.com/questions/891643/twitter-image-enco...
http://s177.photobucket.com/user/p0oki_photo/media/Velocirap...
edit: also note that "infinite" undo is available via the back button.
I would like to apply it to Draw![1] pixel art editor.
If somebody want to help me you can fork the project at https://github.com/potomak/drawbang
[1] http://drawbang.com/
edit: in an older version I tried out compression. I quote from the pix.pe page:
It turns out generic compression of any kind is very rarely helpful below a certain message size. The size of the added overhead overtakes the characters saved. Only about 10% of pictures were RLE compressible, and even then, savings were tiny.
Jokes aside, very cool project. Nice work :)
If you are interested in this, I found hand.js which seems to do a good job of solving my problem.. I plan to use it eventually. http://handjs.codeplex.com/
Wants: 32pixels, a 1:1 pixel preview and favicon support!
[1] http://pix.pe/?C___A_4HH4HA_A_H4_H__H_4_4HA_A_H4_AH__4A_H___...
edit: hint: it's 768 bits, while 32x32=1024
[1] http://en.wikipedia.org/wiki/DEFLATE
I wonder if there are any sentences that are also meaningful pictures?
edit: e.g. http://pix.pe?Cttttt5tt9vt____P_5___J__v9_ttttttt9v9tttttkkk...
Other than that, great work!
http://pix.pe?IJJttttSJTdaStuttts2kkkgkkltttttttkkkkkktltttt...
When you enter in an amount of text that is not exactly 129 base64url characters, it takes out the non base64url characters, turns them into 0-7 numbers, and then 1-dimensionally stretches those until i get exactly 256 pixels- and lay those out along the hilbert curve.
[1]: http://stackoverflow.com/questions/17507091/replacestate-vs-...
[2]: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/M...
Also, i would note that the backbutton is not per pixel. Each pixel event is filtered through a debouncer, so it actually only updates the url if you are inactive for about 200ms.
So the question is, how much can the format be changed to allow for a wider range of expressibility?
The obvious place to start is increasing the resolution by somehow reducing the bits per pixel.
768/(16x16) = 3 (current resolution makes 3 bits per pixel)
768/(17x17) = 2.657
768/(18x18) = 2.370
768/(19x19) = 2.127
768/(20x20) = 1.920
768/(21x21) = 1.741
768/(24x24) = 1.333
768/(26x26) = 1.136
768/(32x32) = 0.75
Of course, once you get a higher resolution with fewer bits you lose the ability to be able to make each individual pixel any colour you want. Once you go below 1 bit per pixel you lose the ability to refer to pixels individually altogether. Most pixel artists would take some degree of hit though, in fact much of the beauty of pixel art is in massaging the restrictions.
A lot of 8 bit systems used 8x8 cells at 1 bit with a colour attribute byte to bring it up to 1.125 bits per pixel. The spectrum used that to make things like http://fc05.deviantart.net/images3/i/2004/116/3/d/ZX_Spectru...
You could quite easily support a 24x24 image in that form, but with only 3 cells across the colour restrictions would be a bit harsh.
My preference would be to try for 21x21 using 3x3 cells. Being restricted to only 2 colours per cell is much less of a problem when the cell size is small. A quick and easy approach would be a 2 byte per cell structure where the first byte defined the foreground an background colours and the second byte defined the pixels. That gets you a palette of 16 colours overall, any two in each cell. It is marginally over the required limit (21x21 at 1.778bpp) though, so would require a little more cleverness to eek out that extra little bit. dropping back to an 8 colour palette would do it easily, but 1.778 is so close to 1.741 that those bits can surely squeezed out from somewhere.
There's potential for extra data in the situation where the two colour attributes are the same. Possibly have a second compliment palette where
That allows for an extra set of colour pairs, to help out in unusual cases. You don't gain ability to set the bottom right pixel of each cell to the compliment colour, so even though it gives you another 16 colours to play with you get some interesting restrictions rewarding clever use.