Dot Matrix grid pattern appearing when exporting to gif

[firasm]

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

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

Expected behaviour

No Dot Matrix pattern in exported gifs.

Workaround

None available...

[mootari]

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

[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):

[firasm]

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

[mootari]

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.

[firasm]

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

Example 2: Starting at 0:01

[mootari]

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).

[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:

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

Here is the ordered dither version (3):

[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:

1. uncropped: 8.3MB
2. cropped at end: 8.2MB
3. cropped at start: 432KB, ordered dither

Something to do with keyframes in the video source perhaps?

[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.

[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.

[AllenSara]

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

[mootari]

@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.

[xtremforce]

same issue here! any way to workaround?

[mixn]

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!

[AlecHaring]

As @mixn mentions, the issue only arises for me when trying to trim the gif before exporting. So I suspect it has to do with the trimming system.

[wailingwombat]

I have the same issue. The only workaround is not to trim the beginning.