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:34:47 GMT
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
>> <farrukh@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
>>>>> <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