| |
algorithm
Registered: May 2002
Posts: 702 |
CSAM Animation/Image quantizer - test version
A preview and unfinished version of the Char Selection and Matching (CSAM) image quantizer is now ready for download
This tool creates (or tries to create) an optimal selection of 4x8 char blocks by analysing the image.
the user has control over the threshold of character selection allowing the image to use less characters or more.
It is also possible to add character data to previous char data.
for example, an image can be loaded, the threshold can be adjusted so that around a quarter of the
256 character blocks are used, then another image (or frame) can be loaded and characters appended to the
definitions
There are a lot of features currently missing from this preview. more notably the manual selection of char blocks as well as the activemovie component which allows video to be imported and converted + the multiframe comparison.
any comments, critisisms and info are welcome
download it from
http://www.naveedkhugiani.com/CSAMquantizer.exe |
|
| |
Raf
Registered: Nov 2003
Posts: 343 |
Good stuff! will it be difficult to play a prepared movie on c64 ? will it be possible to play movies like on pc - taking care only about differences between picture frames? (I guess it will be only faster or so if less that 1/3 content of screen changes among 2 frames...)
www.vulture.c64.org |
| |
Scout
Registered: Dec 2002
Posts: 1568 |
Good work!
I guess we get an tsunami of FMV video demo's now :) |
| |
algorithm
Registered: May 2002
Posts: 702 |
RAF: Unpacked, each frame is essentially a character map (0-256) pointing to the charblocks, 40x25 in size (1000 bytes). The PC preprocessor is similar to the cinepak codec in windows in someways which essentially works in a similar way (eg bytes point to a codebook containing selected small blocks (4x4, 8x8 etc) of the picture. The only thing which is massively different is the selection and matching of characters. There is still huge room for improvement in the matching and selection routine.
to pack in even more frames, the 40x25 maps can be compared with each other and only the differences stored, etc and then additionally packed, etc. its down to the coder to decide whether to unpack on the fly or to depack a stream of 1k 40x25 definitions |
| |
Oswald
Registered: Apr 2002
Posts: 5029 |
some kind of batch processing is missing. e.g. one could set a base filename, and a 0 padded index with lower and upper bound. (filenamein001.in -> filenameout001.out). Maybe I'm missing something but for me nothing happens when I press process. also a dither mode which only allows abab aaaa or bbbb pattern feels like could improve pack ratio. Will be a great tool if finished.
edit: ok I got it now how the process button wox :) |
| |
algorithm
Registered: May 2002
Posts: 702 |
Oswald: Batch processing to follow, as well as importing of movies, selecting the frames and automatic conversion.
Before the process button can be used, characters have to be placed into the codebook 'new codebook' by using the new codebook option. The program at its stage now only works on individual frames. (for multiple frames, you would need to use a tool to save each frame as a bitmap or jpeg. for analysis of other frames, you may use the 'append to codebook' etc.
to do:
automatic frame saving and video loading.
multiple frame analysis.
data packing
other dither methods to improve pack rate
manual character selection. useful for selecting important areas of the video such as eyes, nose, edges etc etc |
| |
Oswald
Registered: Apr 2002
Posts: 5029 |
I'd be interested in the algo u use, or if u have a few links I'd be thankful aswell :)
btw, somehow you should weigh for chars that are used often, It loves to miss monocolor areas (when in undithered mode) for some other chars. |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
We'll get a shitload of porn conversions now. Hooray! \o/ |
| |
algorithm
Registered: May 2002
Posts: 702 |
the algo is based on vector quantisation. but uses my own analysing and selection.
the concept for single images is extremely straightforward. combinations are placed in the codebook, each block in the dithered image is then compared with the codebook, difference based errors are analysed, and other combinations are entered / replaced into the codebook until less errors are encountered.
multiple frame analysis uses grabs image chunk data from various frames until the majority of the frames in total produce less errors. Look up 'vector quantisation' or cinepak for more info |
| |
algorithm
Registered: May 2002
Posts: 702 |
oswald: True, the routine concentrates mainly on complex areas of the image. very easy to implement. only have to perform a histogram on which char blocks are mainly repeated and to input this into the code table, and then to continue with the usual codetable selection or /and to manually select char blocks if required until the result looks better |
| |
Raf
Registered: Nov 2003
Posts: 343 |
well.. this way there will be possibility to play realtime video with sampled sound - all streamed on fast device like ide64 ... nice :)
www.vulture.c64.org |
| |
algorithm
Registered: May 2002
Posts: 702 |
talking about samples, a similar method can also be applied to audio data. While ADPCM2 can compress each sample to 2 bits, this would only give a comp ratio of 2:1 when expanding to 4bits. with the codebook version 4:1 or higher can be achieved no probs (in combination with post processing/stretch interpol. decoding would be extremely straightforward, |
| |
Oswald
Registered: Apr 2002
Posts: 5029 |
streaming video (koala bitmaps+samples) was done ages ago by bigfoot/ breeze :P |
| |
algorithm
Registered: May 2002
Posts: 702 |
streaming from floppy or harddrive? |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
Quote: well.. this way there will be possibility to play realtime video with sampled sound - all streamed on fast device like ide64 ... nice :)
www.vulture.c64.org
hey, don't forget the mmc64! ;-) |
| |
Oswald
Registered: Apr 2002
Posts: 5029 |
streaming from pc.
the transfar code was this:
lda cia
sta mem
lda cia
sta mem
lda cia
sta mem
lda cia
sta mem
lda cia
sta mem
lda cia
sta mem
...
and every now and then:
lda cia
sta d418
for the digis :)
can you do it faster? |
| |
JackAsser
Registered: Jun 2002
Posts: 1994 |
Quote: streaming from pc.
the transfar code was this:
lda cia
sta mem
lda cia
sta mem
lda cia
sta mem
lda cia
sta mem
lda cia
sta mem
lda cia
sta mem
...
and every now and then:
lda cia
sta d418
for the digis :)
can you do it faster?
You liar! That would result in a non-stable scrolling image since you don't have any synchonization between the PC and the C64. :D |
| |
Oswald
Registered: Apr 2002
Posts: 5029 |
jack, well it actually works, as I clearly remember seeing this code in monitor. but have to ask bigfoot for exact explanation. the explanation I vaguely remember sounds something like: "the pc is so much faster than the c64 that when the c64 sets the memory r/w line (?) low/high (?) the pc can put the data out before the actual c64 read takes place" |
| |
Style
Registered: Jun 2004
Posts: 498 |
I remember Highlander/FLT used to use his c64 as a PC soundcard, jamming nybbles into $d418 purloined from the PCs parallel port using a special driver under freebsd.
Personally, I just went and bought a Vibra16 and installed a real OS. But Paul was funny like that :D
|
| |
algorithm
Registered: May 2002
Posts: 702 |
Anything else apart from a stock c64 and diskdrive is considered cheating :-}
|
