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
<farr...@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
<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

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
<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.




--
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com

Reply via email to