Project

General

Profile

Support #1198

Cannot read XMP metadata from (darktable) JPEG images

Added by Matthieu Volat over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Robin Mills
Category:
metadata
Target version:
0.26
Start date:
24 Jul 2016
Due date:
% Done:

100%

Estimated time:
3.00 h

Description

Hello,

Using the latest snapshot from the subversion trunk, I have issues with JPEG files (created with darktable development version).

Using the sample provided:

darktable_exported% exiv2 IMGP2518_01.jpg 
Warning: JPEG format error, rc = 5
File name       : IMGP2518_01.jpg
File size       : 90571 Bytes
MIME type       : image/jpeg
Image size      : 0 x 0
IMGP2518_01.jpg: No Exif data found in the file

I tried to trace a bit this error, it seems that XMP section is read whitout issue, but nothing more. Metadata can be displayed with exiftool (which seems to use exiv2 to retrieve XMP section?), so I guess this is not a format issue.

Here's a small JPEG files exhibiting the error.

Thanks a lot for your work!

Files

IMGP2518_01.jpg (88.4 KB) IMGP2518_01.jpg Matthieu Volat, 24 Jul 2016 18:24

Associated revisions

Revision 4352 (diff)
Added by Robin Mills over 5 years ago

#1198. Fixed issue with http I/O failing a test file.

History

#1

Updated by Alan Pater over 5 years ago

  • Tracker changed from Bug to Support

Try: 

~$ exiv2 -pa IMGP2518_01.jpg

That should show you all the XMP metadata.

By the way, exiftool does NOT use exiv2 to read and display XMP data.

#2

Updated by Matthieu Volat over 5 years ago

Indeed, it still give me a warning:

Warning: JPEG format error, rc = 5

But it seems to be a darktable issue as I realize that exiftool don't print that much more information (no shutter speed, aperture settings, etc).

I'll check on that side, sorry for the misleaded report!

#3

Updated by Robin Mills over 5 years ago

  • Status changed from New to Assigned
  • Assignee set to Robin Mills
  • Target version set to 0.26
  • % Done changed from 0 to 20
  • Estimated time set to 2.00 h

There's something unusual about this file. It does have XMP metadata, however it doesn't have Exif metadata. This is causing pain that I would not expect. I've successfully opened your file with v0.25. So there's something in the trunk code that's refusing to open the file. I will investigate.

#4

Updated by Robin Mills over 5 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 20 to 100

Gentlemen:

I think that file is OK on trunk and v0.25. If I copy the file down with curl, here's what I see:

585 rmills@rmillsmbp:~/gnu/exiv2/trunk $ curl -O http://dev.exiv2.org/attachments/download/1020/IMGP2518_01.jpg
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 90571    0 90571    0     0   272k      0 --:--:-- --:--:-- --:--:--  272k
586 rmills@rmillsmbp:~/gnu/exiv2/trunk $ exiv2 -pa IMGP2518_01.jpg >/dev/null
Warning: JPEG format error, rc = 5
587 rmills@rmillsmbp:~/gnu/exiv2/trunk $
The message about JPEG format error is trying to say "There's no Exif data in this file". Here's the proof:
587 rmills@rmillsmbp:~/gnu/exiv2/trunk $ exiv2 -pS IMGP2518_01.jpg
STRUCTURE OF JPEG FILE: IMGP2518_01.jpg
 address | marker     | length  | data
       2 | 0xd8 SOI   |       0 
       4 | 0xe0 APP0  |      16 | JFIF.....,.,....
      22 | 0xe1 APP1  |   10575 | http://ns.adobe.com/xap/1.0/.<?x  <---- XMP data
   10599 | 0xe2 APP2  |    8980 | rRGB XYZ ...........'acspAPPL..
   19583 | 0xe2 APP2  |    8980 | ICC_PROFILE.....#.lcms....mntrRG  <--- ICC profile
   28565 | 0xdb DQT   |      67 
   28634 | 0xdb DQT   |      67 
   28703 | 0xc0 SOF0  |      17 
   28722 | 0xc4 DHT   |      30 
   28754 | 0xc4 DHT   |      77 
   28833 | 0xc4 DHT   |      28 
   28863 | 0xc4 DHT   |      54 
   28919 | 0xda SOS   |      12 
588 rmills@rmillsmbp:~/gnu/exiv2/trunk $
Compare that to a test JPG file:
588 rmills@rmillsmbp:~/gnu/exiv2/trunk $ exiv2 -pS test/data/Reagan.jpg 
STRUCTURE OF JPEG FILE: test/data/Reagan.jpg
 address | marker     | length  | data
       2 | 0xd8 SOI   |       0 
       4 | 0xe0 APP0  |      16 | JFIF.....,.,....
      22 | 0xe1 APP1  |    5671 | Exif..MM.*......................  <--- Exif data
    5695 | 0xed APP13 |    9594 | Photoshop 3.0.8BIM..........Z...  <--- IPTC data
   15291 | 0xe1 APP1  |    7062 | http://ns.adobe.com/xap/1.0/.<?x  <--- XMP data
   22355 | 0xe2 APP2  |    3160 | ICC_PROFILE......HLino....mntrRG  <--- ICC profile
   25517 | 0xee APP14 |      14 | Adobe.d@......
   25533 | 0xdb DQT   |     132 
   25667 | 0xc0 SOF0  |      17 
   25686 | 0xdd DRI   |       4 
   25692 | 0xc4 DHT   |     418 
   26112 | 0xda SOS   |      12 
589 rmills@rmillsmbp:~/gnu/exiv2/trunk $
The message about "JPEG format" can be eliminated by only requesting XMP with the option: -px.

However there is a little oddity here when the file is read by HTTP instead of the from the local file system:

589 rmills@rmillsmbp:~/gnu/exiv2/trunk $ exiv2 http://dev.exiv2.org/attachments/download/1020/IMGP2518_01.jpg
Exiv2 exception in print action for file http://dev.exiv2.org/attachments/download/1020/IMGP2518_01.jpg:
Failed to read image data
590 rmills@rmillsmbp:~/gnu/exiv2/trunk $
That's obviously an issue with the HTTP I/O code and irrelevant to this discussion.

Returning to the issue report itself, the command: 

$ exiv2 MGP2518_01.jpg
is very terse and only reports a summary of the metadata. Alan is quite correct in saying that the option: -pa should be used to reveal all metadata.

Alan is also correct in saying the exiftool does not use exiv2 - however we are on very friendly terms with Phil who masterminds that awesome tool.

#5

Updated by Matthieu Volat over 5 years ago

Thanks a lot, at least, I know my metadata issues are on the file creation side.

#6

Updated by Robin Mills over 5 years ago

  • Estimated time changed from 2.00 h to 3.00 h

Fixed issue with http i/o incorrectly refusing to open Matthieu's test file.

I'm very pleased to have found this. I've been aware for some time that the HTTP I/O sometimes refuses to open some files. It's in the semantics of seek() when you request past EOF. The implementation refuses, however the implementation of file i/o does a reopen and sets EOF. Fixed r4352.

Also available in: Atom PDF