Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
gdk-pixbuf
gdk-pixbuf
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 73
    • Issues 73
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 7
    • Merge Requests 7
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GNOME
  • gdk-pixbufgdk-pixbuf
  • Issues
  • #70

Closed
Open
Opened Dec 27, 2017 by bugzilla-migration@bugzilla-migrationReporter

Error "Unsupported marker type" when loading JPG files from some cameras

Submitted by Mario Sanchez Prada @msanchez

Link to original bug (#791971)

Description

As reported originally in bug 768639, certain types of files (such as [1], reported as a bug for Vimiv [2]) fail to load when using GdkPixbufLoader, resulting in errors such as the following ones:

Error interpreting JPEG image file (Unsupported marker type 0xb9)
Error interpreting JPEG image file (Unsupported marker type 0x3e)
Error interpreting JPEG image file (Unsupported marker type 0x1a)

As reported in [3] and [4], it's interesting to note that the very same files load fine when using gdk_pixbuf_new_from_file() instead of the GdkPixbufLoader, even though if both code paths end up using the JPEG IO module from gdk-pixbuf.

I've spent some time today debugging this and this looks like a problem in gdk-pixbuf since the problem happens when using gdk_pixbuf_loader_write(), which relies on the internal gdk_pixbuf__jpeg_image_load_increment() function to load the data... well... incrementally. However, the problem doesn't happen when using gdk_pixbuf_new_from_file(), which relies on the internal gdk_pixbuf__jpeg_image_load() function instead (which is much simpler).

If you check bug 768639 you'll see this bug has been reported a while ago already, and initially I thought this might be a problem in the underlying jpeg library, but the more recent comments/experiments point to gdk-pixbuf, so I'm reporting this since I couldn't figure it out by myself yet, in case someone else can help.

FWIW, this seems to be an increasingly annoying problem since, even though originally I could not reproduce it at all, I can now reproduce it very easily with pictures taken with my wife's Moto G3 and my own OnePlus 5 phones, and who knows what else.

  1. https://user-images.githubusercontent.com/7871070/28070025-26867f24-667e-11e7-9ae7-a80290b0c0ff.jpg
  2. https://github.com/karlch/vimiv/issues/49
  3. https://github.com/karlch/vimiv/issues/49#issuecomment-314569184
  4. https://bugzilla.gnome.org/show_bug.cgi?id=768639#c9
Edited May 30, 2018 by Emmanuele Bassi
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: GNOME/gdk-pixbuf#70