| |
algorithm
Registered: May 2002
Posts: 705 |
CSAM Super - In the works
A new tool in the works.. CSAM Super! Created dozons of console and win32 based tools for VQ Image/Video encoding and decided to merge and convert them into one application. (Win32 and linux)
At the moment full color/grayscale bitmap/avi import to specified frames along with c64 preview.
Adjustable settings 'on the fly' while encoding to tweak even more quality. All options available and ready.
This application is based on my own Codebook generation method which is even more of an improvement over the vq output from the c64 demonstrations recently released by me. It gives over 25% improvement over standard LBG and significant improvements over ELBG and PNN codebook generation methods.
Features a combination of clustering with various artificial intelligence hill climbing methods to create a more optimum codebook in combination with genetic mutation and the ability to select from various block sizes.
To implement a weighting scheme to concentrate more on specific areas of the image (manual adjustments) as well as manual source block to codebook selection for even more control.
C64 Video studio to be implemented as well which converts the sequence into various c64 graphic modes with various compression methods. (The preview c64 modes on the screenshot are just an approximation) But the VQ quality is real 256 8x8 blocks in color!
I would like some feedback and info on what you would like to be implemented in this application.
 |
|
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
NUFLI output please. |
| |
Jammer
Registered: Nov 2002
Posts: 1335 |
So, you first create codebook and then convert it to c64 pallette? ;) |
| |
algorithm
Registered: May 2002
Posts: 705 |
@bitbreaker. NUFLI output would not be feasible due to the routine operating in blocks that would not match colors in sprite layers that would spread over more than one char block. There is a way around this but would give more limitations in quality. Static sprite colors (eg MUCSU would not be an issue however) - As well as giving more processing space for the bitmap plotting.
@jammer. Yes, the output is converted to C64 format later and the encoder operates on the truecolor image.
However an increase in encoding speed can be achieved by using direct c64 conversions as the input (In some cases due to low complexity of data, it can give better results) - The Terminator Animation sequence as well as the VQ slideshow released operated directly from 160x200 4 color multicolor conversions |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
I think reducing color depth beforehand can however scale up the error level of a block when being compared, even more when you force dither patterns upon a block and by that also lower the virtual resolution per block. So i'd say you do it the right way with reducing to 16 colors and e.g. 160x200 after codebook generation. My experience is that this gives visibly better results. I did so for e.g. with the boobs in Ächzzeit.
The nufli request was not meant serious, btw. ;-) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
interesting topic, I'd try to remove saturation for even better matching, in the light of what has been said. |
| |
Stone
Registered: Oct 2006
Posts: 172 |
You're doing awesome work Naveed and it would be very interesting to see the code. Any chance of that? |
| |
algorithm
Registered: May 2002
Posts: 705 |
@oswald. Saturation does certainly affect the quality due to more blocks being required to represent the color image.
@stein.
Thanks Stein. Its nothing special really. The bottleneck is the VQ encoder which calculates the error of the image in order for the main routine to determine the action (whether to mutate, pick a new family group, cluster whole etc.) I am sacrificing quality for speed at the moment however (using opcodes that perform euclidian distance on multiple pixels simultaneously) The VQ encode runs at approximately 200,000 iterations per minute (and around 90,000 for color). Will implement more accurate checks for higher quality |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
more emphasis on the user interface please, the earlier CSAM was not possible to use intuitively without reading into the docs, Not that I've used it extensively, but I've tried a few things in them. Just saying :) Even after reading the docs I was often puzzled what I am doing or supposed to, and what the prg is doing inside. I mean the whole workflow, setting up how many anim phases, how many chars u want in a screen, Have you already done a frame or not etc. it was confusing. Should I first press the convert to c64 palette button first, before pressing the "convert to chars" button or not, etc. |
| |
algorithm
Registered: May 2002
Posts: 705 |
Thanks for this info oswald. I may incorporate a Wizard tab as well which goes through the process step by step. All in all, its merely converting a video or image to 256 8x8/4x8 blocks with the lutbuffer uncompressed using 1k of data (1 byte per 8x8 block lookup etc)
An automated mode will also 'tweak' settings on the fly without manual intervention |
| |
Jammer
Registered: Nov 2002
Posts: 1335 |
And now Project Firestart reboot, please! With cutscenes containing colored CSAM animations and compressed 1-bit samples :D Please, please, please :D Any possibility to stream such data during runtime? |
| |
algorithm
Registered: May 2002
Posts: 705 |
@jammer.
Framerate should be ok in bitmap mode depending on how much change there is in the image. I would use the delta approach to plot only changes to the screen, then flip buffer, and plot changes and the new changes to the hidden buffer. etc. Bearing in mind that the koala video mode i demonstrated in 'Algotecher' and 'better' was not using any of this (full bitmap plots), I would expect frame rate of around 12fps with around 30% change inbetween each frame or so. To have Digi's with it with streaming is certainly doable, but would need to compromise between processing use of either the video or audio (or to use a more quicker decode method - eg ambtc for audio) |
| |
Jammer
Registered: Nov 2002
Posts: 1335 |
What about charmode then? :) BTW That eye above is in charmode? |
| |
algorithm
Registered: May 2002
Posts: 705 |
The charmode has the advantage of being very fast (1 byte plot for a 8x8 char.) but only 4 colors.
The eyepicture is an unrestricted c64 16 color image (it can look similar in mcol-laced) but with flicker, alternatively I can use a fixed multicolour 3 color sprite underlay (MUCSU) for non laced image similar to the quality in the preview |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
dont forget d800 from charmode :) |
| |
algorithm
Registered: May 2002
Posts: 705 |
@Oswald. Yes that is going to be one of the additional modes :-) |
| |
algorithm
Registered: May 2002
Posts: 705 |
An update on this app.
Weighting feature available to select individual strength of blocks while encoding. (for individual frames as well)
Manual codevector selection while encoding
Some statistical information such as byte usage of frames/total frames as well as highlighting which codevectors resemble which part of the image etc.
The main core is now complete. Now for the conversion to c64 format and packed animation/image frames
Hoping to include a fair amount of gfx modes
 |
| |
algorithm
Registered: May 2002
Posts: 705 |
A video preview of the application here..
http://www.youtube.com/watch?v=-jSUS4nBaqE |
| |
Conjuror
Registered: Aug 2004
Posts: 168 |
Looks amazing. Enough with the tease :D |
| |
algorithm
Registered: May 2002
Posts: 705 |
Some updates as follows
New dithering option (Block based dispersed dither)
Full color based multicolour char mode (and interlaced)
Preview on youtube below
http://www.youtube.com/watch?v=_kflgq4BEtY&feature=youtu.be |
| |
algorithm
Registered: May 2002
Posts: 705 |
Released now!
CSAM Super |
