[android] Trouble working with JPEGs generated by HTC phones
Submitted by an unknown user
Link to original bug (#716754)
Description
---- Reported by shotwell-maint@gnome.bugs 2010-10-12 03:28:00 -0700 ----
Original Redmine bug id: 2664
Original URL: http://redmine.yorba.org/issues/2664
Searchable id: yorba-bug-2664
Original author: Gari Araolaza
Original description:
Shotwell 0.7.2 doesn't import the timestamp in my pictures from my HTC Tattoo (Android phone).
Looking at exif data, it looks like the date format is missing the seconds, and I assume that it could be the reason.
File name : IMAG0742.jpg
File size : 1035172 Bytes
MIME type : image/jpeg
Image size : 2048 × 1536
Camera make : HTC
Camera model : HTC Tattoo
Image timestamp : 2010:08:15 13:35
While Shotwell works well other pictures like:
File name : DSC06700.%(=caps)JPG%
File size : 1713183 Bytes
MIME type : image/jpeg
Image size : 2304 × 1728
Camera make : SONY
Camera model : DSC-P73
Image timestamp : 2009:01:03 11:49:09
Not sure if it's a bug in Shotwell or a poor Exif implementation in my Android system, but many other users could be affected.
I'm ready to send a sample of a picture not working if you need it.
---- Additional Comments From shotwell-maint@gnome.bugs 2012-03-26 15:44:00 -0700 ----
History
Comment 1
Updated by Adam Dingle about 3 years ago
- Priority set to High
garaolaza: Yes, could you attach a sample picture here? That will certainly help us investigate this. Thanks!
Comment 2
Updated by Jim Nelson about 3 years ago
Would like to see a sample picture, but yes, the missing seconds field is almost certainly the problem. It's specified quite clearly in the EXIF spec.
Comment 3
Updated by Gari Araolaza about 3 years ago
Just sent a sample file to adam and jim . Don't know how to upload it in trac. Sorry.
Comment 4
Updated by Gari Araolaza about 3 years ago
It looks like it's a HTC Tattoo related bug, as seen in another project:
http://josm.openstreetmap.de/ticket/5220
Don't know if you could set seconds=0 if missing.
Comment 5
Updated by Jim Nelson about 3 years ago
My current thinking is to special-case this and set seconds to zero if not present.
Comment 6
Updated by Gari Araolaza over 2 years ago
I finally wrote a script to correct the bad EXIF data in these files:
[How to fix HTC Tattoo's image timestamp](http://eibar.org/blogak/teknosexua/archive/2011/02/23/how-to-fix- htc-tattoos-picture-timestamp)
Comment 7
Updated by Adam Dingle over 2 years ago
- Subject changed from Exif timestamp not imported from Android to Exif timestamp not imported from HTC Tattoo
Comment 8
Updated by Adam Dingle over 2 years ago
-
Priority deleted (
<strike>
_High_</strike>
)
Comment 9
Updated by Martin - almost 2 years ago
- Description updated (diff)
- Priority changed from Low to Normal
- Keywords set to EXIF, HTC
This problem appears to occur on the HTC Sensation (Z710e) as well.
Although the problem seems to be with the phone, would it be possible to add ':00' seconds to the time if this is not provided in the EXIF data correctly? This does not seem to be a very difficult change.
...I've looked at this a bit more, and the following is an excerpt for the EXIF data as reported by ImageMagick identify:
Properties:
date:create: 2011-11-27T15:37:33+08:00
date:modify: 2011-11-27T15:37:32+08:00
..
exif:DateTimeDigitized: 2011/11/27 15:37:32
exif:DateTimeOriginal: 2011/11/27 15:37:32
So it might be a slightly different problem with the Sensation (though with the same results -- Shotwell does not recognise the HTC's time stamps).
...I've checked the EXIF standard at http://exif.org/Exif2-2.PDF, and it says (p22):
"The date and time of image creation. In this standard it is the date and time the file was changed. The format is
"YYYY:MM:DD HH:MM:SS" with time shown in 24-hour format, and the date and time separated by one blank
character [20.H]. When the date and time are unknown, all the character spaces except colons (":") may be filled
with blank characters, or else the Interoperability field may be filled with blank characters. The character string
length is 20 bytes including NULL for termination. When the field is left blank, it is treated as unknown."
It seems to me that HTC are adding the timezone on the end of the time. This is arguably a good thing, but it is contrary to the standard. (Maybe they have put a 'T' before the time rather than a space, but I think that is just ImageMagick reformatting the date). Also, note that the 'original' date has slashes in the date part rather than colons.
I would suggest though that Shotwell accept a timestamp on the end of the date, and whatever other format features HTC uses, even if it is not standard.
Comment 10
Updated by Martin - almost 2 years ago
- File IMAG0239.jpg added
Here's an example photo, pulled directly from the HTC Sensation.
Comment 11
Updated by Adam Dingle almost 2 years ago
- Priority changed from Normal to High
I suppose we could special case this if it is easy. We might not have time to work on this at Yorba, but we could accept a patch.
Comment 12
Updated by Adam Dingle almost 2 years ago
- Subject changed from Exif timestamp not imported from HTC Tattoo to Exif timestamp not imported from HTC phones
Comment 13
Updated by Martin - almost 2 years ago
OK, looking at the source, MediaMetadata.vala has a class MetadataDateTime with a string array EXIF_DATE_TIME_FORMATS. The from_exif_date_time method tries each of these formats through date_time.scanf against its argument, returns false if none of them work, and otherwise creates a Unix timestamp from the parsed values. I couldn't find date_time in the Vala references, but its c++ equivalent matches the specified characters/formats and returns the number of successful matches (and ignores any extra characters, so scanf (and hence exif_date_time) should just ignore the timezone information. Perhaps you need an extra format that handles slashes in the date part? ie add "%d/%d/%d %d:%d:%d" as an extra format. This won't fix the original error (no seconds in #1 (moved)) but we could hard code for this at line 114 something like
if (!found and date_time.scanf("%d:%d:%d %d:%d", &tm.year, &tm.month, &tm.day, &tm.hour, &tm.minute) == 5) {tm.seconds = 0; found = true;}
But shotwell won't build on my system as Fedora automatically installs the latest version of Vala (as with everything else), so I get "Shotwell cannot be built by Vala compiler 0.13.0 or greater. You are running 0.14.0". So I can't test anything. Also I don't know Vala at all.
Comment 14
Updated by Adam Dingle almost 2 years ago
Martin, thanks for your investigation so far. As I mentioned in #4443 (closed), the current version of Shotwell in git master will build with the current Vala, and that's the version you should be making changes to anyway. For help learning Vala, there's a lot of great information including tutorials and sample code at http://live.gnome.org/Vala/Documentation . In the method from_exif_date_time(), date_time is a local variable of type string (it's one of the parameters to the method), so of course you won't find the name 'date_time' in the Vala references. The string method scanf is mentioned in the Vala documentation at http://valadoc.org/glib-2.0/string.html , but there's no explanation of what it does there since it's completely equivalent to its counterpart in the standard C library. Hopefully this is enough to help you keep going - if you have more questions just ask.
Comment 15
Updated by Martin - almost 2 years ago
- File shotwell-diff.txt added
OK, here's a patch then. Works for me.
Comment 16
Updated by Gari Araolaza almost 2 years ago
Thanks for the patch Martin!
I'm the original poster of the bug. I'm sure your patch fixes the problem with your phone model but not sure about the original problem with the HTC Tattoo. The format of the timestamp in that model is:
Image timestamp : 2010:08:15 13:35
so "%d/%d/%d %d:%d"
(without seconds)
Sorry about the question, as I'm not able to fully understand your patch. Does it fix the original bug with the Tattoo?
Comment 17
Updated by Martin - almost 2 years ago
Gan, it's intended to fix the Tatoo problem, but I don't actually have any way of testing it myself. Would you be able to test the patch and see if it works?
Martin
Comment 18
Updated by Adam Dingle almost 2 years ago
- File IMAG0716.jpg added
Here's an image from the HTC Tattoo that Gari emailed me about a year ago. This should be useful for testing the patch.
Comment 19
Updated by Adam Dingle almost 2 years ago
- Status changed from Open to Review
- Target version set to 0.12
Lucas, please review this patch. Thanks!
Comment 20
Updated by Lucas Beeler almost 2 years ago
- Subject changed from Exif timestamp not imported from HTC phones to Trouble working with JPEGs generated by HTC phones
- Status changed from Review to Open
- Assignee set to Clinton Rogers
The patch corrects the problem for images from the HTC Sensation, but not for images from the HTC Tattoo. In fact, we just discovered that HTC Tattoo- generated images aren't readable by Shotwell at all, even though they are readable by Eye of GNOME, the GIMP, etc. So the scope of this ticket is broader than just EXIF data -- it also embraces the wholly unreadable HTC Tattoo images.
Since HTC is now the largest handset manufacturer in the world, we should fix this. I'm retitling the ticket and assigning it to Clinton for further investigation.
Comment 21
Updated by Clinton Rogers almost 2 years ago
When opening IMAG0716.jpg with a recent version of GIMP, I noticed that GIMP complains about a premature end-of-file, and the loaded image has a grey bar halfway across the bottom, which suggests that the JPEG itself is malformed in some way. (Eyeofgnome silently crops the image internally at the last complete row of pixels and doesn't display an error, so it looks like it's working normally.)
Would it be possible for us to obtain one or more fresh images shot with an HTC Tattoo?
Comment 22
Updated by Gari Araolaza almost 2 years ago
- File htc_tattoo_exif_bad_timestamp.jpg added
- File htc_tattoo_exif_corrected_timestamp.jpg added
Your example file might be corrupted. Believe me, the only problem I had with my Tattoo pictures (used for 18 months) was the wrong timestamp.
Attached two new Tattoo images, one original from the phone, with wrong timestamp and another one with corrected exif timestamp (just adding ":00" at the end of the timestamp)
Comment 23
Updated by Clinton Rogers almost 2 years ago
Hi Gari,
Thanks for the sample photographs; I've verified that Shotwell can read them both, so it looks like IMAG0716 was a fluke.
Comment 24
Updated by Laura Khalil almost 2 years ago
- Subject changed from Trouble working with JPEGs generated by HTC phones to [android] Trouble working with JPEGs generated by HTC phones
Comment 25
Updated by Adam Dingle over 1 year ago
-
Assignee deleted (
<strike>
_Clinton Rogers_</strike>
)
Comment 26
Updated by Adam Dingle over 1 year ago
-
Target version deleted (
<strike>
_0.12_</strike>
)
--- Bug imported by chaz@yorba.org 2013-11-25 21:47 UTC ---
This bug was previously known as bug 2664 at http://redmine.yorba.org/show_bug.cgi?id=2664 Imported an attachment (id=261781) Imported an attachment (id=261782) Imported an attachment (id=261783) Imported an attachment (id=261784) Imported an attachment (id=261785)
Unknown Component Using default product and component set in Parameters Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution