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
