commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <damjan....@gmail.com>
Subject Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image format neutral code
Date Thu, 05 Jul 2012 13:16:28 GMT
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
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message