20
In search of a non-electron text editor that can fold | Are emacs and (neo)vim my only options? (discuss.online)
submitted 1 year ago by to c/linux@programming.dev
20 comments fedilink hide all child comments
 

The following gif demonstrates folding:

you are viewing a single comment's thread
view the rest of the comments
[–] [S] 1 point 1 year ago (6 children)

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?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 2 points 1 year ago (5 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] [S] 1 point 1 year ago* (last edited 1 year ago) (4 children)

    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 -i input.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:

    Does any one of the above gifs do better?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 1 year ago* (3 children)

    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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] [S] 1 point 1 year ago* (2 children)

    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!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 1 year ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [S] 2 points 1 year ago

    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 -i input.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.

    ffmpeg -i input.mp4 -i palette.png -lavfi paletteuse output.gif

    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.

    ffmpeg -i input.mp4 -vf "split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" output.gif

    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.

    Makes sense.

  • permalink
  • fedilink
  • source
  • parent