Galaxy S2 ISO tag

[GoogleCodeExporter]

What steps will reproduce the problem?

if (tag.getTagType() == 34855 ){ //ExifSubIFDDirectory.TAG_ISO_EQUIVALENT
    String iso = tag.toString();

When reading the iso tag on a  galaxy S2 phone it reads the tag perfectly, 
except when the value is 40. When the value is 40 the tag.toString() reports 
the iso as 8000. I have only found this problem on the galaxy S2, the Galaxy S 
works perfectly. 

I'm using this in the android SDK and metadata-extractor-2.5.0RC2

this bug has been noted in other applications ie, FireFox EXIF reader but not 
in other apps like Chrome EXIF reader. So I'm not sure if it is a Galaxy S2 bug 
or a but in some EXIF viewers?

This forum is all I could find on the issue
http://forums.dpreview.com/forums/readflat.asp?forum=1012&message=38465702&chang
emode=1

Original issue reported on code.google.com by stephen....@gmail.com on 29 Oct 2011 at 12:27

[GoogleCodeExporter]

Hi Stephen,

Are you able to attach a file that reproduces this issue?  I have an S1 myself. 
 It'd be ideal if you were able to provide an image that I could include in the 
test data set, and therefore one that you were happy to release publicly.  The 
actual image doesn't matter.

Original comment by drewnoakes on 14 Nov 2011 at 11:32

• Changed state: Accepted

[GoogleCodeExporter]

I'll steal my wife's S2 and snap an image for you ... as I said it works
perfectly with my S1 .

Original comment by stephen....@gmail.com on 14 Nov 2011 at 11:36

[GoogleCodeExporter]

I used the image from the forum you linked to.  Turns out that the code which 
converts from the underlying integer value to a descriptive string had this 
condition:

        if (isoEquiv < 50)
            isoEquiv *= 200;

There must have been some old camera model that misrepresented its values by 
this factor.

I prefer to adhere to the standard and so have removed this conditional factor.

Thanks again for the bug report.

Original comment by drewnoakes on 14 Nov 2011 at 11:48

• Changed state: Fixed

[GoogleCodeExporter]

cool thanks so much for the fast reply. So which version of the library
will have the update. I'm using the metadata-extractor for a UNI project
that is due at the end of next week. It's probably not likely to include it
in the final code submission but at least I can add this information in my
final report.

Thanks again for your assistance

Original comment by stephen....@gmail.com on 14 Nov 2011 at 11:56

[GoogleCodeExporter]

Hi Stephen,

Currently this fix is only available in the trunk source.  If you get the 
latest code from SVN and build it using ant, you'll have a version that works.

I hope to put together a new release soon with a few other fixes, but I too am 
studying and have a mid-term exam this weekend.

Let me know if you need any help getting a build working.  The build.xml file 
has a target called "dist-binaries" that you should use to create a new .jar 
file.  You can edit the "version" property to control the name of the file if 
you need to, although of course you can change that afterwards too.

http://code.google.com/p/metadata-extractor/source/browse/trunk/build.xml

Original comment by drewnoakes on 15 Nov 2011 at 2:16