You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Farrukh Najmi <fa...@wellfleetsoftware.com> on 2012/07/03 01:12:20 UTC
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Here is a proposed change to the API that would help my scenario...
Modify the org.apache.commons.imaging.common.ImageMetadata$Item class to
have the following additional methods:
* getMetadataSpecification() method that returns a constant String
such as "IPTC:1.1", "EXIF:2.1", "EXIF:2.2"
* getId() method that returns a unique id as follows:
o For EXIF return the Field Name as in Table 3 TIFF Rev. 6.0
Attribute Information Used in Exif in the Exif spec
<http://www.exif.org/Exif2-2.PDF>.
o For IPTC return the IptcRecord..iptcType.getType()
This would allow the first code pattern below to identify each item
based on a specific metadata field defined by a specific specification.
Thoughts?
On 07/02/2012 06:18 PM, Farrukh Najmi wrote:
>
> Hi Guys,
>
> I am trying to use commons-imaging latest svn bits to write a program
> that will read standard metadata such as Exif and IPTC from images in
> a variety of image formats using code that is as image format neutral
> as possible. The goal is to store each class of metadata (e.g. Exif,
> IPTC, ...) in a separate Map where the key identifies a metadata
> attribute identifier defined by the standard and a value that is the
> metadata attribute's value.
>
> Here are two patterns I have identified for reading the metadata by
> looking at test programs and code....
>
> 1. Read metadata items without considering image format or metadata
> standard.
>
> IImageMetadata metadata = Imaging.getMetadata(is, "Oregon
> Scientific DS6639 - DSC_0307 - iptc added with irfanview.jpg");
> List<? extends IImageMetadata.IImageMetadataItem> items =
> metadata.getItems();
>
> int i=0;
> for (IImageMetadata.IImageMetadataItem iitem : items) {
> ImageMetadata.Item item = (ImageMetadata.Item)iitem;
> System.err.println("Index: " + i + " Key: " +
> item.getKeyword() + " Value: " + item.getText() + " class: " +
> iitem.getClass()); //common.ImageMetadata$Item, Tiff.TiffImageMetadata
> i++;
> }
>
>
> This is closest to what I want. The EXIF metadata is represented by
> org.apache.commons.imaging.formats.tiff.TiffImageMetadata$Item and I
> can get at the TiffField and its tagName and value (good). However,
> IPTC metadata is represented by
> org.apache.commons.imaging.common.ImageMetadata$Item. This class seems
> to have no link back to the
> org.apache.commons.imaging.formats.jpeg.iptc.IptcRecord and thus I
> cannot find a way to get the attribute defined by the IPTC spec
> <http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf>
> under the IIM mapping rows.
>
>
> 2. Read Exif and IPTC separately using following metadata and image
> format specific patterns as shown below...
>
> //Read EXIF
> JpegImageMetadata metadata = (JpegImageMetadata)
> Imaging.getMetadata(is, "Oregon Scientific DS6639 - DSC_0307 - iptc
> added with irfanview.jpg");
> TiffImageMetadata exifMetadata = metadata.getExif();
> List<TiffField> fields = exifMetadata.getAllFields();
>
> int i=0;
> for (TiffField field : fields) {
> String key = field.getTagName();
> Object value = field.getValue();
> String fieldName = field.tagInfo.name;
> System.err.println("Index: " + i + " Key: " + key + ",
> Value: " + value + ", valueType: " + value.getClass());
> i++;
> }
>
> //Read IPTC
> JpegImageMetadata metadata = (JpegImageMetadata)
> Imaging.getMetadata(is, "Oregon Scientific DS6639 - DSC_0307 - iptc
> added with irfanview.jpg");
> JpegPhotoshopMetadata psMetadata = metadata.getPhotoshop();
> List oldRecords = psMetadata.photoshopApp13Data.getRecords();
>
> for (int j = 0; j < oldRecords.size(); j++) {
> IptcRecord record = (IptcRecord) oldRecords.get(j);
> System.err.println("Key: " + record.iptcType.getName()
> + " (0x"
> +
> Integer.toHexString(record.iptcType.getType())
> + "), value: " + record.value);
> }
>
> Above gives me all the linkage back to specification defined metadata
> fields but is less desirable because it metadata and image format
> specific.
>
> I feel that it would be ideal to support a generic api that is
> agnostic to metadata and image format but provides a reference back to
> the specification defined field (attribute) identifier some how.
>
> I would very much appreciate some ideas from dev team on how we could
> improve the api to support providing a reference back to a
> specification defined field in a metadata and image format neutral manner.
>
> My apologies if I am missing an obvious solution while I am getting
> familiar with the code.
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Damjan Jovanovic <da...@gmail.com>.
Hi Farrukh
Pleasure :).
I am not sure about the API we should be using, and want to
investigate what other image frameworks do first.
Regards
Damjan
On Thu, Jul 5, 2012 at 12:56 PM, Farrukh Najmi
<fa...@wellfleetsoftware.com> wrote:
>
> Hi Damjan,
>
> Confirming that your recent fix for supporting Exif FieldName looks good
> great. Thank you!
>
> When do you think you may be able to commit the changes to support the
> following metadata format-specific methods so I can provide feedback:
>
> Imaging.getExifMetadata()
> Imaging.getIptcMetadata()
> Imaging.getXmpMetadata()
>
>
>
>
> On 07/04/2012 12:38 AM, Damjan Jovanovic wrote:
>>
>> I just committed new TIFF tag names to SVN, let me know how they work for
>> you.
>>
>> The best time to add the new metadata methods is before the 1.0
>> release, since changing binary compatibility later will be harder.
>>
>> On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
>> <fa...@wellfleetsoftware.com> wrote:
>>>
>>> +1 on having the methods:
>>>
>>> Imaging.getExifMetadata()
>>> Imaging.getIptcMetadata()
>>> Imaging.getXmpMetadata()
>>>
>>> It is is a good idea so one can access metadata-format-specific metadata
>>> in
>>> a metadata-format-specific way and handling all special needs of specific
>>> metadata formats. These methods should work on any image resource and
>>> throw
>>> something like MissingFeatureException for when a metadata format is not
>>> yet
>>> supported for an image format or throw something like an
>>> InvalidRequestException when a metadata format is invalid for a image
>>> format.
>>>
>>> That said, there may still be some value to having a metadata-format
>>> netrual
>>> getMetadata() interface along the lines of the patch I submitted. For
>>> now,
>>> we could simply log an issue and defer it and insteda focus on your
>>> suggestion above. That would meet my needs just fine.
>>>
>>> Question is do we do these changes after a formal 1.0 release or before?
>>> May
>>> be it is better to get stable code under current API out as 1.0 and then
>>> work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are not
>>> backward compatible and are in fact major). Or is it better to do these
>>> changes for the 1.0 release so consumers of the project do not get
>>> exposed
>>> to a big API change?
>>>
>>> If we can do the proposed change without a long delay then I suggest we
>>> do
>>> it for 1.0. If it means a long delay then I suggest we defer to 2.0.
>>>
>>> Thoughts?
>>>
>>>
>>>
>>> On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:
>>>>
>>>> I've also considered the metadata interfaces we use, and I am not sure
>>>> the current approaches are any good.
>>>>
>>>> Most metadata formats are designed in a way specific to that format,
>>>> eg. some have arbitrary levels of nesting, others have a flat
>>>> structure, etc. But most are designed to be stored in any image
>>>> format.
>>>>
>>>> So instead of a Imaging.getMetadata() method that tries to unify all
>>>> metadata into one common interface - and does so badly, because eg.
>>>> EXIF can have nested subdirectories and this information is lost -
>>>> maybe we should have:
>>>> Imaging.getExifMetadata()
>>>> Imaging.getIptcMetadata()
>>>> Imaging.getXmpMetadata()
>>>>
>>>> Regards
>>>> Damjan
>>>>
>>>> On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>>
>>>>> Updated proposed patch with following new changes:
>>>>>
>>>>> Add getValue() method to nested class IImageMetadataItem. These return
>>>>> the
>>>>> value of the item as an Object allowing for values of various types to
>>>>> be
>>>>> returned.
>>>>>
>>>>>
>>>>> On 07/03/2012 11:01 AM, Farrukh Najmi wrote:
>>>>>
>>>>> Moving this thread to dev list as it seems to be more appropriate
>>>>> there....
>>>>>
>>>>> Attached is a patch to the IImageMetadata.java that reflects my revised
>>>>> proposal thinking this through in conjunction with the proposed
>>>>> solution
>>>>> in
>>>>> another thread...
>>>>>
>>>>> Add a getMetadataSpecification() method to IImageMetadata so we can
>>>>> manage
>>>>> the metadata specification that defines the metadata
>>>>> Add getMetadata() to nested class IImageMetadataItem to get back at the
>>>>> parent IImageMetadata instance so we can access the metadata
>>>>> specification
>>>>> information managed from an IImageMetadata instance
>>>>> Add getId(), getName(), getDescription() methods to nested class
>>>>> IImageMetadataItem. These are the key triplet of info about the
>>>>> metadata
>>>>> item that is needed in my experience
>>>>>
>>>>> Of course implementations of these two interfaces would need to also be
>>>>> updated to support the new methods according to proposed semantics. I
>>>>> would
>>>>> be happy to contribute in any way that I can and as requested.
>>>>>
>>>>> Dev team colleagues, please weigh in on the proposal. Thanks for your
>>>>> awesome work to create this project and for considering this proposal.
>>>>>
>>>>>
>>>
>
> --
> Regards,
> Farrukh
>
> Web: http://www.wellfleetsoftware.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Damjan Jovanovic <da...@gmail.com>.
There's also http://xmlgraphics.apache.org/commons/ which does TIFF
and PNG parsing among other things.
I'll have to investigate all of those after the 1.0 release.
Regards
Damjan
On Tue, Jul 10, 2012 at 10:55 AM, Ray Gauss II <ra...@alfresco.com> wrote:
> In case you're not aware, much has been done around EXIF, IPTC, and XMP in Apache Tika which uses the Drew Noakes library [1] for some of its work and there's a parser which wraps ExifTool [2].
>
> Perhaps there's some opportunity to combine efforts?
>
> Regards,
>
> Ray
>
> [1] http://www.drewnoakes.com/code/exif/
> [2] https://github.com/Alfresco/tika-exiftool
>
>
> On Jul 8, 2012, at 8:59 PM, Farrukh Najmi wrote:
>
>>
>> There are two specs:
>>
>> 1. IPTC Standard Photo Metadata 2008 IPTC Core Specification Version 1.1
>> IPTC Extension Specification Version 1.0
>> Document Revision 2
>> <http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf>
>> (IPTC-PhotoMetadata-2008 spec)
>> 2. IPTC - NAA Information Interchange Model Version 4
>> <http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf> (IIM spec)
>>
>>
>> The IPTC-PhotoMetadata-2008 spec suprecedes the IIM spec from what I have read. We should therefor be implementing the IPTC-PhotoMetadata-2008 (the spec) and not the IIM spec.
>>
>> The TODO comment is about the properties that are in IIM spec but not in IPTC-PhotoMetadata-2008. I have chosen to leave them there for now. All the IptcTypes.name field values are aligned with the XMP property id values from the spec. That was the main change in the patch. I think we should change IptcTypes.name field to IptcTypes.propertyId field and perhaps later add a name field that aligns with the Name field values from the spec. BTW, I would be happy to have a skype (skype id: farrukh_najmi) call to discuss this if you would like.
>>
>>
>> On 07/08/2012 11:34 AM, Damjan Jovanovic wrote:
>>> You ask "TODO: What to do about properties not seen in
>>> IPTC-PhotoMetadata-2008 (e.g. "Record Version"))"
>>>
>>> Look at http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/IPTC.html
>>> Scroll down to "IPTC ApplicationRecord Tags"
>>> Those names seem to resemble what is in
>>> http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf page 24
>>> onwards.
>>>
>>> The names in your patch differ from that list.
>>>
>>> ?
>>>
>>> On Sat, Jul 7, 2012 at 3:55 PM, Farrukh Najmi
>>> <fa...@wellfleetsoftware.com> wrote:
>>>> Oops. Here is the correct file this time.
>>>>
>>>>
>>>> On 07/07/2012 01:39 AM, Damjan Jovanovic wrote:
>>>>> Hi Farrukh
>>>>>
>>>>> Your patch is just an empty file.
>>>>>
>>>>> Regards
>>>>> Damjan
>>>>>
>>>>> On Fri, Jul 6, 2012 at 9:23 PM, Farrukh Najmi
>>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>>> Hi Damjan,
>>>>>>
>>>>>> Attached is the patch for implementing the proposed change outlined in
>>>>>> bullets below.
>>>>>> Please review and then commit if satisfied or discuss further. Thanks.
>>>>>>
>>>>>>
>>>>>> On 07/06/2012 02:29 PM, Farrukh Najmi wrote:
>>>>>>>
>>>>>>> An example of a metadata property that has no IIM mapping defined is
>>>>>>> Name:
>>>>>>> Scene Code, XMP property id: Scene (page 15 of 55 in spec)
>>>>>>>
>>>>>>>
>>>>>>> On 07/06/2012 02:25 PM, Farrukh Najmi wrote:
>>>>>>>> Hi Damjan,
>>>>>>>>
>>>>>>>> Thanks for the +1. As I started on this patch I made some observations
>>>>>>>> in
>>>>>>>> the IPTC-PhotoMetadata-2008.pdfspec:
>>>>>>>>
>>>>>>>> * Not all metadata properties have an IIM mapping defined. For these
>>>>>>>> we will have to invent a type code. I propose we assign codes
>>>>>>>> starting at 10000 arbitrarily in such cases
>>>>>>>> * Every field does have an XMP property id at present. I am not sure
>>>>>>>> if there is any guarantee that future fields will have an XMP
>>>>>>>> property id. I think we should continue with XMP property id for
>>>>>>>> IptcTypes.name field but if in future versions there is no XMP
>>>>>>>> property id then the backup would be to use the Name field from
>>>>>>>> the spec
>>>>>>>>
>>>>>>>> The only other alternative I can think of for IptcTypes.name field
>>>>>>>> issue
>>>>>>>> is to use the Name field from the spec which is guaranteed to be
>>>>>>>> present,
>>>>>>>> will never be translated but has the issue that it has white space in
>>>>>>>> its
>>>>>>>> content. My preference is to do what is proposed in bullets above.
>>>>>>>>
>>>>>>>> Comments? Thanks.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>
>> --
>> Regards,
>> Farrukh
>>
>> Web: http://www.wellfleetsoftware.com
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image format neutral code
Posted by Ray Gauss II <ra...@alfresco.com>.
In case you're not aware, much has been done around EXIF, IPTC, and XMP in Apache Tika which uses the Drew Noakes library [1] for some of its work and there's a parser which wraps ExifTool [2].
Perhaps there's some opportunity to combine efforts?
Regards,
Ray
[1] http://www.drewnoakes.com/code/exif/
[2] https://github.com/Alfresco/tika-exiftool
On Jul 8, 2012, at 8:59 PM, Farrukh Najmi wrote:
>
> There are two specs:
>
> 1. IPTC Standard Photo Metadata 2008 IPTC Core Specification Version 1.1
> IPTC Extension Specification Version 1.0
> Document Revision 2
> <http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf>
> (IPTC-PhotoMetadata-2008 spec)
> 2. IPTC - NAA Information Interchange Model Version 4
> <http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf> (IIM spec)
>
>
> The IPTC-PhotoMetadata-2008 spec suprecedes the IIM spec from what I have read. We should therefor be implementing the IPTC-PhotoMetadata-2008 (the spec) and not the IIM spec.
>
> The TODO comment is about the properties that are in IIM spec but not in IPTC-PhotoMetadata-2008. I have chosen to leave them there for now. All the IptcTypes.name field values are aligned with the XMP property id values from the spec. That was the main change in the patch. I think we should change IptcTypes.name field to IptcTypes.propertyId field and perhaps later add a name field that aligns with the Name field values from the spec. BTW, I would be happy to have a skype (skype id: farrukh_najmi) call to discuss this if you would like.
>
>
> On 07/08/2012 11:34 AM, Damjan Jovanovic wrote:
>> You ask "TODO: What to do about properties not seen in
>> IPTC-PhotoMetadata-2008 (e.g. "Record Version"))"
>>
>> Look at http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/IPTC.html
>> Scroll down to "IPTC ApplicationRecord Tags"
>> Those names seem to resemble what is in
>> http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf page 24
>> onwards.
>>
>> The names in your patch differ from that list.
>>
>> ?
>>
>> On Sat, Jul 7, 2012 at 3:55 PM, Farrukh Najmi
>> <fa...@wellfleetsoftware.com> wrote:
>>> Oops. Here is the correct file this time.
>>>
>>>
>>> On 07/07/2012 01:39 AM, Damjan Jovanovic wrote:
>>>> Hi Farrukh
>>>>
>>>> Your patch is just an empty file.
>>>>
>>>> Regards
>>>> Damjan
>>>>
>>>> On Fri, Jul 6, 2012 at 9:23 PM, Farrukh Najmi
>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>> Hi Damjan,
>>>>>
>>>>> Attached is the patch for implementing the proposed change outlined in
>>>>> bullets below.
>>>>> Please review and then commit if satisfied or discuss further. Thanks.
>>>>>
>>>>>
>>>>> On 07/06/2012 02:29 PM, Farrukh Najmi wrote:
>>>>>>
>>>>>> An example of a metadata property that has no IIM mapping defined is
>>>>>> Name:
>>>>>> Scene Code, XMP property id: Scene (page 15 of 55 in spec)
>>>>>>
>>>>>>
>>>>>> On 07/06/2012 02:25 PM, Farrukh Najmi wrote:
>>>>>>> Hi Damjan,
>>>>>>>
>>>>>>> Thanks for the +1. As I started on this patch I made some observations
>>>>>>> in
>>>>>>> the IPTC-PhotoMetadata-2008.pdfspec:
>>>>>>>
>>>>>>> * Not all metadata properties have an IIM mapping defined. For these
>>>>>>> we will have to invent a type code. I propose we assign codes
>>>>>>> starting at 10000 arbitrarily in such cases
>>>>>>> * Every field does have an XMP property id at present. I am not sure
>>>>>>> if there is any guarantee that future fields will have an XMP
>>>>>>> property id. I think we should continue with XMP property id for
>>>>>>> IptcTypes.name field but if in future versions there is no XMP
>>>>>>> property id then the backup would be to use the Name field from
>>>>>>> the spec
>>>>>>>
>>>>>>> The only other alternative I can think of for IptcTypes.name field
>>>>>>> issue
>>>>>>> is to use the Name field from the spec which is guaranteed to be
>>>>>>> present,
>>>>>>> will never be translated but has the issue that it has white space in
>>>>>>> its
>>>>>>> content. My preference is to do what is proposed in bullets above.
>>>>>>>
>>>>>>> Comments? Thanks.
>>>>>>>
>>>>>>>
>>>>>>>
>
> --
> Regards,
> Farrukh
>
> Web: http://www.wellfleetsoftware.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Farrukh Najmi <fa...@wellfleetsoftware.com>.
There are two specs:
1. IPTC Standard Photo Metadata 2008 IPTC Core Specification Version 1.1
IPTC Extension Specification Version 1.0
Document Revision 2
<http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf>
(IPTC-PhotoMetadata-2008 spec)
2. IPTC - NAA Information Interchange Model Version 4
<http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf> (IIM spec)
The IPTC-PhotoMetadata-2008 spec suprecedes the IIM spec from what I
have read. We should therefor be implementing the
IPTC-PhotoMetadata-2008 (the spec) and not the IIM spec.
The TODO comment is about the properties that are in IIM spec but not in
IPTC-PhotoMetadata-2008. I have chosen to leave them there for now. All
the IptcTypes.name field values are aligned with the XMP property id
values from the spec. That was the main change in the patch. I think we
should change IptcTypes.name field to IptcTypes.propertyId field and
perhaps later add a name field that aligns with the Name field values
from the spec. BTW, I would be happy to have a skype (skype id:
farrukh_najmi) call to discuss this if you would like.
On 07/08/2012 11:34 AM, Damjan Jovanovic wrote:
> You ask "TODO: What to do about properties not seen in
> IPTC-PhotoMetadata-2008 (e.g. "Record Version"))"
>
> Look at http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/IPTC.html
> Scroll down to "IPTC ApplicationRecord Tags"
> Those names seem to resemble what is in
> http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf page 24
> onwards.
>
> The names in your patch differ from that list.
>
> ?
>
> On Sat, Jul 7, 2012 at 3:55 PM, Farrukh Najmi
> <fa...@wellfleetsoftware.com> wrote:
>> Oops. Here is the correct file this time.
>>
>>
>> On 07/07/2012 01:39 AM, Damjan Jovanovic wrote:
>>> Hi Farrukh
>>>
>>> Your patch is just an empty file.
>>>
>>> Regards
>>> Damjan
>>>
>>> On Fri, Jul 6, 2012 at 9:23 PM, Farrukh Najmi
>>> <fa...@wellfleetsoftware.com> wrote:
>>>> Hi Damjan,
>>>>
>>>> Attached is the patch for implementing the proposed change outlined in
>>>> bullets below.
>>>> Please review and then commit if satisfied or discuss further. Thanks.
>>>>
>>>>
>>>> On 07/06/2012 02:29 PM, Farrukh Najmi wrote:
>>>>>
>>>>> An example of a metadata property that has no IIM mapping defined is
>>>>> Name:
>>>>> Scene Code, XMP property id: Scene (page 15 of 55 in spec)
>>>>>
>>>>>
>>>>> On 07/06/2012 02:25 PM, Farrukh Najmi wrote:
>>>>>> Hi Damjan,
>>>>>>
>>>>>> Thanks for the +1. As I started on this patch I made some observations
>>>>>> in
>>>>>> the IPTC-PhotoMetadata-2008.pdfspec:
>>>>>>
>>>>>> * Not all metadata properties have an IIM mapping defined. For these
>>>>>> we will have to invent a type code. I propose we assign codes
>>>>>> starting at 10000 arbitrarily in such cases
>>>>>> * Every field does have an XMP property id at present. I am not sure
>>>>>> if there is any guarantee that future fields will have an XMP
>>>>>> property id. I think we should continue with XMP property id for
>>>>>> IptcTypes.name field but if in future versions there is no XMP
>>>>>> property id then the backup would be to use the Name field from
>>>>>> the spec
>>>>>>
>>>>>> The only other alternative I can think of for IptcTypes.name field
>>>>>> issue
>>>>>> is to use the Name field from the spec which is guaranteed to be
>>>>>> present,
>>>>>> will never be translated but has the issue that it has white space in
>>>>>> its
>>>>>> content. My preference is to do what is proposed in bullets above.
>>>>>>
>>>>>> Comments? Thanks.
>>>>>>
>>>>>>
>>>>>>
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Damjan Jovanovic <da...@gmail.com>.
You ask "TODO: What to do about properties not seen in
IPTC-PhotoMetadata-2008 (e.g. "Record Version"))"
Look at http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/IPTC.html
Scroll down to "IPTC ApplicationRecord Tags"
Those names seem to resemble what is in
http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf page 24
onwards.
The names in your patch differ from that list.
?
On Sat, Jul 7, 2012 at 3:55 PM, Farrukh Najmi
<fa...@wellfleetsoftware.com> wrote:
>
> Oops. Here is the correct file this time.
>
>
> On 07/07/2012 01:39 AM, Damjan Jovanovic wrote:
>>
>> Hi Farrukh
>>
>> Your patch is just an empty file.
>>
>> Regards
>> Damjan
>>
>> On Fri, Jul 6, 2012 at 9:23 PM, Farrukh Najmi
>> <fa...@wellfleetsoftware.com> wrote:
>>>
>>> Hi Damjan,
>>>
>>> Attached is the patch for implementing the proposed change outlined in
>>> bullets below.
>>> Please review and then commit if satisfied or discuss further. Thanks.
>>>
>>>
>>> On 07/06/2012 02:29 PM, Farrukh Najmi wrote:
>>>>
>>>>
>>>> An example of a metadata property that has no IIM mapping defined is
>>>> Name:
>>>> Scene Code, XMP property id: Scene (page 15 of 55 in spec)
>>>>
>>>>
>>>> On 07/06/2012 02:25 PM, Farrukh Najmi wrote:
>>>>>
>>>>> Hi Damjan,
>>>>>
>>>>> Thanks for the +1. As I started on this patch I made some observations
>>>>> in
>>>>> the IPTC-PhotoMetadata-2008.pdfspec:
>>>>>
>>>>> * Not all metadata properties have an IIM mapping defined. For these
>>>>> we will have to invent a type code. I propose we assign codes
>>>>> starting at 10000 arbitrarily in such cases
>>>>> * Every field does have an XMP property id at present. I am not sure
>>>>> if there is any guarantee that future fields will have an XMP
>>>>> property id. I think we should continue with XMP property id for
>>>>> IptcTypes.name field but if in future versions there is no XMP
>>>>> property id then the backup would be to use the Name field from
>>>>> the spec
>>>>>
>>>>> The only other alternative I can think of for IptcTypes.name field
>>>>> issue
>>>>> is to use the Name field from the spec which is guaranteed to be
>>>>> present,
>>>>> will never be translated but has the issue that it has white space in
>>>>> its
>>>>> content. My preference is to do what is proposed in bullets above.
>>>>>
>>>>> Comments? Thanks.
>>>>>
>>>>>
>
>
> --
> Regards,
> Farrukh
>
> Web: http://www.wellfleetsoftware.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Farrukh Najmi <fa...@wellfleetsoftware.com>.
Oops. Here is the correct file this time.
On 07/07/2012 01:39 AM, Damjan Jovanovic wrote:
> Hi Farrukh
>
> Your patch is just an empty file.
>
> Regards
> Damjan
>
> On Fri, Jul 6, 2012 at 9:23 PM, Farrukh Najmi
> <fa...@wellfleetsoftware.com> wrote:
>> Hi Damjan,
>>
>> Attached is the patch for implementing the proposed change outlined in
>> bullets below.
>> Please review and then commit if satisfied or discuss further. Thanks.
>>
>>
>> On 07/06/2012 02:29 PM, Farrukh Najmi wrote:
>>>
>>> An example of a metadata property that has no IIM mapping defined is Name:
>>> Scene Code, XMP property id: Scene (page 15 of 55 in spec)
>>>
>>>
>>> On 07/06/2012 02:25 PM, Farrukh Najmi wrote:
>>>> Hi Damjan,
>>>>
>>>> Thanks for the +1. As I started on this patch I made some observations in
>>>> the IPTC-PhotoMetadata-2008.pdfspec:
>>>>
>>>> * Not all metadata properties have an IIM mapping defined. For these
>>>> we will have to invent a type code. I propose we assign codes
>>>> starting at 10000 arbitrarily in such cases
>>>> * Every field does have an XMP property id at present. I am not sure
>>>> if there is any guarantee that future fields will have an XMP
>>>> property id. I think we should continue with XMP property id for
>>>> IptcTypes.name field but if in future versions there is no XMP
>>>> property id then the backup would be to use the Name field from
>>>> the spec
>>>>
>>>> The only other alternative I can think of for IptcTypes.name field issue
>>>> is to use the Name field from the spec which is guaranteed to be present,
>>>> will never be translated but has the issue that it has white space in its
>>>> content. My preference is to do what is proposed in bullets above.
>>>>
>>>> Comments? Thanks.
>>>>
>>>>
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Damjan Jovanovic <da...@gmail.com>.
Hi Farrukh
Your patch is just an empty file.
Regards
Damjan
On Fri, Jul 6, 2012 at 9:23 PM, Farrukh Najmi
<fa...@wellfleetsoftware.com> wrote:
> Hi Damjan,
>
> Attached is the patch for implementing the proposed change outlined in
> bullets below.
> Please review and then commit if satisfied or discuss further. Thanks.
>
>
> On 07/06/2012 02:29 PM, Farrukh Najmi wrote:
>>
>>
>> An example of a metadata property that has no IIM mapping defined is Name:
>> Scene Code, XMP property id: Scene (page 15 of 55 in spec)
>>
>>
>> On 07/06/2012 02:25 PM, Farrukh Najmi wrote:
>>>
>>> Hi Damjan,
>>>
>>> Thanks for the +1. As I started on this patch I made some observations in
>>> the IPTC-PhotoMetadata-2008.pdfspec:
>>>
>>> * Not all metadata properties have an IIM mapping defined. For these
>>> we will have to invent a type code. I propose we assign codes
>>> starting at 10000 arbitrarily in such cases
>>> * Every field does have an XMP property id at present. I am not sure
>>> if there is any guarantee that future fields will have an XMP
>>> property id. I think we should continue with XMP property id for
>>> IptcTypes.name field but if in future versions there is no XMP
>>> property id then the backup would be to use the Name field from
>>> the spec
>>>
>>> The only other alternative I can think of for IptcTypes.name field issue
>>> is to use the Name field from the spec which is guaranteed to be present,
>>> will never be translated but has the issue that it has white space in its
>>> content. My preference is to do what is proposed in bullets above.
>>>
>>> Comments? Thanks.
>>>
>>>
>>>
>>
>>
>
>
> --
> Regards,
> Farrukh
>
> Web: http://www.wellfleetsoftware.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Farrukh Najmi <fa...@wellfleetsoftware.com>.
Hi Damjan,
Attached is the patch for implementing the proposed change outlined in
bullets below.
Please review and then commit if satisfied or discuss further. Thanks.
On 07/06/2012 02:29 PM, Farrukh Najmi wrote:
>
> An example of a metadata property that has no IIM mapping defined is
> Name: Scene Code, XMP property id: Scene (page 15 of 55 in spec)
>
>
> On 07/06/2012 02:25 PM, Farrukh Najmi wrote:
>> Hi Damjan,
>>
>> Thanks for the +1. As I started on this patch I made some
>> observations in the IPTC-PhotoMetadata-2008.pdfspec:
>>
>> * Not all metadata properties have an IIM mapping defined. For these
>> we will have to invent a type code. I propose we assign codes
>> starting at 10000 arbitrarily in such cases
>> * Every field does have an XMP property id at present. I am not sure
>> if there is any guarantee that future fields will have an XMP
>> property id. I think we should continue with XMP property id for
>> IptcTypes.name field but if in future versions there is no XMP
>> property id then the backup would be to use the Name field from
>> the spec
>>
>> The only other alternative I can think of for IptcTypes.name field
>> issue is to use the Name field from the spec which is guaranteed to
>> be present, will never be translated but has the issue that it has
>> white space in its content. My preference is to do what is proposed
>> in bullets above.
>>
>> Comments? Thanks.
>>
>>
>>
>
>
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Farrukh Najmi <fa...@wellfleetsoftware.com>.
An example of a metadata property that has no IIM mapping defined is
Name: Scene Code, XMP property id: Scene (page 15 of 55 in spec)
On 07/06/2012 02:25 PM, Farrukh Najmi wrote:
> Hi Damjan,
>
> Thanks for the +1. As I started on this patch I made some observations
> in the IPTC-PhotoMetadata-2008.pdfspec:
>
> * Not all metadata properties have an IIM mapping defined. For these
> we will have to invent a type code. I propose we assign codes
> starting at 10000 arbitrarily in such cases
> * Every field does have an XMP property id at present. I am not sure
> if there is any guarantee that future fields will have an XMP
> property id. I think we should continue with XMP property id for
> IptcTypes.name field but if in future versions there is no XMP
> property id then the backup would be to use the Name field from
> the spec
>
> The only other alternative I can think of for IptcTypes.name field
> issue is to use the Name field from the spec which is guaranteed to be
> present, will never be translated but has the issue that it has white
> space in its content. My preference is to do what is proposed in
> bullets above.
>
> Comments? Thanks.
>
>
>
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Farrukh Najmi <fa...@wellfleetsoftware.com>.
Hi Damjan,
Thanks for the +1. As I started on this patch I made some observations
in the IPTC-PhotoMetadata-2008.pdfspec:
* Not all metadata properties have an IIM mapping defined. For these
we will have to invent a type code. I propose we assign codes
starting at 10000 arbitrarily in such cases
* Every field does have an XMP property id at present. I am not sure
if there is any guarantee that future fields will have an XMP
property id. I think we should continue with XMP property id for
IptcTypes.name field but if in future versions there is no XMP
property id then the backup would be to use the Name field from the spec
The only other alternative I can think of for IptcTypes.name field issue
is to use the Name field from the spec which is guaranteed to be
present, will never be translated but has the issue that it has white
space in its content. My preference is to do what is proposed in bullets
above.
Comments? Thanks.
On 07/05/2012 03:20 PM, Damjan Jovanovic wrote:
> Hi Farrukh
>
> +1
>
> Thank you
> Damjan
>
> On Thu, Jul 5, 2012 at 3:34 PM, Farrukh Najmi
> <fa...@wellfleetsoftware.com> wrote:
>> Hi Damjan,
>>
>> Just looked here:
>>
>> http://www.iptc.org/site/Photo_Metadata/IIM/
>>
>> This suggests that IIM is older and th
>>>>>>> On 07/05/2012 06:56 AM, Farrukh Najmi wrote:
>>>>>>>> Hi Damjan,
>>>>>>>>
>>>>>>>> Confirming that your recent fix for supporting Exif FieldName looks
>>>>>>>> good
>>>>>>>> great. Thank you!
>>>>>>>>
>>>>>>>> When do you think you may be able to commit the changes to support the
>>>>>>>> following metadata format-specific methods so I can provide feedback:
>>>>>>>>
>>>>>>>> Imaging.getExifMetadata()
>>>>>>>> Imaging.getIptcMetadata()
>>>>>>>> Imaging.getXmpMetadata()
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 07/04/2012 12:38 AM, Damjan Jovanovic wrote:
>>>>>>>>> I just committed new TIFF tag names to SVN, let me know how they work
>>>>>>>>> for
>>>>>>>>> you.
>>>>>>>>>
>>>>>>>>> The best time to add the new metadata methods is before the 1.0
>>>>>>>>> release, since changing binary compatibility later will be harder.
>>>>>>>>>
>>>>>>>>> On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
>>>>>>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>>>>>>> +1 on having the methods:
>>>>>>>>>>
>>>>>>>>>> Imaging.getExifMetadata()
>>>>>>>>>> Imaging.getIptcMetadata()
>>>>>>>>>> Imaging.getXmpMetadata()
>>>>>>>>>>
>>>>>>>>>> It is is a good idea so one can access metadata-format-specific
>>>>>>>>>> metadata
>>>>>>>>>> in
>>>>>>>>>> a metadata-format-specific way and handling all special needs of
>>>>>>>>>> specific
>>>>>>>>>> metadata formats. These methods should work on any image resource and
>>>>>>>>>> throw
>>>>>>>>>> something like MissingFeatureException for when a metadata format is
>>>>>>>>>> not
>>>>>>>>>> yet
>>>>>>>>>> supported for an image format or throw something like an
>>>>>>>>>> InvalidRequestException when a metadata format is invalid for a image
>>>>>>>>>> format.
>>>>>>>>>>
>>>>>>>>>> That said, there may still be some value to having a metadata-format
>>>>>>>>>> netrual
>>>>>>>>>> getMetadata() interface along the lines of the patch I submitted. For
>>>>>>>>>> now,
>>>>>>>>>> we could simply log an issue and defer it and insteda focus on your
>>>>>>>>>> suggestion above. That would meet my needs just fine.
>>>>>>>>>>
>>>>>>>>>> Question is do we do these changes after a formal 1.0 release or
>>>>>>>>>> before?
>>>>>>>>>> May
>>>>>>>>>> be it is better to get stable code under current API out as 1.0 and
>>>>>>>>>> then
>>>>>>>>>> work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are
>>>>>>>>>> not
>>>>>>>>>> backward compatible and are in fact major). Or is it better to do
>>>>>>>>>> these
>>>>>>>>>> changes for the 1.0 release so consumers of the project do not get
>>>>>>>>>> exposed
>>>>>>>>>> to a big API change?
>>>>>>>>>>
>>>>>>>>>> If we can do the proposed change without a long delay then I suggest
>>>>>>>>>> we
>>>>>>>>>> do
>>>>>>>>>> it for 1.0. If it means a long delay then I suggest we defer to 2.0.
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:
>>>>>>>>>>> I've also considered the metadata interfaces we use, and I am not
>>>>>>>>>>> sure
>>>>>>>>>>> the current approaches are any good.
>>>>>>>>>>>
>>>>>>>>>>> Most metadata formats are designed in a way specific to that format,
>>>>>>>>>>> eg. some have arbitrary levels of nesting, others have a flat
>>>>>>>>>>> structure, etc. But most are designed to be stored in any image
>>>>>>>>>>> format.
>>>>>>>>>>>
>>>>>>>>>>> So instead of a Imaging.getMetadata() method that tries to unify all
>>>>>>>>>>> metadata into one common interface - and does so badly, because eg.
>>>>>>>>>>> EXIF can have nested subdirectories and this information is lost -
>>>>>>>>>>> maybe we should have:
>>>>>>>>>>> Imaging.getExifMetadata()
>>>>>>>>>>> Imaging.getIptcMetadata()
>>>>>>>>>>> Imaging.getXmpMetadata()
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Damjan
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
>>>>>>>>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>>>>>>>>> Updated proposed patch with following new changes:
>>>>>>>>>>>>
>>>>>>>>>>>> Add getValue() method to nested class IImageMetadataItem. These
>>>>>>>>>>>> return
>>>>>>>>>>>> the
>>>>>>>>>>>> value of the item as an Object allowing for values of various types
>>>>>>>>>>>> to
>>>>>>>>>>>> be
>>>>>>>>>>>> returned.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 07/03/2012 11:01 AM, Farrukh Najmi wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Moving this thread to dev list as it seems to be more appropriate
>>>>>>>>>>>> there....
>>>>>>>>>>>>
>>>>>>>>>>>> Attached is a patch to the IImageMetadata.java that reflects my
>>>>>>>>>>>> revised
>>>>>>>>>>>> proposal thinking this through in conjunction with the proposed
>>>>>>>>>>>> solution
>>>>>>>>>>>> in
>>>>>>>>>>>> another thread...
>>>>>>>>>>>>
>>>>>>>>>>>> Add a getMetadataSpecification() method to IImageMetadata so we can
>>>>>>>>>>>> manage
>>>>>>>>>>>> the metadata specification that defines the metadata
>>>>>>>>>>>> Add getMetadata() to nested class IImageMetadataItem to get back at
>>>>>>>>>>>> the
>>>>>>>>>>>> parent IImageMetadata instance so we can access the metadata
>>>>>>>>>>>> specification
>>>>>>>>>>>> information managed from an IImageMetadata instance
>>>>>>>>>>>> Add getId(), getName(), getDescription() methods to nested class
>>>>>>>>>>>> IImageMetadataItem. These are the key triplet of info about the
>>>>>>>>>>>> metadata
>>>>>>>>>>>> item that is needed in my experience
>>>>>>>>>>>>
>>>>>>>>>>>> Of course implementations of these two interfaces would need to
>>>>>>>>>>>> also
>>>>>>>>>>>> be
>>>>>>>>>>>> updated to support the new methods according to proposed semantics.
>>>>>>>>>>>> I
>>>>>>>>>>>> would
>>>>>>>>>>>> be happy to contribute in any way that I can and as requested.
>>>>>>>>>>>>
>>>>>>>>>>>> Dev team colleagues, please weigh in on the proposal. Thanks for
>>>>>>>>>>>> your
>>>>>>>>>>>> awesome work to create this project and for considering this
>>>>>>>>>>>> proposal.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>> --
>>>> Regards,
>>>> Farrukh
>>>>
>>>> Web: http://www.wellfleetsoftware.com
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> e IPTC standard is the IPTC Core +
>> Extensions spec
>> <http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf>.
>> So my proposal is still valid that we use the XMP Property Id from the IPTC
>> Core + Extensions spec
>> <http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf>
>> for the string value of enum in
>> org.apache.commons.imaging.formats.jpeg.iptc.IptcTypes.java.
>>
>> Again I am awaiting a +1 from you before working on a tedious patch to
>> implement the propose change.
>>
>>
>> On 07/05/2012 09:28 AM, Farrukh Najmi wrote:
>>>
>>> The change I proposed for IPTC is contingent upon identifying what IPTC
>>> spec we are using. I am surprised that the IPTC IIM spec which is more
>>> recent makes no reference to the IPTC Core spec. I think we need to
>>> determine the correct spec before looking at my proposed change for IPTC
>>> support.
>>>
>>> On 07/05/2012 09:16 AM, Damjan Jovanovic wrote:
>>>> I'll have a look later and let you know.
>>>>
>>>> On Thu, Jul 5, 2012 at 2:52 PM, Farrukh Najmi
>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>> A similar change needs to be made IMHO to
>>>>> org.apache.commons.imaging.formats.jpeg.iptc.IptcTypes.java
>>>>>
>>>>> so that the enum string value is XML Property Id value instead of the
>>>>> IIM
>>>>> mapping value.
>>>>>
>>>>> As an example:
>>>>>
>>>>> COUNTRY_PRIMARY_LOCATION_NAME(
>>>>> 101, "Country/Primary Location Name"),
>>>>>
>>>>>
>>>>>
>>>>> would become:
>>>>>
>>>>> COUNTRY_PRIMARY_LOCATION_NAME(
>>>>> 101, "Country"),
>>>>>
>>>>>
>>>>> I can do this patch for you once I get a +1 to do it. Until the +1 I
>>>>> will
>>>>> hold off as the work is tedious and time consuming.
>>>>>
>>>>> Please let me know. Thanks.
>>>>>
>>>>>
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Damjan Jovanovic <da...@gmail.com>.
Hi Farrukh
+1
Thank you
Damjan
On Thu, Jul 5, 2012 at 3:34 PM, Farrukh Najmi
<fa...@wellfleetsoftware.com> wrote:
> Hi Damjan,
>
> Just looked here:
>
> http://www.iptc.org/site/Photo_Metadata/IIM/
>
> This suggests that IIM is older and the IPTC standard is the IPTC Core +
> Extensions spec
> <http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf>.
> So my proposal is still valid that we use the XMP Property Id from the IPTC
> Core + Extensions spec
> <http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf>
> for the string value of enum in
> org.apache.commons.imaging.formats.jpeg.iptc.IptcTypes.java.
>
> Again I am awaiting a +1 from you before working on a tedious patch to
> implement the propose change.
>
>
> On 07/05/2012 09:28 AM, Farrukh Najmi wrote:
>>
>>
>> The change I proposed for IPTC is contingent upon identifying what IPTC
>> spec we are using. I am surprised that the IPTC IIM spec which is more
>> recent makes no reference to the IPTC Core spec. I think we need to
>> determine the correct spec before looking at my proposed change for IPTC
>> support.
>>
>> On 07/05/2012 09:16 AM, Damjan Jovanovic wrote:
>>>
>>> I'll have a look later and let you know.
>>>
>>> On Thu, Jul 5, 2012 at 2:52 PM, Farrukh Najmi
>>> <fa...@wellfleetsoftware.com> wrote:
>>>>
>>>> A similar change needs to be made IMHO to
>>>> org.apache.commons.imaging.formats.jpeg.iptc.IptcTypes.java
>>>>
>>>> so that the enum string value is XML Property Id value instead of the
>>>> IIM
>>>> mapping value.
>>>>
>>>> As an example:
>>>>
>>>> COUNTRY_PRIMARY_LOCATION_NAME(
>>>> 101, "Country/Primary Location Name"),
>>>>
>>>>
>>>>
>>>> would become:
>>>>
>>>> COUNTRY_PRIMARY_LOCATION_NAME(
>>>> 101, "Country"),
>>>>
>>>>
>>>> I can do this patch for you once I get a +1 to do it. Until the +1 I
>>>> will
>>>> hold off as the work is tedious and time consuming.
>>>>
>>>> Please let me know. Thanks.
>>>>
>>>>
>>>> On 07/05/2012 06:56 AM, Farrukh Najmi wrote:
>>>>>
>>>>>
>>>>> Hi Damjan,
>>>>>
>>>>> Confirming that your recent fix for supporting Exif FieldName looks
>>>>> good
>>>>> great. Thank you!
>>>>>
>>>>> When do you think you may be able to commit the changes to support the
>>>>> following metadata format-specific methods so I can provide feedback:
>>>>>
>>>>> Imaging.getExifMetadata()
>>>>> Imaging.getIptcMetadata()
>>>>> Imaging.getXmpMetadata()
>>>>>
>>>>>
>>>>>
>>>>> On 07/04/2012 12:38 AM, Damjan Jovanovic wrote:
>>>>>>
>>>>>> I just committed new TIFF tag names to SVN, let me know how they work
>>>>>> for
>>>>>> you.
>>>>>>
>>>>>> The best time to add the new metadata methods is before the 1.0
>>>>>> release, since changing binary compatibility later will be harder.
>>>>>>
>>>>>> On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
>>>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>>>>
>>>>>>> +1 on having the methods:
>>>>>>>
>>>>>>> Imaging.getExifMetadata()
>>>>>>> Imaging.getIptcMetadata()
>>>>>>> Imaging.getXmpMetadata()
>>>>>>>
>>>>>>> It is is a good idea so one can access metadata-format-specific
>>>>>>> metadata
>>>>>>> in
>>>>>>> a metadata-format-specific way and handling all special needs of
>>>>>>> specific
>>>>>>> metadata formats. These methods should work on any image resource and
>>>>>>> throw
>>>>>>> something like MissingFeatureException for when a metadata format is
>>>>>>> not
>>>>>>> yet
>>>>>>> supported for an image format or throw something like an
>>>>>>> InvalidRequestException when a metadata format is invalid for a image
>>>>>>> format.
>>>>>>>
>>>>>>> That said, there may still be some value to having a metadata-format
>>>>>>> netrual
>>>>>>> getMetadata() interface along the lines of the patch I submitted. For
>>>>>>> now,
>>>>>>> we could simply log an issue and defer it and insteda focus on your
>>>>>>> suggestion above. That would meet my needs just fine.
>>>>>>>
>>>>>>> Question is do we do these changes after a formal 1.0 release or
>>>>>>> before?
>>>>>>> May
>>>>>>> be it is better to get stable code under current API out as 1.0 and
>>>>>>> then
>>>>>>> work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are
>>>>>>> not
>>>>>>> backward compatible and are in fact major). Or is it better to do
>>>>>>> these
>>>>>>> changes for the 1.0 release so consumers of the project do not get
>>>>>>> exposed
>>>>>>> to a big API change?
>>>>>>>
>>>>>>> If we can do the proposed change without a long delay then I suggest
>>>>>>> we
>>>>>>> do
>>>>>>> it for 1.0. If it means a long delay then I suggest we defer to 2.0.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:
>>>>>>>>
>>>>>>>> I've also considered the metadata interfaces we use, and I am not
>>>>>>>> sure
>>>>>>>> the current approaches are any good.
>>>>>>>>
>>>>>>>> Most metadata formats are designed in a way specific to that format,
>>>>>>>> eg. some have arbitrary levels of nesting, others have a flat
>>>>>>>> structure, etc. But most are designed to be stored in any image
>>>>>>>> format.
>>>>>>>>
>>>>>>>> So instead of a Imaging.getMetadata() method that tries to unify all
>>>>>>>> metadata into one common interface - and does so badly, because eg.
>>>>>>>> EXIF can have nested subdirectories and this information is lost -
>>>>>>>> maybe we should have:
>>>>>>>> Imaging.getExifMetadata()
>>>>>>>> Imaging.getIptcMetadata()
>>>>>>>> Imaging.getXmpMetadata()
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Damjan
>>>>>>>>
>>>>>>>> On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
>>>>>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>>>>>>
>>>>>>>>> Updated proposed patch with following new changes:
>>>>>>>>>
>>>>>>>>> Add getValue() method to nested class IImageMetadataItem. These
>>>>>>>>> return
>>>>>>>>> the
>>>>>>>>> value of the item as an Object allowing for values of various types
>>>>>>>>> to
>>>>>>>>> be
>>>>>>>>> returned.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 07/03/2012 11:01 AM, Farrukh Najmi wrote:
>>>>>>>>>
>>>>>>>>> Moving this thread to dev list as it seems to be more appropriate
>>>>>>>>> there....
>>>>>>>>>
>>>>>>>>> Attached is a patch to the IImageMetadata.java that reflects my
>>>>>>>>> revised
>>>>>>>>> proposal thinking this through in conjunction with the proposed
>>>>>>>>> solution
>>>>>>>>> in
>>>>>>>>> another thread...
>>>>>>>>>
>>>>>>>>> Add a getMetadataSpecification() method to IImageMetadata so we can
>>>>>>>>> manage
>>>>>>>>> the metadata specification that defines the metadata
>>>>>>>>> Add getMetadata() to nested class IImageMetadataItem to get back at
>>>>>>>>> the
>>>>>>>>> parent IImageMetadata instance so we can access the metadata
>>>>>>>>> specification
>>>>>>>>> information managed from an IImageMetadata instance
>>>>>>>>> Add getId(), getName(), getDescription() methods to nested class
>>>>>>>>> IImageMetadataItem. These are the key triplet of info about the
>>>>>>>>> metadata
>>>>>>>>> item that is needed in my experience
>>>>>>>>>
>>>>>>>>> Of course implementations of these two interfaces would need to
>>>>>>>>> also
>>>>>>>>> be
>>>>>>>>> updated to support the new methods according to proposed semantics.
>>>>>>>>> I
>>>>>>>>> would
>>>>>>>>> be happy to contribute in any way that I can and as requested.
>>>>>>>>>
>>>>>>>>> Dev team colleagues, please weigh in on the proposal. Thanks for
>>>>>>>>> your
>>>>>>>>> awesome work to create this project and for considering this
>>>>>>>>> proposal.
>>>>>>>>>
>>>>>>>>>
>>>>
>>
>
>
> --
> Regards,
> Farrukh
>
> Web: http://www.wellfleetsoftware.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Farrukh Najmi <fa...@wellfleetsoftware.com>.
Hi Damjan,
Just looked here:
http://www.iptc.org/site/Photo_Metadata/IIM/
This suggests that IIM is older and the IPTC standard is the IPTC Core +
Extensions spec
<http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf>.
So my proposal is still valid that we use the XMP Property Id from the
IPTC Core + Extensions spec
<http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf>
for the string value of enum in
org.apache.commons.imaging.formats.jpeg.iptc.IptcTypes.java.
Again I am awaiting a +1 from you before working on a tedious patch to
implement the propose change.
On 07/05/2012 09:28 AM, Farrukh Najmi wrote:
>
> The change I proposed for IPTC is contingent upon identifying what
> IPTC spec we are using. I am surprised that the IPTC IIM spec which is
> more recent makes no reference to the IPTC Core spec. I think we need
> to determine the correct spec before looking at my proposed change for
> IPTC support.
>
> On 07/05/2012 09:16 AM, Damjan Jovanovic wrote:
>> I'll have a look later and let you know.
>>
>> On Thu, Jul 5, 2012 at 2:52 PM, Farrukh Najmi
>> <fa...@wellfleetsoftware.com> wrote:
>>> A similar change needs to be made IMHO to
>>> org.apache.commons.imaging.formats.jpeg.iptc.IptcTypes.java
>>>
>>> so that the enum string value is XML Property Id value instead of
>>> the IIM
>>> mapping value.
>>>
>>> As an example:
>>>
>>> COUNTRY_PRIMARY_LOCATION_NAME(
>>> 101, "Country/Primary Location Name"),
>>>
>>>
>>>
>>> would become:
>>>
>>> COUNTRY_PRIMARY_LOCATION_NAME(
>>> 101, "Country"),
>>>
>>>
>>> I can do this patch for you once I get a +1 to do it. Until the +1 I
>>> will
>>> hold off as the work is tedious and time consuming.
>>>
>>> Please let me know. Thanks.
>>>
>>>
>>> On 07/05/2012 06:56 AM, Farrukh Najmi wrote:
>>>>
>>>> Hi Damjan,
>>>>
>>>> Confirming that your recent fix for supporting Exif FieldName looks
>>>> good
>>>> great. Thank you!
>>>>
>>>> When do you think you may be able to commit the changes to support the
>>>> following metadata format-specific methods so I can provide feedback:
>>>>
>>>> Imaging.getExifMetadata()
>>>> Imaging.getIptcMetadata()
>>>> Imaging.getXmpMetadata()
>>>>
>>>>
>>>>
>>>> On 07/04/2012 12:38 AM, Damjan Jovanovic wrote:
>>>>> I just committed new TIFF tag names to SVN, let me know how they
>>>>> work for
>>>>> you.
>>>>>
>>>>> The best time to add the new metadata methods is before the 1.0
>>>>> release, since changing binary compatibility later will be harder.
>>>>>
>>>>> On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
>>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>>> +1 on having the methods:
>>>>>>
>>>>>> Imaging.getExifMetadata()
>>>>>> Imaging.getIptcMetadata()
>>>>>> Imaging.getXmpMetadata()
>>>>>>
>>>>>> It is is a good idea so one can access metadata-format-specific
>>>>>> metadata
>>>>>> in
>>>>>> a metadata-format-specific way and handling all special needs of
>>>>>> specific
>>>>>> metadata formats. These methods should work on any image resource
>>>>>> and
>>>>>> throw
>>>>>> something like MissingFeatureException for when a metadata format
>>>>>> is not
>>>>>> yet
>>>>>> supported for an image format or throw something like an
>>>>>> InvalidRequestException when a metadata format is invalid for a
>>>>>> image
>>>>>> format.
>>>>>>
>>>>>> That said, there may still be some value to having a metadata-format
>>>>>> netrual
>>>>>> getMetadata() interface along the lines of the patch I submitted.
>>>>>> For
>>>>>> now,
>>>>>> we could simply log an issue and defer it and insteda focus on your
>>>>>> suggestion above. That would meet my needs just fine.
>>>>>>
>>>>>> Question is do we do these changes after a formal 1.0 release or
>>>>>> before?
>>>>>> May
>>>>>> be it is better to get stable code under current API out as 1.0
>>>>>> and then
>>>>>> work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes
>>>>>> are not
>>>>>> backward compatible and are in fact major). Or is it better to do
>>>>>> these
>>>>>> changes for the 1.0 release so consumers of the project do not get
>>>>>> exposed
>>>>>> to a big API change?
>>>>>>
>>>>>> If we can do the proposed change without a long delay then I
>>>>>> suggest we
>>>>>> do
>>>>>> it for 1.0. If it means a long delay then I suggest we defer to 2.0.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:
>>>>>>> I've also considered the metadata interfaces we use, and I am
>>>>>>> not sure
>>>>>>> the current approaches are any good.
>>>>>>>
>>>>>>> Most metadata formats are designed in a way specific to that
>>>>>>> format,
>>>>>>> eg. some have arbitrary levels of nesting, others have a flat
>>>>>>> structure, etc. But most are designed to be stored in any image
>>>>>>> format.
>>>>>>>
>>>>>>> So instead of a Imaging.getMetadata() method that tries to unify
>>>>>>> all
>>>>>>> metadata into one common interface - and does so badly, because eg.
>>>>>>> EXIF can have nested subdirectories and this information is lost -
>>>>>>> maybe we should have:
>>>>>>> Imaging.getExifMetadata()
>>>>>>> Imaging.getIptcMetadata()
>>>>>>> Imaging.getXmpMetadata()
>>>>>>>
>>>>>>> Regards
>>>>>>> Damjan
>>>>>>>
>>>>>>> On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
>>>>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>>>>> Updated proposed patch with following new changes:
>>>>>>>>
>>>>>>>> Add getValue() method to nested class IImageMetadataItem. These
>>>>>>>> return
>>>>>>>> the
>>>>>>>> value of the item as an Object allowing for values of various
>>>>>>>> types to
>>>>>>>> be
>>>>>>>> returned.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 07/03/2012 11:01 AM, Farrukh Najmi wrote:
>>>>>>>>
>>>>>>>> Moving this thread to dev list as it seems to be more appropriate
>>>>>>>> there....
>>>>>>>>
>>>>>>>> Attached is a patch to the IImageMetadata.java that reflects my
>>>>>>>> revised
>>>>>>>> proposal thinking this through in conjunction with the proposed
>>>>>>>> solution
>>>>>>>> in
>>>>>>>> another thread...
>>>>>>>>
>>>>>>>> Add a getMetadataSpecification() method to IImageMetadata so we
>>>>>>>> can
>>>>>>>> manage
>>>>>>>> the metadata specification that defines the metadata
>>>>>>>> Add getMetadata() to nested class IImageMetadataItem to get
>>>>>>>> back at
>>>>>>>> the
>>>>>>>> parent IImageMetadata instance so we can access the metadata
>>>>>>>> specification
>>>>>>>> information managed from an IImageMetadata instance
>>>>>>>> Add getId(), getName(), getDescription() methods to nested class
>>>>>>>> IImageMetadataItem. These are the key triplet of info about the
>>>>>>>> metadata
>>>>>>>> item that is needed in my experience
>>>>>>>>
>>>>>>>> Of course implementations of these two interfaces would need to
>>>>>>>> also
>>>>>>>> be
>>>>>>>> updated to support the new methods according to proposed
>>>>>>>> semantics. I
>>>>>>>> would
>>>>>>>> be happy to contribute in any way that I can and as requested.
>>>>>>>>
>>>>>>>> Dev team colleagues, please weigh in on the proposal. Thanks
>>>>>>>> for your
>>>>>>>> awesome work to create this project and for considering this
>>>>>>>> proposal.
>>>>>>>>
>>>>>>>>
>>>
>
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Farrukh Najmi <fa...@wellfleetsoftware.com>.
The change I proposed for IPTC is contingent upon identifying what IPTC
spec we are using. I am surprised that the IPTC IIM spec which is more
recent makes no reference to the IPTC Core spec. I think we need to
determine the correct spec before looking at my proposed change for IPTC
support.
On 07/05/2012 09:16 AM, Damjan Jovanovic wrote:
> I'll have a look later and let you know.
>
> On Thu, Jul 5, 2012 at 2:52 PM, Farrukh Najmi
> <fa...@wellfleetsoftware.com> wrote:
>> A similar change needs to be made IMHO to
>> org.apache.commons.imaging.formats.jpeg.iptc.IptcTypes.java
>>
>> so that the enum string value is XML Property Id value instead of the IIM
>> mapping value.
>>
>> As an example:
>>
>> COUNTRY_PRIMARY_LOCATION_NAME(
>> 101, "Country/Primary Location Name"),
>>
>>
>>
>> would become:
>>
>> COUNTRY_PRIMARY_LOCATION_NAME(
>> 101, "Country"),
>>
>>
>> I can do this patch for you once I get a +1 to do it. Until the +1 I will
>> hold off as the work is tedious and time consuming.
>>
>> Please let me know. Thanks.
>>
>>
>> On 07/05/2012 06:56 AM, Farrukh Najmi wrote:
>>>
>>> Hi Damjan,
>>>
>>> Confirming that your recent fix for supporting Exif FieldName looks good
>>> great. Thank you!
>>>
>>> When do you think you may be able to commit the changes to support the
>>> following metadata format-specific methods so I can provide feedback:
>>>
>>> Imaging.getExifMetadata()
>>> Imaging.getIptcMetadata()
>>> Imaging.getXmpMetadata()
>>>
>>>
>>>
>>> On 07/04/2012 12:38 AM, Damjan Jovanovic wrote:
>>>> I just committed new TIFF tag names to SVN, let me know how they work for
>>>> you.
>>>>
>>>> The best time to add the new metadata methods is before the 1.0
>>>> release, since changing binary compatibility later will be harder.
>>>>
>>>> On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>> +1 on having the methods:
>>>>>
>>>>> Imaging.getExifMetadata()
>>>>> Imaging.getIptcMetadata()
>>>>> Imaging.getXmpMetadata()
>>>>>
>>>>> It is is a good idea so one can access metadata-format-specific metadata
>>>>> in
>>>>> a metadata-format-specific way and handling all special needs of
>>>>> specific
>>>>> metadata formats. These methods should work on any image resource and
>>>>> throw
>>>>> something like MissingFeatureException for when a metadata format is not
>>>>> yet
>>>>> supported for an image format or throw something like an
>>>>> InvalidRequestException when a metadata format is invalid for a image
>>>>> format.
>>>>>
>>>>> That said, there may still be some value to having a metadata-format
>>>>> netrual
>>>>> getMetadata() interface along the lines of the patch I submitted. For
>>>>> now,
>>>>> we could simply log an issue and defer it and insteda focus on your
>>>>> suggestion above. That would meet my needs just fine.
>>>>>
>>>>> Question is do we do these changes after a formal 1.0 release or before?
>>>>> May
>>>>> be it is better to get stable code under current API out as 1.0 and then
>>>>> work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are not
>>>>> backward compatible and are in fact major). Or is it better to do these
>>>>> changes for the 1.0 release so consumers of the project do not get
>>>>> exposed
>>>>> to a big API change?
>>>>>
>>>>> If we can do the proposed change without a long delay then I suggest we
>>>>> do
>>>>> it for 1.0. If it means a long delay then I suggest we defer to 2.0.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>>
>>>>>
>>>>> On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:
>>>>>> I've also considered the metadata interfaces we use, and I am not sure
>>>>>> the current approaches are any good.
>>>>>>
>>>>>> Most metadata formats are designed in a way specific to that format,
>>>>>> eg. some have arbitrary levels of nesting, others have a flat
>>>>>> structure, etc. But most are designed to be stored in any image
>>>>>> format.
>>>>>>
>>>>>> So instead of a Imaging.getMetadata() method that tries to unify all
>>>>>> metadata into one common interface - and does so badly, because eg.
>>>>>> EXIF can have nested subdirectories and this information is lost -
>>>>>> maybe we should have:
>>>>>> Imaging.getExifMetadata()
>>>>>> Imaging.getIptcMetadata()
>>>>>> Imaging.getXmpMetadata()
>>>>>>
>>>>>> Regards
>>>>>> Damjan
>>>>>>
>>>>>> On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
>>>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>>>> Updated proposed patch with following new changes:
>>>>>>>
>>>>>>> Add getValue() method to nested class IImageMetadataItem. These return
>>>>>>> the
>>>>>>> value of the item as an Object allowing for values of various types to
>>>>>>> be
>>>>>>> returned.
>>>>>>>
>>>>>>>
>>>>>>> On 07/03/2012 11:01 AM, Farrukh Najmi wrote:
>>>>>>>
>>>>>>> Moving this thread to dev list as it seems to be more appropriate
>>>>>>> there....
>>>>>>>
>>>>>>> Attached is a patch to the IImageMetadata.java that reflects my
>>>>>>> revised
>>>>>>> proposal thinking this through in conjunction with the proposed
>>>>>>> solution
>>>>>>> in
>>>>>>> another thread...
>>>>>>>
>>>>>>> Add a getMetadataSpecification() method to IImageMetadata so we can
>>>>>>> manage
>>>>>>> the metadata specification that defines the metadata
>>>>>>> Add getMetadata() to nested class IImageMetadataItem to get back at
>>>>>>> the
>>>>>>> parent IImageMetadata instance so we can access the metadata
>>>>>>> specification
>>>>>>> information managed from an IImageMetadata instance
>>>>>>> Add getId(), getName(), getDescription() methods to nested class
>>>>>>> IImageMetadataItem. These are the key triplet of info about the
>>>>>>> metadata
>>>>>>> item that is needed in my experience
>>>>>>>
>>>>>>> Of course implementations of these two interfaces would need to also
>>>>>>> be
>>>>>>> updated to support the new methods according to proposed semantics. I
>>>>>>> would
>>>>>>> be happy to contribute in any way that I can and as requested.
>>>>>>>
>>>>>>> Dev team colleagues, please weigh in on the proposal. Thanks for your
>>>>>>> awesome work to create this project and for considering this proposal.
>>>>>>>
>>>>>>>
>>
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Damjan Jovanovic <da...@gmail.com>.
I'll have a look later and let you know.
On Thu, Jul 5, 2012 at 2:52 PM, Farrukh Najmi
<fa...@wellfleetsoftware.com> wrote:
>
> A similar change needs to be made IMHO to
> org.apache.commons.imaging.formats.jpeg.iptc.IptcTypes.java
>
> so that the enum string value is XML Property Id value instead of the IIM
> mapping value.
>
> As an example:
>
> COUNTRY_PRIMARY_LOCATION_NAME(
> 101, "Country/Primary Location Name"),
>
>
>
> would become:
>
> COUNTRY_PRIMARY_LOCATION_NAME(
> 101, "Country"),
>
>
> I can do this patch for you once I get a +1 to do it. Until the +1 I will
> hold off as the work is tedious and time consuming.
>
> Please let me know. Thanks.
>
>
> On 07/05/2012 06:56 AM, Farrukh Najmi wrote:
>>
>>
>> Hi Damjan,
>>
>> Confirming that your recent fix for supporting Exif FieldName looks good
>> great. Thank you!
>>
>> When do you think you may be able to commit the changes to support the
>> following metadata format-specific methods so I can provide feedback:
>>
>> Imaging.getExifMetadata()
>> Imaging.getIptcMetadata()
>> Imaging.getXmpMetadata()
>>
>>
>>
>> On 07/04/2012 12:38 AM, Damjan Jovanovic wrote:
>>>
>>> I just committed new TIFF tag names to SVN, let me know how they work for
>>> you.
>>>
>>> The best time to add the new metadata methods is before the 1.0
>>> release, since changing binary compatibility later will be harder.
>>>
>>> On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
>>> <fa...@wellfleetsoftware.com> wrote:
>>>>
>>>> +1 on having the methods:
>>>>
>>>> Imaging.getExifMetadata()
>>>> Imaging.getIptcMetadata()
>>>> Imaging.getXmpMetadata()
>>>>
>>>> It is is a good idea so one can access metadata-format-specific metadata
>>>> in
>>>> a metadata-format-specific way and handling all special needs of
>>>> specific
>>>> metadata formats. These methods should work on any image resource and
>>>> throw
>>>> something like MissingFeatureException for when a metadata format is not
>>>> yet
>>>> supported for an image format or throw something like an
>>>> InvalidRequestException when a metadata format is invalid for a image
>>>> format.
>>>>
>>>> That said, there may still be some value to having a metadata-format
>>>> netrual
>>>> getMetadata() interface along the lines of the patch I submitted. For
>>>> now,
>>>> we could simply log an issue and defer it and insteda focus on your
>>>> suggestion above. That would meet my needs just fine.
>>>>
>>>> Question is do we do these changes after a formal 1.0 release or before?
>>>> May
>>>> be it is better to get stable code under current API out as 1.0 and then
>>>> work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are not
>>>> backward compatible and are in fact major). Or is it better to do these
>>>> changes for the 1.0 release so consumers of the project do not get
>>>> exposed
>>>> to a big API change?
>>>>
>>>> If we can do the proposed change without a long delay then I suggest we
>>>> do
>>>> it for 1.0. If it means a long delay then I suggest we defer to 2.0.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>> On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:
>>>>>
>>>>> I've also considered the metadata interfaces we use, and I am not sure
>>>>> the current approaches are any good.
>>>>>
>>>>> Most metadata formats are designed in a way specific to that format,
>>>>> eg. some have arbitrary levels of nesting, others have a flat
>>>>> structure, etc. But most are designed to be stored in any image
>>>>> format.
>>>>>
>>>>> So instead of a Imaging.getMetadata() method that tries to unify all
>>>>> metadata into one common interface - and does so badly, because eg.
>>>>> EXIF can have nested subdirectories and this information is lost -
>>>>> maybe we should have:
>>>>> Imaging.getExifMetadata()
>>>>> Imaging.getIptcMetadata()
>>>>> Imaging.getXmpMetadata()
>>>>>
>>>>> Regards
>>>>> Damjan
>>>>>
>>>>> On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
>>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>>>
>>>>>> Updated proposed patch with following new changes:
>>>>>>
>>>>>> Add getValue() method to nested class IImageMetadataItem. These return
>>>>>> the
>>>>>> value of the item as an Object allowing for values of various types to
>>>>>> be
>>>>>> returned.
>>>>>>
>>>>>>
>>>>>> On 07/03/2012 11:01 AM, Farrukh Najmi wrote:
>>>>>>
>>>>>> Moving this thread to dev list as it seems to be more appropriate
>>>>>> there....
>>>>>>
>>>>>> Attached is a patch to the IImageMetadata.java that reflects my
>>>>>> revised
>>>>>> proposal thinking this through in conjunction with the proposed
>>>>>> solution
>>>>>> in
>>>>>> another thread...
>>>>>>
>>>>>> Add a getMetadataSpecification() method to IImageMetadata so we can
>>>>>> manage
>>>>>> the metadata specification that defines the metadata
>>>>>> Add getMetadata() to nested class IImageMetadataItem to get back at
>>>>>> the
>>>>>> parent IImageMetadata instance so we can access the metadata
>>>>>> specification
>>>>>> information managed from an IImageMetadata instance
>>>>>> Add getId(), getName(), getDescription() methods to nested class
>>>>>> IImageMetadataItem. These are the key triplet of info about the
>>>>>> metadata
>>>>>> item that is needed in my experience
>>>>>>
>>>>>> Of course implementations of these two interfaces would need to also
>>>>>> be
>>>>>> updated to support the new methods according to proposed semantics. I
>>>>>> would
>>>>>> be happy to contribute in any way that I can and as requested.
>>>>>>
>>>>>> Dev team colleagues, please weigh in on the proposal. Thanks for your
>>>>>> awesome work to create this project and for considering this proposal.
>>>>>>
>>>>>>
>>>>
>>
>
>
> --
> Regards,
> Farrukh
>
> Web: http://www.wellfleetsoftware.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Damjan Jovanovic <da...@gmail.com>.
I have no idea. I never wrote any of the IPTC code.
On Thu, Jul 5, 2012 at 3:10 PM, Farrukh Najmi
<fa...@wellfleetsoftware.com> wrote:
> BTW, I had thus far been assuming the IPTC spec to use was:
>
> IPTC Standard Photo Metadata 2008 IPTC Core Specification Version 1.1
> IPTC Extension Specification Version 1.0
> Document Revision 2
> <http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf>
>
> But then I was looking for some missing constants and came across:
>
> IPTC - NAA Information Interchange Model Version 4
> <http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf> (IIM)
>
> Which is the spec that we should be using? How are they related?
>
> The IIM spec does not have the XMP Property Id (which I incorrectly referred
> to as XML Property Id) as does the IPTC Core spec.
>
> Sorry for my confusion.
>
>
> On 07/05/2012 08:52 AM, Farrukh Najmi wrote:
>>
>>
>> A similar change needs to be made IMHO to
>> org.apache.commons.imaging.formats.jpeg.iptc.IptcTypes.java
>>
>> so that the enum string value is XML Property Id value instead of the IIM
>> mapping value.
>>
>> As an example:
>>
>> COUNTRY_PRIMARY_LOCATION_NAME(
>> 101, "Country/Primary Location Name"),
>>
>>
>>
>> would become:
>>
>> COUNTRY_PRIMARY_LOCATION_NAME(
>> 101, "Country"),
>>
>>
>> I can do this patch for you once I get a +1 to do it. Until the +1 I will
>> hold off as the work is tedious and time consuming.
>>
>> Please let me know. Thanks.
>>
>> On 07/05/2012 06:56 AM, Farrukh Najmi wrote:
>>>
>>>
>>> Hi Damjan,
>>>
>>> Confirming that your recent fix for supporting Exif FieldName looks good
>>> great. Thank you!
>>>
>>> When do you think you may be able to commit the changes to support the
>>> following metadata format-specific methods so I can provide feedback:
>>>
>>> Imaging.getExifMetadata()
>>> Imaging.getIptcMetadata()
>>> Imaging.getXmpMetadata()
>>>
>>>
>>>
>>> On 07/04/2012 12:38 AM, Damjan Jovanovic wrote:
>>>>
>>>> I just committed new TIFF tag names to SVN, let me know how they work
>>>> for you.
>>>>
>>>> The best time to add the new metadata methods is before the 1.0
>>>> release, since changing binary compatibility later will be harder.
>>>>
>>>> On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>>
>>>>> +1 on having the methods:
>>>>>
>>>>> Imaging.getExifMetadata()
>>>>> Imaging.getIptcMetadata()
>>>>> Imaging.getXmpMetadata()
>>>>>
>>>>> It is is a good idea so one can access metadata-format-specific
>>>>> metadata in
>>>>> a metadata-format-specific way and handling all special needs of
>>>>> specific
>>>>> metadata formats. These methods should work on any image resource and
>>>>> throw
>>>>> something like MissingFeatureException for when a metadata format is
>>>>> not yet
>>>>> supported for an image format or throw something like an
>>>>> InvalidRequestException when a metadata format is invalid for a image
>>>>> format.
>>>>>
>>>>> That said, there may still be some value to having a metadata-format
>>>>> netrual
>>>>> getMetadata() interface along the lines of the patch I submitted. For
>>>>> now,
>>>>> we could simply log an issue and defer it and insteda focus on your
>>>>> suggestion above. That would meet my needs just fine.
>>>>>
>>>>> Question is do we do these changes after a formal 1.0 release or
>>>>> before? May
>>>>> be it is better to get stable code under current API out as 1.0 and
>>>>> then
>>>>> work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are not
>>>>> backward compatible and are in fact major). Or is it better to do these
>>>>> changes for the 1.0 release so consumers of the project do not get
>>>>> exposed
>>>>> to a big API change?
>>>>>
>>>>> If we can do the proposed change without a long delay then I suggest we
>>>>> do
>>>>> it for 1.0. If it means a long delay then I suggest we defer to 2.0.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>>
>>>>>
>>>>> On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:
>>>>>>
>>>>>> I've also considered the metadata interfaces we use, and I am not sure
>>>>>> the current approaches are any good.
>>>>>>
>>>>>> Most metadata formats are designed in a way specific to that format,
>>>>>> eg. some have arbitrary levels of nesting, others have a flat
>>>>>> structure, etc. But most are designed to be stored in any image
>>>>>> format.
>>>>>>
>>>>>> So instead of a Imaging.getMetadata() method that tries to unify all
>>>>>> metadata into one common interface - and does so badly, because eg.
>>>>>> EXIF can have nested subdirectories and this information is lost -
>>>>>> maybe we should have:
>>>>>> Imaging.getExifMetadata()
>>>>>> Imaging.getIptcMetadata()
>>>>>> Imaging.getXmpMetadata()
>>>>>>
>>>>>> Regards
>>>>>> Damjan
>>>>>>
>>>>>> On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
>>>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>>>>
>>>>>>> Updated proposed patch with following new changes:
>>>>>>>
>>>>>>> Add getValue() method to nested class IImageMetadataItem. These
>>>>>>> return
>>>>>>> the
>>>>>>> value of the item as an Object allowing for values of various types
>>>>>>> to be
>>>>>>> returned.
>>>>>>>
>>>>>>>
>>>>>>> On 07/03/2012 11:01 AM, Farrukh Najmi wrote:
>>>>>>>
>>>>>>> Moving this thread to dev list as it seems to be more appropriate
>>>>>>> there....
>>>>>>>
>>>>>>> Attached is a patch to the IImageMetadata.java that reflects my
>>>>>>> revised
>>>>>>> proposal thinking this through in conjunction with the proposed
>>>>>>> solution
>>>>>>> in
>>>>>>> another thread...
>>>>>>>
>>>>>>> Add a getMetadataSpecification() method to IImageMetadata so we can
>>>>>>> manage
>>>>>>> the metadata specification that defines the metadata
>>>>>>> Add getMetadata() to nested class IImageMetadataItem to get back at
>>>>>>> the
>>>>>>> parent IImageMetadata instance so we can access the metadata
>>>>>>> specification
>>>>>>> information managed from an IImageMetadata instance
>>>>>>> Add getId(), getName(), getDescription() methods to nested class
>>>>>>> IImageMetadataItem. These are the key triplet of info about the
>>>>>>> metadata
>>>>>>> item that is needed in my experience
>>>>>>>
>>>>>>> Of course implementations of these two interfaces would need to also
>>>>>>> be
>>>>>>> updated to support the new methods according to proposed semantics. I
>>>>>>> would
>>>>>>> be happy to contribute in any way that I can and as requested.
>>>>>>>
>>>>>>> Dev team colleagues, please weigh in on the proposal. Thanks for your
>>>>>>> awesome work to create this project and for considering this
>>>>>>> proposal.
>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>>
>
>
> --
> Regards,
> Farrukh
>
> Web: http://www.wellfleetsoftware.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Farrukh Najmi <fa...@wellfleetsoftware.com>.
BTW, I had thus far been assuming the IPTC spec to use was:
IPTC Standard Photo Metadata 2008 IPTC Core Specification Version 1.1
IPTC Extension Specification Version 1.0
Document Revision 2
<http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf>
But then I was looking for some missing constants and came across:
IPTC - NAA Information Interchange Model Version 4
<http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf> (IIM)
Which is the spec that we should be using? How are they related?
The IIM spec does not have the XMP Property Id (which I incorrectly
referred to as XML Property Id) as does the IPTC Core spec.
Sorry for my confusion.
On 07/05/2012 08:52 AM, Farrukh Najmi wrote:
>
> A similar change needs to be made IMHO to
> org.apache.commons.imaging.formats.jpeg.iptc.IptcTypes.java
>
> so that the enum string value is XML Property Id value instead of the
> IIM mapping value.
>
> As an example:
>
> COUNTRY_PRIMARY_LOCATION_NAME(
> 101, "Country/Primary Location Name"),
>
>
>
> would become:
>
> COUNTRY_PRIMARY_LOCATION_NAME(
> 101, "Country"),
>
>
> I can do this patch for you once I get a +1 to do it. Until the +1 I
> will hold off as the work is tedious and time consuming.
>
> Please let me know. Thanks.
>
> On 07/05/2012 06:56 AM, Farrukh Najmi wrote:
>>
>> Hi Damjan,
>>
>> Confirming that your recent fix for supporting Exif FieldName looks
>> good great. Thank you!
>>
>> When do you think you may be able to commit the changes to support
>> the following metadata format-specific methods so I can provide
>> feedback:
>>
>> Imaging.getExifMetadata()
>> Imaging.getIptcMetadata()
>> Imaging.getXmpMetadata()
>>
>>
>>
>> On 07/04/2012 12:38 AM, Damjan Jovanovic wrote:
>>> I just committed new TIFF tag names to SVN, let me know how they
>>> work for you.
>>>
>>> The best time to add the new metadata methods is before the 1.0
>>> release, since changing binary compatibility later will be harder.
>>>
>>> On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
>>> <fa...@wellfleetsoftware.com> wrote:
>>>> +1 on having the methods:
>>>>
>>>> Imaging.getExifMetadata()
>>>> Imaging.getIptcMetadata()
>>>> Imaging.getXmpMetadata()
>>>>
>>>> It is is a good idea so one can access metadata-format-specific
>>>> metadata in
>>>> a metadata-format-specific way and handling all special needs of
>>>> specific
>>>> metadata formats. These methods should work on any image resource
>>>> and throw
>>>> something like MissingFeatureException for when a metadata format
>>>> is not yet
>>>> supported for an image format or throw something like an
>>>> InvalidRequestException when a metadata format is invalid for a image
>>>> format.
>>>>
>>>> That said, there may still be some value to having a
>>>> metadata-format netrual
>>>> getMetadata() interface along the lines of the patch I submitted.
>>>> For now,
>>>> we could simply log an issue and defer it and insteda focus on your
>>>> suggestion above. That would meet my needs just fine.
>>>>
>>>> Question is do we do these changes after a formal 1.0 release or
>>>> before? May
>>>> be it is better to get stable code under current API out as 1.0 and
>>>> then
>>>> work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are
>>>> not
>>>> backward compatible and are in fact major). Or is it better to do
>>>> these
>>>> changes for the 1.0 release so consumers of the project do not get
>>>> exposed
>>>> to a big API change?
>>>>
>>>> If we can do the proposed change without a long delay then I
>>>> suggest we do
>>>> it for 1.0. If it means a long delay then I suggest we defer to 2.0.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>> On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:
>>>>> I've also considered the metadata interfaces we use, and I am not
>>>>> sure
>>>>> the current approaches are any good.
>>>>>
>>>>> Most metadata formats are designed in a way specific to that format,
>>>>> eg. some have arbitrary levels of nesting, others have a flat
>>>>> structure, etc. But most are designed to be stored in any image
>>>>> format.
>>>>>
>>>>> So instead of a Imaging.getMetadata() method that tries to unify all
>>>>> metadata into one common interface - and does so badly, because eg.
>>>>> EXIF can have nested subdirectories and this information is lost -
>>>>> maybe we should have:
>>>>> Imaging.getExifMetadata()
>>>>> Imaging.getIptcMetadata()
>>>>> Imaging.getXmpMetadata()
>>>>>
>>>>> Regards
>>>>> Damjan
>>>>>
>>>>> On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
>>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>>> Updated proposed patch with following new changes:
>>>>>>
>>>>>> Add getValue() method to nested class IImageMetadataItem. These
>>>>>> return
>>>>>> the
>>>>>> value of the item as an Object allowing for values of various
>>>>>> types to be
>>>>>> returned.
>>>>>>
>>>>>>
>>>>>> On 07/03/2012 11:01 AM, Farrukh Najmi wrote:
>>>>>>
>>>>>> Moving this thread to dev list as it seems to be more appropriate
>>>>>> there....
>>>>>>
>>>>>> Attached is a patch to the IImageMetadata.java that reflects my
>>>>>> revised
>>>>>> proposal thinking this through in conjunction with the proposed
>>>>>> solution
>>>>>> in
>>>>>> another thread...
>>>>>>
>>>>>> Add a getMetadataSpecification() method to IImageMetadata so we can
>>>>>> manage
>>>>>> the metadata specification that defines the metadata
>>>>>> Add getMetadata() to nested class IImageMetadataItem to get back
>>>>>> at the
>>>>>> parent IImageMetadata instance so we can access the metadata
>>>>>> specification
>>>>>> information managed from an IImageMetadata instance
>>>>>> Add getId(), getName(), getDescription() methods to nested class
>>>>>> IImageMetadataItem. These are the key triplet of info about the
>>>>>> metadata
>>>>>> item that is needed in my experience
>>>>>>
>>>>>> Of course implementations of these two interfaces would need to
>>>>>> also be
>>>>>> updated to support the new methods according to proposed
>>>>>> semantics. I
>>>>>> would
>>>>>> be happy to contribute in any way that I can and as requested.
>>>>>>
>>>>>> Dev team colleagues, please weigh in on the proposal. Thanks for
>>>>>> your
>>>>>> awesome work to create this project and for considering this
>>>>>> proposal.
>>>>>>
>>>>>>
>>>>
>>
>
>
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Farrukh Najmi <fa...@wellfleetsoftware.com>.
A similar change needs to be made IMHO to
org.apache.commons.imaging.formats.jpeg.iptc.IptcTypes.java
so that the enum string value is XML Property Id value instead of the
IIM mapping value.
As an example:
COUNTRY_PRIMARY_LOCATION_NAME(
101, "Country/Primary Location Name"),
would become:
COUNTRY_PRIMARY_LOCATION_NAME(
101, "Country"),
I can do this patch for you once I get a +1 to do it. Until the +1 I
will hold off as the work is tedious and time consuming.
Please let me know. Thanks.
On 07/05/2012 06:56 AM, Farrukh Najmi wrote:
>
> Hi Damjan,
>
> Confirming that your recent fix for supporting Exif FieldName looks
> good great. Thank you!
>
> When do you think you may be able to commit the changes to support the
> following metadata format-specific methods so I can provide feedback:
>
> Imaging.getExifMetadata()
> Imaging.getIptcMetadata()
> Imaging.getXmpMetadata()
>
>
>
> On 07/04/2012 12:38 AM, Damjan Jovanovic wrote:
>> I just committed new TIFF tag names to SVN, let me know how they work
>> for you.
>>
>> The best time to add the new metadata methods is before the 1.0
>> release, since changing binary compatibility later will be harder.
>>
>> On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
>> <fa...@wellfleetsoftware.com> wrote:
>>> +1 on having the methods:
>>>
>>> Imaging.getExifMetadata()
>>> Imaging.getIptcMetadata()
>>> Imaging.getXmpMetadata()
>>>
>>> It is is a good idea so one can access metadata-format-specific
>>> metadata in
>>> a metadata-format-specific way and handling all special needs of
>>> specific
>>> metadata formats. These methods should work on any image resource
>>> and throw
>>> something like MissingFeatureException for when a metadata format is
>>> not yet
>>> supported for an image format or throw something like an
>>> InvalidRequestException when a metadata format is invalid for a image
>>> format.
>>>
>>> That said, there may still be some value to having a metadata-format
>>> netrual
>>> getMetadata() interface along the lines of the patch I submitted.
>>> For now,
>>> we could simply log an issue and defer it and insteda focus on your
>>> suggestion above. That would meet my needs just fine.
>>>
>>> Question is do we do these changes after a formal 1.0 release or
>>> before? May
>>> be it is better to get stable code under current API out as 1.0 and
>>> then
>>> work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are not
>>> backward compatible and are in fact major). Or is it better to do these
>>> changes for the 1.0 release so consumers of the project do not get
>>> exposed
>>> to a big API change?
>>>
>>> If we can do the proposed change without a long delay then I suggest
>>> we do
>>> it for 1.0. If it means a long delay then I suggest we defer to 2.0.
>>>
>>> Thoughts?
>>>
>>>
>>>
>>> On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:
>>>> I've also considered the metadata interfaces we use, and I am not sure
>>>> the current approaches are any good.
>>>>
>>>> Most metadata formats are designed in a way specific to that format,
>>>> eg. some have arbitrary levels of nesting, others have a flat
>>>> structure, etc. But most are designed to be stored in any image
>>>> format.
>>>>
>>>> So instead of a Imaging.getMetadata() method that tries to unify all
>>>> metadata into one common interface - and does so badly, because eg.
>>>> EXIF can have nested subdirectories and this information is lost -
>>>> maybe we should have:
>>>> Imaging.getExifMetadata()
>>>> Imaging.getIptcMetadata()
>>>> Imaging.getXmpMetadata()
>>>>
>>>> Regards
>>>> Damjan
>>>>
>>>> On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
>>>> <fa...@wellfleetsoftware.com> wrote:
>>>>> Updated proposed patch with following new changes:
>>>>>
>>>>> Add getValue() method to nested class IImageMetadataItem. These
>>>>> return
>>>>> the
>>>>> value of the item as an Object allowing for values of various
>>>>> types to be
>>>>> returned.
>>>>>
>>>>>
>>>>> On 07/03/2012 11:01 AM, Farrukh Najmi wrote:
>>>>>
>>>>> Moving this thread to dev list as it seems to be more appropriate
>>>>> there....
>>>>>
>>>>> Attached is a patch to the IImageMetadata.java that reflects my
>>>>> revised
>>>>> proposal thinking this through in conjunction with the proposed
>>>>> solution
>>>>> in
>>>>> another thread...
>>>>>
>>>>> Add a getMetadataSpecification() method to IImageMetadata so we can
>>>>> manage
>>>>> the metadata specification that defines the metadata
>>>>> Add getMetadata() to nested class IImageMetadataItem to get back
>>>>> at the
>>>>> parent IImageMetadata instance so we can access the metadata
>>>>> specification
>>>>> information managed from an IImageMetadata instance
>>>>> Add getId(), getName(), getDescription() methods to nested class
>>>>> IImageMetadataItem. These are the key triplet of info about the
>>>>> metadata
>>>>> item that is needed in my experience
>>>>>
>>>>> Of course implementations of these two interfaces would need to
>>>>> also be
>>>>> updated to support the new methods according to proposed semantics. I
>>>>> would
>>>>> be happy to contribute in any way that I can and as requested.
>>>>>
>>>>> Dev team colleagues, please weigh in on the proposal. Thanks for your
>>>>> awesome work to create this project and for considering this
>>>>> proposal.
>>>>>
>>>>>
>>>
>
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Farrukh Najmi <fa...@wellfleetsoftware.com>.
Hi Damjan,
Confirming that your recent fix for supporting Exif FieldName looks good
great. Thank you!
When do you think you may be able to commit the changes to support the
following metadata format-specific methods so I can provide feedback:
Imaging.getExifMetadata()
Imaging.getIptcMetadata()
Imaging.getXmpMetadata()
On 07/04/2012 12:38 AM, Damjan Jovanovic wrote:
> I just committed new TIFF tag names to SVN, let me know how they work for you.
>
> The best time to add the new metadata methods is before the 1.0
> release, since changing binary compatibility later will be harder.
>
> On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
> <fa...@wellfleetsoftware.com> wrote:
>> +1 on having the methods:
>>
>> Imaging.getExifMetadata()
>> Imaging.getIptcMetadata()
>> Imaging.getXmpMetadata()
>>
>> It is is a good idea so one can access metadata-format-specific metadata in
>> a metadata-format-specific way and handling all special needs of specific
>> metadata formats. These methods should work on any image resource and throw
>> something like MissingFeatureException for when a metadata format is not yet
>> supported for an image format or throw something like an
>> InvalidRequestException when a metadata format is invalid for a image
>> format.
>>
>> That said, there may still be some value to having a metadata-format netrual
>> getMetadata() interface along the lines of the patch I submitted. For now,
>> we could simply log an issue and defer it and insteda focus on your
>> suggestion above. That would meet my needs just fine.
>>
>> Question is do we do these changes after a formal 1.0 release or before? May
>> be it is better to get stable code under current API out as 1.0 and then
>> work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are not
>> backward compatible and are in fact major). Or is it better to do these
>> changes for the 1.0 release so consumers of the project do not get exposed
>> to a big API change?
>>
>> If we can do the proposed change without a long delay then I suggest we do
>> it for 1.0. If it means a long delay then I suggest we defer to 2.0.
>>
>> Thoughts?
>>
>>
>>
>> On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:
>>> I've also considered the metadata interfaces we use, and I am not sure
>>> the current approaches are any good.
>>>
>>> Most metadata formats are designed in a way specific to that format,
>>> eg. some have arbitrary levels of nesting, others have a flat
>>> structure, etc. But most are designed to be stored in any image
>>> format.
>>>
>>> So instead of a Imaging.getMetadata() method that tries to unify all
>>> metadata into one common interface - and does so badly, because eg.
>>> EXIF can have nested subdirectories and this information is lost -
>>> maybe we should have:
>>> Imaging.getExifMetadata()
>>> Imaging.getIptcMetadata()
>>> Imaging.getXmpMetadata()
>>>
>>> Regards
>>> Damjan
>>>
>>> On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
>>> <fa...@wellfleetsoftware.com> wrote:
>>>> Updated proposed patch with following new changes:
>>>>
>>>> Add getValue() method to nested class IImageMetadataItem. These return
>>>> the
>>>> value of the item as an Object allowing for values of various types to be
>>>> returned.
>>>>
>>>>
>>>> On 07/03/2012 11:01 AM, Farrukh Najmi wrote:
>>>>
>>>> Moving this thread to dev list as it seems to be more appropriate
>>>> there....
>>>>
>>>> Attached is a patch to the IImageMetadata.java that reflects my revised
>>>> proposal thinking this through in conjunction with the proposed solution
>>>> in
>>>> another thread...
>>>>
>>>> Add a getMetadataSpecification() method to IImageMetadata so we can
>>>> manage
>>>> the metadata specification that defines the metadata
>>>> Add getMetadata() to nested class IImageMetadataItem to get back at the
>>>> parent IImageMetadata instance so we can access the metadata
>>>> specification
>>>> information managed from an IImageMetadata instance
>>>> Add getId(), getName(), getDescription() methods to nested class
>>>> IImageMetadataItem. These are the key triplet of info about the metadata
>>>> item that is needed in my experience
>>>>
>>>> Of course implementations of these two interfaces would need to also be
>>>> updated to support the new methods according to proposed semantics. I
>>>> would
>>>> be happy to contribute in any way that I can and as requested.
>>>>
>>>> Dev team colleagues, please weigh in on the proposal. Thanks for your
>>>> awesome work to create this project and for considering this proposal.
>>>>
>>>>
>>
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Damjan Jovanovic <da...@gmail.com>.
I just committed new TIFF tag names to SVN, let me know how they work for you.
The best time to add the new metadata methods is before the 1.0
release, since changing binary compatibility later will be harder.
On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
<fa...@wellfleetsoftware.com> wrote:
> +1 on having the methods:
>
> Imaging.getExifMetadata()
> Imaging.getIptcMetadata()
> Imaging.getXmpMetadata()
>
> It is is a good idea so one can access metadata-format-specific metadata in
> a metadata-format-specific way and handling all special needs of specific
> metadata formats. These methods should work on any image resource and throw
> something like MissingFeatureException for when a metadata format is not yet
> supported for an image format or throw something like an
> InvalidRequestException when a metadata format is invalid for a image
> format.
>
> That said, there may still be some value to having a metadata-format netrual
> getMetadata() interface along the lines of the patch I submitted. For now,
> we could simply log an issue and defer it and insteda focus on your
> suggestion above. That would meet my needs just fine.
>
> Question is do we do these changes after a formal 1.0 release or before? May
> be it is better to get stable code under current API out as 1.0 and then
> work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are not
> backward compatible and are in fact major). Or is it better to do these
> changes for the 1.0 release so consumers of the project do not get exposed
> to a big API change?
>
> If we can do the proposed change without a long delay then I suggest we do
> it for 1.0. If it means a long delay then I suggest we defer to 2.0.
>
> Thoughts?
>
>
>
> On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:
>>
>> I've also considered the metadata interfaces we use, and I am not sure
>> the current approaches are any good.
>>
>> Most metadata formats are designed in a way specific to that format,
>> eg. some have arbitrary levels of nesting, others have a flat
>> structure, etc. But most are designed to be stored in any image
>> format.
>>
>> So instead of a Imaging.getMetadata() method that tries to unify all
>> metadata into one common interface - and does so badly, because eg.
>> EXIF can have nested subdirectories and this information is lost -
>> maybe we should have:
>> Imaging.getExifMetadata()
>> Imaging.getIptcMetadata()
>> Imaging.getXmpMetadata()
>>
>> Regards
>> Damjan
>>
>> On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
>> <fa...@wellfleetsoftware.com> wrote:
>>>
>>> Updated proposed patch with following new changes:
>>>
>>> Add getValue() method to nested class IImageMetadataItem. These return
>>> the
>>> value of the item as an Object allowing for values of various types to be
>>> returned.
>>>
>>>
>>> On 07/03/2012 11:01 AM, Farrukh Najmi wrote:
>>>
>>> Moving this thread to dev list as it seems to be more appropriate
>>> there....
>>>
>>> Attached is a patch to the IImageMetadata.java that reflects my revised
>>> proposal thinking this through in conjunction with the proposed solution
>>> in
>>> another thread...
>>>
>>> Add a getMetadataSpecification() method to IImageMetadata so we can
>>> manage
>>> the metadata specification that defines the metadata
>>> Add getMetadata() to nested class IImageMetadataItem to get back at the
>>> parent IImageMetadata instance so we can access the metadata
>>> specification
>>> information managed from an IImageMetadata instance
>>> Add getId(), getName(), getDescription() methods to nested class
>>> IImageMetadataItem. These are the key triplet of info about the metadata
>>> item that is needed in my experience
>>>
>>> Of course implementations of these two interfaces would need to also be
>>> updated to support the new methods according to proposed semantics. I
>>> would
>>> be happy to contribute in any way that I can and as requested.
>>>
>>> Dev team colleagues, please weigh in on the proposal. Thanks for your
>>> awesome work to create this project and for considering this proposal.
>>>
>>>
>
> --
> Regards,
> Farrukh
>
> Web: http://www.wellfleetsoftware.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Farrukh Najmi <fa...@wellfleetsoftware.com>.
+1 on having the methods:
Imaging.getExifMetadata()
Imaging.getIptcMetadata()
Imaging.getXmpMetadata()
It is is a good idea so one can access metadata-format-specific metadata
in a metadata-format-specific way and handling all special needs of
specific metadata formats. These methods should work on any image
resource and throw something like MissingFeatureException for when a
metadata format is not yet supported for an image format or throw
something like an InvalidRequestException when a metadata format is
invalid for a image format.
That said, there may still be some value to having a metadata-format
netrual getMetadata() interface along the lines of the patch I
submitted. For now, we could simply log an issue and defer it and
insteda focus on your suggestion above. That would meet my needs just fine.
Question is do we do these changes after a formal 1.0 release or before?
May be it is better to get stable code under current API out as 1.0 and
then work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are
not backward compatible and are in fact major). Or is it better to do
these changes for the 1.0 release so consumers of the project do not get
exposed to a big API change?
If we can do the proposed change without a long delay then I suggest we
do it for 1.0. If it means a long delay then I suggest we defer to 2.0.
Thoughts?
On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:
> I've also considered the metadata interfaces we use, and I am not sure
> the current approaches are any good.
>
> Most metadata formats are designed in a way specific to that format,
> eg. some have arbitrary levels of nesting, others have a flat
> structure, etc. But most are designed to be stored in any image
> format.
>
> So instead of a Imaging.getMetadata() method that tries to unify all
> metadata into one common interface - and does so badly, because eg.
> EXIF can have nested subdirectories and this information is lost -
> maybe we should have:
> Imaging.getExifMetadata()
> Imaging.getIptcMetadata()
> Imaging.getXmpMetadata()
>
> Regards
> Damjan
>
> On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
> <fa...@wellfleetsoftware.com> wrote:
>> Updated proposed patch with following new changes:
>>
>> Add getValue() method to nested class IImageMetadataItem. These return the
>> value of the item as an Object allowing for values of various types to be
>> returned.
>>
>>
>> On 07/03/2012 11:01 AM, Farrukh Najmi wrote:
>>
>> Moving this thread to dev list as it seems to be more appropriate there....
>>
>> Attached is a patch to the IImageMetadata.java that reflects my revised
>> proposal thinking this through in conjunction with the proposed solution in
>> another thread...
>>
>> Add a getMetadataSpecification() method to IImageMetadata so we can manage
>> the metadata specification that defines the metadata
>> Add getMetadata() to nested class IImageMetadataItem to get back at the
>> parent IImageMetadata instance so we can access the metadata specification
>> information managed from an IImageMetadata instance
>> Add getId(), getName(), getDescription() methods to nested class
>> IImageMetadataItem. These are the key triplet of info about the metadata
>> item that is needed in my experience
>>
>> Of course implementations of these two interfaces would need to also be
>> updated to support the new methods according to proposed semantics. I would
>> be happy to contribute in any way that I can and as requested.
>>
>> Dev team colleagues, please weigh in on the proposal. Thanks for your
>> awesome work to create this project and for considering this proposal.
>>
>>
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Damjan Jovanovic <da...@gmail.com>.
I've also considered the metadata interfaces we use, and I am not sure
the current approaches are any good.
Most metadata formats are designed in a way specific to that format,
eg. some have arbitrary levels of nesting, others have a flat
structure, etc. But most are designed to be stored in any image
format.
So instead of a Imaging.getMetadata() method that tries to unify all
metadata into one common interface - and does so badly, because eg.
EXIF can have nested subdirectories and this information is lost -
maybe we should have:
Imaging.getExifMetadata()
Imaging.getIptcMetadata()
Imaging.getXmpMetadata()
Regards
Damjan
On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
<fa...@wellfleetsoftware.com> wrote:
>
> Updated proposed patch with following new changes:
>
> Add getValue() method to nested class IImageMetadataItem. These return the
> value of the item as an Object allowing for values of various types to be
> returned.
>
>
> On 07/03/2012 11:01 AM, Farrukh Najmi wrote:
>
> Moving this thread to dev list as it seems to be more appropriate there....
>
> Attached is a patch to the IImageMetadata.java that reflects my revised
> proposal thinking this through in conjunction with the proposed solution in
> another thread...
>
> Add a getMetadataSpecification() method to IImageMetadata so we can manage
> the metadata specification that defines the metadata
> Add getMetadata() to nested class IImageMetadataItem to get back at the
> parent IImageMetadata instance so we can access the metadata specification
> information managed from an IImageMetadata instance
> Add getId(), getName(), getDescription() methods to nested class
> IImageMetadataItem. These are the key triplet of info about the metadata
> item that is needed in my experience
>
> Of course implementations of these two interfaces would need to also be
> updated to support the new methods according to proposed semantics. I would
> be happy to contribute in any way that I can and as requested.
>
> Dev team colleagues, please weigh in on the proposal. Thanks for your
> awesome work to create this project and for considering this proposal.
>
> On 07/02/2012 07:12 PM, Farrukh Najmi wrote:
>
>
> Here is a proposed change to the API that would help my scenario...
>
> Modify the org.apache.commons.imaging.common.ImageMetadata$Item class to
> have the following additional methods:
>
> getMetadataSpecification() method that returns a constant String such as
> "IPTC:1.1", "EXIF:2.1", "EXIF:2.2"
> getId() method that returns a unique id as follows:
>
> For EXIF return the Field Name as in Table 3 TIFF Rev. 6.0 Attribute
> Information Used in Exif in the Exif spec.
> For IPTC return the IptcRecord..iptcType.getType()
>
> This would allow the first code pattern below to identify each item based on
> a specific metadata field defined by a specific specification.
>
> Thoughts?
>
> On 07/02/2012 06:18 PM, Farrukh Najmi wrote:
>
>
> Hi Guys,
>
> I am trying to use commons-imaging latest svn bits to write a program that
> will read standard metadata such as Exif and IPTC from images in a variety
> of image formats using code that is as image format neutral as possible. The
> goal is to store each class of metadata (e.g. Exif, IPTC, ...) in a separate
> Map where the key ide
>
>
> --
> Regards,
> Farrukh
>
> Web: http://www.wellfleetsoftware.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> ntifies a metadata attribute identifier defined by the standard and a value
> that is the metadata attribute's value.
>
> Here are two patterns I have identified for reading the metadata by looking
> at test programs and code....
>
> 1. Read metadata items without considering image format or metadata
> standard.
>
> IImageMetadata metadata = Imaging.getMetadata(is, "Oregon
> Scientific DS6639 - DSC_0307 - iptc added with irfanview.jpg");
> List<? extends IImageMetadata.IImageMetadataItem> items =
> metadata.getItems();
>
> int i=0;
> for (IImageMetadata.IImageMetadataItem iitem : items) {
> ImageMetadata.Item item = (ImageMetadata.Item)iitem;
> System.err.println("Index: " + i + " Key: " +
> item.getKeyword() + " Value: " + item.getText() + " class: " +
> iitem.getClass()); //common.ImageMetadata$Item, Tiff.TiffImageMetadata
> i++;
> }
>
>
> This is closest to what I want. The EXIF metadata is represented by
> org.apache.commons.imaging.formats.tiff.TiffImageMetadata$Item and I can get
> at the TiffField and its tagName and value (good). However, IPTC metadata is
> represented by org.apache.commons.imaging.common.ImageMetadata$Item. This
> class seems to have no link back to the
> org.apache.commons.imaging.formats.jpeg.iptc.IptcRecord and thus I cannot
> find a way to get the attribute defined by the IPTC spec under the IIM
> mapping rows.
>
>
> 2. Read Exif and IPTC separately using following metadata and image format
> specific patterns as shown below...
>
> //Read EXIF
> JpegImageMetadata metadata = (JpegImageMetadata)
> Imaging.getMetadata(is, "Oregon Scientific DS6639 - DSC_0307 - iptc added
> with irfanview.jpg");
> TiffImageMetadata exifMetadata = metadata.getExif();
> List<TiffField> fields = exifMetadata.getAllFields();
>
> int i=0;
> for (TiffField field : fields) {
> String key = field.getTagName();
> Object value = field.getValue();
> String fieldName = field.tagInfo.name;
> System.err.println("Index: " + i + " Key: " + key + ",
> Value: " + value + ", valueType: " + value.getClass());
> i++;
> }
>
> //Read IPTC
> JpegImageMetadata metadata = (JpegImageMetadata)
> Imaging.getMetadata(is, "Oregon Scientific DS6639 - DSC_0307 - iptc added
> with irfanview.jpg");
> JpegPhotoshopMetadata psMetadata = metadata.getPhotoshop();
> List oldRecords = psMetadata.photoshopApp13Data.getRecords();
>
> for (int j = 0; j < oldRecords.size(); j++) {
> IptcRecord record = (IptcRecord) oldRecords.get(j);
> System.err.println("Key: " + record.iptcType.getName() + "
> (0x"
> + Integer.toHexString(record.iptcType.getType())
> + "), value: " + record.value);
> }
>
> Above gives me all the linkage back to specification defined metadata fields
> but is less desirable because it metadata and image format specific.
>
> I feel that it would be ideal to support a generic api that is agnostic to
> metadata and image format but provides a reference back to the specification
> defined field (attribute) identifier some how.
>
> I would very much appreciate some ideas from dev team on how we could
> improve the api to support providing a reference back to a specification
> defined field in a metadata and image format neutral manner.
>
> My apologies if I am missing an obvious solution while I am getting familiar
> with the code.
>
>
>
>
> --
> Regards,
> Farrukh
>
> Web: http://www.wellfleetsoftware.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Farrukh Najmi <fa...@wellfleetsoftware.com>.
Updated proposed patch with following new changes:
* Add getValue() method to nested class IImageMetadataItem. These
return the value of the item as an Object allowing for values of
various types to be returned.
On 07/03/2012 11:01 AM, Farrukh Najmi wrote:
> Moving this thread to dev list as it seems to be more appropriate
> there....
>
> Attached is a patch to the IImageMetadata.java that reflects my
> revised proposal thinking this through in conjunction with the
> proposed solution in another
> <http://mail-archives.apache.org/mod_mbox/commons-dev/201207.mbox/ajax/%3C4FF213A5.3090600%40wellfleetsoftware.com%3E>
> thread...
>
> * Add a getMetadataSpecification() method to IImageMetadata so we
> can manage the metadata specification that defines the metadata
> * Add getMetadata() to nested class IImageMetadataItem to get back
> at the parent IImageMetadata instance so we can access the
> metadata specification information managed from an IImageMetadata
> instance
> * Add getId(), getName(), getDescription() methods to nested class
> IImageMetadataItem. These are the key triplet of info about the
> metadata item that is needed in my experience
>
> Of course implementations of these two interfaces would need to also
> be updated to support the new methods according to proposed semantics.
> I would be happy to contribute in any way that I can and as requested.
>
> Dev team colleagues, please weigh in on the proposal. Thanks for your
> awesome work to create this project and for considering this proposal.
>
> On 07/02/2012 07:12 PM, Farrukh Najmi wrote:
>>
>> Here is a proposed change to the API that would help my scenario...
>>
>> Modify the org.apache.commons.imaging.common.ImageMetadata$Item class
>> to have the following additional methods:
>>
>> * getMetadataSpecification() method that returns a constant String
>> such as "IPTC:1.1", "EXIF:2.1", "EXIF:2.2"
>> * getId() method that returns a unique id as follows:
>> o For EXIF return the Field Name as in Table 3 TIFF Rev. 6.0
>> Attribute Information Used in Exif in the Exif spec
>> <http://www.exif.org/Exif2-2.PDF>.
>> o For IPTC return the IptcRecord..iptcType.getType()
>>
>> This would allow the first code pattern below to identify each item
>> based on a specific metadata field defined by a specific specification.
>>
>> Thoughts?
>>
>> On 07/02/2012 06:18 PM, Farrukh Najmi wrote:
>>>
>>> Hi Guys,
>>>
>>> I am trying to use commons-imaging latest svn bits to write a
>>> program that will read standard metadata such as Exif and IPTC from
>>> images in a variety of image formats using code that is as image
>>> format neutral as possible. The goal is to store each class of
>>> metadata (e.g. Exif, IPTC, ...) in a separate Map where the key ide
>>>>
>>>> --
>>>> Regards,
>>>> Farrukh
>>>>
>>>> Web:http://www.wellfleetsoftware.com
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> ntifies a metadata attribute identifier defined by the standard and
>>> a value that is the metadata attribute's value.
>>>
>>> Here are two patterns I have identified for reading the metadata by
>>> looking at test programs and code....
>>>
>>> 1. Read metadata items without considering image format or metadata
>>> standard.
>>>
>>> IImageMetadata metadata = Imaging.getMetadata(is,
>>> "Oregon Scientific DS6639 - DSC_0307 - iptc added with irfanview.jpg");
>>> List<? extends IImageMetadata.IImageMetadataItem> items
>>> = metadata.getItems();
>>>
>>> int i=0;
>>> for (IImageMetadata.IImageMetadataItem iitem : items) {
>>> ImageMetadata.Item item = (ImageMetadata.Item)iitem;
>>> System.err.println("Index: " + i + " Key: " +
>>> item.getKeyword() + " Value: " + item.getText() + " class: " +
>>> iitem.getClass()); //common.ImageMetadata$Item, Tiff.TiffImageMetadata
>>> i++;
>>> }
>>>
>>>
>>> This is closest to what I want. The EXIF metadata is represented by
>>> org.apache.commons.imaging.formats.tiff.TiffImageMetadata$Item and I
>>> can get at the TiffField and its tagName and value (good). However,
>>> IPTC metadata is represented by
>>> org.apache.commons.imaging.common.ImageMetadata$Item. This class
>>> seems to have no link back to the
>>> org.apache.commons.imaging.formats.jpeg.iptc.IptcRecord and thus I
>>> cannot find a way to get the attribute defined by the IPTC spec
>>> <http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf>
>>> under the IIM mapping rows.
>>>
>>>
>>> 2. Read Exif and IPTC separately using following metadata and image
>>> format specific patterns as shown below...
>>>
>>> //Read EXIF
>>> JpegImageMetadata metadata = (JpegImageMetadata)
>>> Imaging.getMetadata(is, "Oregon Scientific DS6639 - DSC_0307 - iptc
>>> added with irfanview.jpg");
>>> TiffImageMetadata exifMetadata = metadata.getExif();
>>> List<TiffField> fields = exifMetadata.getAllFields();
>>>
>>> int i=0;
>>> for (TiffField field : fields) {
>>> String key = field.getTagName();
>>> Object value = field.getValue();
>>> String fieldName = field.tagInfo.name;
>>> System.err.println("Index: " + i + " Key: " + key +
>>> ", Value: " + value + ", valueType: " + value.getClass());
>>> i++;
>>> }
>>>
>>> //Read IPTC
>>> JpegImageMetadata metadata = (JpegImageMetadata)
>>> Imaging.getMetadata(is, "Oregon Scientific DS6639 - DSC_0307 - iptc
>>> added with irfanview.jpg");
>>> JpegPhotoshopMetadata psMetadata = metadata.getPhotoshop();
>>> List oldRecords =
>>> psMetadata.photoshopApp13Data.getRecords();
>>>
>>> for (int j = 0; j < oldRecords.size(); j++) {
>>> IptcRecord record = (IptcRecord) oldRecords.get(j);
>>> System.err.println("Key: " +
>>> record.iptcType.getName() + " (0x"
>>> +
>>> Integer.toHexString(record.iptcType.getType())
>>> + "), value: " + record.value);
>>> }
>>>
>>> Above gives me all the linkage back to specification defined
>>> metadata fields but is less desirable because it metadata and image
>>> format specific.
>>>
>>> I feel that it would be ideal to support a generic api that is
>>> agnostic to metadata and image format but provides a reference back
>>> to the specification defined field (attribute) identifier some how.
>>>
>>> I would very much appreciate some ideas from dev team on how we
>>> could improve the api to support providing a reference back to a
>>> specification defined field in a metadata and image format neutral
>>> manner.
>>>
>>> My apologies if I am missing an obvious solution while I am getting
>>> familiar with the code.
>>
>
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com
Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image
format neutral code
Posted by Farrukh Najmi <fa...@wellfleetsoftware.com>.
Moving this thread to dev list as it seems to be more appropriate there....
Attached is a patch to the IImageMetadata.java that reflects my revised
proposal thinking this through in conjunction with the proposed solution
in another
<http://mail-archives.apache.org/mod_mbox/commons-dev/201207.mbox/ajax/%3C4FF213A5.3090600%40wellfleetsoftware.com%3E>
thread...
* Add a getMetadataSpecification() method to IImageMetadata so we can
manage the metadata specification that defines the metadata
* Add getMetadata() to nested class IImageMetadataItem to get back at
the parent IImageMetadata instance so we can access the metadata
specification information managed from an IImageMetadata instance
* Add getId(), getName(), getDescription() methods to nested class
IImageMetadataItem. These are the key triplet of info about the
metadata item that is needed in my experience
Of course implementations of these two interfaces would need to also be
updated to support the new methods according to proposed semantics. I
would be happy to contribute in any way that I can and as requested.
Dev team colleagues, please weigh in on the proposal. Thanks for your
awesome work to create this project and for considering this proposal.
On 07/02/2012 07:12 PM, Farrukh Najmi wrote:
>
> Here is a proposed change to the API that would help my scenario...
>
> Modify the org.apache.commons.imaging.common.ImageMetadata$Item class
> to have the following additional methods:
>
> * getMetadataSpecification() method that returns a constant String
> such as "IPTC:1.1", "EXIF:2.1", "EXIF:2.2"
> * getId() method that returns a unique id as follows:
> o For EXIF return the Field Name as in Table 3 TIFF Rev. 6.0
> Attribute Information Used in Exif in the Exif spec
> <http://www.exif.org/Exif2-2.PDF>.
> o For IPTC return the IptcRecord..iptcType.getType()
>
> This would allow the first code pattern below to identify each item
> based on a specific metadata field defined by a specific specification.
>
> Thoughts?
>
> On 07/02/2012 06:18 PM, Farrukh Najmi wrote:
>>
>> Hi Guys,
>>
>> I am trying to use commons-imaging latest svn bits to write a program
>> that will read standard metadata such as Exif and IPTC from images in
>> a variety of image formats using code that is as image format neutral
>> as possible. The goal is to store each class of metadata (e.g. Exif,
>> IPTC, ...) in a separate Map where the key identifies a metadata
>> attribute identifier defined by the standard and a value that is the
>> metadata attribute's value.
>>
>> Here are two patterns I have identified for reading the metadata by
>> looking at test programs and code....
>>
>> 1. Read metadata items without considering image format or metadata
>> standard.
>>
>> IImageMetadata metadata = Imaging.getMetadata(is, "Oregon
>> Scientific DS6639 - DSC_0307 - iptc added with irfanview.jpg");
>> List<? extends IImageMetadata.IImageMetadataItem> items =
>> metadata.getItems();
>>
>> int i=0;
>> for (IImageMetadata.IImageMetadataItem iitem : items) {
>> ImageMetadata.Item item = (ImageMetadata.Item)iitem;
>> System.err.println("Index: " + i + " Key: " +
>> item.getKeyword() + " Value: " + item.getText() + " class: " +
>> iitem.getClass()); //common.ImageMetadata$Item, Tiff.TiffImageMetadata
>> i++;
>> }
>>
>>
>> This is closest to what I want. The EXIF metadata is represented by
>> org.apache.commons.imaging.formats.tiff.TiffImageMetadata$Item and I
>> can get at the TiffField and its tagName and value (good). However,
>> IPTC metadata is represented by
>> org.apache.commons.imaging.common.ImageMetadata$Item. This class
>> seems to have no link back to the
>> org.apache.commons.imaging.formats.jpeg.iptc.IptcRecord and thus I
>> cannot find a way to get the attribute defined by the IPTC spec
>> <http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf>
>> under the IIM mapping rows.
>>
>>
>> 2. Read Exif and IPTC separately using following metadata and image
>> format specific patterns as shown below...
>>
>> //Read EXIF
>> JpegImageMetadata metadata = (JpegImageMetadata)
>> Imaging.getMetadata(is, "Oregon Scientific DS6639 - DSC_0307 - iptc
>> added with irfanview.jpg");
>> TiffImageMetadata exifMetadata = metadata.getExif();
>> List<TiffField> fields = exifMetadata.getAllFields();
>>
>> int i=0;
>> for (TiffField field : fields) {
>> String key = field.getTagName();
>> Object value = field.getValue();
>> String fieldName = field.tagInfo.name;
>> System.err.println("Index: " + i + " Key: " + key +
>> ", Value: " + value + ", valueType: " + value.getClass());
>> i++;
>> }
>>
>> //Read IPTC
>> JpegImageMetadata metadata = (JpegImageMetadata)
>> Imaging.getMetadata(is, "Oregon Scientific DS6639 - DSC_0307 - iptc
>> added with irfanview.jpg");
>> JpegPhotoshopMetadata psMetadata = metadata.getPhotoshop();
>> List oldRecords = psMetadata.photoshopApp13Data.getRecords();
>>
>> for (int j = 0; j < oldRecords.size(); j++) {
>> IptcRecord record = (IptcRecord) oldRecords.get(j);
>> System.err.println("Key: " +
>> record.iptcType.getName() + " (0x"
>> +
>> Integer.toHexString(record.iptcType.getType())
>> + "), value: " + record.value);
>> }
>>
>> Above gives me all the linkage back to specification defined metadata
>> fields but is less desirable because it metadata and image format
>> specific.
>>
>> I feel that it would be ideal to support a generic api that is
>> agnostic to metadata and image format but provides a reference back
>> to the specification defined field (attribute) identifier some how.
>>
>> I would very much appreciate some ideas from dev team on how we could
>> improve the api to support providing a reference back to a
>> specification defined field in a metadata and image format neutral
>> manner.
>>
>> My apologies if I am missing an obvious solution while I am getting
>> familiar with the code.
>
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com