mirror of
https://github.com/NickeManarin/ScreenToGif.git
synced 2026-04-26 07:35:54 +03:00
[GH-ISSUE #1069] [Feature Request] Yet another GIF Encoder #2987
Labels
No labels
copy cats
duplicated
future feature
pull-request
⬜ Accepted
⬜ Completed
⬜ Help Wanted 💪
⬜ In Progress
⬜ Missing Details
⬜ Pending
⬜ Waiting For Answer ⏳
🆕 feature preview
🔷 Bug 🐛
🔷 Out Of Scope
🔷 Out Of Scope
🔷 Question
🔷Enhancement
🔷Enhancement
🔷Invalid / External
🔷Knowledge Base
🔷Won't Fix
🕑 High
🕑 High
🕑 High
🕕 Medium
🕙 Low
🕛 Critical
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ScreenToGif#2987
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @koszeggy on GitHub (Feb 7, 2022).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/1069
Originally assigned to: @koszeggy on GitHub.
I've been actually working on this already, but I didn't want to introduce an unwanted pull request without any notification.
Motivation
I really like ScreenToGif and it is very useful in a lot of cases. However, the built-in GIF Encoders have some weaknesses, especially with alpha images. Additionally, the built-in encoders do not support dithering and have only a few quantizers (eg. there is no B&W one), etc. To address these issues I included my GIF Encoder in ScreenToGif but so far it was meant for private usage only. As it proved to be quite useful for me now I ask if you are also interested in it.
Comparisons:
Preview:
Still under development but now it looks like this (it also shows some of the supported quantizers and ditherers):
Bonus (offtopic):
During development I bumped into some issues regarding user settings deserialization, where I noticed the comment about looking for a better solution. As a matter of fact, I addressed the problem on a separate branch. The refactored version is 253 lines shorter than the original, and it doesn't need adjustments when using new types in user settings (such as new enums, nullables, etc). Its branch was created from the new encoder's feature branch rather than master (not published yet), and as it uses some features from the same library referenced also by KGy SOFT Drawing Libraries maybe it makes sense if I create a pull request only if the new encoder is accepted along with its dependencies.
So what do you think? Will you accept a pull request for the new encoder? If so, I could improve the user experience a bit (more tooltips/hints, etc.), and maybe I can add some localization, too. Maybe I could finish it in a week or two.