[GH-ISSUE #694] Cinemagraph feature "smears" its result

kerem commented

2026-02-26 09:31:54 +03:00

Owner

Originally created by @SJT1988 on GitHub (Jul 22, 2020).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/694

Originally assigned to: @NickeManarin on GitHub.

The "ScreenToGif" saving option (default) that finds unchanged pixels works great sometimes, not-so-great other times. I commonly throw up image sequences where almost half of the pixels are unchanged but it can't detect them. Comparable gifs that are barely 8mb are sometimes 20mb because of this.

I wanted to paint-in an inverted chroma key using the Cinemagraph feature. This is supposed to literally highlight pixels in an image that are changing over the sequence. When you activate this tool, the image preview force-zooms to 100%. After painting, the program thinks for a bit and SMEARS the zoomed-out image within the painted area over the 100% area. I have not verified any kind of workaround for this. This is an important feature and I hope it gets fixed?

Originally created by @SJT1988 on GitHub (Jul 22, 2020). Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/694 Originally assigned to: @NickeManarin on GitHub. The "ScreenToGif" saving option (default) that finds unchanged pixels works great sometimes, not-so-great other times. I commonly throw up image sequences where almost half of the pixels are unchanged but it can't detect them. Comparable gifs that are barely 8mb are sometimes 20mb because of this. I wanted to paint-in an inverted chroma key using the Cinemagraph feature. This is supposed to literally highlight pixels in an image that are changing over the sequence. When you activate this tool, the image preview force-zooms to 100%. After painting, the program thinks for a bit and SMEARS the zoomed-out image within the painted area over the 100% area. I have not verified any kind of workaround for this. This is an important feature and I hope it gets fixed? ![Annotation 2020-07-21 195313](https://user-images.githubusercontent.com/41922761/88129535-33511300-cb8d-11ea-9173-5e9cc5c56ac4.jpg)

kerem

2026-02-26 09:31:54 +03:00

closed this issue
added the
🔷 Bug 🐛
label

kerem commented

2026-02-26 09:31:54 +03:00

Author

Owner

@NickeManarin commented on GitHub (Jul 22, 2020):

Can you share the project and your system related settings? (take a print of the statistics tab)

@NickeManarin commented on GitHub (Jul 22, 2020): Can you share the project and your system related settings? (take a print of the statistics tab)

kerem commented

2026-02-26 09:31:54 +03:00

Author

Owner

@NickeManarin commented on GitHub (Jul 22, 2020):

The "ScreenToGif" saving option (default) that finds unchanged pixels works great sometimes, not-so-great other times. I commonly throw up image sequences where almost half of the pixels are unchanged but it can't detect them.

The encoder should be detecting any unchanged pixel. It's a pixel-by-pixel operation.

@NickeManarin commented on GitHub (Jul 22, 2020): > The "ScreenToGif" saving option (default) that finds unchanged pixels works great sometimes, not-so-great other times. I commonly throw up image sequences where almost half of the pixels are unchanged but it can't detect them. The encoder should be detecting any unchanged pixel. It's a pixel-by-pixel operation.

kerem commented

2026-02-26 09:31:54 +03:00

Author

Owner

@SJT1988 commented on GitHub (Aug 1, 2020):

Hi, it's a pretty big project (lots of large, rich frames). What I am doing is marking the pixel AREA that I KNOW the character will be contained in as he rocks side-to-side--all the "non-static" pixels, including his shadows.I am attaching a Google Drive link since the project is too big:

https://drive.google.com/file/d/1DZMiR1STHQpLg1xa2e1THXb3dzh63xz5/view?usp=sharing

(I forgot to change the timing to 33 ms before I saved it, but that won't matter)
To get a similar result to mine:

Access the "Cinemagraph" tool.
Paint over Thwomp in his default position.
Scroll to a frame with an extreme position, and paint out any part where he moved outside the previous painted region.
Scroll to a frame with the opposite extreme position and do the same thing.
Also get the shadows in front of him.
Scrub the frames to make sure you paint anywhere his edges poke out of the highlights.
Select all frames.
Hit "Apply".

result:

I actually think what is happening inside the silhouette is correct, it's the background that looks resized and off-frame.
It should either know that the other pixels should be the same, or ask the user to pick a frame to use as the static background.
When this is fixed, your tool is going to be the gif maker to beat.

@SJT1988 commented on GitHub (Aug 1, 2020): Hi, it's a pretty big project (lots of large, rich frames). What I am doing is marking the pixel AREA that I KNOW the character will be contained in as he rocks side-to-side--all the "non-static" pixels, including his shadows.I am attaching a Google Drive link since the project is too big: https://drive.google.com/file/d/1DZMiR1STHQpLg1xa2e1THXb3dzh63xz5/view?usp=sharing (I forgot to change the timing to 33 ms before I saved it, but that won't matter) To get a similar result to mine: Access the "Cinemagraph" tool. Paint over Thwomp in his default position. Scroll to a frame with an extreme position, and paint out any part where he moved outside the previous painted region. Scroll to a frame with the opposite extreme position and do the same thing. Also get the shadows in front of him. Scrub the frames to make sure you paint anywhere his edges poke out of the highlights. Select all frames. Hit "Apply". result: ![buggy](https://user-images.githubusercontent.com/41922761/89111676-948aa900-d40d-11ea-801b-35ae340c1b04.jpg) I actually think what is happening inside the silhouette is correct, it's the background that looks resized and off-frame. It should either know that the other pixels should be the same, or ask the user to pick a frame to use as the static background. When this is fixed, your tool is going to be the gif maker to beat.

kerem commented

2026-02-26 09:31:54 +03:00

Author

Owner

@NickeManarin commented on GitHub (Aug 2, 2020):

Hi, I asked for a screenshot of the statistics tab because I guessed it could be an issue related to a different DPI of the screen and the recorded content.

From your first picture, I was not sure of what I was looking at. Now I'm aware of the issue.
Thanks.

@NickeManarin commented on GitHub (Aug 2, 2020): Hi, I asked for a screenshot of the statistics tab because I guessed it could be an issue related to a different DPI of the screen and the recorded content. From your first picture, I was not sure of what I was looking at. Now I'm aware of the issue. Thanks.

kerem commented

2026-02-26 09:31:54 +03:00

Author

Owner

@SJT1988 commented on GitHub (Aug 2, 2020):

I think I left the download link "restricted", I apologize for that oversight. That link is now public.
Sorry, I don't pay enough attention sometimes:

@SJT1988 commented on GitHub (Aug 2, 2020): I think I left the download link "restricted", I apologize for that oversight. That link is now public. Sorry, I don't pay enough attention sometimes: ![Annotation 2020-08-01 205120](https://user-images.githubusercontent.com/41922761/89115089-d250f700-d438-11ea-87b7-7e4b282eb6f6.jpg)

kerem commented

2026-02-26 09:31:54 +03:00

Author

Owner

@NickeManarin commented on GitHub (Aug 3, 2020):

Thanks. That's the issue, the Cinemagraph is currently broken for projects with a different DPI than the screen. As you can see, yours is 72 DPI.

As a workaround, try generating the images with 96DPI (I'm guessing that you generated them using other app).

@NickeManarin commented on GitHub (Aug 3, 2020): Thanks. That's the issue, the Cinemagraph is currently broken for projects with a different DPI than the screen. As you can see, yours is 72 DPI. As a workaround, try generating the images with 96DPI (I'm guessing that you generated them using other app).

kerem commented

2026-02-26 09:31:54 +03:00

Author

Owner

@NickeManarin commented on GitHub (Aug 12, 2020):

Fixed.
Results in an image with the same size and DPI.

Before applying cinamegraph:

After:

@NickeManarin commented on GitHub (Aug 12, 2020): Fixed. Results in an image with the same size and DPI. Before applying cinamegraph: ![image](https://user-images.githubusercontent.com/14798947/90049545-54e47c80-dcab-11ea-8922-f767fb9d4d5a.png) After: ![image](https://user-images.githubusercontent.com/14798947/90049601-688fe300-dcab-11ea-803c-317365d4ca54.png)

kerem referenced this issue

2026-03-01 18:47:33 +03:00

[GH-ISSUE #389] Bundling FFmpeg #1692

kerem referenced this issue

2026-03-01 18:50:42 +03:00

[GH-ISSUE #563] [Preview] New installer #1944

kerem referenced this issue

2026-03-01 18:50:45 +03:00

[GH-ISSUE #563] [Preview] New installer #1949

kerem referenced this issue

2026-03-01 18:50:49 +03:00

[GH-ISSUE #563] [Preview] New installer #1951