coder-free / metadata-extractor Goto Github PK

Hello, 
I am working with a CMS that uses ImageMagick to extract IPTC 
information out of the images and stores them into a database. I now 
have run into several images that have the IPTC information encoded 
"at the end" of the file instead of the beginning and because of this 
IM seems not to be able to read the information. We suspect that the 
Adobe Bridge writes the information that way. 
So I am looking now for another way to get this information into our 
system and stumbled across the metadata-extractor. Sadly I have no 
Java skills other than the Javascript engine that we have in our 
system and I translated a code sample I found for the 2.4 and let it 
run to show me all the directories and their tags for a particular 
image: 
    var tifFile = new File("/ 
773503_1413255_2808_1872_dfb_allstars_duerr_feil_159.tif"); 
    var metadata = TiffMetadataReader.readMetadata(tifFile); 
    var directory = metadata.getDirectoryIterator(); 
    while (directory.hasNext()) { 
      var tag = directory.next(); 
            var tags = tag.getTagIterator(); 
            while (tags.hasNext()) { 
                var zeile = tags.next().toString(); 
                print(zeile); 
            } 
    } 
For a "normal" file this works and shows me e.g. all the exif and the 
iptc tags. For a "problem" file it only showed the exif part and then 
stops. 
I tried the 2.5 version but there seem to have been some changes and I 
was not able to make a script run under JavaScript. 
So what my question is, if I could make a sample file available for 
some volunteer from this list to throw it at a working implementation 
and let me know, if the iptc directory is accessible to the metadata- 
extractor? That would really help and would earn the tester a beer if 
you ever are coming to Hamburg. And depending on the result I then dig 
deeper into the API or have to find another way. 
Thanks and best regards 
Uli 

When the metadata-extractor is used on a server, Directory.getDate() uses the 
server's timezone for parsing, which can be different from the timezone of the 
user's camera (e.g. when uploading photos to a photo community).

What steps will reproduce the problem?
1. Use metadata-extractor on a server set to GMT
2. Upload a photo taken at 12:34 GMT+2
3. Use Directory.getDate() to find out when the photo was taken

What is the expected output? What do you see instead?
Expected: 10:34 GMT (which is 12:34 GMT+2)
Actual: 12:34 GMT (which is 14:34 GMT+2)

Proposed change:

Add a method Directory.getDate(int tagType, TimeZone tz), which accepts a 
TimeZone that is used when the Exif timestamp is parsed. Directory.getDate(int 
tagType) continues to use the system's TimeZone, to maintain downward 
compatibility.

This error happeeds when compiling and testing metadata-extractor on Mac OS X 
(java version "1.6.0_24"):

Testsuite: com.drew.metadata.xmp.test.XmpReaderTest
Tests run: 14, Failures: 0, Errors: 2, Time elapsed: 0,33 sec

Testcase: testExtract_LensInformation took 0,167 sec
Testcase: testExtract_Lens took 0,014 sec
Testcase: testExtract_SerialNumber took 0,013 sec
Testcase: testExtract_Firmware took 0,012 sec
Testcase: testExtract_Maker took 0,011 sec
Testcase: testExtract_Model took 0,011 sec
Testcase: testExtract_ExposureTime took 0,012 sec
Testcase: testExtract_ExposureProgram took 0,01 sec
Testcase: testExtract_FNumber took 0,01 sec
Testcase: testExtract_FocalLength took 0,009 sec
Testcase: testExtract_ShutterSpeed took 0,009 sec
Testcase: testExtract_OriginalDateTime took 0,011 sec
        Caused an ERROR
Unparseable date: "11:41:35 12 Dec 2010"
java.text.ParseException: Unparseable date: "11:41:35 12 Dec 2010"
        at java.text.DateFormat.parse(DateFormat.java:337)
        at com.drew.metadata.xmp.test.XmpReaderTest.testExtract_OriginalDateTime(Unknown Source)

Testcase: testExtract_DigitizedDateTime took 0,009 sec
        Caused an ERROR
Unparseable date: "11:41:35 12 Dec 2010"
java.text.ParseException: Unparseable date: "11:41:35 12 Dec 2010"
        at java.text.DateFormat.parse(DateFormat.java:337)
        at com.drew.metadata.xmp.test.XmpReaderTest.testExtract_DigitizedDateTime(Unknown Source)

Testcase: testGetXmpProperties took 0,008 sec

I received an email from "Y.B." with a patch that adds JFIF support:

The patch mainly adds ability to parse JFIF data (APP0) - I needed it for the 
resolution info. EXIF (APP1) does not provide reliable one, at least for my set 
of images.
I also makes it possible to read all SOFx (not only SOF0) i.e. SOF2 - 
"Progressive, Huffman" JPEG encoding.
Some of the date/time fields are returned as java.util.Date and the user can 
use them formatted.

I would be happy if you find my patch useful and include it (entire or part) in 
the next version.

Hi, 

For a personal project, I had a need to lookup in Dublin Core (dc:) and 
Photoshop (photoshop:) XMP tags.

After a few modifications to the original XmpParser and XmpDirectory, I started 
developping an extension framework to support additional namespaces.

Please find attached a small contribution to this helpful project.

Current supported namespaces are:
  * EXIF - http://ns.adobe.com/exif/1.0/ (Partial support)
  * Photoshop Auxiliary - http://ns.adobe.com/exif/1.0/aux/
  * EXIF TIFF - http://ns.adobe.com/tiff/1.0/ (Partial support)
  * Dublin Core - http://purl.org/dc/elements/1.1/
  * Adobe Photoshop - http://ns.adobe.com/photoshop/1.0/
  * Creative Commons - http://creativecommons.org/ns#


Each extension is registered to the XmpDirectory, eg:
    directory.addExtension(new XmpDcExtension());


The existing API has not been modified, but the XmpDirectory tags have been 
marked deprecated.

Accessing the data is now done using the extension's enum values, eg:
    directory.getDescription(XmpDcExtension.DC.DESCRIPTION.value());

Enjoy!
Olivier

Ie. use attributes rather than deriving from TestCase

I was trying to use this on a large number of images, many older, but all of my 
Canon CRW files fail to be parsed.

This is (I think) because they are guessed to be TIFF, but the older CRW files 
are not in standard TIFF format:

http://www.sno.phy.queensu.ca/~phil/exiftool/canon_raw.html

Therefore, when the TiffMetadataReader attempts to verify them, it falls over 
with ExifReader expecting 49492a but getting 49491a due to the incorrect format.

Michael.

There are a lot of different makernote tags out there.  Here is a great list:

http://gvsoft.homedns.org/exif/

Hand-coding classes for all of these formats may not be the best approach.  
Some analysis could be done to see whether this could be data-driven (say from 
an XML file, for example), either at runtime or design time via codegen.

com.drew.metadata.iptc.IptcReaderTest is not working, because
iptc1.bytes and iptc2-photoshop6.bytes are missing

Great work! Will the latest version be pushed to central maven repo? it has 
2.4.0 beta at this moment.

What steps will reproduce the problem?
1. Try to read metadata of the attached file

What is the expected output? What do you see instead?
Instead of the result we have exception, that crashes all the results.

What version of the product are you using? On what operating system?
2.5.0RC2. Windows XP SP3.

Please provide any additional information below.

IccReader.java
...
    // Process 'ICC tags'
    int tagCount = reader.getInt32(IccDirectory.TAG_ICC_TAG_COUNT);
    directory.setInt(IccDirectory.TAG_ICC_TAG_COUNT, tagCount);

    for (int i = 0; i < tagCount; i++) {
        int pos = 128 + 4 + i*12;
        int tagType = reader.getInt32(pos);
        int tagPtr = reader.getInt32(pos + 4);
        int tagLen = reader.getInt32(pos + 8);
        if (tagPtr + tagLen > data.length)
            throw new BufferBoundsException(data, tagPtr, tagLen);
        byte[] b = new byte[tagLen];
        System.arraycopy(data, tagPtr, b, 0, tagLen);
        directory.setByteArray(tagType, b);
    }
...
The biggest value of tagPtr and tagLen is 7FFF FFFF.
Try to imagine that tha values are not correct now and both are clothe to to 
max value. 

If we plus them to each other - we can overflow the int type and get... 
negative number. And just after that moment I can't understand the logic of 
java. In watch list if we combine them we will get the negative value. But in 
if change code to
    if ((tagPtr + tagLen > data.length) || (tagPtr + tagLen < 0))
       throw new BufferBoundsException(data, tagPtr, tagLen);
it won't work. Java behave herself very strange.

In my file the third ICC possible tag will give tagLen = 1443583418.
And this construction will crash the programm.
byte[] b = new byte[tagLen];

Fails on attached image with NumberFormatException.

Stack trace:

java.lang.NumberFormatException: For input string: "Ручная"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
    at java.lang.Integer.parseInt(Integer.java:449)
    at java.lang.Integer.valueOf(Integer.java:554)
    at com.drew.metadata.xmp.XmpReader.processXmpTag(XmpReader.java:175)
    at com.drew.metadata.xmp.XmpReader.extract(XmpReader.java:108)
    at com.drew.imaging.jpeg.JpegMetadataReader.extractMetadataFromJpegSegmentReader(JpegMetadataReader.java:111)
    at com.drew.imaging.jpeg.JpegMetadataReader.readMetadata(JpegMetadataReader.java:70)
    at com.drew.imaging.ImageMetadataReader.readMetadata(ImageMetadataReader.java:106)
    at com.drew.imaging.ImageMetadataReader.readMetadata(ImageMetadataReader.java:93)
    at com.drew.imaging.ImageMetadataReader.main(ImageMetadataReader.java:157)

Investigate supporting javax.imageio types:

{{{
Metadata readMetadata(IIOMetadata metadata)
Metadata readMetadata(ImageInputStream in) 
Metadata readMetadata(IIOImage image)
Metadata readMetadata(ImageReader reader)
}}}

Hi,

I have updated the Panasonic Makernote Tags with some additional Tags (these 
are now all tags I have found information on the internet to). The patch to the 
SVN Revision 89 is attached.

Greetings,

Philipp 

Hello, I shot a photo with an HTC Android smartphone.

The metadata extraction library correctly shows GPS values but does not for 
all. Actually there are problems with fields name, "GPS Img Direction Ref" and 
"GPS Img Direction". Problems occurs also for tag 27 (0x001B) 
GPSProcessingMethod or "Name of GPS processing method" and tag (0x001D) 
GPSDateStamp or "GPS date".

Sincerely
Antonio Merola

Apparently DNG files are TIFF.

Some tag info (for TIFF in general) is here:

http://www.awaresystems.be/imaging/tiff/tifftags.html

They show some DNG tags.

Exif and other forms of supported metadata found in Jpeg files only make up a 
small portion of the file's size.  This is especially true of very large image 
files.

Currently the library loads unneeded segments, such as image segments, into 
memory before proceeding to read Exif data.

One user of the library was working with 1GB+ images and found performance to 
be very bad.

I'd like to have metadata readers register with the file processors before the 
file is parsed.  This way, only the required subset of Jpeg data will be loaded 
into memory.

It may actually make the most sense to have the metadata reading done against 
the stream directly, to avoid loading any data into memory at all (if possible.)

This should amount to very significant performance improvements for some users.

GpsDirectory should have a new method that returns the latitude/longitude as a 
new object type that allows conversion between different representations 
(decimal, DMS, etc.)

Someone posted something similar here:

http://forums.eye.fi/viewtopic.php?t=2623&p=11475

The JpegSegmentReader.checkForBytesOnStream method uses stream.available() to 
see if enough bytes are available on a stream, also in a wait loop. This will 
not work with certain streams, even non-network or in-memory ones. Example: 
SequenceInputStream.available() will return 0 (forever) if the read position is 
at the boundary between two of the streams in the sequence, ie if the last byte 
of one member stream has been read and the next stream has not been started. 
(Frameworks like Apache mime4j use SequenceInputStreams.) AFAIK, there's no 
other reliable way of testing if there is at least one more byte available than 
trying to read one.

The current TIFF file handing uses the Exif TIFF reading code.  Many of the 
tags in standard Exif data are reused in TIFF files, however there are some 
differences.

Consider making a generic TiffReader class that takes a set of TIFF 
definitions.  This would then be used for Exif data as well as TIFF files and 
in yet other configurations for different camera raw files.

But the real benefit to users would be improved coverage of tags in these other 
file types.

com.drew.metadata.exif.NikonType2MakernoteTest1#testGetAutoFlashCompensationDesc
ription
is not working in Germany as the formatted value is "0,67 EV" not "0.67 EV".

This may also be the case for other tests.

Preference is to force the culture during unit testing rather than modifying 
the code under test to always use the en-GB culture.  Users should get a format 
that's suited to their culture.

What steps will reproduce the problem?
1. Run the metadata-extractor on an image with the CodedCharacterSet tag set 
(e.g. to "UTF-8") and field values encoded in UTF-8.

What is the expected output? What do you see instead?
Special characters (such as german umlauts) are broken, because the system file 
encoding set to windows-1252.

What version of the product are you using? On what operating system?
2.5.0-RC2 on Windows 7

Please provide any additional information below.
The IPTC CodedCharacterSet tag can be used to specify the encoding of the IPTC 
tag values. But the setting is currently ignored.

http://en.wikipedia.org/wiki/GeoTIFF

Attached is some sample code from http://www.gelbin.org/code/

http://en.wikipedia.org/wiki/DICOM

Please vote on this issue if you would like to see it supported.

Currently Metadata Extractor merged IFD0, Exif SubIFD and IFD1 into 
ExifDirectory.

It turns out that IFD0 (main image) and IFD1 (thumbnail image) use some of the 
same tags, and so the thumbnail values are overwriting values from the main 
image.

Specifically:

0x0112 Orientation     : Horizontal (normal)
0x011a X Resolution    : 72
0x011b Y Resolution    : 72
0x0128 Resolution Unit : inches

People are noticing that after rotating, the orientation may be incorrect, and 
that the resolution is always reported as 72 (common for thumbnails).

The solution is to split ExifDirectory into ExifIFD0Directory, 
ExifSubIFDDirectory and ExifIFD1Directory.

This will make it easier to support writing metadata back to files in future 
too.

when i upload a image with XMP meta data, I cannot upload an image not retrieve 
the meta data.
Here is the error i see in my logs.
java.lang.AbstractMethodError: 
javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
    at com.adobe.xmp.impl.XMPMetaParser.createDocumentBuilderFactory(Unknown Source)
    at com.adobe.xmp.impl.XMPMetaParser.<clinit>(Unknown Source)
    at com.adobe.xmp.XMPMetaFactory.parseFromBuffer(Unknown Source)
    at com.adobe.xmp.XMPMetaFactory.parseFromBuffer(Unknown Source)
    at com.drew.metadata.xmp.XmpReader.extract(Unknown Source)
    at com.drew.imaging.jpeg.JpegMetadataReader.extractMetadataFromJpegSegmentReader(Unknown Source)
    at com.drew.imaging.jpeg.JpegMetadataReader.readMetadata(Unknown Source)
    at com.drew.imaging.ImageMetadataReader.readMetadata(Unknown Source)
    at com.drew.imaging.ImageMetadataReader.readMetadata(Unknown Source)




I am using the latest extractor on your website. 2.5.0 RC2

To simplify for users of build tools with dependency management (like Maven, 
Ivy, etc), it would greatly simplify for users of your library if you would 
deploy to Maven central.
Sonatype provides repository support free of charge to facilitate for all this. 
Please read more here:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage
+Guide

This process is simpler for you if you use Maven, but it is not a requirement.

v2.4.0 beta exists in central, but 2.3.1 and the RCs for 2.5.0 is currently 
missing.

http://code.google.com/p/support/wiki/ConvertingSvnToGit

What steps will reproduce the problem?
1. Have a JPG file having the 0xEE segment

A patch has already been submitted to the author and is contained again.

PSD files appear to contain at least two types of metadata that is already 
supported: XMP and Photoshop.

Here is a reference to the format:

http://www.fileformat.info/format/psd/egff.htm

In CanonMakernoteDescriptor.java method getFlashDetailsDescription(), the bit 
shift operator should be a right shift instead of a left shift.  

Using the code as written, you get output like: 
[Canon Makernote] Flash Details = Unknown (8192)
or
[Canon Makernote] Flash Details = Unknown (16392)

But with the right shift operator the output is correctly displayed as:
[Canon Makernote] Flash Details = Internal flash
or 
[Canon Makernote] Flash Details = External E-TTL


There is a sample image "Canon IXUS 300.jpg" already in the sample-images 
folder that can be used to duplicate this.  

http://www.jetbrains.com/idea/documentation/howto.html

Assuming the annotations may be defined in the .jar itself rather than an 
external one (as can be done in .NET) then this would be good for users 
performing this kind of analysis, and for developers of the library itself to 
help avoid NullPointerExceptions.

http://code.google.com/p/metadata-extractor/wiki/ChangeLog

This page doesn't yet have details of 2.5.* releases.

Currently attempting to read descriptions can result in exceptions.

This is because Directory.getInt (and family) can't return nullable primitive 
values when they can't satisfy the request (because either the tag doesn't 
exist, or it has the wrong type), so throw instead.

Changing Directory.get* to return Integer instead of int (etc) will allow 
nulls, and hence we can remove throw statements from all descriptor methods, 
making the API much nicer to work with, without removing any capability.

I am using the latest extractor on your website. 2.5.0 RC3.

Jpg file exception:

When I try to get the date of release of this photo I get an exception that I 
can not manage, the program crashes anyone has any idea?

The development environment is the NetBeans 7.1.1, jdk version 1.6
s.o. windows 7 32 bit and windows xp 32 bit

The method I used is as follows:

     public static String LeggiMetaDataDataScatto (java.lang.String Path) {

         String result = "";

         JpegFile file = new File (Path);
             try {
                 Metadata metadata = ImageMetadataReader.readMetadata (jpegFile);

                 for (Directory directory: metadata.getDirectories ()) {
                     for (Tag tag: directory.getTags ()) {
                         String info = tag.toString ();

                         System.out.println (info);
                         if (Info.contains ("Date / Time Digitized")) {
                             Result = info;
                         }
                     }
                 }
                 System.out.println (metadata);
             } Catch (Exception e) {
             }
}


I get this error:

Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: com / 
adobe / xmp / XMPException
com.drew.imaging.jpeg.JpegMetadataReader.extractMetadataFromJpegSegmentReader 
at (Unknown Source)
com.drew.imaging.jpeg.JpegMetadataReader.readMetadata at (Unknown Source)
com.drew.imaging.ImageMetadataReader.readMetadata at (Unknown Source)
com.drew.imaging.ImageMetadataReader.readMetadata at (Unknown Source)


Please provide any additional information below.

I'm using metadata-extractor (java app in attachments), but it doesn't get ISO 
Speed from Exif data for my photos taken with Nikon D90.

Expected output:
http://www.flickr.com/photos/mariooshinnet/5935924901/meta/in/photostream/

ISO 100
ISOExpansion    Lo 1.0
ISO2    100
ISOExpansion2   Lo 1.0

Instead of metadata-extractor result:
[Jpeg] Compression Type - Baseline
[Jpeg] Data Precision - 8 bits
[Jpeg] Image Height - 531 pixels
[Jpeg] Image Width - 800 pixels
[Jpeg] Number of Components - 3
[Jpeg] Component 1 - Y component: Quantization table 0, Sampling factors 1 
horiz/2 vert
[Jpeg] Component 2 - Cb component: Quantization table 1, Sampling factors 1 
horiz/1 vert
[Jpeg] Component 3 - Cr component: Quantization table 1, Sampling factors 1 
horiz/1 vert
[Jfif] Version - 1.1
[Jfif] Resolution Units - unit
[Jfif] X Resolution - 19661100 dots
[Jfif] Y Resolution - 19660800 dots
[Exif SubIFD] Exposure Time - 1/400 sec
[Exif SubIFD] F-Number - F4
[Exif SubIFD] Exposure Program - Aperture priority
[Exif SubIFD] Exif Version - 2.21
[Exif SubIFD] Date/Time Original - 2011:07:09 19:34:30
[Exif SubIFD] Date/Time Digitized - 2011:07:09 19:34:30
[Exif SubIFD] Components Configuration - YCbCr
[Exif SubIFD] Compressed Bits Per Pixel - 4 bits/pixel
[Exif SubIFD] Exposure Bias Value - 0 EV
[Exif SubIFD] Max Aperture Value - F1,4
[Exif SubIFD] Metering Mode - Multi-segment
[Exif SubIFD] White Balance - Unknown (9)
[Exif SubIFD] Flash - Flash did not fire
[Exif SubIFD] Focal Length - 50,0 mm
[Exif SubIFD] User Comment - 
[Exif SubIFD] Sub-Sec Time - 00
[Exif SubIFD] Sub-Sec Time Original - 00
[Exif SubIFD] Sub-Sec Time Digitized - 00
[Exif SubIFD] FlashPix Version - 1.00
[Exif SubIFD] Color Space - Undefined
[Exif SubIFD] Exif Image Width - 4288 pixels
[Exif SubIFD] Exif Image Height - 2848 pixels
[Exif SubIFD] Sensing Method - One-chip color area sensor
[Exif SubIFD] File Source - Digital Still Camera (DSC)
[Exif SubIFD] Scene Type - Directly photographed image
[Exif SubIFD] CFA Pattern - 0 2 0 2 1 2 0 1
[Exif SubIFD] Custom Rendered - Normal process
[Exif SubIFD] Exposure Mode - Auto exposure
[Exif SubIFD] White Balance Mode - Manual white balance
[Exif SubIFD] Digital Zoom Ratio - 1
[Exif SubIFD] Focal Length 35 - 75mm
[Exif SubIFD] Scene Capture Type - Standard
[Exif SubIFD] Gain Control - None
[Exif SubIFD] Contrast - None
[Exif SubIFD] Saturation - None
[Exif SubIFD] Sharpness - None
[Exif SubIFD] Subject Distance Range - Unknown
[Exif SubIFD] Gamma - 2.2
[Exif IFD0] Make - NIKON CORPORATION
[Exif IFD0] Model - NIKON D90
[Exif IFD0] Orientation - Top, left side (Horizontal / normal)
[Exif IFD0] X Resolution - 300 dots per inch
[Exif IFD0] Y Resolution - 300 dots per inch
[Exif IFD0] Resolution Unit - Inch
[Exif IFD0] Software - Ver.1.00 
[Exif IFD0] Date/Time - 2011:07:09 19:34:30
[Exif IFD0] White Point - 313/1000 329/1000
[Exif IFD0] Primary Chromaticities - 64/100 33/100 21/100 71/100 15/100 6/100
[Exif IFD0] YCbCr Coefficients - 299/1000 587/1000 114/1000
[Exif IFD0] YCbCr Positioning - Datum point
[Nikon Makernote] Firmware Version - 2.10
[Nikon Makernote] ISO - Unknown (0 0 0 0)
[Nikon Makernote] Quality & File Format - FINE   
[Nikon Makernote] White Balance - SUNNY       
[Nikon Makernote] AF Type - AF-A  
[Nikon Makernote] Flash Sync Mode - NORMAL      
[Nikon Makernote] Auto Flash Mode -                    
[Nikon Makernote] White Balance Fine - 0 0
[Nikon Makernote] White Balance RB Coefficients - 461/256 335/256 256/256 
256/256
[Nikon Makernote] Program Shift - 0 EV
[Nikon Makernote] Exposure Difference - 0 EV
[Nikon Makernote] Preview IFD - 9210
[Nikon Makernote] Auto Flash Compensation - -0,67 EV
[Nikon Makernote] ISO - 0 0 0 0
[Nikon Makernote] Image Boundary - 0 0 4288 2848
[Nikon Makernote] Flash Exposure Compensation - 0 EV
[Nikon Makernote] Flash Bracket Compensation - 0 EV
[Nikon Makernote] AE Bracket Compensation - 0
[Nikon Makernote] Crop High Speed - 0 4352 2868 4352 2868 0 0
[Nikon Makernote] Exposure Tuning - 0 EV
[Nikon Makernote] Camera Serial Number - 6586619
[Nikon Makernote] Color Space - Adobe RGB
[Nikon Makernote] VR Info - 48 49 48 48 2 2 0 0
[Nikon Makernote] Active D-Lighting - Off
[Nikon Makernote] Picture Control - [58 bytes]
[Nikon Makernote] World Time - 0 120 1 2
[Nikon Makernote] ISO Info - [14 bytes]
[Nikon Makernote] Unknown 41 - [94 bytes]
[Nikon Makernote] Lens Type - AF, D
[Nikon Makernote] Lens - 50-50mm f/1.4-1.4
[Nikon Makernote] Flash Used - Flash Not Used
[Nikon Makernote] Shooting Mode - Single Frame
[Nikon Makernote] Unknown 20 - 1
[Nikon Makernote] Lens Stops - 7 EV
[Nikon Makernote] Shot Info - [6600 bytes]
[Nikon Makernote] Noise Reduction - OFF 
[Nikon Makernote] Color Balance - [1302 bytes]
[Nikon Makernote] Lens Data - [33 bytes]
[Nikon Makernote] Retouch History - 0 0 0 0 0 0 0 0 0 0
[Nikon Makernote] Image Data Size - 5972197
[Nikon Makernote] Unknown 27 - 0
[Nikon Makernote] Exposure Sequence Number - 13386
[Nikon Makernote] Flash Info - [22 bytes]
[Nikon Makernote] Digital Vari Program -                
[Nikon Makernote] Multi Exposure - [16 bytes]
[Nikon Makernote] High ISO Noise Reduction - Off
[Nikon Makernote] Power Up Time - 7 -37 7 2 9 6 44 0 (unable to formulate 
description)
[Nikon Makernote] AF Info 2 - [30 bytes]
[Nikon Makernote] File Info - [172 bytes]
[Nikon Makernote] Unknown 49 - 48 49 48 48 -1 0
[Interoperability] Interoperability Index - Unknown (R03)
[Interoperability] Interoperability Version - 1.00
[GPS] GPS Version ID - 2.200
[Exif Thumbnail] Thumbnail Compression - JPEG (old-style)
[Exif Thumbnail] X Resolution - 300 dots per inch
[Exif Thumbnail] Y Resolution - 300 dots per inch
[Exif Thumbnail] Resolution Unit - Inch
[Exif Thumbnail] Thumbnail Offset - 34416 bytes
[Exif Thumbnail] Thumbnail Length - 9075 bytes
[Exif Thumbnail] YCbCr Positioning - Datum point

Version: metadata-extractor-2.5.0-RC2.jar, OS: Windows xp and Linux

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

http://code.google.com/p/metadata-extractor/source/browse/trunk/Source/com/drew/
metadata/exif/ExifReader.java#471

Unsigned rationals are currently being read using getInt32, which is inadequate 
for some values.  As Alex points out on the mailing list:

> I'm trying to get 2 TIFF resolution tags that are supposed to equate
to
>
> XResolution (1 Rational): 26023.6398751818
> YResolution (1 Rational): 26023.6398751818
>
> but what I'm getting is:
>
> X Resolution: -25771/165040 dots per cm
> Y Resolution: -25771/165040 dots per cm

The numerator is being read as -25771, whereas it should really be 4294941525.

The case block needs to be split in two.  I'd like to add a unit test for this 
that proves the issue will not come back.

I have asked Alex if it's possible to add a sample image that reproduces the 
problem to this issue.

Problem occurs in the JpegSegmentReader

Specifically private boolean checkForBytesOnStream

(bytesNeeded <= stream.available()) always returns true.


The code I am using is:
BlobstoreInputStream inputStream = new BlobstoreInputStream(new 
BlobKey(image.blobKey))
Object metadata = ImageMetadataReader.readMetadata(new 
BufferedInputStream(inputStream), true);

Is it possible to provide an alternative method readMetadata that takes a 
regular InputStream?


I have no problem getting Apache Sanselan to work:

BlobstoreInputStream inputStream = new BlobstoreInputStream(new 
BlobKey(image.blobKey))
    IImageMetadata metadata = Sanselan.getMetadata(inputStream, null)
    JpegImageMetadata jpegMetadata = (JpegImageMetadata) metadata;
    if (jpegMetadata != null) {
        Object metadata = jpegMetadata.getExif();
    }

There's a small typo where "now" should be "know" in Section 1 ("Read metadata 
from an Image")

I'm very thankful you're providing this software. Hoping I can help with 
documentation if not code :)

IccReader fails with OutOfMemoryError on  
http://www.aten.bg/pict/prod/aten_2l-1030pc.jpg

It seems that check condition is insufficient in IccReader.java:94 -- (tagPtr + 
tagLen) gives negative value. Thus the condition passes.

Playing around with a mix of TIFF and JPEG files, I found the attached helper 
class useful. Maybe you want to add something like that (or the tag values) to 
the code.

Host JavaDoc on Google Code, update the Ant build to produce it, and improve 
the coverage and quality across the public API.

What steps will reproduce the problem?
1. try to extract with example code some Metadata from rawfile
2. http://www.mavinci.de/download/test.RW2 
3. Camera: Panasonic Lumix DMC-GF1 

What is the expected output? What do you see instead?
no exception, but all metadata containers are empty...

What version of the product are you using? On what operating system?
metadata-extractor-2.5.0-RC2.jar
openSuse 11.4 64bit

Please provide any additional information below.
I was able to view the exif stuff via "digicam" (linux application)

THX!
-Marco

Currently the API for a tag has getDescription() and essentially you lose all 
typing information.

EXIF dates appear to always be the same formatted 20-character ASCII string, 
yet there is no way (short of pattern) matching to figure out which tags 
*should* be dates.

It would be nice if the library would have a getValue() for any tag which could 
return the value in a more native representation.  In the case of dates though, 
I would still particularly avoid using a millisecond value or a java.util.Date, 
as EXIF dates appear to be local and lack time zone information.

Assumption is that this would improve discoverability of API and type/value 
safety.

Would also need ability to pass int directly (for tag types at least, not 
format types etc) so that additional tags can be queried without resorting to 
recompiling library.

What steps will reproduce the problem?
1. Try to parse an ORF RAW image
2. Iterate through the directories (you will get an IFD0 directory)
3. Try to iterate through the tags (you will find no tags)

What is the expected output? What do you see instead?
The tags in the ORF-RAW file. I only get an IDF0 directory, but with no tags 
inside.

What version of the product are you using? On what operating system?
2.5.0-RC3, Eclipse Java, Android

Please provide any additional information below.
Sample image: http://dl.dropbox.com/u/15496646/PA180834.ORF
(Can not be attached, 11 MB)

Since this project has been assigned a license, headers in the source code 
should be updated.

What steps will reproduce the problem?
1. Use an image where Exif Image Width is not set 
2. Select that image in jAlbum explorer mode
3. Open the Camera tab

Missing metadata tag should be ignored and valid metadata displayed.
Instead, other metadata are not reported - "Error extracting metadata" is shown.

Using jAlbum 8.13 on Windows 7

See jAlbum forum thread
http://jalbum.net/forum/thread.jspa?messageID=234246&#234246

Based a few test samples I've ran and also according to the sample output of 
FUJIFILM - FinePixS1Pro [1], I suppose the artist information (0x013b) should 
be part of the ExifIFD0Directory instead of the ExifSubIFDDirectory.