mirror of
https://github.com/NickeManarin/ScreenToGif.git
synced 2026-04-25 23:25:52 +03:00
[GH-ISSUE #1] Progress bar detail gets lost with quality #1371
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#1371
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 @duarteframos on GitHub (Aug 6, 2016).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/1
Originally assigned to: @NickeManarin on GitHub.
Heard you were trying to move away from Codeplex to Github so I'll try to post issue here.
Not sure if this is something solvable without increasing file size or save quality, but see the GIF recorded here
My guess is the GIF compression ate away the detail of the progress bar, making it look fragmented or broken. It looked fine in the preview before saving
This release is great so far :)
@NickeManarin commented on GitHub (Aug 6, 2016):
Your guess is right. The neural quantizer (NeuQuant) algorithm transforms 24 bits images to 8 bits images (256 colors).
Since the bar increase it self piece by piece, the algorithm only takes into account a few number of pixels per frame. The other pixels that are changing take more "space" than the piece of the bar.
So the bar color information is lost when there's too much info per frame. :(
@duarteframos commented on GitHub (Aug 6, 2016):
Ah that's too bad, but I suspected as much.
I use ScreentoGif mainly to help users out over Blender Stack exchange and upload sizes are limited to 2Mb there, so file sizes already very tight without increasing image quality.
Anyway thanks for the reply, keep up the great work.
@NickeManarin commented on GitHub (Sep 12, 2016):
I created from scratch a new encoder that avoids this bug. This new encoder lacks the current NeuQuant (color quantitizer) but I plan to improve with other color quantization algorithms.
@duarteframos commented on GitHub (Sep 12, 2016):
Wow you are tireless. That is great news, curious to see how it preforms.
I'll be keeping an eye on this 👍
@sirtet commented on GitHub (Nov 9, 2016):
Could a solution be to first add a background stripe, and let the progressbar run on that?
@NickeManarin commented on GitHub (Jan 18, 2017):
No, the problem starts with gif encoder (the color quantization).
@NickeManarin commented on GitHub (Feb 9, 2017):
I fixed a bug related to this issue, #79
@NickeManarin commented on GitHub (Jul 13, 2017):
There's a new color quantization algorithm almost ready for the encoder 2.0.
@duarteframos commented on GitHub (Jul 13, 2017):
Yeah, cool! Looking forward to seeing it in action
@NickeManarin commented on GitHub (Jul 31, 2017):
Previous (1.5 MB):
New (1.11 MB):
I noticed the color banding, but at least the progress bar is alright.
@duarteframos commented on GitHub (Jul 31, 2017):
Wow this is absolutely fantastic, both improved image quality and reduced file size!
Banding is barely noticeable at all, and quite an acceptable compromise for the quality gains.
This will make long GIFs a lot easier to watch. Thanks a lot! :)