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 57183 - Implement gray scale pixbufs
Implement gray scale pixbufs
Status: RESOLVED WONTFIX
Product: gdk-pixbuf
Classification: Platform
Component: general
git master
Other Linux
: Normal enhancement
: ---
Assigned To: gdk-pixbuf-maint
gdk-pixbuf-maint
: 352785 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2001-07-06 17:54 UTC by Mike Whitson
Modified: 2014-07-19 03:17 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Malformed TIFF file which causes lossage (32.01 KB, image/tiff)
2001-07-06 17:57 UTC, Mike Whitson
Details

Description Mike Whitson 2001-07-06 17:54:59 UTC
When attempting to load the TIFF image available at
<URL:http://primates.ximian.com/~mike/invoice.tif>, both gqview and eog
display the warning:

libpixbuf-tiff: Warning, unknown field with tag 292 (0x124) ignored.

and then attempt to allocate massive amounts of memory.  On one test
machine, gqview allocated over 400 MB before finally displaying the file.

xv displays exactly the same warning, but does not exhibit the same
memory-hogging behaviour.

Others around here have had limited success reproducing this; one person
had gdk-pixbuf simply refuse to display the image.  If this is not easily
reproducible, I will attempt to debug in greater detail.

This is gdk-pixbuf 0.11.0, with gtk+ 1.2.10.
Comment 1 Mike Whitson 2001-07-06 17:57:41 UTC
Created attachment 725 [details]
Malformed TIFF file which causes lossage
Comment 2 Matthias Clasen 2001-08-28 11:22:05 UTC
Looking at the image, this doesn't seem to be related to it being
bad tiff, its just that gdk-pixbuf is a memory hog when it comes to
images like this. It is a 5100x6600 bw image, so it contains 32M 1bit
pixels. I think xv stores bw images as 1 byte per pixel, so it would
use 32M for this image. gdk-pixbuf on the other hand, stores every
image as 4 bytes per pixel, so you end up with 128M for this image.
On top of this, gdk-pixbuf allocates twice this memory to deal with
the different coordinate system used by TIFFReadRGBAImage. 
gdk-pixbuf grows its buffer by repeatedly reallocating it to powers
of two, it may well waste additional memory, which could explain the
peak of 400M which you've seen. 

I guess for pictures like this, load-at-size functionality would really be worthwile, since you're probably not interested in 
5100x6600 pixels. 

How easy it would be to implement load-at-size efficiently on top of
libtiff without allocating a huge buffer, I don't know.
Comment 3 Owen Taylor 2002-01-11 23:02:14 UTC
Gray scale pixbufs (1 byte per pixel) are generally pretty useful
and would reduce memory consumption here. There would have
to be an option to gdk_pixbuf_load to allow turning this on
since current code doesn't expect this. Load-at-size may not
work so well with libtiff (though you could clearly load it
at 1bpp and then scale it in pieces to the final size), but
is certainly a win for libjpeg and thumbnailing.
Comment 4 Matthias Clasen 2002-07-07 20:27:17 UTC
Load-at-size done now (though not very efficient for tiff).
Comment 5 Matthias Clasen 2011-12-16 22:19:54 UTC
*** Bug 352785 has been marked as a duplicate of this bug. ***
Comment 6 Matthias Clasen 2014-07-19 03:17:38 UTC
after 13 years, it seems clear that we're not going to get this.