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 Fri, 06 Jul 2012 18:25:48 GMT
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
> <farrukh@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
>>>>>>>>> <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
>>>
>> 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
>>>> <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.
>>>>>
>>>>>


-- 
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com


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