next »

[JP]

Hi folks!  I'm working on a paint tool for ASCII/ANSI art called EDSCII.

It's still at an early stage, but I wanted to start showing it off to get feedback on what potential users would like to see.

Here's a video - some of what makes its interface unique makes more sense in motion:





You can download a windows EXE of the alpha here:

http://code.google.com/p/vectorpoem/downloads/list
Direct link: http://code.google.com/p/vectorpoem/downloads/detail?name=edscii_alpha4.zip

EDSCII is written in Python with PyGame, so you can also easily run from source on windows, OSX and Linux.

Here's the readme:
http://code.google.com/p/vectorpoem/source/browse/trunk/petscii/readme.txt

Here's my todo list, showing what's been done and what I have planned:
http://code.google.com/p/vectorpoem/source/browse/trunk/petscii/todo.txt

I'd love to hear what you think of it!

Here are some screenshots showing off early support for different character sets and color palettes:

[1982]

Holy shit this is great!

[JP]

sneak peek at raster image conversion:

[JP]

Hi hi.  I put up a new alpha build: http://code.google.com/p/vectorpoem/downloads/detail?name=edscii_alpha3.zip

Many new things since the last build, like cut/copy/paste and being able to resize the window.  The most notable new feature though is, as sneak-previewed above, raster image conversion:



To be clear, this works with arbitrary character sets and color palettes... EDSCII goes through the source image block-by-block and determines the best possible character and color combination to use.  This is actually way more sophisticated than any ASCII conversion algorithm that I know of - which all just map a blocks's aggregate value to one character from a hardcoded ramp of 8-10 characters - none of which really take into account the shape of the character pixel-by-pixel.

For those who care about technical details: the source image is first resized using PyGame's "smoothscale" function, which seems to be a generic bilinear resample.  The image's pixel data is then converted into a list-based format for faster processing - PyGame's methods for dealing with pixel data are cumbersome and slow for this kind of work.  The image is then converted into the L*a*b* color space for more accurate color comparisons - this makes for a huge improvement in quality.  Next comes a standard Floyd-Steinberg dither, which for many but not all images makes for a nicer looking result - this is an option you can set in the imgconv.cfg file.  The conversion is then done block by block while the application still runs, so you can see it in progress.  Each character-sized block is considered against all relevant potential character + foreground color + background color combinations, and the character with the lowest pixel difference (in linear Lab colorspace distance) is created in place.





At the end of this conversion you have a fully editable representation!

Unfortunately, because this conversion process is so precise it is very slow, taking several minutes to convert larger images.  I'll be looking for ways to optimize this.

[cystem glitch]

that's really cool

[Dane]

Really hot.

[Endurion]

Neat. The PETSCII looks modified however, at least it doesn't match the C64´s

Any chance to include the upper case PETSCII with the bigger range of graphic characters?

[JP]

Neat. The PETSCII looks modified however, at least it doesn't match the C64´s

Any chance to include the upper case PETSCII with the bigger range of graphic characters?

Here's what the PETSCII character set image looks like:



I'm pretty sure all the characters from the PETSCII set are included, though I could be wrong.

The way I created it was, I took screenshots of the upper and lower case character maps from an emulator, compiled all the non-duplicates into one image, and then shuffled the layout so that similar characters were next to each other (you can see this most clearly with how all the different straight-line pieces are arranged).  You can use q/w and shift-Q/W to move left/down and up/down through the map while painting.

So the ordering of the characters is more or less arbitrary.  When I write support for export to common ASCII formats (and possibly also C64 .PRGs for authentic demos!) I'll make sure this gets sorted into the order the actual native character set uses.

[Endurion]

Ah, I mistook the second screenshot for being PETSCII, my mistake

The image you showed there seems to be the complete set of unique characters from both lowercase/uppercase already. Good one!

Played around with it, neat!

ImageShack doesn't seem to work, so here:

http://imageshack.us/photo/my-images/823/edscii.png

Is there an image export?

<Nerd mode>
The palette is weird (for the C64), white doesn't look white; also the color ordering is weird.
Also, would be neat to have a mode where the proper restrictions of the machine apply
</Nerd Mode>

Once it crashed when I pressed the right mouse button (right at the start), other than that it was quite solid.
Middle mouse button is offputting, I usually don't like when the wheel is misused as button. It happens to easy accidentally.

Nice work!

[Pineapple]

this looks awesome, and incited me to write something similar for my own ansi graphics bit

will report back if I can actually get the damned algorithm to work correctly (which is getting shit done at a speedy 3ms/tile, and the issues should not be to do with what makes it so snazzy)

[JP]

<Nerd mode>
The palette is weird (for the C64), white doesn't look white; also the color ordering is weird.
Also, would be neat to have a mode where the proper restrictions of the machine apply
</Nerd Mode>

Yeah, it's a bit difficult to come up with a canonical C64 palette.  The one I'm using is sourced from this classic image:



which is also what my forum+twitter avatar icon uses.

This guy did some really interesting work to get an accurate hardware-sourced C64 palette, but the white on it seems very dim and the value separation of the greys is off.  I might try to make a hybrid palette based on that and the current one.

BTW, all you have to do to use an alternate palette is drop an 8-bit PNG file into the pal/ subdirectory, and then inside the program press TAB to bring up the command line, then type "pal mypal" where "mypal.png" is the name of your palette image.  The readme has some more info.

Is there an image export?

Yes, try "export filename" at the command line, where "filename" is the name of the file you want to save.  That will produce a native-resolution PNG.

Once it crashed when I pressed the right mouse button (right at the start), other than that it was quite solid.
Middle mouse button is offputting, I usually don't like when the wheel is misused as button. It happens to easy accidentally.Nice work!

I need to spend some time hunting down crashes.

What are you using the middle mouse button for?  I designed the app to mainly use left and right mouse buttons, but I'm using raw SDL button numbers, so that may correspond with different buttons on different systems.

[Endurion]

Copy/Paste requires the middle mouse button.

[Pineapple]

My results are much less precise, but they're also quite quick. If you're interested in the particular algorithm I'd love to share and try to improve upon it. Note that increasing palette size is going to also increase running time.



14.5 seconds (7.6 with only 16 colors)



9.4 seconds (7.9 with only 16 colors)



3.5 seconds (1.6 with only 16 colors)



11.2 seconds (6.1 with only 16 colors)



5.3 seconds (3.0 with only 16 colors)


another edit:
oops, I had a bit of a bug going on so that it was missing some of its intelligence in considering characters. I updated the images and times with that of the fixed algorithm.




thanks to further optimization and tweaks, this one only took 4.5 seconds.




bonus image: different character set




yet another edit.

for a more direct comparison, I used your character set and the same number of palette colors (64). this image took 585 milliseconds to produce.

[JP]

Copy/Paste requires the middle mouse button.

Ah yes.  The usual CTRL-X, CTRL-C, and CTRL-V also work for cut, copy, and paste, respectively.

Awesome to see people doing art with it!

[JP]

My results are much less precise, but they're also quite quick. If you're interested in the particular algorithm I'd love to share and try to improve upon it. Note that increasing palette size is going to also increase running time.

Really, really awesome!  It looks like you're matching colors and characters separately, which is smart - 1-bit comparisons are much faster.  When I profiled my algorithm a lot of the time was taken up with simple square root calculations, used for the L*a*b* color difference checks, one for each pixel in the block.

What's cool is that each algorithm has its own aesthetic, adding its own weird details.  And because the output data is common to all of them, there's no reason you couldn't take the best bits from each for a piece.

[Pineapple]

I'm not sure how viable it would be to combine the two, I think they work pretty differently. Anyway, a rough description of the algorithm.

note: "Luminosity" refers to red*3+green*6+blue


- Make an initial pass to store information about the on/off bits of the tileset in an array for quick access

For every block in the image which is to correspond to some tile:

 - Make an initial pass over each pixel to store the block's color information in arrays for quick access, also compute the lowest and the average luminosity of the block

 - Check every tile against the block to discover which has the fewest bits which differ from the block where a luminosity above the target ((average*7+lowest) shr 3) should be an on bit and lower or equal should be an off bit. An exact opposite is considered to fit just as well as an exact match to account for that colors can be alternated.

 - Simultaneously (but independently) determine which of all the colors in the palette results in a closest match for the foreground and the background (with colors scaled for luminescence such that a difference in green carries twice more weight than a difference in red which carries thrice more than a difference in blue)

[JP]

New alpha here: http://code.google.com/p/vectorpoem/downloads/detail?name=edscii_alpha4.zip

This is the first windows build with the image conversion stuff.  Plus I fixed all the non-minor bugs I could find.  It's in pretty good shape, so I'm going to leave it alone for a while and focus on other projects.  Do tell me what you think, and where it's lacking.

Thanks!

[Kaelan]

MSVCR71.dll is missing for the windows build.

EDIT: Also I keep getting crashes when I try to use the conv command:

Code:

Traceback (most recent call last):
  File "edscii.py", line 2593, in <module>
    input()
  File "edscii.py", line 2244, in input
    app.commandline.input(event.key, ctrl, alt, shift)
  File "edscii.py", line 1519, in input
    self.run_command()
  File "edscii.py", line 1502, in run_command
    self.parse_command()
  File "edscii.py", line 1653, in parse_command
    if i.image:
AttributeError: ImageConverter instance has no attribute 'image'

[JP]

MSVCR71.dll is missing for the windows build.

EDIT: Also I keep getting crashes when I try to use the conv command:

Code:

Traceback (most recent call last):
  File "edscii.py", line 2593, in <module>
    input()
  File "edscii.py", line 2244, in input
    app.commandline.input(event.key, ctrl, alt, shift)
  File "edscii.py", line 1519, in input
    self.run_command()
  File "edscii.py", line 1502, in run_command
    self.parse_command()
  File "edscii.py", line 1653, in parse_command
    if i.image:
AttributeError: ImageConverter instance has no attribute 'image'

D'oh, I meant to fix that.  It means the image conversion didn't initialize properly, for some reason - possibly as simple as file not found.

If you can run from source, try adding this line right after line 347 of imgconv.py:

Code:

self.image = None