Bonjour,

Here's a first test for a new script.
The letters are centered on colorful squares.
I'll see later if ansi codes can operate.
.xcf file is in the archive.

Hey that looks cool Sam.
Nifty idea.

Definitely cool samj.

That looks interesting.
This might help lyle and his quest for some ANSI graphics

A font to use with Gmic. The numerals and lower case characters replaced by some of the bolder ansi extended characters.
Not my credit for the font, it comes from here. https://github.com/jcs/ansiterm/tree/master/font
Just a little re-arranging in fontforge. Remember to unzip the attachment.

Bonjour,

Thank you all
@ Rich2005 : I'll try this font in the day

*****

An example with small colorful letters over a black background.
GMIC "Dynamic range increase" is used for small letters.

Thanks Rich; will check these fonts out w.r.t. ansi renders when I get a chance.

@Rich2005
Here's a test using Gimp 2.6 for this font (does not work in Gimp 2.8 )
The characters used are : w12346789abcdmefghilnkzv5j

Bonjour,

Here is a non-optimized version of the script that works with Gimp 2.8 and Gimp 2.6 Windows.
THIS SCRIPT IS VERY, VERY, VERY SLOW
If you are impatient, do not use this script
This is the only version I'll do for Gimp 2.6

Access on the RGB image by :
Filters > Render > QWERTY Gimp 2.6 ...


Gimp 2.8 : I will continue my tests for UTF-8 characters, and check the compatibility with Linux.

No, that font is not going to work at all, is it. Forget that one.

The whole point of either ascii or ansi graphics is that large areas of the graphic are composed of the same character. I go back to student days (1970) and punched cards, line printers, fan-fold paper.
That particular image is very difficult.

So I am back to a mosaic application, metapixel (linux) and this time a limited tile set (only 4000-something this time) and a bit of editing on the original to remove some of the background.



IMHO a faithfull rendition of ascii is going to be a problem. But still looking forward to the next Gmic

@Rich2005

The font is not a problem.
Gimp 2.8 Windows is not able to properly render characters.

*****

Edit : The font works fine with Gimp 2.8 Linux (picture attached)

Hi Sam , I do not understand your script but I think I know what you are trying to achieve. I think you are trying to generate a alphanumeric character based on colour and overlay the character over the image.
I tried to do something similar and perhaps it will give you some other ideas.
I copied an image of Lena and did a blur/pixellate at 20 px , Then did an elsamuko-Obama-Hope filter which gave me 5 black and white thresholded images in the xcf which I used as selections to fill with previously made .pat (pattern) files The Paterns were made to space chars at 20 px. (unfortunately my @ signs were not very accurate, hence the striping) I show you the ascii image and the ascii image with Lena .

As an aside, Rich2005 is quite correct that the ascii prints were usually done on line printers and many a banner and portrait was made, you have probably seen the ascii images on Google. One of the methods to achieve darker print was to overstrike by isuing repeated "print/ nospace" commands to the printer. Unfortunately, sometimes the paper used to shred. The ink was wet and the hammers would "pound" through the paper and cause the print train to crash with paper debris between the type slugs. I know because I worked on the 1403 printers

I tried to alter the obama-hope filter script to give more images but got hopelessly lost.

@Wbool63

Thank you for the reply and the tutorial

This is not the result I want.

What do the script I propose :
It decomposes image into rectangles with unique color.
It places characters centered on this rectangle.
The characters are not random.
It uses UTF8 characters.
The realization is not so simple ...

Bonjour,

Here is an example (Made from script-fu "ASCII UTF-8") of what I want.
Any suggestion faster than my new script running Gimp would be appreciated.

One way to speed up your script is to disable UNDO for the new image -- you are currently using 'gimp-undo-push-group-*'. The only thing that performing undo would accomplish on a new image is take you back to an empty image. This is not worthwhile (you'll notice that all of the images created under "File->Create" menu have empty undo histories).

When you use gimp-undo-push, every operation you perform that modifies the image requires an additional step to save that operation in the UNDO history. By disabling UNDO, these additional steps are avoided. How much speed is gained by this depends upon what your script is doing.

I have been looking at your script and think you might also benefit by using lists and vectors to hold all of your car_### variables. Script-fu does not using any fancy symbol lookups for local variables (the theory being that you will typically only have a few) and so when you have hundreds of local variables (such as car_0 through car_188), it might have to traverse the entire list of variable assignments every time it needs to find or change a variable's value. (Script-fu does optimize lookups for global variables, since there can be expected to be thousands of those.)

By using lists for your car_### strings, you can use 'map' and 'apply' which will simplify some of your code (though maybe not improve its speed much). You can then convert the lists to vectors and use 'vector-ref' which I suspect would be faster than your current approach which requires linear searches of local variable bindings.

Here is some of the re-working of your code that I have done. It should give you an idea of what I mean (of course, the 'define' statements would be replaced with 'let' statements). I haven't reached the part of your code that actually places the characters, but it looks as though converting 'car_set' and the 'hauteur' and 'largeur' lists from lists to vectors would address what you are doing. If you decide to take this approach, be aware that I have used a string comprising the space character (" ") instead of the empty string ("") in 'car_set'; though I treat the space as an empty string when computing its width and height.

I normally wouldn't post such incomplete code but I probably won't be able to do anything further with it until after the holiday.

Bonjour,

@Saulgoode

Thank you for the reply and suggestions

*****

UNDO

In my new script I deleted it and added this line (gimp-image-undo-disable xxxxx) . This greatly improves things

*****

lists to vectors

I will follow this advice and create things that look like this for UTF-8 :

(xxxxxx #(
(list #xE8, #xEF, #xEE , #xEC, #xC4, #xC5, #xC9, #xE6, #xC6, #x25B6 )
(list #xF6, #xF2, #xFB, #xF9, #xFF, #xD6, #xDC, #xA2, #xA3, #xA5 )
(list #xC2, #xAE, #xE1, #xED, #xF3, #xFA, #xF1, #xD1, #xAA, #xBA)
))

I'll see if it is faster, the work is not huge (I write a lot of scripts with OO.o spreadsheets and functions "text").

I'll make databases with 256 characters to avoid intermediate conversions (1 color = 1 character)

*****

Again thank you for the advice , I will make a new version of the script viewtopic.php?f=9&t=9341

@Saulgoode

Variables : Here, the principle that I will choose :

(define MyChars '(#x0021 #x0022 #x0023 #x0024 #x0025 #x0026 #x0027))
(define W_MyChars '(27 28 29 30 23 20 26)) ; determination using a loop
(define H_MyChars '(30 32 33 30 31 32 33)) ; determination using a loop

The characteristics of the character number 3 are :
(list-ref MyChars 2) ; UTF-8
(list-ref W_MyChars 2) ; width
(list-ref H_MyChars 2) ; height

Excellent script Sam!
Thanks.

Instead of using list-ref, I'd suggest converting your lists to vectors and using vector-ref.

Elements in a vector are stored in sequential memory location so performing a (vector-ref my-vec 100), as an example, can be accomplished by calculating the offset as 100 times the size of an element. Whereas performing (list-ref my-lis 100) requires that the interpreter "fetch" each of the first 99 elements in order to get to the 100th.

Lists are convenient when you know you have to access all of the elements -- for example if you are getting the character sizes of each character or finding the maximum value of their widths -- but when you need to randomly access the elements then you should use a vector.

From a speed standpoint, converting from a list to vector only takes about as long as two or three 'list-ref' calls, so it is well worth converting your lists.

Bonjour,

Rod , Saulgoode

Here is a new version of the script-fu that uses lists of characters (256 characters per list).
The script is in the archive message : viewtopic.php?f=9&t=9341&p=121326#p121326
It is always very slow (iterations are causing the problem).
Renderings are different from version 1.
Access to an RGB image by : Filters > Render > QWERTY 256 ...
Each character is positioned in size to the center of the rectangle color.

Merry Christmas

Edit 20131224 : New Version