Some JPEG not supported (GdkPixbufLoader upstream bug)

Thanks for posting the issue again with more info (original one (inbox#758 (closed)) will be closed in favor of this one).

Next time, please rather add info to the issue when asked about it instead of opening a new one.

mentioned in issue inbox#758 (closed)

Windows 10, Inkscape 0.92.4 (5da689c313, 2019-01-14)
when I try to load this file I get the popup windows which is titled "jpeg bitmap image import"
then I get the message saying "failed to load etc"
after closing Inkscape I get the DOS error message
GdkPixbuf loader failed
very strange that this message appears only after closing Inkscape, not after the load failed.

on Inkscape 1.0beta1 (156f9500, 2019-09-29) I get the following error messages:

Pixbuf::create_from_file: Error interpreting JPEG image file (Unsupported marker type 0xa4)
   (C:\Windows\Temp\IMG_20160520_151742459.jpg)
GdkPixbuf loader failed
C:\Windows\Temp\IMG_20160520_151742459.jpg:1: parser error : Start tag expected, '<' not found
yExif
^
ink_file_open: 'C:\Windows\Temp\IMG_20160520_151742459.jpg' cannot be opened!
InkscapeApplication::document_open: Failed to open: C:\Windows\Temp\IMG_20160520_151742459.jpg
ConcreteInkscapeApplication<T>::create_window: Failed to load: C:\Windows\Temp\IMG_20160520_151742459.jpg
ConcreteInkscapeApplication<T>::create_window: Failed to create desktop!

the program exiftool lists the byte order as:
Exif Byte Order : Big-endian (Motorola, MM)

added 1 deleted label

So could any of you confirm that this is a bug (on your end), @Moini / @alvinpenner ?

Yes.

yes, this is a bug on Windows 10, Inkscape 1.0beta2 (4c82e78a, 2019-12-05).
the file will not load, and I get the DOS error message:

Pixbuf::create_from_file: Error interpreting JPEG image file (Unsupported marker type 0xa4)
   (C:\Windows\Temp\IMG_20160520_151742459.jpg)
GdkPixbuf loader failed
C:\Windows\Temp\IMG_20160520_151742459.jpg:1: parser error : Start tag expected, '<' not found
yExif
^
ink_file_open: 'C:\Windows\Temp\IMG_20160520_151742459.jpg' cannot be opened!
InkscapeApplication::document_open: Failed to open: C:\Windows\Temp\IMG_20160520_151742459.jpg
ConcreteInkscapeApplication<T>::create_window: Failed to load: C:\Windows\Temp\IMG_20160520_151742459.jpg
ConcreteInkscapeApplication<T>::create_window: Failed to create desktop!

on Windows 10, Inkscape 0.92.4 (36965ca6, 2019-12-05) I get the DOS error message:
GdkPixbuf loader failed

Upstream issue: https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/70

added 1 deleted label

removed 1 deleted label

changed title from Linked image not found to Big-endian JPEG not supported (GdkPixbufLoader upstream bug)

marked this issue as related to inbox#1388 (closed)

marked inbox#1388 (closed) as a duplicate of this issue

For those who need it, this seems to be listing a workaround: https://exiftool.org/forum/index.php?topic=3539.0

Another workaround: Remove the exif data for the image that you import into Inkscape. For example, with the following command: exiftool -all= myphoto.jpg

Another suggestion was to convert it to PNG in another program, or to resave it as JPG in another program. E.g. Gimp seems to remove the exif data on saving.

What's weird is that this image IMG_20160520_151742459_from_gimp is reported to have a BigEndian Exif byte order, too. And it can be opened with Inkscape.

Exif data from both for comparison: changed_exif_data.txt

The main difference seems to be the thumbnail data. Which, incidentally, seems to be not loading in the preview of the import dialog in Inkscape already.

changed title from Big-endian JPEG not supported (GdkPixbufLoader upstream bug) to Some JPEG not supported (GdkPixbufLoader upstream bug)

Changing name as per duplicate issue which had little endian (inbox#1388 (closed))

Closed https://bugs.launchpad.net/inkscape/+bug/1679442 as duplicate of this.

Not replicated Windows 10 with 0.48.5
Update: not replicated Windows 10 with 0.91 r13725 or 0.92.1 r15371 7z versions
Not replicated Windows 7 with 0.92.x r15413 (2017 commit) 32bit
Somewhat replicated r15616 MSYS2 devlibs 64b (The imported image is empty, and the console shows a bunch of GdkPixbuf errors. No error dialog. Attachments listing errors are found in the migrated issue but I don't see it as relevant now (I can tell you that in gdk_pixbuf_loader_write, after reading the header, the image is listed as having no width/height/etc.)
Daniel Stiefelmaier (mail-stiefelweb) listed various attempts to fix the image minimally (see expander)

Daniel Stiefelmaier's tests

NOT a fix: recompressing, or removing random EXIF data gm convert IMG_20161206_163501.jpg -size 10% small.jpg exiv2 -M"del Exif.Photo.MakerNote" small.jpg

A fix: stripping ONLY the thumbnail exiv2 -dt *.jpg

However, diff reveals that this moves the metadata section from the front to the back of the file. So, the real issue might be either the size or the position of the meta data.

Also NOT a fix: stripping thumb from front and appending it to the end exiv2 -et test.jpg # export to test-thumb.jpg exiv2 -dt test.jpg # delete thumb exiv2 -it test.jpg # import from test-thumb.jpg

However, ALSO A FIX: making the thumb smaller: cp test-thumb.jpg test-thumb.org.jpg gm convert test-thumb.org.jpg -quality 30% test-thumb.jpg exiv2 -dt test.jpg # delete old thumb first - it DOES make a difference exiv2 -it test.jpg

The largest thumbnail that worked was with 43% quality, which is very close to 10KiB.

Extra example of failing jpg: https://bugs.launchpad.net/inkscape/+bug/1679442/+attachment/4853882/+files/IMG_20161206_163501.jpg

moved from inbox#964 (moved)

added 1 deleted label

added ImportanceMedium label

marked inbox#1717 (closed) as a duplicate of this issue

mentioned in issue inbox#1717 (closed)

marked this issue as related to inbox#1717 (closed)

mentioned in issue inbox#817 (closed)

now fixed upstream (in master, not in a stable build) https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/70

If there's a desire to fix this asap, we can fix this by reading the file in 65536 chunks till the whole file is read. This workarounds the bug. Shouldn't have any real overhead but will add complexity that we may forget to remove. inkscape-incremental-read.diff

They accepted your MR, that's awesome! So it will be fixed in gdk-pixbuf-2.41.0? Looks like the last release was 5 months ago, but before that they used to release more often. So there is a chance it'll be released soon I guess?

I wouldn't mind your inkscape-incremental-read.diff fix if you guard it with GDK_PIXBUF_CHECK_VERSION.