Exiv2

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

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.

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

$ exiv2 ex DSC_8184.NEF

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

(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

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

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..

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.

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.

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

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!!!

Great, thanks for the quick response!