After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 613595 - gdk-pixbuf does not manage animation sizes correctly
gdk-pixbuf does not manage animation sizes correctly
Status: VERIFIED FIXED
Product: gdk-pixbuf
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: gdk-pixbuf-maint
gdk-pixbuf-maint
Depends on:
Blocks:
 
 
Reported: 2010-03-22 14:33 UTC by Xabier Rodríguez Calvar
Modified: 2012-07-31 14:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GIF to describe the problem (2.00 KB, text/x-csrc)
2010-03-22 14:33 UTC, Xabier Rodríguez Calvar
  Details
Offending GIF file (274.42 KB, image/gif)
2010-03-22 14:34 UTC, Xabier Rodríguez Calvar
  Details
Call size_func in io-gif so that pixbuf is aware of it. (2.10 KB, patch)
2010-03-22 14:38 UTC, Xabier Rodríguez Calvar
accepted-commit_now Details | Review
Try to use animation size in the loader for animations. (2.39 KB, patch)
2010-03-22 14:39 UTC, Xabier Rodríguez Calvar
accepted-commit_now Details | Review
Fixing doc about relying on pixbuf size for animations (2.07 KB, patch)
2010-03-22 14:39 UTC, Xabier Rodríguez Calvar
none Details | Review
Changed doc of GdkPixbufAnimation about size management (1.10 KB, patch)
2010-10-24 12:29 UTC, Xabier Rodríguez Calvar
accepted-commit_now Details | Review
Pixbuf shall have at least one pixel width or height when scaling (1.12 KB, patch)
2012-05-16 11:29 UTC, Xabier Rodríguez Calvar
accepted-commit_now Details | Review
Removed entities from the code markup (5.72 KB, patch)
2012-07-30 11:04 UTC, Xabier Rodríguez Calvar
accepted-commit_now Details | Review
Changed doc of GdkPixbufAnimation about size management (2.26 KB, application/octet-stream)
2012-07-30 11:05 UTC, Xabier Rodríguez Calvar
  Details
Too much rounding when calculating the size of the scaled frame (1.28 KB, application/octet-stream)
2012-07-30 16:48 UTC, Xabier Rodríguez Calvar
  Details

Description Xabier Rodríguez Calvar 2010-03-22 14:33:48 UTC
Created attachment 156745 [details]
GIF to describe the problem

I'll provide an offending GIF as next attachment.

The test program takes a filename as parameter and optionally a size and height. It uses a GdkPixbufLoader to load a file and then it prints pixbuf and animation sizes. The pixbuf is the first animation frame.

1. According to the GdkPixbufAnimation documentation ( http://library.gnome.org/devel/gdk-pixbuf/unstable/gdk-pixbuf-animation.html#gdk-pixbuf-animation.description ) every frame has the same size, which does not happen here.

2. As it trusts the first point, GdkPixbufLoader uses pixbuf size to calculate the scale and it fails. Let's suppose that you run the test program with limit of 400x400, I expected to get an animation of 400x400, but I get a pixbuf of 400x400 and a much bigger animation, so when I was expected to make the animation smaller, I made it much bigger because first frame is 45x73 and total animation size is 86x13364.

Program output should be:
$ /tmp/animation_size /tmp/dancing.gif 400 400
** (process:27255): DEBUG: max size: 400x400
** (process:27255): DEBUG: animation: 400x400
** (process:27255): DEBUG: pixbuf: 209x2
** Message: animation size (400x400) != pixbuf_size (209x2)

And it ends up being:
$ /tmp/animation_size /tmp/dancing.gif 400 400
** (process:27228): DEBUG: max size: 400x400
** (process:27228): DEBUG: animation: 764x73227
** (process:27228): DEBUG: pixbuf: 400x400
**
ERROR:../../animation_size.c:58:main: assertion failed: (animation_width <= max_width && animation_height <= max_height)
Comment 1 Xabier Rodríguez Calvar 2010-03-22 14:34:25 UTC
Created attachment 156746 [details]
Offending GIF file
Comment 2 Xabier Rodríguez Calvar 2010-03-22 14:38:21 UTC
Created attachment 156747 [details] [review]
Call size_func in io-gif so that pixbuf is aware of it.

This patch makes the GIF loader announce the size of the loaded image.
Comment 3 Xabier Rodríguez Calvar 2010-03-22 14:39:25 UTC
Created attachment 156748 [details] [review]
Try to use animation size in the loader for animations.

Pixbuf size can be innacurate for some animations with frames of different sizes.
Comment 4 Xabier Rodríguez Calvar 2010-03-22 14:39:51 UTC
Created attachment 156749 [details] [review]
Fixing doc about relying on pixbuf size for animations
Comment 5 Xabier Rodríguez Calvar 2010-10-24 12:29:21 UTC
Created attachment 173114 [details] [review]
Changed doc of GdkPixbufAnimation about size management
Comment 6 Xabier Rodríguez Calvar 2010-10-24 12:30:46 UTC
I updated third patch as it was not applying anymore with the new structure.
Comment 7 Matthias Clasen 2010-10-25 18:30:15 UTC
This doesn't seem quite right to me. 

  "every frame has the same size, which does not happen here."

This is something that the gif loader must ensure, really.
Comment 8 Xabier Rodríguez Calvar 2010-10-26 07:07:40 UTC
(In reply to comment #7)
> This doesn't seem quite right to me. 
> 
>   "every frame has the same size, which does not happen here."
> 
> This is something that the gif loader must ensure, really.

So there is a bug anyway, though I think that removing the condition of having all frames with the same size is not that big problem.
Comment 9 Xabier Rodríguez Calvar 2010-11-25 11:01:37 UTC
(In reply to comment #7)
> This doesn't seem quite right to me. 
> 
>   "every frame has the same size, which does not happen here."
> 
> This is something that the gif loader must ensure, really.

We can discuss about two things. One of them is that gdk-pixbuf has a problem when scaling the animations and in this case, the scaling causes that we increase the size (a lot) instead of reducing it. This is fixed by the two first patches, so I really think that at least these two should be applied.

Then we have the other problem. In this case, the frames have different size. I don't know if the GIF standard allows having frames with different sizes or not, but removing the size constraint would allow us to save some memory with some animations that could have different frames size and it would ease the development of the different loaders (this would be one and in case we get any new animation format allowing different frames size).

Other consideration is that what is working so far, will be working the same way as different sizes is a supercase of same size.
Comment 10 Xabier Rodríguez Calvar 2011-08-08 16:59:08 UTC
We just talk about this at desktop summit. Remainder ;)
Comment 11 Xabier Rodríguez Calvar 2012-05-16 10:09:35 UTC
Poking a bit around and testing with the latest master branch:

Information about the pixbuf is the same with and without patches:

$ G_MESSAGES_DEBUG="all" /tmp/animation_size /tmp/dancing.gif
** (process:9864): DEBUG: animation: 86x13364
** (process:9864): DEBUG: pixbuf: 45x73
** Message: animation size (86x13364) != pixbuf_size (45x73)

As you can see, the animation and first pixbuf sizes are different and that contradicts the documentation. But I will like to discuss this later.

Running the test program without the first two patches:

$ G_MESSAGES_DEBUG="all" /tmp/animation_size /tmp/dancing.gif 400 400
** (process:6199): DEBUG: max size: 400x400
** (process:6199): DEBUG: animation: 764x73227
** (process:6199): DEBUG: pixbuf: 400x400
**
ERROR:/tmp/animation_size.c:58:main: assertion failed: (animation_width <= max_width && animation_height <= max_height)
Aborted

In this case we are telling the loader to restrict the maximum size to 400x400 and given that it is using the first pixbuf to calculate the scaling ratio instead of the animation one, it is even increasing the size, as I already stated in the comment 1.

Running it with the first two patches:

$ G_MESSAGES_DEBUG="all" /tmp/animation_size /tmp/dancing.gif 400 400
** (process:2253): DEBUG: max size: 400x400
** (process:2253): DEBUG: animation: 400x400
** (process:2253): DEBUG: pixbuf: 209x2
** Message: animation size (400x400) != pixbuf_size (209x2)

In this case, the animation is correctly scaled to its max size. The size of every pixbuf is still different that that's another story.

Given these facts I consider that it would be needed to apply both first two patches as soon as possible to properly scale gifs.

This bug was created more than two years ago and patches are provided, I think it deserves a bit of love.
Comment 12 Xabier Rodríguez Calvar 2012-05-16 10:26:58 UTC
About the problem with the different pixbuf sizes. I really think we should consider frames can have different sizes. http://en.wikipedia.org/wiki/GIF#Animated_GIF says that they have "by default" the same size, but it does not say is is mandatory. In cases like the one I am bringing to this bug, having all frames with the same size would be a waste of computation and memory as we would need to create new pixbufs with the right animation size to comply with the "all frames must have the same size".

Another reason to consider different sizes is that we already have this case where there are animations with different sizes in different frames. Applications considering this will be already buggy (at least for this case) either if we consider the documentation change or not so it does not harm to do it.

If you prefer, we can have the discussion on the mailing list.
Comment 13 Xabier Rodríguez Calvar 2012-05-16 11:29:09 UTC
Created attachment 214177 [details] [review]
Pixbuf shall have at least one pixel width or height when scaling

Another problem I found when scaling is that in some cases it can happen that it tries to scale to 0, which is forbidden in some dimension. Example:

$ G_MESSAGES_DEBUG="all" /tmp/animation_size /tmp/dancing.gif 40 40
** (process:24208): DEBUG: max size: 40x40

(process:24208): GdkPixbuf-CRITICAL **: gdk_pixbuf_scale_simple: assertion `dest_height > 0' failed
**
ERROR:/tmp/animation_size.c:46:main: assertion failed: (pixbuf)
Aborted

This patch fixes that and the outcome is:

$ G_MESSAGES_DEBUG="all" /tmp/animation_size /tmp/dancing.gif 40 40
** (process:27792): DEBUG: max size: 40x40
** (process:27792): DEBUG: animation: 40x40
** (process:27792): DEBUG: pixbuf: 21x1
** Message: animation size (40x40) != pixbuf_size (21x1)
Comment 14 Xabier Rodríguez Calvar 2012-05-16 11:31:17 UTC
(In reply to comment #0)
> Created an attachment (id=156745) [details]
> GIF to describe the problem

Btw, sorry in the first place for the description of this attachment, but it is the test program instead of the offending GIF, which is another one.
Comment 15 Xabier Rodríguez Calvar 2012-07-29 17:02:42 UTC
Mathias, would you approve this?
Comment 16 Matthias Clasen 2012-07-30 06:20:36 UTC
Review of attachment 156747 [details] [review]:

ok
Comment 17 Matthias Clasen 2012-07-30 06:22:05 UTC
Review of attachment 156748 [details] [review]:

ok
Comment 18 Matthias Clasen 2012-07-30 06:25:56 UTC
Review of attachment 173114 [details] [review]:

ok
Comment 19 Matthias Clasen 2012-07-30 06:26:28 UTC
Review of attachment 214177 [details] [review]:

nice catch
Comment 20 Xabier Rodríguez Calvar 2012-07-30 11:04:56 UTC
Created attachment 219877 [details] [review]
Removed entities from the code markup

It is not being expanded and by checking other projects doc (GLib for example) it is more consistent.
Comment 21 Xabier Rodríguez Calvar 2012-07-30 11:05:41 UTC
Created attachment 219878 [details]
Changed doc of GdkPixbufAnimation about size management
Comment 22 Matthias Clasen 2012-07-30 11:14:23 UTC
Review of attachment 219877 [details] [review]:

Sure, ok
Comment 23 Xabier Rodríguez Calvar 2012-07-30 11:27:24 UTC
Pushed: http://git.gnome.org/browse/gdk-pixbuf/log/

Thanks Matthias!
Comment 24 Xabier Rodríguez Calvar 2012-07-30 16:48:07 UTC
Created attachment 219914 [details]
Too much rounding when calculating the size of the scaled frame

This was causing some frames to be 1 pixel bigger than the animation.
Comment 25 Xabier Rodríguez Calvar 2012-07-30 16:49:29 UTC
I need to reopen this because I brought a regression with one of the patches shoud be fixed with that last patch.
Comment 26 Xabier Rodríguez Calvar 2012-07-31 14:30:16 UTC
(In reply to comment #25)
> I need to reopen this because I brought a regression with one of the patches
> shoud be fixed with that last patch.

Fixed.