[Feature Request] Yet another GIF Encoder

[koszeggy]

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.

📝 Note: I know about the external 3rd party GIF Encoders but I don't cover them in this issue. KGy SOFT Drawing Libraries are built for .NET, providing a direct, in-proc solution with good integration, supporting async-await, progress reporting, cancellation, etc.

Comparisons:

⚠️ Disclaimer: The new encoder does not aim to replace the existing ones. Sometimes the built-in encoders can be faster, more compact or better in other ways so it would be just a new option. The images below do not reflect the general quality difference of the encoders. It is intentionally a special example where the new encoder might be a better choice.

Animation	Description	Size
Original APNG image		363.1K
System Encoder		288.4K
STG Encoder (Default Preset)		341.9K
STG Encoder (High Quality Preset)		347.1K
STG Encoder (High Quality • Graphics Preset)		256.6K
STG Encoder (High Quality • Transparent Background Preset)		320.8K
KGy SOFT Encoder (Balanced Preset)		151.2K
KGy SOFT Encoder (High Quality Preset)		158.1K
KGy SOFT Encoder (Low Quality Preset)		102.7K
KGy SOFT Encoder (custom preset: Wu quantizer, white background, no alpha)		276.1K

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.

[NickeManarin]

Hi @koszeggy, this looks great!

I'm yet to look at your branch (next weekend when I have more time). If I understood correctly, you want to make your encoder available with ScreenToGif, not as an external download, right?

Also, I'm interested in knowing how you solved my issue with the settings parsing. :)

[koszeggy]

If I understood correctly, you want to make your encoder available with ScreenToGif, not as an external download, right?

That's correct. It is downloaded at compile time from NuGet.

In the meantime I finished the polishing and added some localization so I can create the pull request for review.

Also, I'm interested in knowing how you solved my issue with the settings parsing. :)

I updated and published the refactoring branch so here you can see the new version. I tried to generate the largest possible settings file to test it (I just opened all the possible menus and clicked randomly here and there 😁) and now it seems alright to me but maybe it needs some more throughout testing.

[koszeggy]

I added the pull request for the new encoder so you can review it.

It does not contain the settings parsing refactoring but feel free to create a separate issue for it. As I mentioned it has a dependency on the same library the new encoder also references so it seems reasonable to create a pull request for that after this one is accepted.

[NickeManarin]

Thank you!

[NickeManarin]

Btw, do you have an ARM64 device to test out this new feature? Looks like the DLLs are 32 bits (when the project is exported as ARM64). Not sure if this will cause some problems with ARM64 computers.

[koszeggy]

The .dlls are AnyCPU .NET assemblies so they must be able to be referenced by both 32 and 64 bit .NET applications.

From .NET Reflector:

However, I don't really know how .NET is realized on an ARM64 system, but I would be really surprised if it didn't work because it would be a serious issue for almost every other packages, too. But let me know if any issue occurs on an ARM platform.

If anything, possible big endianness might be a problem because I have never tested the libraries on big endian systems. But AFAIK the ARM64 CPUs supports both modes so hopefully a Windows uses the little endian mode on ARM, too... Edit: Yes, it seems so.

[NickeManarin]

Hi @koszeggy, I'm receiving some feedback about the "Save As" panel closing and not opening anymore after selecting the KGySoft encoder.

I'm unable to reproduce that, but from what I could see in someone's else computer, selecting the encoder will simply close the panel. Trying to click in "Save As" to expand the panel again will give no result.

Also, there's no error messages or logs, not even in Windows Events.

[koszeggy]

Hmm... I've never encountered this issue but I will pull the latest sources and play with it a bit. Let's see if I find something.