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 496306 - gdk_pixbuf_scale_simple() resizes when it shouldn't
gdk_pixbuf_scale_simple() resizes when it shouldn't
Status: RESOLVED DUPLICATE of bug 80927
Product: gdk-pixbuf
Classification: Platform
Component: general
2.21.x
Other Linux
: Normal normal
: ---
Assigned To: gdk-pixbuf-maint
gdk-pixbuf-maint
Depends on:
Blocks:
 
 
Reported: 2007-11-13 00:19 UTC by Andrew Smith
Modified: 2014-10-22 17:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Contains an example of fuzziing image while 1:1 scale. (688 bytes, application/x-compressed-tar)
2008-05-30 11:01 UTC, Andrey Tsyvarev
Details

Description Andrew Smith 2007-11-13 00:19:57 UTC
A call to gdk_pixbuf_scale_simple() with the GDK_INTERP_HYPER parameter for some reason ends up resizing an image, even if the size requested matches the size of the pixbuf I give it.

It's not very hard to check for it myself - but I wasted some of my time figuring out why the images look fuzzy, and I suspect I'm not the only one.

Would be good if gdk_pixbuf_scale_simple() would do a check itself.
Comment 1 Andrey Tsyvarev 2008-05-30 11:01:14 UTC
Created attachment 111791 [details]
Contains an example of fuzziing image while 1:1 scale.

The GDK_INTERP_HYPER filter is described as follows in the documentation for gdk-pixbuf scaling functions:

This is the slowest and highest quality reconstruction function. It is derived from the hyperbolic filters in Wolberg's "Digital Image Warping", and is formally defined as the hyperbolic-filter sampling the ideal hyperbolic-filter interpolated image (the filter is designed to be idempotent for 1:1 pixel mapping). 

It appears from the note in the brackets that if an image is scaled 1:1 with this filter applied, the image should remain the same.

So current behaviuor of this filter contradicts not only to the user's expectations, but also to the documentation.
Comment 2 Denis Pauk 2012-03-31 19:31:47 UTC
look as duplicate for #80927
Comment 3 Andrey Tsyvarev 2012-04-06 05:29:54 UTC
Yes, it seems that 80927 is origin of this bug
Comment 4 Bastien Nocera 2014-10-22 17:10:00 UTC
And bug 80927 was finally fixed today :)

*** This bug has been marked as a duplicate of bug 80927 ***