commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Farrukh Najmi <farr...@wellfleetsoftware.com>
Subject Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image format neutral code
Date Thu, 05 Jul 2012 13:10:55 GMT
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
>>> <farrukh@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
>>>>> <farrukh@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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message