| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Converting animation into lossy charset - how ?
I've always wondered how an algorithm decides how far is a char from another. any pointers ? |
|
... 40 posts hidden. Click here to view all posts....
|
| |
Trash
Registered: Jan 2002
Posts: 122 |
Quote: also tried to google for code but no luck.. best was some mathlab stuff which seemed to rely too much on built in functions
I got curious of this thread and decided to look for samplecode but took another route on finding it i think. There are a great deal of ASCII-demos out there with sourcecode that generates 320x200 images and converts them to ASCII-art according to a friend. I am still looking but I guess (hoping) its the same stuff you are curious about (both math and codewise)... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
so how about a pattern matching compo? I'm wondering how much better a more sophisticate algo does than my naive one. Anyone can show his? (penis:)
I've added that each pixel checks its surroundings and weighing (which doesnt seem do shit), only slightly better than counting non matching pixesl.
imho it missreads a lot of features of the original like the inverse ( on the head etc. there's a lot
original pic:
 |
| |
algorithm
Registered: May 2002
Posts: 705 |
just some basics here
select 256 random 8x8 char blocks from the source image/frames
for each block in the original, find the closest match in the 256 random entries and place these together. repeat until all blocks are read
merge the entries. repeat the above steps a few times.
The above is the basics of LBG. Now what you will find more than likely are orphan codebooks where the blocks in the source did not pair up. ELBG solves this issue by reassignment.
Another alternative after this process is to refine the entries after the lbg via hill climbing/genetic methods (as used in CSAM)
This also operates in quarter block and half block regions mapping over to the closest edges of a codebook (instead of forcing to merge the whole block)
Weighting is a must where specific source areas of the image/frames are focused on more/less than others.
There was a good point from Marq where he mentioned shifting some entries before comparison. For example a negative chequerboard and positive one look identical, but when performing a distance check, it would give the worst error ratio. Alternates to the shifting method is to transform the blocks via DCT/FFT and compare
Overall, its not really a nice way of packing data but it is certainly VERY ideal for the c64's tile mode (very fast)
Preprocessing of the animation frames also helps via attempting to keep slightly variated blocks static or some blurring of hard edges.
If ram space is limited, can transform each codevector in many ways xflip,yflip, luminance adjust, although it would use more ram for the buffer (and operate in bitmap mode usually) but speedups can be gained by adjusting only blocks that changed since the last update to that buffer (by keeping the reference recreated lookups)
if dealing with non quantized data, use slightly higher codebook entries (280 etc) as Christopher jam mentioned (this would then more than likely be reduced with some duplicates due to quantization. Alternatively quantize the data first, although mileage may vary and the merging is also less efficient. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
thanks, ATMO I'm concentrating on pattern matching, anything on that? can you do a fast CSAM with rom cset on the pic above? :) |
| |
Marq
Registered: Sep 2011
Posts: 50 |
PETSCII editor's brutal built-in converter (just simple pixel matching IIRC):
Kinda lousy, but it's there as a semi-useless add-on anyway :) |
| |
algorithm
Registered: May 2002
Posts: 705 |
Via predefined blocks, it gets much more easy to do this. The hard part is generating custom blocks that represent the image as accurately as possible.
I have a tool here on CSDB (BmpToPET) that does this,
Bmp2pet
maybe you can try it with some settings
using CSAM and custom charset I get the below
 |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Using the converter I wrote when I did my PETSCII version of the Amigaball challenge we had here on the forums a while ago.
Can probably be improved a lot, as it is now it just counts pixels. Will see if I have time to play with it a bit more. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
atmo I concentrate on pattern matching, its quite interesting to see how good an algo can match the rom cset against pics :)
will try cross correlation and probably FFT too. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
