Thank you so much for this! Hopefully I’m not bothering you with this*.
Did you scale the source with ffmpeg?
I’m not entirely sure, but I don’t think I did. The invoked command was the following:
❯ ffmpeg -iinput.mp4 output.gif
Do you have a visual pattern in your console background?
I don’t think I do. It doesn’t look like it at least. To be clear, even on my laptop I notice the visual pattern visible in the gif. But that’s totally absent when I’m working within Emacs. Or at least, it looks as if it’s just a singular solid color.
The second best to render a small enough size that it does not get resized in the browser.
Hmm…, makes sense. Not a huge fan, though 😅. Hopefully I can solve it through other means instead.
I assume you scaled it up
Yup. For the sake of readability*. But the upscaling (or rather zooming in*) was done natively within Emacs.
Alright, so I went to do some digging and the pattern only starts to show up in the gif. Perhaps as a result of the smaller color palette*. Regardless, I tried to see if it is solved by simply generating a ‘better’ palette and using it as a filter of sorts. Furthermore, in case that wasn’t enough, I also tried playing with different dither algorithms:
Thank you so much for your patience in teaching me something new! Much, much appreciated!
With the help of your observations, I can confidently say that the different dither methods don’t play much of a role after filtering with a better palette has already been done. So palette-filtering -if we can refer to it as such- is the actual MVP in resolving this issue.
animated webp may also be an option
Hehe :P , I’ll take note of this and perhaps resort to it the next time. The whole palette-filtering stuff seemed like some occult incantations that somehow worked. But I would much rather use a different (sane) format instead.
Again, I would like to stress that I’ve very much enjoyed this interaction! While it’s been (mostly) totally unrelated to the original post, this has actually been one of the most informative interactions found within its comments. Therefore, thank you!
Glad you’re so appreciative and worked through it! I gladly share, discuss, and respond.
I’ll have to read up on palette filters. :) I do semi-regularly use ffmpeg, but palette filters are not something I have heard or used before.
I assume in this case it’s a downsampling into fewer colors, evading the issues of almost-same-colors?
Especially given the last square/check pattern makes me thing of codecs splitting into square blocks and then encoding those. It could make sense that this division leads to different results for one reason or another, which then produces a check pattern without it being there before.
Glad you’re so appreciative and worked through it! I gladly share, discuss, and respond.
Thank you for being you!
I’ll have to read up on palette filters. :) I do semi-regularly use ffmpeg, but palette filters are not something I have heard or used before.
Please allow me to point you towards the relevant parts within its documentation; palettegen and paletteuse.
Together, they constitute -from what I can gather- the absolute minimal required to create a .gif with desirable qualities. As such, they will make their appearances within the following two commands that closely mirror the examples found in the documentation:
ffmpeg -iinput.mp4 -vf palettegen palette.png
This generates a representative palette with 255 colors maximum from the video. Note that AFAIU the set of colors this can draw from is the same as the one used for gifs. Which will likely come into play when we try to understand why this works in the first place.
This starts with converting the colors found in the original .mp4 to their closest counterparts found within the palette. Then, with converted colors, it’s turned into a .gif. Note that AFAIU we’ve effectively eliminated the algorithm that would otherwise kick in to convert the .mp4’s wide arrange of colors into the ones compatible with gif.
To be clear, I don’t claim to understand why this actually works 😅. But, combined, the above two commands do yield desirable gifs. Like, for example, the one found below.
Note that we can achieve the same with just a single command. For that, consider the command found below.
I assume in this case it’s a downsampling into fewer colors, evading the issues of almost-same-colors?
That would also be my conjecture.
Especially given the last square/check pattern makes me thing of codecs splitting into square blocks and then encoding those. It could make sense that this division leads to different results for one reason or another, which then produces a check pattern without it being there before.
Thank you so much for this! Hopefully I’m not bothering you with this*.
I’m not entirely sure, but I don’t think I did. The invoked command was the following:
❯ ffmpeg -i input.mp4 output.gifI don’t think I do. It doesn’t look like it at least. To be clear, even on my laptop I notice the visual pattern visible in the gif. But that’s totally absent when I’m working within Emacs. Or at least, it looks as if it’s just a singular solid color.
Hmm…, makes sense. Not a huge fan, though 😅. Hopefully I can solve it through other means instead.
Yup. For the sake of readability*. But the upscaling (or rather zooming in*) was done natively within Emacs.
Alright, so I went to do some digging and the pattern only starts to show up in the gif. Perhaps as a result of the smaller color palette*. Regardless, I tried to see if it is solved by simply generating a ‘better’ palette and using it as a filter of sorts. Furthermore, in case that wasn’t enough, I also tried playing with different dither algorithms:
Does any one of the above gifs do better?
1, 2, 4, 5, 6 all look fine resized in the post and full size
3 looks fine full size but has slight visual artifacts resized in the post (check/square pattern)
I can barely see it on my monitor. So on worse monitors it may not even be visible. #272a31 vs #262b31
animated webp may also be an option
Thank you so much for your patience in teaching me something new! Much, much appreciated!
With the help of your observations, I can confidently say that the different dither methods don’t play much of a role after filtering with a better palette has already been done. So palette-filtering -if we can refer to it as such- is the actual MVP in resolving this issue.
Hehe :P , I’ll take note of this and perhaps resort to it the next time. The whole palette-filtering stuff seemed like some occult incantations that somehow worked. But I would much rather use a different (sane) format instead.
Again, I would like to stress that I’ve very much enjoyed this interaction! While it’s been (mostly) totally unrelated to the original post, this has actually been one of the most informative interactions found within its comments. Therefore, thank you!
Glad you’re so appreciative and worked through it! I gladly share, discuss, and respond.
I’ll have to read up on palette filters. :) I do semi-regularly use ffmpeg, but palette filters are not something I have heard or used before.
I assume in this case it’s a downsampling into fewer colors, evading the issues of almost-same-colors?
Especially given the last square/check pattern makes me thing of codecs splitting into square blocks and then encoding those. It could make sense that this division leads to different results for one reason or another, which then produces a check pattern without it being there before.
Thank you for being you!
Please allow me to point you towards the relevant parts within its documentation; palettegen and paletteuse.
Together, they constitute -from what I can gather- the absolute minimal required to create a .gif with desirable qualities. As such, they will make their appearances within the following two commands that closely mirror the examples found in the documentation:
ffmpeg -i input.mp4 -vf palettegen palette.pngThis generates a representative palette with 255 colors maximum from the video. Note that AFAIU the set of colors this can draw from is the same as the one used for gifs. Which will likely come into play when we try to understand why this works in the first place.
ffmpeg -i input.mp4 -i palette.png -lavfi paletteuse output.gifThis starts with converting the colors found in the original .mp4 to their closest counterparts found within the palette. Then, with converted colors, it’s turned into a .gif. Note that AFAIU we’ve effectively eliminated the algorithm that would otherwise kick in to convert the .mp4’s wide arrange of colors into the ones compatible with gif.
To be clear, I don’t claim to understand why this actually works 😅. But, combined, the above two commands do yield desirable gifs. Like, for example, the one found below.
Note that we can achieve the same with just a single command. For that, consider the command found below.
ffmpeg -i input.mp4 -vf "split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" output.gifThat would also be my conjecture.
Makes sense.