Bug #876

New lens: Canon EF 35mm f/2 IS USM

Added by markus kanet over 4 years ago. Updated almost 4 years ago.

Status:ClosedStart date:11 Jan 2013
Priority:NormalDue date:
Assignee:Robin Mills% Done:

0%

Category:metadata
Target version:0.24

Description

There is a new Canon lens 35mm f/2 IS USM (Note: There is already an older 35mm f/2 lens without IS).

Lens-ID: 505
I added the following line to src/canonmn.cpp and lens is identified correct

{ 505, "Canon EF 35mm f/2 IS USM" },

#: exiv2 -Pkvt IMG_2108.CR2 | grep -i "lens"
Exif.CanonCs.LensType 505 Canon EF 35mm f/2 IS USM
Exif.CanonCs.Lens 35 35 1 35.0 mm
Exif.Canon.LensModel EF35mm f/2 IS USMQeD� EF35mm f/2 IS USMQeD�
Exif.Photo.LensSpecification 35/1 35/1 0/1 0/1 35/1 35/1 0/1 0/1
Exif.Photo.LensModel EF35mm f/2 IS USM EF35mm f/2 IS USM
Exif.Photo.LensSerialNumber 00000013e8 00000013e8

Exif.Canon.LensModel shows some garbage after the modelname.


Related issues

Related to Exiv2 - Patch #839: Canon EOS M EF-M lenses Closed 21 Aug 2012

Associated revisions

Revision 2963
Added by Robin Mills over 4 years ago

Issue: #876 and #877. Addition to Canon Maker Notes. Thanks to Markus for the fix.

Revision 2964
Added by Robin Mills over 4 years ago

Issue: #876. Garbage in Exif.Canon.LensModel. Thanks to Markus for reporting this and providing test data.

Revision 2965
Added by Robin Mills over 4 years ago

Issue: #876 and 877. Updated test suite. Thanks to Markus for the test file.

Revision 2966
Added by Robin Mills over 4 years ago

Issue: #876 Fix for Exiv.Canon.LensModel displaying garbage bytes.

Revision 2967
Added by Robin Mills over 4 years ago

Issue: #876. Updated test file. Incorrect version submitted in SVN#2966

Revision 3190
Added by Andreas Huggel almost 4 years ago

#876: Reverted changes made with r2966, r2976 and r2973 and added a fix to only output characters up to the first \0 in ASCII values.

History

#1 Updated by Robin Mills over 4 years ago

  • Category set to metadata
  • Status changed from New to Assigned
  • Assignee set to Robin Mills
  • Target version set to 0.24

Please see my comment in Issue#877.

Robin

#2 Updated by Robin Mills over 4 years ago

I've updated the test suite to use the test file provided by Markus. Thank you Markus for providing this.

I'm unhappy about this fix. In an earlier submission, I thought I had this fixed by getting StringValueBase::read to respect the nul as a terminator. Indeed that passed test/bugfixes-test.sh and was submitted. However that fix broke test/conversion.sh and other tests as it prematurely terminated unicode strings.

There is a test in TiffReader::readTiffEntry() for tag Exif.Canon.LensModel and to respect nul. This fix doesn't scale as more instances of this behavior will require special handling.

#3 Updated by Robin Mills over 4 years ago

  • Status changed from Assigned to Resolved

#4 Updated by Robin Mills over 4 years ago

I've revisited the subject of nul-terminated ascii strings in Canon MakeNotes.

Code was added to tiffvisitor.cpp in January (r2966) to give special treatment to Exif.Canon.LensModel. Although I suspect there are other tags with this behavior, I found no vidence using the files in <exiv2dir>/test/data. For example, the length every string in 01.jpg is correct:

653 rmills@rmills-imac:~/gnu/exiv2/exiv2.master/test/data $ exiv2 -pt 01.jpg | grep Ascii
Exif.Image.Make                              Ascii       6  Canon
Exif.Image.Model                             Ascii      12  Canon EOS M
Exif.Image.DateTime                          Ascii      20  2012:06:29 14:48:14
Exif.Image.Artist                            Ascii       1  
Exif.Image.Copyright                         Ascii       1  
Exif.Photo.DateTimeOriginal                  Ascii      20  2012:06:29 14:48:14
Exif.Photo.DateTimeDigitized                 Ascii      20  2012:06:29 14:48:14
Exif.MakerNote.ByteOrder                     Ascii       3  II
Exif.Canon.ImageType                         Ascii      12  Canon EOS M
Exif.Canon.FirmwareVersion                   Ascii      22  Firmware Version 5.2.3
Exif.Canon.OwnerName                         Ascii      32  
Exif.Canon.LensModel                         Ascii      16  EF-M22mm f/2 STM
Exif.Canon.InternalSerialNumber              Ascii       9  EA0002893
Exif.Photo.SubSecTime                        Ascii       3  88
Exif.Photo.SubSecTimeOriginal                Ascii       3  88
Exif.Photo.SubSecTimeDigitized               Ascii       3  88
Exif.Iop.InteroperabilityIndex               Ascii       4  R98
Exif.Photo.CameraOwnerName                   Ascii       1  
Exif.Photo.BodySerialNumber                  Ascii      13  001009900099
Exif.Photo.LensModel                         Ascii      17  EF-M22mm f/2 STM
Exif.Photo.LensSerialNumber                  Ascii      11  000000002d
654 rmills@rmills-imac:~/gnu/exiv2/exiv2.master/test/data $ 

I don't intend to spend further time on this matter (however I suspect it will resurface on another tag).

#5 Updated by Robin Mills about 4 years ago

  • Status changed from Resolved to Closed

Fixed in 0.24.

#6 Updated by Andreas Huggel almost 4 years ago

I've undone the changes in r2966 (and related in r2973 and r2976) and added a fix on the output side instead (exactly what you said in http://dev.exiv2.org/issues/839#note-2, Robin): We read the complete tag value from the image but when output to a stream is requested, only write up to the first \0 character. That's more generic and more inline with the general exiv2 philosophy as it ensures the tag value won't change - even if it contains \0 characters - unless explicitly requested.

#7 Updated by Robin Mills almost 4 years ago

Thanks for dealing with this, Andreas.

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux