Hi Farrukh +1
Thank you Damjan On Thu, Jul 5, 2012 at 3:34 PM, Farrukh Najmi <farr...@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 >>> <farr...@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 >>>>>> <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
