Very interesting. I suppose that’s an artifact of the ffmpeg hacking used to convert the screencast to a gif. Would you happen to know what I could do to prevent that from happening in the future?
Btw, FWIW, I seem to only notice this myself when I’m on the phone. Does the picture above also happen to be from your phone?
The screenshot is from my desktop with wide enough screen on Lemmy web (programming.dev).
The issue is one of scaling.
When I open the image without being resized into the website layout, it has the following visual pattern:
When I zoom out to 50% it looks (almost?) fine
Did you scale the source with ffmpeg? Do you have a visual pattern in your console background? The simplest solution would be to have a solid color as background. The second best to render a small enough size that it does not get resized in the browser.
At 1920x1038, it’s very big right now. I’m surprised the font is big enough to be readable. I assume you scaled it up or have a high dpi display resulting in this.
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:
That visual pattern compression though
Very interesting. I suppose that’s an artifact of the
ffmpeghacking used to convert the screencast to a gif. Would you happen to know what I could do to prevent that from happening in the future?Btw, FWIW, I seem to only notice this myself when I’m on the phone. Does the picture above also happen to be from your phone?
The screenshot is from my desktop with wide enough screen on Lemmy web (programming.dev).
The issue is one of scaling.
When I open the image without being resized into the website layout, it has the following visual pattern:
When I zoom out to 50% it looks (almost?) fine
Did you scale the source with ffmpeg? Do you have a visual pattern in your console background? The simplest solution would be to have a solid color as background. The second best to render a small enough size that it does not get resized in the browser.
At 1920x1038, it’s very big right now. I’m surprised the font is big enough to be readable. I assume you scaled it up or have a high dpi display resulting in this.
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