Kap Dot Matrix grid pattern appearing when exporting to gif

trafficstars

macOS version: 12.1 (Monterey) Kap version: 3.5.1

Steps to reproduce

Record a screencast
Convert to Gif (tested at many different settings, even original size)

Current behaviour

Here is the current behaviour when exporting as a gif (note the dot matrix pattern, possibly a compression artefact?)

Bad Artefacts

github_download

Unfortunately even at original resolution, I can still see it, but obviously it's fainter.

Kapture 2022-01-09 at 08 18 24

Expected behaviour

No Dot Matrix pattern in exported gifs.

Workaround

None available...

Jan 09 '22 16:01 firasm

I've been experiencing the same for a while now. For some reason Kap exports GIFs with ordered dithering.

Jan 09 '22 21:01 mootari

The problem may be related to https://github.com/wulkano/Kap/pull/748

Here is one of the latest examples that was produced with Kap 3.4.2 on Big Sur (be sure to view it at full size):

Jan 09 '22 22:01 mootari

Yes I see it in the image you posted as well...

Jan 09 '22 22:01 firasm

Creating a repro was difficult, but I may have found the cause. The only difference between these two GIFs is that for the first ("offset-0", clear colors) the timeline starts exactly at 0:00, while for the latter ("offset-custom", ordered dither) the starting point has been moved slightly (by about 0.1 or 0.2 seconds). Again, be sure to view them in full size.

offset-0:

offset-custom:

So once you change the starting offset, the dithering appears to switch to ordered dither.

Jan 09 '22 23:01 mootari

wow - seriously impressive troubleshooting! Nice work!

I was able to reproduce with the same settings, except just editing the start point.

Example 1: Starting at exactly 0:00

test1

Example 2: Starting at 0:01

test2

Jan 10 '22 00:01 firasm

Your second example doesn't seem to have ordered dither though. I'd recommend to test with a mostly static scene, since the overall mix of colors in the entire sequence will likely affect algorithm selection and is harder to control (and compare) with large moving areas.

Ideally you include a few seconds of stillness at the start and end of your recording, so that small offset changes have less effect on the overall gif.

You may also want to create an mp4/webm export and test whether you can produce the same differences when loading and converting the video file (instead of a directly recorded clip).

Jan 10 '22 00:01 mootari

I just ran another test because I couldn't quite believe it myself.

Source is a static scene (~6sec) without any movement. Export was done at 100% size and 20 FPS:

uncropped: 20.2MB, noise changes visibly for every frame
cropped only at the end: 19.6MB, noise changes visibly for every frame
cropped only at the beginning: 940KB, ordered dither, very minor frame-to-frame changes in dither

Here is the ordered dither version (3):

Jan 10 '22 12:01 mootari

Testing with an MP4/H264 export from Kap (98KB): https://user-images.githubusercontent.com/322014/148767868-28a2d686-c2e8-4bb0-92ea-178cde165029.mp4

Results are the same:

uncropped: 8.3MB
cropped at end: 8.2MB
cropped at start: 432KB, ordered dither

Something to do with keyframes in the video source perhaps?

Jan 10 '22 12:01 mootari

Actually, what we're seeing has nothing to do with gifsicle. It's ffmpeg's bayer filter. I get the same behavior when lossy compression is disabled.

Jan 10 '22 18:01 mootari

I'm not familiar with Kap's internals and only vaguely familiar with ffmpeg, so the following may be a red herring.

There appears to have been a functional change during the TypeScript conversion. Before, the filter [x][1:v]paletteuse would always be specified:

https://github.com/wulkano/Kap/blob/a1aed0a14e5c0a1baac5443fece3313c8101c05f/main/convert.js#L269

Since the conversion the filter will only be specified if a palette is available:

https://github.com/wulkano/Kap/blob/b1bcc4b7b765fd626c5d593d8b6a3b8ea4ca5ca8/main/converters/h264.ts#L49-L64

Aside: Apparently [x] is just the name assigned to the filter, so that following filters can reference its output by the name.

Jan 10 '22 19:01 mootari

Hi! @mootari Is there an easy way to fix this bug besides for starting all GIFs at the 0:00 second?

Mar 01 '23 13:03 AllenSara

@AllenSara not that I'm aware, but I also haven't created any gifs in while. I'd suggest to use another tool for the encoding in this case.

Mar 01 '23 14:03 mootari

same issue here! any way to workaround?

Apr 11 '23 09:04 xtremforce

I can also reproduce and confirm @mootari’s debugging, I don’t get the grid pattern once the starting time is exactly 0:00. Works for me for now, thanks!