Project

General

Profile

bogus timezone value

Added by Anonymous Poster almost 6 years ago

I noticed, that some of my images contained a bogus value for timezone:

$ exiv2 -g Exif.NikonWt.Timezone DSC_3249-nc.jpg
Exif.NikonWt.Timezone SShort 1 UTC +256:00

The originating RAW file was okay:

$ exiv2 -g Exif.NikonWt.Timezone DSC_3249.NEF
Exif.NikonWt.Timezone SShort 1 UTC +01:00

So I decided to remove all EXIF data

$ exiv2 rm DSC_3249-nc.jpg
$ exiv2 -g Exif.NikonWt.Timezone DSC_3249-nc.jpg
<nothing>

and re-import the data from the RAW file:

$ exiv2 ex DSC_3249.NEF
$ mv DSC_3249.exv DSC_3249-nc.exv
$ exiv2 in DSC_3249-nc.jpg
$ exiv2 -g Exif.NikonWt.Timezone DSC_3249-nc.jpg
Exif.NikonWt.Timezone SShort 1 UTC +01:00

So everything looked fine. As I had tagged the JPEG before, I added this tag afterwards:

$ exiv2 -M"add Iptc.Application2.Keywords String 2400pix" DSC_3249-nc.jpg

But this last step damages the timezone data again:

$ exiv2 -g Exif.NikonWt.Timezone DSC_3249-nc.jpg
Exif.NikonWt.Timezone SShort 1 UTC +256:00

Adding a description "fixes" this:

$ exiv2 -M"add Iptc.Application2.Caption String Storch" DSC_3249-nc.jpg
$ exiv2 -g Exif.NikonWt.Timezone DSC_3249-nc.jpg
Exif.NikonWt.Timezone SShort 1 UTC +01:00

What's going on here? This happens with exiv2 0.23 on NetBSD 6.0/amd64.


Replies (11)

RE: bogus timezone value - Added by Andreas Huggel almost 6 years ago

Happy to report that I can't reproduce this ;-)

$ exiv2 -u -pa ee.jpg 
$ exiv2 -M 'set Exif.Image.Make NIKON' -M 'set Exif.NikonWt.Timezone 60' ee.jpg 
$ exiv2 -u -pa ee.jpg 
Exif.Image.Make                              Ascii       6  NIKON
Exif.Image.ExifTag                           Long        1  44
Exif.Photo.MakerNote                         Undefined  36  78 105 107 111 110 0 2 16 0 0 73 73 42 0 8 0 0 0 1 0 36 0 7 0 4 0 0 0 60 0 0 0 0 0 0 0
Exif.MakerNote.Offset                        Long        1  62
Exif.MakerNote.ByteOrder                     Ascii       3  II
Exif.NikonWt.Timezone                        SShort      1  UTC +01:00
Exif.NikonWt.DaylightSavings                 Byte        1  No
Exif.NikonWt.DateDisplayFormat               Byte        1  Y/M/D
$ exiv2 -M"add Iptc.Application2.Keywords String 2400pix" ee.jpg 
$ exiv2 -u -pa ee.jpg 
Exif.Image.Make                              Ascii       6  NIKON
Exif.Image.ExifTag                           Long        1  44
Exif.Photo.MakerNote                         Undefined  36  78 105 107 111 110 0 2 16 0 0 73 73 42 0 8 0 0 0 1 0 36 0 7 0 4 0 0 0 60 0 0 0 0 0 0 0
Exif.MakerNote.Offset                        Long        1  62
Exif.MakerNote.ByteOrder                     Ascii       3  II
Exif.NikonWt.Timezone                        SShort      1  UTC +01:00
Exif.NikonWt.DaylightSavings                 Byte        1  No
Exif.NikonWt.DateDisplayFormat               Byte        1  Y/M/D
Iptc.Application2.Keywords                   String      7  2400pix
$ 

But seriously, this sounds very strange. Can you provide a picture that has the Nikon Exif data but not the IPTC tag for me to play with? (Either upload it here or send it to ahuggel at gmx dot net.)

Andreas

RE: bogus timezone value - Added by Anonymous Poster almost 6 years ago

What a surprise ;)

I have uploaded two sets (RAW and JPEGs) of images to

https://drive.google.com/folderview?id=0B_8w9Tstv6xZT0szWjAzQjJlRHM

DSC_8184.NEF was made with a D300s, DSC_3249.NEF with a D800 (i.e. the RAW file is quite big!). The JPEGs already contain bogus timezone values, but I can't remember the exact way how these images were created.

I have repeated the same sequence of commands on Mac OS X 10.9, and there the timezone is not mangled. On Solaris 10/i86, I can repeat the problem.

In all cases, exiv2 is built via pkgsrc. The compilers used are

NetBSD 6.0/amd64: gcc (NetBSD nb2 20110806) 4.5.3
Solaris 10/i86: gcc (GCC) 4.7.0
Mac OS X: Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)

On NetBSD, the gcc generates 64bit code, on Solaris 32bit code. So this might be a GCC problem.

RE: bogus timezone value - Added by Andreas Huggel almost 6 years ago

I can reproduce the issue now. The first step is enough:

$ exiv2 ex DSC_8184.NEF
generates an exv file with the bogus timezone value. Valgrind doesn't complain, so it must be a relatively straightforward issue. However, I still can't re-create it with my own little image ee.jpg from the example above. Please bear with me, I'll investigate further.

Can you try the above command again on your Mac, does it still not happen there?

RE: bogus timezone value - Added by Jörn Clausen almost 6 years ago

(thought I'd better register if this drags on... :)

The exported .exv file actually does contain the wrong value on Mac OS X, too:

$ exiv2 ex DSC_8184.NEF
$ exiv2 -g Exif.NikonWt.Timezone DSC_8184.*
DSC_8184.NEF Exif.NikonWt.Timezone SShort 1 UTC +01:00
DSC_8184.exv Exif.NikonWt.Timezone SShort 1 UTC +256:00

But for some reason it is "fixed" on import:

$ mv DSC_8184.exv DSC_8184-800x600.exv
$ exiv2 in DSC_8184-800x600.jpg
$ exiv2 -g Exif.NikonWt.Timezone DSC_8184*
DSC_8184-800x600.exv Exif.NikonWt.Timezone SShort 1 UTC +256:00
DSC_8184-800x600.jpg Exif.NikonWt.Timezone SShort 1 UTC +01:00
DSC_8184.NEF Exif.NikonWt.Timezone SShort 1 UTC +01:00

RE: bogus timezone value - Added by Robin Mills almost 6 years ago

256 = 255 +1

Is this a formatting issue or an unsigned char is being used instead of an unsigned short? It's something like that.

Robin

RE: bogus timezone value - Added by Andreas Huggel almost 6 years ago

Or an endianness issue: 1 = 0x0001, 256 = 0x0100
If the bytes are wrongly swapped every time the operation is run, it would also explain why a seemingly unrelated command can "fix" the problem.
I just haven't had time to look for the code that is responsible for this mess yet..

RE: bogus timezone value - Added by Anonymous Poster almost 6 years ago

One thing I forgot to try before: Repeating the exactly same operation over and over again flips the timezone value each time:

$ exiv2 -g Exif.NikonWt.Timezone DSC_8184-800x600.jpg
Exif.NikonWt.Timezone SShort 1 UTC +01:00
$ exiv2 -M"add Iptc.Application2.Keywords String birding" DSC_8184-800x600.jpg
$ exiv2 -g Exif.NikonWt.Timezone DSC_8184-800x600.jpg
Exif.NikonWt.Timezone SShort 1 UTC +256:00
$ exiv2 -M"add Iptc.Application2.Keywords String birding" DSC_8184-800x600.jpg
$ exiv2 -g Exif.NikonWt.Timezone DSC_8184-800x600.jpg
Exif.NikonWt.Timezone SShort 1 UTC +01:00
$ exiv2 -M"add Iptc.Application2.Keywords String birding" DSC_8184-800x600.jpg
$ exiv2 -g Exif.NikonWt.Timezone DSC_8184-800x600.jpg
Exif.NikonWt.Timezone SShort 1 UTC +256:00

So a byte-swap seems to be a reasonable explanation.

A workaround for me is to remove all EXIF data, copy over the original value from the RAW file and then make sure that an even number of operations is used to add tags and descriptions - by simply repeating each command twice. Some of my images have only tags but no descriptions, those were the cases where I ended up with a wrong timezone value.

RE: bogus timezone value - Added by Andreas Huggel almost 6 years ago

Interestingly, the 4 bytes that make up the NikonWt array are exactly the same in DSC_8184.NEF and DSC_8184.exv; the 2 timezone bytes are NOT swapped. One difference is however that DSC_8184.NEF uses big-endian (MM) for both the TIFF (Exif) data as well as for the Makernote, whereas the Exif data in the exv file uses little-endian (II) and the Makernote uses big-endian (MM). So this seems to rather be an issue with the code that reads the data, not the writing part.

RE: bogus timezone value - Added by Andreas Huggel over 5 years ago

I've created bug #945 for this and checked-in a fix. Jörn, could you please test the current trunk revision and confirm if that solves the issue for you?

Andreas

RE: bogus timezone value - Added by Jörn Clausen over 5 years ago

I have applied the changes to version 0.23, as I have problems building 0.24 (different story, maybe later :). With these patches, the problem seems to be gone:

$ exiv2 -g Exif.NikonWt.Timezone DSC_3249*
DSC_3249-800.jpg Exif.NikonWt.Timezone SShort 1 UTC +256:00
DSC_3249.NEF Exif.NikonWt.Timezone SShort 1 UTC +01:00

$ exiv2 ex DSC_3249.NEF

$ exiv2 -g Exif.NikonWt.Timezone DSC_3249*
DSC_3249-800.jpg Exif.NikonWt.Timezone SShort 1 UTC +256:00
DSC_3249.NEF Exif.NikonWt.Timezone SShort 1 UTC +01:00
DSC_3249.exv Exif.NikonWt.Timezone SShort 1 UTC +01:00

$ mv DSC_3249.exv DSC_3249-800.exv
$ exiv2 in DSC_3249-800.jpg

$ exiv2 -g Exif.NikonWt.Timezone DSC_3249*
DSC_3249-800.exv Exif.NikonWt.Timezone SShort 1 UTC +01:00
DSC_3249-800.jpg Exif.NikonWt.Timezone SShort 1 UTC +01:00
DSC_3249.NEF Exif.NikonWt.Timezone SShort 1 UTC +01:00

$ exiv2 -M"add Iptc.Application2.Keywords String birding" DSC_3249-800.jpg
$ exiv2 -g Exif.NikonWt.Timezone DSC_3249*
DSC_3249-800.exv Exif.NikonWt.Timezone SShort 1 UTC +01:00
DSC_3249-800.jpg Exif.NikonWt.Timezone SShort 1 UTC +01:00
DSC_3249.NEF Exif.NikonWt.Timezone SShort 1 UTC +01:00

$ exiv2 -M"add Iptc.Application2.Caption String Storch" DSC_3249-800.jpg
$ exiv2 -g Exif.NikonWt.Timezone DSC_3249*
DSC_3249-800.exv Exif.NikonWt.Timezone SShort 1 UTC +01:00
DSC_3249-800.jpg Exif.NikonWt.Timezone SShort 1 UTC +01:00
DSC_3249.NEF Exif.NikonWt.Timezone SShort 1 UTC +01:00

No more byte swapping, no matter what operation is executed. I have also tested the other example image, with the same results. This looks really good. I have tried it on NetBSD/amd64 with GCC 4.5.3. I can crosscheck on Solaris and Mac OS X in the next days, but I don't expect any more problems.

Thanks a lot!!!

RE: bogus timezone value - Added by Andreas Huggel over 5 years ago

Great, thanks for the quick response!

    (1-11/11)