On 25 Sep, 13:46, "Andrew Thompson" <u32984@uwe> wrote:
kitkatrobins wrote:
..
...Do you know of any alternative Quantisation
implementations on this source code? My understanding of Quantisation
code isn't very strong. Or do you know of any links to gain a better
understanding of Quantisation?
The short answer is 'no'. I treated the FM library as though
it were a 'black box' and never even looked into the code itself
to any degree, guessing that the author knew more about it
than I ever would.
As an aside though. What format are your source images?*
The quantisation is meant to reduce the source imageS
colors to a single palette of 256. If the images are all the
*same* 256 colors to begin with, its work is done.
This might be easier (or at least, more control over final
size) if you were to reduce the colors in the original
images to the same 256 color palette prior to running
them through the encoder.
* GIF images are automatically 256 colors, but no two
will necessarily have the *same* 256 colors, OTOH,
grayscale images (for example) should be.
--
Andrew Thompsonhttp://www.athompson.info/andrew/
Message posted viahttp://www.javakb.com
The source files are from a single animated gif, which in turn is
split into several frames. I would guess each time it splits it saves
the palette information and thus when encoded back it duplicates these
values?
The single animated gif is split into several frames using this
Quantisation (http://msdn2.microsoft.com/en-us/library/aa479306.aspx)
(I'm using .net but principle is the same), if you add the file sizes
up of each of the 15 frames, it amounts to about 70k + 10k for the
delay information.
Somehow I need to reduce the palettes in each indiviual image and use
one global one, would that work? if so how is best to go about it?
The difference could also be compression...
GIFs wasn't free to license. I don't know the details of what you're
doesn't. Hope this helps.