All,

Uploaded -- Details of IPTC Photo Metadata 2008 (w/ errata 2009-04-08)
implemented in MetaGrove File Info.

Includes:
- Example JPEG populated with IPTC Photo 2008 Metadata
- Screen shots of the IPTC Photo 2008 MetaGrove dialog (ten menus and
one readme)
- XMP packet from the example

Pound Hill Software's MetaGrove Plug-in for Adobe Photoshop supports
the two dimensional XMP arrays that are required by the IPTC Photo
Metadata 2008 schema. The schemas, vocabularies and the dialog were
created using the MetaGrove Developer application.

I invite comments.

Regards,
Carl Rambert, Pound Hill Software

I will be out of the office starting 27.05.2009 and will not return until 08.06.2009.

My mobile: +49.172.609.0984
Switch Board: +49.6151.733.6

Page 45-46 of the specification Country ISO-Code calls out that it
should be a CV-code but then has no entry for Required CV and
specifies XMP Property Type = Text.

Perhaps this should parallel the Country Code(legacy) on Page 12.

Required CV: ISO 3166-1 - 2 or 3 characters
XMP Property Type: closed choice Text

Carl

The new fields introduced in the IPTC Core schema as mentioned in
http://iptc.cms.apa.at/std/Iptc4xmpCore/1.0/documentation/Iptc4xmpCore_1.0-doc-C\
panelsUserGuide_13.pdf

Creator's Contact Info:City
Creator's Contact Info:Country
Creator's Contact Info:Address
Creator's Contact Info: Postal Code
Creator's Contact Info:State/Province
Creator's Contact Info:Email(s)
Creator's Contact Info:Phone(s)
Creator's Contact Info:WebURL(s)
ISO Country Code
Intellectual genre
Location
Rights Usage Terms
Subject Code
IPTC Scene

We need the field Ids of these fields to read contents from id3 library, eg
$iptc['2#120'] = "caption"

But I can't find the field ids for these new fields. Any helps appreciated!

Michael,

A questions / comments on erratum 1:
Since 1.2.0, the PLUS schema has indeed a property called "Image Supplier Image
ID". See: http://ns.useplus.org/LDF/ldf-XMPSpecification#ImageSupplierImageID

Hans Fremuth
Metability Software
www.metabilitysoftware.com
"Know Your Files".

Sean McCormack released this shocker this morning.....

http://lightroom-blog.com/2009/04/lightroom-24-with-video-support.html

Read carefully!

David

--
David Riecks  (that's "i" before "e", but the "e" is silent)
Need Keywords for your database? Get the Controlled Vocabulary Solution
http://controlledvocabulary.com/products/ support for a dozen of the
most popular imaging applications from Adobe Bridge to Photo Mechanic.

At 11:45 AM 3/28/2009, Anand wrote:
>Now it works fine in photo shop and other software, but only in one
>software the keywords are not getting split, they are shown in one
>row only i.e. "Keyword1 ; keyword 2; keyword 3" and when i remove
>the " (quotes) the keywords gets split properly.

Anand:

Most applications (with the exception of photoshop) only use the
comma "," as a separator between keyword values.

In photoshop you can paste in a comma, semicolon, or even hard return
and it will understand that each of these are separate values.
However, photoshop is the exception in this instance.

I would recommend the use of the comma and see if that makes it so
your application works for all this problem application as well as others.

David

--
David Riecks  (that's "i" before "e", but the "e" is silent)
Need Keywords for your database? Get the Controlled Vocabulary Solution
http://controlledvocabulary.com/products/ support for a dozen of the
most popular imaging applications from Adobe Bridge to Photo Mechanic.

Hi,
I have developed an web application for my cleint which accepts the photographs
from diferent sources, the application write the IPTC data to the image file on
the fly, when the image file is uploaded to the server. User have IPTC data
template creation facility so that user can apply same IPTC data to all the
files on one go. Now, i am facing a small issue that while adding the keywords.
I am adding the multiple keywords and separating them by ; (semi-colon) . Now it
works fine in photo shop and other software, but only in one software the
keywords are not getting split, they are shown in one row only i.e. "Keyword1 ;
keyword 2; keyword 3" and when i remove the " (quotes) the keywords gets split
properly.

I know this is a specific software related issue, but if someone has exp. it
before such issue, then it shall be helpful for me. Please let me know if you
have some tips for fixing it. The web application is developed in PHP/MySQL

Regards,
Anand

I seem to have trouble reconciling which metadata fields pertain to the physical image artifact (negative, slide, print) and which apply to the scan & file I have created.

In my situation, who is the `creator'?  Who is the `author'?  Who is the `source'?  My guess is that I am the creator of the scanned image, but that my father is the source.  Is this correct?

I am not sure if the person who scans an existing image gets any particular credit in the metadata fields, unless they are also the photographer or owner.  Do they?

Suppose that I scan some artwork done by my aunt: who is the creator in this case?  And in a more complicated case, where I scan a print belonging to a cousin, but originally owned by my grandfather, is there a correct way to describe that situation in the authorship/source metadata fields?

--
David Riecks  (that's "i" before "e", but the "e" is silent)
Need Keywords for your database? Get the Controlled Vocabulary Solution
http://controlledvocabulary.com/products/ support for a dozen of the
most popular imaging applications from Adobe Bridge to Photo Mechanic.

I am an amateur genealogist, researching and archiving my own
family's history.  I have been scanning negatives, slides, and prints
taken by various family members.  Now I would like to apply metadata
information to these image files.  I want someone viewing these files
to know not only who and what is in the image, but also who took the
photograph (my late father, for instance) and who scanned it
and `owns' it now (me).

I seem to have trouble reconciling which metadata fields pertain to
the physical image artifact (negative, slide, print) and which apply
to the scan & file I have created.   In my situation, who is
the `creator'?  Who is the `author'?  Who is the `source'?  My guess
is that I am the creator of the scanned image, but that my father is
the source.  Is this correct?

I am not sure if the person who scans an existing image gets any
particular credit in the metadata fields, unless they are also the
photographer or owner.  Do they? Suppose that I scan some artwork
done by my aunt: who is the creator in this case?  And in a more
complicated case, where I scan a print belonging to a cousin, but
originally owned by my grandfather, is there a correct way to
describe that situation in the authorship/source metadata fields?

Any thoughts on the matter are appreciated!

Carl,

Michael has an excellent point here. Once your information is in
UTF-8, there is no more need to carry along character set information.
  For legacy support, your application can read 1:90 before updating
the IIM block and use the appropriate character set (instead of the
system set); this preserves the legacy data.

Hans Fremuth
Metability Software

> On 18 Jul 2008 at 15:16, Carl Rambert wrote:
> > E) 1:90 Coded Character Set  -- IIM has a rich set of choices for
> > this property. Unfortunately, the (typical) absence of this metadata
> > property means "default system character set" which varies on
> > different platforms. XMP is only implemented in UTF-8. The platform
> > interoperability benefit that XMP offers is an important motivation
> > for defining this schema. It warrants mention in the introduction.
>
> Hm, I don't get the idea of this comment: 1:90 is not included into
the XMP schema as it
> completely pointless: the character encoding of an XMP packet has to
follow the XMP rules
> which are - as you say - "use UTF-8".
> >

On 21 Jul 2008 at 8:46, Carl Rambert wrote:

>
> Responses begin with **
>
> On Jul 21, 2008, at 12:10 AM, Michael Steidl (IPTC) wrote:
>
> first: this is not a draft, IIM Schema for XMP is an approved standard!
> ** The cover page top line reads: "IPTC Standard Draft" and your announcement
e-mail invited
> comments.

Sorry indeed, we have uploaded the outdated draft. This file was deleted and
replaced by
the correct file
http://www.iptc.org/std/IIM/4.1/specification/IPTC-IIM-Schema4XMP-1.0-
spec_1.pdf

Michael

==================================================
Sent by:
Michael Steidl
Managing Director of IPTC <mdirector@...>
International Press Telecommunications Council
Working to improve the efficiency of News exchange.
Visit our Web Site at  http://www.iptc.org

Group:

sorry, we have uploaded an outdated draft file of the IPTC standard "IIM Schema
for XMP
1.0" - the correct document is:

http://www.iptc.org/std/IIM/4.1/specification/IPTC-IIM-Schema4XMP-1.0-spec_1.pdf

and the draft file was withdrawn.

Regards

Michael

==================================================
Sent by:
Michael Steidl
Managing Director of IPTC <mdirector@...>
International Press Telecommunications Council
Working to improve the efficiency of News exchange.
Visit our Web Site at  http://www.iptc.org

Carl

first: this is not a draft, IIM Schema for XMP is an approved standard!

see more below ..

On 18 Jul 2008 at 15:16, Carl Rambert wrote:

> A) Three IIM fields 2:10 Urgency, 2:15 Category, and 2:20
> Supplemental Category are represented in, and synchronized with,
> photoshop:Urgency, photoshop:Category, and
> photoshop:SupplementalCategories by Adobe today, even though they
> were not adopted in the approved IPTC Core schema for XMP. They are
> listed as deprecated. But they are "still synchronized with the XMP
> property", ... "hence available for future use -- but outside the
> IPTC Core."
>
> If the IPTC use definitions are consistent with these photoshop
> fields, then might it be prudent to specify the photoshop namespace
> fields instead of defining three new Iptc4xmpIIM namespace fields?
>
> At least the implementation note for each should make reference to
> this past assignment in the photoshop namespace.

We were aware but: a) there three fields are not in the IPTC Core and the goal
of this "IIM
Schema" is to map all IIM datasets which are not in the IPTC Core and b) as
anybody is free
to define a XMP property and to map IIM Dataset we decided not trying to reflect
XMP
properties outside the IPTC Core.

Ok, but we should add a note to make this clear in the document.

>
>
> B) Content Location - Since alignment of Code and Name is required in
> the IIM implementation, I suggest that this dictates an XMP bag array
> structure to maintain the alignment.
>
> Iptc4xmpIIM:ContentLocation  bag ContentLocationDetails (structure)
>
> ContentLocationDetails (structure)
>  Code Text
>  Name Text

The goal of the "IIM Schema for XMP" is not to add any functionality over IIM. I
agree to your
design thoughts but as no sub-structure for Code/Name exists in IIM no such
structure was
adopted for the XMP schema

>
>
> C) Reference - 2:45, 47, and 50 are repeatable in "sequential
> triplets" in IIM. I suggest that this dictates an XMP seq array
> structure to maintain the alignment of the triplets.
>
> Iptc4xmpIIM:Reference seq ReferenceDetails (structure)
>
> ReferenceDetails (structure)
>  Service Text
>  Date Date
>  Number Text
>

See my note above, the same applie here.

>
> D) XMP property id choices - The cryptic XMP property id "IIM2-003"
> for "2:003 Object Type Reference" , for example, runs counter to the
> practice used in IPTC Core where the XMP property id "SubjectCode"
> was used for "2:012 Subject Reference". I suggest that the property
> id be formulated from the property name, not its IIM encoding
> assignment.

As said in the introduction to the specification document the goal was to
provide a simple
expression of IIM fields in XMP. For that reason we adopted a simple naming
convention,
the more as some IIM dataset name are pretty lenghty.

>
>
> E) 1:90 Coded Character Set  -- IIM has a rich set of choices for
> this property. Unfortunately, the (typical) absence of this metadata
> property means "default system character set" which varies on
> different platforms. XMP is only implemented in UTF-8. The platform
> interoperability benefit that XMP offers is an important motivation
> for defining this schema. It warrants mention in the introduction.

Hm, I don't get the idea of this comment: 1:90 is not included into the XMP
schema as it
completely pointless: the character encoding of an XMP packet has to follow the
XMP rules
which are - as you say - "use UTF-8".
>
> F) Appendix: Mapping of all IIM properties -- It would be useful if
> the twenty IPTC IIM properties that are missing from this table were
> added with "Not mapped, not relevant"

Ok, we could a this in an updated document revision.

Michael

==================================================
Sent by:
Michael Steidl
Managing Director of IPTC <mdirector@...>
International Press Telecommunications Council
Working to improve the efficiency of News exchange.
Visit our Web Site at  http://www.iptc.org

A) Three IIM fields 2:10 Urgency, 2:15 Category, and 2:20
Supplemental Category are represented in, and synchronized with,
photoshop:Urgency, photoshop:Category, and
photoshop:SupplementalCategories by Adobe today, even though they
were not adopted in the approved IPTC Core schema for XMP. They are
listed as deprecated. But they are "still synchronized with the XMP
property", ... "hence available for future use -- but outside the
IPTC Core."

If the IPTC use definitions are consistent with these photoshop
fields, then might it be prudent to specify the photoshop namespace
fields instead of defining three new Iptc4xmpIIM namespace fields?

At least the implementation note for each should make reference to
this past assignment in the photoshop namespace.


B) Content Location - Since alignment of Code and Name is required in
the IIM implementation, I suggest that this dictates an XMP bag array
structure to maintain the alignment.

Iptc4xmpIIM:ContentLocation  bag ContentLocationDetails (structure)

ContentLocationDetails (structure)
	 Code Text
	 Name Text


C) Reference - 2:45, 47, and 50 are repeatable in "sequential
triplets" in IIM. I suggest that this dictates an XMP seq array
structure to maintain the alignment of the triplets.

Iptc4xmpIIM:Reference seq ReferenceDetails (structure)

ReferenceDetails (structure)
	 Service Text
	 Date Date
	 Number Text


D) XMP property id choices - The cryptic XMP property id "IIM2-003"
for "2:003 Object Type Reference" , for example, runs counter to the
practice used in IPTC Core where the XMP property id "SubjectCode"
was used for "2:012 Subject Reference". I suggest that the property
id be formulated from the property name, not its IIM encoding
assignment.


E) 1:90 Coded Character Set  -- IIM has a rich set of choices for
this property. Unfortunately, the (typical) absence of this metadata
property means "default system character set" which varies on
different platforms. XMP is only implemented in UTF-8. The platform
interoperability benefit that XMP offers is an important motivation
for defining this schema. It warrants mention in the introduction.

F) Appendix: Mapping of all IIM properties -- It would be useful if
the twenty IPTC IIM properties that are missing from this table were
added with "Not mapped, not relevant"