-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to cache using rgba8888 in applyPalette? #13
Comments
I had a similar issue, and here is what I've tried. When using the library's functions, I get a flicker: const palette = quantize(data, 256);
const index = applyPalette(data, palette); I tried @davepagurek 's solution, but it only showed a single color (on github, it looks black, but when i open the same file on my machine, it is the gray background color): const palette = quantize(data, 256);
const index = getIndexedFrame(data, palette); What worked for me was to reduce const palette = quantize(data, 4);
const index = applyPalette(data, palette); |
So, I'm looking into this a bit today. The reason I didn't use full uint32 as keys is that it's very slow (500ms to 5seconds type of slow). I think it would be worth keeping it as an option, although part of the reason for the modularity of this library is to allow users to choose their own quantization functions (which might be more accurate but much slower). Another approach that is worth exploring, aside from reducing color counts, is to use dithering. In the latest I also wonder if there is any other better way of searching/indexing colors that do not reduce bit depth or that are able to maintain some choices across frames. I think gifenc is due for a litttle overhaul at some point, cleaning up some of the code and maybe introducing perceptual color difference functions that are already present in the source code but not exposed to the library. |
This makes sense! And like you mentioned, using our own function instead of
Your output image looks great! I suppose this might still potentially have flickering, but due to the dithering breaking up large bands of color, it would be less likely to occur in large areas like in my original gif? That seems like a good compromise between speed and output quality.
A potentially quick fix might be to let users pass a |
you might quantize data use foramt not transparent, like default 'rgb565'. so when use nearestColorIndex fun the 2nd params is 3 length array. modify davepagurek's code like this:
with all i*4 tmp in s, will like this
transparent format is frame.slice(s, s+4) |
In my scenario, adding a byte on the end of 4 bytes in the cache key base on @davepagurek code.
|
Hi! Firstly, thanks for this library, it's really useful!
I've noticed some flickering that can happen in outputted gifs. Given images generated from this p5 sketch, I get output gifs like this:
I've narrowed this down to the
applyPalette
function. What I believe is happening is this:applyPalette
caches palette indices based on a hash of the color, which depends on theformat
you pass inI'm dealing with the flickering by effectively writing my own version of
applyPalette
which caches based on the full 8-bit-per-channel color:This results in an output like this:
Anyway, just putting my discovery here in case something like this would be helpful to include in the library! An alternate way of dealing with the flickering might be to find the nearest palette index based on the bit-truncated color as opposed to the source color.
The text was updated successfully, but these errors were encountered: