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 Tue, 03 Jul 2012 20:16:24 GMT
+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