gdk-pixbuf issueshttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues2021-09-13T15:20:08Zhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/39macos backend for gdk-pixbuf2021-09-13T15:20:08ZBugzillamacos backend for gdk-pixbuf## Submitted by Allison (desrt)
**[Link to original bug (#720762)](https://bugzilla.gnome.org/show_bug.cgi?id=720762)**
## Description
I'm not sure of the specifics, but there must surely be some native functions for loading (and sa...## Submitted by Allison (desrt)
**[Link to original bug (#720762)](https://bugzilla.gnome.org/show_bug.cgi?id=720762)**
## Description
I'm not sure of the specifics, but there must surely be some native functions for loading (and saving?) png/jpeg/tiff/etc. files on the Mac. When building on Mac OS, we should depend on those instead of having to use libpng/libjpeg/libtiff.
This would be similar in spirit to the gdi backend for win32.
### Blocking
* [Bug 722476](https://bugzilla.gnome.org/show_bug.cgi?id=722476)https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/38.ani files fail to load when using GDI+ loaders2018-05-22T13:14:40ZBugzilla.ani files fail to load when using GDI+ loaders## Submitted by Chun-wei Fan `@fanc999`
**[Link to original bug (#704730)](https://bugzilla.gnome.org/show_bug.cgi?id=704730)**
## Description
Hi,
When I was running the test programs, animation and pixbuf-read (when using .ani fil...## Submitted by Chun-wei Fan `@fanc999`
**[Link to original bug (#704730)](https://bugzilla.gnome.org/show_bug.cgi?id=704730)**
## Description
Hi,
When I was running the test programs, animation and pixbuf-read (when using .ani files), I get an assertion error indicating that the .ani files couln't be loaded:
ERROR:animation.c:11:test_animation: assertion failed (error == NULL): InvalidParameter (gdk-pixbuf-error-quark, 5)
(A similar error is given when I run pixbuf-read on test-animation.ani)
This occurs when I built gdk-pixbuf with the GDI+ image loaders, but these tests ran fine when I used the "traditional" image laders (i.e. those that made use of libtiff, jpeg-turbo/libjpeg and optionally libjasper).
So, after some investigation it seems that this is caused by GDI+ being unable to support the decoding and reading of .ani files directly.
As I was poking around the code, it seems that although the ANI module was loaded to load the .ani file, the GDI+ module was loaded (and and took over the ANI loader) as the ANI module processed an ICO during the loading process.
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/37invalid offset used when decoding certain BMP images2018-05-30T13:44:32ZBugzillainvalid offset used when decoding certain BMP images## Submitted by Andreas Oberritter
**[Link to original bug (#700952)](https://bugzilla.gnome.org/show_bug.cgi?id=700952)**
## Description
There's a testsuite for BMP images available under the following URL:
http://entropymine.com/j...## Submitted by Andreas Oberritter
**[Link to original bug (#700952)](https://bugzilla.gnome.org/show_bug.cgi?id=700952)**
## Description
There's a testsuite for BMP images available under the following URL:
http://entropymine.com/jason/bmpsuite/bmpsuite/html/bmpsuite.html
Gdk-pixbuf fails to decode the following picture classified as "good" correctly:
http://entropymine.com/jason/bmpsuite/bmpsuite/g/rgb16-565pal.bmp
Of those pictures classified as "questionable", decoding the following fails:
http://entropymine.com/jason/bmpsuite/bmpsuite/q/pal8offs.bmp
My guess is that the "bfOffBits" field at offset 10 of the "BITMAPFILEHEADER" gets ignored. You could validate its value based on the total file size.
Regards,
Andreas
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/36can't load some MPF JPEG images2018-05-30T13:44:18ZBugzillacan't load some MPF JPEG images## Submitted by Lucas Beeler
**[Link to original bug (#694832)](https://bugzilla.gnome.org/show_bug.cgi?id=694832)**
## Description
A consortium of digital camera manufacturers has introduced the MPF (multi-picture format) extension...## Submitted by Lucas Beeler
**[Link to original bug (#694832)](https://bugzilla.gnome.org/show_bug.cgi?id=694832)**
## Description
A consortium of digital camera manufacturers has introduced the MPF (multi-picture format) extension to the standard JPEG/EXIF file format. The standard is described here: http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-007_E.pdf. A variety of Samsung, Sony, and Fuji digital cameras now write MPF JPEG files. The gdk-pixbuf library errors out when attempting to load at least some of these files.
Version: 2.26.x
### Blocking
* [Bug 718123](https://bugzilla.gnome.org/show_bug.cgi?id=718123)https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/35YCbCr JPEG 2000 images not supported2018-05-30T12:59:29ZBugzillaYCbCr JPEG 2000 images not supported## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#685543)](https://bugzilla.gnome.org/show_bug.cgi?id=685543)**
## Description
2 of the jp2k files I tested with didn't work.
See file 2 and 3 in http://pkgs.fedorapr...## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#685543)](https://bugzilla.gnome.org/show_bug.cgi?id=685543)**
## Description
2 of the jp2k files I tested with didn't work.
See file 2 and 3 in http://pkgs.fedoraproject.org/repo/pkgs/openjpeg/j2kp4files_v1_5.zip/27780ed3254e6eb763ebd718a8ccc340/
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/34Resolve a relative path in the module file relative to the module file2018-05-22T13:13:36ZBugzillaResolve a relative path in the module file relative to the module file## Submitted by Anselm Kruis
**[Link to original bug (#678703)](https://bugzilla.gnome.org/show_bug.cgi?id=678703)**
## Description
Created attachment 217112
Resolve a relative path in the module file relative to the module file
Pr...## Submitted by Anselm Kruis
**[Link to original bug (#678703)](https://bugzilla.gnome.org/show_bug.cgi?id=678703)**
## Description
Created attachment 217112
Resolve a relative path in the module file relative to the module file
Problem: currently the ".../libpixbufloader-*.so" lines in the module file must be absolute file names. This renders gdk-pixbuf non relocatable.
I use this path to build a fully relocatable application.
The patch changes gdk-pixbuf to resolve a relative path in the module file relative to the module file itself.
**Patch 217112**, "Resolve a relative path in the module file relative to the module file":
[gdk-pixbuf-2.22.0-relative-module-path.patch](/uploads/1d84df66c33a47e56db52ae612864681/gdk-pixbuf-2.22.0-relative-module-path.patch)
Version: 2.24.xhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/33crash on loading gif image when using gdk-pixbuf with gdi+ backend in gdb env...2019-03-28T08:42:55ZBugzillacrash on loading gif image when using gdk-pixbuf with gdi+ backend in gdb environment## Submitted by A.M
**[Link to original bug (#674337)](https://bugzilla.gnome.org/show_bug.cgi?id=674337)**
## Description
Created attachment 212299
code of sample program and gdb backtrace
I attached code of sample program.i used ...## Submitted by A.M
**[Link to original bug (#674337)](https://bugzilla.gnome.org/show_bug.cgi?id=674337)**
## Description
Created attachment 212299
code of sample program and gdb backtrace
I attached code of sample program.i used binary files i downloaded from gtk.org. program only crashes when using gdb. without gdb it works normally
**Attachment 212299**, "code of sample program and gdb backtrace":
[main.tar.gz](/uploads/199264c53d04152e748543862b087b5a/main.tar.gz)
Version: 2.24.xhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/32Annotate var-arg gdk_pixbuf_save*() as aliases for save*v()2018-05-22T13:12:50ZBugzillaAnnotate var-arg gdk_pixbuf_save*() as aliases for save*v()## Submitted by Torsten Schönfeld `@tsch`
**[Link to original bug (#670372)](https://bugzilla.gnome.org/show_bug.cgi?id=670372)**
## Description
Created attachment 207956
Annotate var-arg gdk_pixbuf_save*() as aliases for save*v()
...## Submitted by Torsten Schönfeld `@tsch`
**[Link to original bug (#670372)](https://bugzilla.gnome.org/show_bug.cgi?id=670372)**
## Description
Created attachment 207956
Annotate var-arg gdk_pixbuf_save*() as aliases for save*v()
This patch the various vector variants so that they shadow the var-arg variants.
~~**Patch 207956**~~, "Annotate var-arg gdk_pixbuf_save*() as aliases for save*v()":
[0001-Annotate-var-arg-gdk_pixbuf_save-as-aliases-for-save.patch](/uploads/55010856959ca4bac908847fc6a31bd3/0001-Annotate-var-arg-gdk_pixbuf_save-as-aliases-for-save.patch)
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/31configure checks for versioned libpng instead of relying on plain .so versioning2019-03-10T12:58:45ZBugzillaconfigure checks for versioned libpng instead of relying on plain .so versioning## Submitted by Pacho Ramos `@pachoramos1`
**[Link to original bug (#667068)](https://bugzilla.gnome.org/show_bug.cgi?id=667068)**
## Description
This comes from:
https://bugs.gentoo.org/show_bug.cgi?id=395037
As explained in https...## Submitted by Pacho Ramos `@pachoramos1`
**[Link to original bug (#667068)](https://bugzilla.gnome.org/show_bug.cgi?id=667068)**
## Description
This comes from:
https://bugs.gentoo.org/show_bug.cgi?id=395037
As explained in https://bugs.gentoo.org/show_bug.cgi?id=395037#c1 we need to make the following hack in gentoo:
# This will avoid polluting the pkg-config file with versioned libpng,
# which is causing problems with libpng14 -> libpng15 upgrade
sed -i -e 's:libpng15:libpng libpng15:' configure.ac || die
to prevent problems when upgrading libpng like:
https://bugs.gentoo.org/383655?id=383655
We could avoid that if unversioned libpng was searched by configure.ac, is there any reason for looking for versioned versions instead? If not, would be nice if you could drop that checks and simply rely on .so versioning
Thanks a lot
Version: 2.24.xhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/30gdk-pixbuf does not handle large tiff images well2019-03-01T11:30:06ZBugzillagdk-pixbuf does not handle large tiff images well## Submitted by Matthias Clasen `@matthiasc`
**[Link to original bug (#666391)](https://bugzilla.gnome.org/show_bug.cgi?id=666391)**
## Description
This is a single bug to track this issue that has been reported multiple times.
Ver...## Submitted by Matthias Clasen `@matthiasc`
**[Link to original bug (#666391)](https://bugzilla.gnome.org/show_bug.cgi?id=666391)**
## Description
This is a single bug to track this issue that has been reported multiple times.
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/29add gdk-pixbuf-loader funtion to read from stream2018-06-30T11:01:08ZBugzillaadd gdk-pixbuf-loader funtion to read from stream## Submitted by Christian Persch `@chpe`
**[Link to original bug (#666377)](https://bugzilla.gnome.org/show_bug.cgi?id=666377)**
## Description
gdk-pixbuf-loader lacks a function to read from a GInputStream. I need that since I need...## Submitted by Christian Persch `@chpe`
**[Link to original bug (#666377)](https://bugzilla.gnome.org/show_bug.cgi?id=666377)**
## Description
gdk-pixbuf-loader lacks a function to read from a GInputStream. I need that since I need to create a pixbuf loader for a specific type, while all the public gdk-pixbuf stream-API (gdk_pixbuf_new_from_stream*) create a nonspecific loader internally.
There's an internal function already that takes a GInputStream, reads its data and writes that to a GdkPixbufLoader; attached patch simply splits that out into a public function.
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/28Pixbuf.fill segfaults2018-06-29T18:20:22ZBugzillaPixbuf.fill segfaults## Submitted by Johannes Sasongko `@sjohannes`
**[Link to original bug (#658702)](https://bugzilla.gnome.org/show_bug.cgi?id=658702)**
## Description
from gi.repository import GdkPixbuf
p = GdkPixbuf.Pixbuf()
p.fill(0)
Result: Segm...## Submitted by Johannes Sasongko `@sjohannes`
**[Link to original bug (#658702)](https://bugzilla.gnome.org/show_bug.cgi?id=658702)**
## Description
from gi.repository import GdkPixbuf
p = GdkPixbuf.Pixbuf()
p.fill(0)
Result: Segmentation fault
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/27can't open some gifs and prints: Circular table entry in GIF file2019-02-18T16:06:04ZBugzillacan't open some gifs and prints: Circular table entry in GIF file## Submitted by leniviy
**[Link to original bug (#647251)](https://bugzilla.gnome.org/show_bug.cgi?id=647251)**
## Description
Created attachment 185576
failing gif
See the attachment. gthumb can't open this file and prints "Circul...## Submitted by leniviy
**[Link to original bug (#647251)](https://bugzilla.gnome.org/show_bug.cgi?id=647251)**
## Description
Created attachment 185576
failing gif
See the attachment. gthumb can't open this file and prints "Circular table entry in GIF file"
OK in firefox.
**Attachment 185576**, "failing gif":
![0cfb2f29379b8ad9d989cfcfaef90315](/uploads/2a35212752c9df9a0ee9ad78f6ffefb8/0cfb2f29379b8ad9d989cfcfaef90315.gif)
Version: 2.23.x
### Depends on
* [Bug 739202](https://bugzilla.gnome.org/show_bug.cgi?id=739202)https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/26Loaded JPGs transfered to cairo with gdk_cairo_set_source_pixbuf() don't use ...2018-06-30T11:02:58ZBugzillaLoaded JPGs transfered to cairo with gdk_cairo_set_source_pixbuf() don't use cairo_surface_set_mime_data()## Submitted by Andrew Cowie
**[Link to original bug (#637515)](https://bugzilla.gnome.org/show_bug.cgi?id=637515)**
## Description
When using ImageSurfaces implicily creating a Cairo Surface with gdk_cairo_set_source_pixbuf(). Cair...## Submitted by Andrew Cowie
**[Link to original bug (#637515)](https://bugzilla.gnome.org/show_bug.cgi?id=637515)**
## Description
When using ImageSurfaces implicily creating a Cairo Surface with gdk_cairo_set_source_pixbuf(). Cairo will draw the image as a bitmap.
This is sub-optimal for when drawing out to a vector backend like PDF, SVG, PS, etc [ie, when printing] - you end up with huge multi megabyte files where the origin JPEG was only a few hundred kilobytes. Bummer.
As of Cairo 1.10 there's now cairo_surface_set_mime_data() where the original encoded image data can be attached to the surface being drawn, and, if the output turns out to be a vector backend the mime data is used instead of the fallback bitmap.
In our case, that means:
```cpp
// use data to create GdkPixbuf
gdk_pixbuf_new_from_...
gdk_cairo_set_source_pixbuf()
// extract the implicitly created surface
cairo_pattern_get_surface()
// use the original data here as the anti-fallback :)
cairo_surface_set_mime_data()
// continue, drawing image onto target.
cairo_paint()
```
Adrian Johnson suggested that maybe the `gdk_cairo_set_source_pixbuf()` could just do the `cairo_surface_set_mime_data()` call automatically.
I'm not sure if we still have the originally loaded from disk etc image still attached to the GdkPixbuf, but if we do this would be easy. If not, seems like it would be something to think about seeing as we are now drawing exclusively with Cairo, all in the "give Cairo more information" department.
Wasn't really clear whether this should go here or against gdk-pixbuf in Bugzilla.
AfC
Version: 2.23.xhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/25Access violation writing location2018-05-22T13:10:49ZBugzillaAccess violation writing location## Submitted by JesseStone
**[Link to original bug (#619991)](https://bugzilla.gnome.org/show_bug.cgi?id=619991)**
## Description
when
if (Ok != (status = GdipBitmapGetPixel (bitmap, x, y, &pixel)))
{...}
will happen
First-chanc...## Submitted by JesseStone
**[Link to original bug (#619991)](https://bugzilla.gnome.org/show_bug.cgi?id=619991)**
## Description
when
if (Ok != (status = GdipBitmapGetPixel (bitmap, x, y, &pixel)))
{...}
will happen
First-chance exception at 0x4b03b280 in gtk-demo.exe: 0xC0000005: Access violation writing location 0x01c6000e.
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/24jpeg loader fails (on some images) with big buffers2018-06-29T17:47:07ZBugzillajpeg loader fails (on some images) with big buffers## Submitted by Stephane Delcroix
**[Link to original bug (#592446)](https://bugzilla.gnome.org/show_bug.cgi?id=592446)**
## Description
For some images (see attachment), the GdkPixbufLoader for jpegs abort with errors "Error interp...## Submitted by Stephane Delcroix
**[Link to original bug (#592446)](https://bugzilla.gnome.org/show_bug.cgi?id=592446)**
## Description
For some images (see attachment), the GdkPixbufLoader for jpegs abort with errors "Error interpreting JPEG image file (JPEG datastream contains no image)" if gdk_pixbuf_loader_write count argument is big.
Test case:
```cpp
#include <stdio.h>
#include <glib.h>
#include <gdk-pixbuf/gdk-pixbuf.h>
int main ()
{
int count = 1 << 20;
char buf [count];
FILE *f = fopen ("img.jpg", "r");
GdkPixbufLoader *loader;
GError *err = NULL;
g_type_init ();
loader = gdk_pixbuf_loader_new ();
while (!feof (f)) {
size_t c = fread (buf, sizeof (char), count, f);
gdk_pixbuf_loader_write (loader, buf, c, &err);
if (err != NULL) {
fprintf (stderr, "%s\n", err->message);
g_error_free (err);
return 1;
}
}
return 0;
}
```
replacing `count = 1 << 20` by `count = 1 << 16` loads the attached image just fine.
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/23gdk_pixbuf_loader_get_pixbuf returns different results if gdk_pixbuf_loader_s...2018-05-22T13:10:21ZBugzillagdk_pixbuf_loader_get_pixbuf returns different results if gdk_pixbuf_loader_set_size has been called## Submitted by Andrey Tsyvarev
**[Link to original bug (#583547)](https://bugzilla.gnome.org/show_bug.cgi?id=583547)**
## Description
Values, returned by gdk_pixbuf_loader_get_pixbuf before and after call of gdk_pixbuf_loader_close...## Submitted by Andrey Tsyvarev
**[Link to original bug (#583547)](https://bugzilla.gnome.org/show_bug.cgi?id=583547)**
## Description
Values, returned by gdk_pixbuf_loader_get_pixbuf before and after call of gdk_pixbuf_loader_close, may differ. This difference contradict to the description of gdk_pixbuf_loader_get_pixbuf:
The returned pixbuf will be the same in all future calls to the loader, so simply calling g_object_ref() should be sufficient to continue using it.
This occures when gdk_pixbuf_loader_set_size has been called with sizes which different from sizes of image loaded.
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/22The gdk_pixbuf_composite_color function uses wrong checkboard offset2018-05-22T13:10:09ZBugzillaThe gdk_pixbuf_composite_color function uses wrong checkboard offset## Submitted by Andrey Tsyvarev
**[Link to original bug (#583029)](https://bugzilla.gnome.org/show_bug.cgi?id=583029)**
## Description
From the description of gdk_pixbuf_composite_color:
Creates a transformation of the source image ...## Submitted by Andrey Tsyvarev
**[Link to original bug (#583029)](https://bugzilla.gnome.org/show_bug.cgi?id=583029)**
## Description
From the description of gdk_pixbuf_composite_color:
Creates a transformation of the source image src by scaling by scale_x and scale_y then translating by offset_x and offset_y, then composites the rectangle (dest_x ,dest_y, dest_width, dest_height) of the resulting image with a checkboard of the colors color1 and color2 and renders it onto the destination image.
There is also a note about the origin of the checkboard in the description of check_x parameter:
origin of checkboard is at -check_x, -check_y
However gdk_pixbuf_composite_color is implemented so, that the checkboard is shifted by dest_x and dest_y before composition with the source image. So the actual position of the checkboard's origin is (dest_x-check_x, dest_y-check_y) when composition is performed.
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/21Need pixbuf orientation available on GdkPixbufLoader "size-prepared" signal2018-05-22T13:09:59ZBugzillaNeed pixbuf orientation available on GdkPixbufLoader "size-prepared" signal## Submitted by Marina Zhurakhinskaya
**[Link to original bug (#579003)](https://bugzilla.gnome.org/show_bug.cgi?id=579003)**
## Description
It would be useful to make pixbuf orientation available by the time GdkPixbufLoader "size-p...## Submitted by Marina Zhurakhinskaya
**[Link to original bug (#579003)](https://bugzilla.gnome.org/show_bug.cgi?id=579003)**
## Description
It would be useful to make pixbuf orientation available by the time GdkPixbufLoader "size-prepared" signal is emitted, so that the scaled size for the pixbuf can be determined correctly given the available width and height.
It is currently not available from the pixbuf returned by gdk_pixbuf_loader_get_pixbuf() at that time of the signal or from any function of the GdkPixbufLoader itself.
The workaround I am using now is loading a scaled image with the default orientation, then calling gdk_pixbuf_apply_embedded_orientation() for it, checking if the width of the pixbuf returned by that function is different from the width of the original pixbuf, and if it is, reloading the scaled image with the available dimensions reversed, and calling gdk_pixbuf_apply_embedded_orientation() on it.
There are a few possibilities, including making related functions available for the pixbuf returned by the GdkPixbufLoader at the time or having the GdkPixbufLoader itself have a function to get or apply embedded orientation before the pixbuf is actually loaded. Since getting embedded orientation can return multiple values the same way "orientation" option for gdk_pixbuf_get_option() returns multiple values, it might be useful to just have a function that returns a boolean indicating if rotation will be necessary when embedded orientation is applied.
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/20DNG images show as thumbnails, not the real image.2020-04-01T18:12:13ZBugzillaDNG images show as thumbnails, not the real image.## Submitted by Adam Buchbinder
**[Link to original bug (#577499)](https://bugzilla.gnome.org/show_bug.cgi?id=577499)**
## Description
Please describe the problem:
The embedded thumbnails, rather than the real images, in DNG files a...## Submitted by Adam Buchbinder
**[Link to original bug (#577499)](https://bugzilla.gnome.org/show_bug.cgi?id=577499)**
## Description
Please describe the problem:
The embedded thumbnails, rather than the real images, in DNG files are displayed in apps that use gdk-pixbuf. I believe this is because it's being recognized as a TIFF image.
Steps to reproduce:
1. Go to www.rawsamples.ch and download the DNG sample for a Leica M8. (It's 10MB, so I'm not attaching it here.)
2. Open it with gthumb.
Actual results:
The image displayed is 320x240.
Expected results:
The full, 3920x2638, image should be displayed.
Does this happen every time?
Yes; this is reproducible. The issue appears in gthumb, eog, and f-spot. I believe the problem is in gdk-pixbuf, since all three apps use it.
Other information:
Decoding the image to a TIFF with dcraw allows me to view it properly; the image does not appear to have anything wrong with it.
$ dcraw -i -v RAW_LEICA_M8.DNG |grep size
Thumb size: 320 x 240
Full size: 3920 x 2638
Image size: 3920 x 2638
Output size: 3920 x 2638
If the image is read as a TIFF, the thumbnail size is read:
$ tiffinfo RAW_LEICA_M8.DNG 2>/dev/null|grep Width
Image Width: 320 Image Length: 240
gdk-pixbuf is displaying what we'd get if we tried to load the DNG as a TIFF.
$ tifftopnm RAW_LEICA_M8.DNG 2>/dev/null | head -2 | tail -1
320 240
This was originally reported on the Ubuntu bugtracker:
https://bugs.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/333388
Version: git master