Closed sindresorhus closed 2 years ago
I don't think it's a bug per se — it is working as designed. When you ask for low quality, you get frames limited to very few colors. MPEG compression adds changes all over the place, which requires redraw of a large area, which then is a mess, because it isn't allowed to use enough colors to redraw it nicely.
This case could have been handled better if I optimized specifically for it, but I never did. The quality option is documented as: "1-100, but useful range is 50-100"
As a temporary fix, what do you think of making the "Quality" slider range be constrained to 0.2...1
?
Yes.
@kornelski With latest Gifski, I noticed a small artifact on the lowest quality. Notice how the blue rectangle at the top (which says "Open the Mac app store...") is stuck on all the frames. Not a big deal. Just wanted to mention it in case there's anything that can be done about it. It was a user that sent me this.
Source video: https://user-images.githubusercontent.com/170270/149186875-13668834-b4e3-42c4-a478-15fc0608601d.mov
This artifact is file size reduction in action. Transparent pixels are cheaper than white pixels, so not overwriting the background color is cheaper than setting it to white. The previous color is kept when it's "close enough", and at low quality, everything is close enough.
I kinda feel that when the whole contents change (in the GIF when there's a page change), it should waste some white pixels to get a clean slate. But it's not a big deal.
GIF: https://user-images.githubusercontent.com/170270/148274421-a1d41304-e418-45ea-b21c-69a45289afaf.gif
Source video: https://user-images.githubusercontent.com/170270/148274565-5ec81390-60fc-4eab-ad18-b2839deca842.mov
@kornelski Is there anything the gifski library can do about this?