Could it be the simple fact that I'm sorting the palette by hue to try to make the numeric predictor more likely to be helpful? Ordering obviously makes a difference, but there isn't time to try all of the 16! possibilities so that's my current guess. Another way through might be to build some sort of graph that awards each palette colour a distance from the other colours depending on the probability of it falling next to them in the image, then to arrange the palette so that colours that are more likely to be nearby in the image are more likely to be nearby in the palette.
On Sat, Jul 31, 2010 at 3:01 PM, Adrian Brown <[email protected]> wrote: > Yer - yours is probably a little better then, the flashback screens are more > what you want to look at. Ill play around a little more. > > Adrian > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Thomas Harte > Sent: 31 July 2010 14:31 > To: [email protected] > Subject: Re: Dizzy (was:Porting spectrum games...) > > Oh, but wait! Enabling searching for the best LZ77 window and pattern > size (just in terms of 4 bits, 8 bits, 12 bits or 16 bits - not a > completely free search) seems to put me at: > > 1: 256 x 141 : 4593 > 2: 256 x 141 : 5731 > 3: 256 x 192 : 8520 > 4: 256 x 192 : 8267 > 5: 256 x 192 : 9440 > > Currently a little worse than you for the Dizzys, a little better for > the Flashbacks. I'm going to see if there's anything to gain from > variable length LZ77 regions (at the minute it picks the predictor per > line by trying every predictor with every combination of LZ77 length, > then bundles together all the best predictors into a big block and > LZ77s the whole lot, finding the best window/pattern size afresh for > the whole lot). I guess I can look for patterns in the results of the > line-by-line search. > > On Sat, Jul 31, 2010 at 2:04 PM, Thomas Harte <[email protected]> > wrote: >> Oh, but for the record, with what I think is a completely straight >> reimplementation of PNG that isn't particularly intelligent in >> searching for the smallest size: >> >> 1: 256 x 141 : 5190 (774 bytes worse than you) >> 2: 256 x 141 : 6439 (826 bytes worse) >> 3: 256 x 192 : 10041 (938 bytes worse) >> 4: 256 x 192 : 9326 (732 bytes worse) >> 5: 256 x 192 : 10599 (496 bytes worse) >> >> Which puts me, on average, about 10% worse than you. >> >> On Sat, Jul 31, 2010 at 1:33 PM, Thomas Harte <[email protected]> >> wrote: >>> Sadly I'm already doing that and still doing a lot worse than you. At >>> this point I'd definitely suggest that if you're willing to donate >>> code then it be used over anything I can come up with. >>> >>> I'm still trying though! >>> >>> On Sat, Jul 31, 2010 at 1:23 PM, Adrian Brown >>> <[email protected]> wrote: >>>> Oh one thing ive found out that may help in your tests. Dont compress >>>> the data as nibble pairs. If you convert the data into bytes (only >>>> using values 0 - 15) then compress that. (obviously in the decompressor >>>> you need to patch it back so two bytes become one nibble). You may find >>>> you get a much better compression rate. >>>> >>>> Adrian >>>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] >>>> On Behalf Of Adrian Brown >>>> Sent: 31 July 2010 13:16 >>>> To: [email protected] >>>> Subject: RE: Dizzy (was:Porting spectrum games...) >>>> >>>> Ok, providing I havent made any mistakes on the compressor it looks like >>>> the sizes are down at: >>>> >>>> 1: 256 x 141 : 4416 >>>> 2: 256 x 141 : 5613 >>>> 3: 256 x 192 : 9103 >>>> 4: 256 x 192 : 8594 >>>> 5: 256 x 192 : 10103 >>>> >>>> Ill write the decompressor and check, depends how slow it is to >>>> decompress i guess ;) >>>> >>>> >>>> >>>> >>>> >>> >> > > > >
