Cannot read XMP metadata from (darktable) JPEG images
|Status:||Closed||Start date:||24 Jul 2016|
|Assignee:||Robin Mills||% Done:|
|Category:||metadata||Estimated time:||3.00 hours|
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!
#2 Updated by Matthieu Volat 12 months 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 12 months 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
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 12 months ago
- Status changed from Assigned to Closed
- % Done changed from 20 to 100
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:
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.jpgis very terse and only reports a summary of the metadata. Alan is quite correct in saying that the option:
-pashould 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.
#6 Updated by Robin Mills 12 months ago
- Estimated time changed from 2.00 to 3.00
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.