I have no idea. I never wrote any of the IPTC code.

On Thu, Jul 5, 2012 at 3:10 PM, Farrukh Najmi
<farr...@wellfleetsoftware.com> wrote:
> 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
>>>> <farr...@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
>>>>>> <farr...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to