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 19:20:34 GMT
Hi Farrukh

+1

Thank you
Damjan

On Thu, Jul 5, 2012 at 3:34 PM, Farrukh Najmi
<farrukh@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
>>> <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


Mime
View raw message