Re: Jeri videoboard gfxconv

From: Jeri Ellsworth (
Date: 2001-05-25 12:26:11

I'll respond to your letters after the show... I'm very interested in
what you are doing.

--- "Hársfalvi, Levente" <> wrote:
> Hi!
> I'm having some problems with the gfxconv stuff I'm working on (
> usual
> :-/ ). ...At first, sorry for the long letter; just delete if you're
> not
> interested in color optimization issues.
> This routine is intended to take raw 24 bit 320x400 images and
> convert them
> to the C64 styled, enhanced multicolor mode of Jeri's new videoboard
> (in the
> same resolution). I'm at the last stage of the optimizer algorithm.
> Things
> like reducing the number of colors, picking up a suitable value for
> background color and selecting color triads for each 4x8 color blocks
> are
> done (and work O.K. as far as I'm concerned).
> (Just for a short explanation: the mode works exactly as the usual
> multicolor bitmap mode, except for the resolution and the colors. The
> resolution is just 'expanded', no real change in the organization.
> For the
> color thing: there is a color palette with 256 entries (instead of
> the
> original fixed 16 color long 'palette'). Color registers (like
> background
> and the others) are treated like 8 bit indexes to this palette (all 8
> bits
> are used, instead of 4 bits like the original VIC did). In bitmap
> modes, the
> situation is similar, with one addition: the color memory values (the
> usual
> 4 bit nibbles) give the low 4 bit nibbles of the index. The higher 4
> bit
> nibble is given by the high 4 bits of the color RAM, and this higher
> 4 bit
> is common for all color indexes in the respective 4x8 color block.).
> There is a problem. In MC mode, the above (last) rule means that all
> 3 MC
> colors for color blocks must be in one (16 colors long) palette
> chunk.
> (Different color blocks can select colors from different chunks, of
> course).
> No problem when it's just one, or a few blocks -- but this rule must
> be
> taken into account for _all_ such color blocks in the image, creating
> a
> heavy dependence between colors.
> (Quick calculation shows that if there are just 20 colors on the
> whole
> image, and each colors are featured with the other colors in the
> image at
> least once, with the above organization they occupy exactly 256
> places from
> the palette.)
> I inserted a small code piece that listed out the color dependencies
> on the
> test image and the results are hmmm... 'embittering'. When using
> color
> reduction to just 64 colors for the whole image, some colors depended
> on
> 30-40 other colors in the map.
> I think I know the 'direction', just don't know the way. I hope
> someone did
> similar programming tricks, so he could give me some help.
> Imagine an X*X type symmetrical matrix, where X is the total number
> of
> colors in the image. If there's a '+' in the (i,j) position of the
> matrix,
> that means that the two colors (i, and j) were found in the same
> color block
> of the image at least once (ie. they're dependent). (Crosses in the
> (i,i)
> positions correspond to the fact that the i-th color was found in the
> image
> at least once (ie. 'dependent on just itself')). The problem to be
> solved:
> form <=16 disjunct groups from the above dependency matrix, where
> each
> disjunct groups include <= 16 elements, with the possible least
> number of
> ignored dependencies.
> ...Well, this is what is above me at the moment. Anyone with some
> ideas on a
> working algorithm?...
> Thanks,
> L.
> -
> This message was sent through the cbm-hackers mailing list.
> To unsubscribe: echo unsubscribe | mail

Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail

Archive generated by hypermail 2.1.1.