option to put nearest place name to a image caption

8 views
Skip to first unread message

bernis

unread,
Jun 19, 2007, 4:11:52 AM6/19/07
to gpicsync
Whoud there be a chance to introduce an *option* to write a nearest
place name into *IPTC caption* (besides IPTC keywords)

Right now gpicsync includes something like this into IPTC keywords:

Lower Shotover
New Zealand
2.31 Km to Lower Shotover in New Zealand

geotagged
geo:lat=-45.002405
geo:lon=168.754972

Could the first (or combination of first and second) line be put into
image caption? For example Picasa (and i believe also other image
organizers) allow to display image caption under each thumbnail in
gallery view. It would make it much easier to know where the picture
was taken ...

Thank you
Marek

francois...@gmail.com

unread,
Jun 19, 2007, 2:51:19 PM6/19/07
to gpicsync
Hello,

Yes this is a good idea. I will add it soon (I'll probaly make a
release this week-end).

Thanks

francois

francois...@gmail.com

unread,
Jun 23, 2007, 1:46:04 PM6/23/07
to gpicsync
Ok this is now available in version 1.05 (see changelog on the
website)

francois

On Jun 19, 8:51 pm, "francois.schn...@gmail.com"

bernis

unread,
Jun 25, 2007, 4:43:07 PM6/25/07
to gpicsync
Thank you for adding it. Still though, if i can dare ... i think for
purpose of showing captions under the thumbnails, the textual
information (ie place names) is more suiting than just "some
numbers" (ie geolocation). For *me*, it would be better if it showed
the "near:" information in the first line. I understand that others
may prefer different order or just selected info.

To get everyone satisfied I think best implementation would be
introducing variables, for example prefixed by a "%" sign. Instead of
simple

geoname_caption=False

user could enter his own variables with his own formatting. for
example current format of

Latitude/Longitude=(48.444433 , 8.015170 )
Near Geonames: Hinterohlsbach Baden-Württemberg Germany (Map link)

would be transcribed in conf file as:

geoname_caption=Latitude/Longitude=(%latitude , %longitude )\nNear
Geonames: %name (%link)

where %latitude, %longitude, %name, %link (and possibly others that
are available) would get replaced by actual information, \n would get
replaced by newline character, possibly \t by Tab character

anyway, thanks for current implementation also ... i think i can find
the way to erase the info i don't want to see in captions myself

Marek

On Jun 23, 7:46 pm, "francois.schn...@gmail.com"

Jul

unread,
Jun 30, 2007, 4:59:37 AM6/30/07
to gpicsync
Hello and thanks for this promising software!


I am very happy to see the inclusion of geographic data in the
metadata, but I have a different view on its insertion in IIM/IPTC or
XMP/IPTC Core metadata. IMHO, it is a shame to use the keywords or the
caption fields for data that fit perfectly in specific fields.
According to the spec on http://www.iptc.org/IIM/, here are the
characteristics of these fields:

2:25 Keywords
Repeatable, maximum 64 octets, consisting of graphic
characters plus spaces.
Used to indicate specific information retrieval words.
Each keyword uses a single Keywords DataSet. Multiple
keywords use multiple Keywords DataSets.
It is expected that a provider of various types of data
that are related in subject matter uses the same keyword, enabling the
receiving system or subsystems to search across all types
of data for related material.
Examples:
"GRAND PRIX"
"AUTO"


2:120 Caption/Abstract
Not repeatable, maximum of 2000 octets, consisting of
graphic characters plus carriage-returns, linefeeds and spaces.
A textual description of the objectdata, particularly
used where the object is not text.

As you can see, keywords are more appropriate for a tag description
system, which is user specific, and the caption should/can be written
by a human for direct publication. I'm not sure whether the solution
in the new version would replace an existing caption, but this would
be very problematic.

On the other hand, the specification offers specific fields for
places' description:

2:90 City
Not repeatable, maximum 32 octets, consisting of graphic
characters plus spaces.
Identifies city of objectdata origin according to guidelines
established by the provider.
Examples:
"Zürich"
"Milano"
"New York"

2:95 Province/State
Not repeatable, maximum 32 octets, consisting of
graphic characters plus spaces.
Identifies Province/State of origin according to
guidelines established by the provider.
Examples:
"WA"
"Sussex"
"Baden-Württenberg"

2:101 Country/ Primary Location Name
Not repeatable, maximum 64 octets, consisting of
graphic characters plus spaces.

Provides full, publishable, name of the country/primary
location where the intellectual property of the object data was
created,
according to guidelines of the provider.


IMHO, if you need the geographical info to appear under the thumbnails
in your photo app, you should try to change the displayed fields,
rather than putting the info in caption when it belongs somewhere
else... I know that Imatch allows this.

Of course, the IIM spec being deprecated, it would be great if this
data could be also written in XMP ( spec available on http://www.iptc.org/IPTC4XMP/
), which has the same fields...

Thanks for reading!

Jul

francois schnell

unread,
Jun 30, 2007, 6:03:56 PM6/30/07
to gpic...@googlegroups.com
Hello Julien and thanks for your detailed feedback.

On 6/30/07, Jul <julien...@wanadoo.fr> wrote:

> IMHO, it is a shame to use the keywords or the
> caption fields for data that fit perfectly in specific fields.

Like a lot of people I'm a Flickr user, Flickr takes keywords
metadata and transforms them in tags. It maybe takes also the specific
fields: I'll have to test.

Flickr also takes the caption field and put this content in the
comment part under the picture. I find it's very useful to have it as
an *option* as proposed by Bernis (a summarize directly in the picture
comments).

> As you can see, keywords are more appropriate for a tag description
> system, which is user specific,

That's probably why Flickr transforms them also as tags.

> and the caption should/can be written
> by a human for direct publication.

My experience is that few people (at least me) have the time to
comment the batch of photos they took during their day trip (giving a
title is already difficult...) so the automatic caption feature is
there for that as an *option*. Obviously nothing is written if the
"add geonames and geotagged" option is left unchecked in the interface
(and even so it is possible to disable the specific caption summarize
feature in the configuration file).

>I'm not sure whether the solution
> in the new version would replace an existing caption,

Yes it would replace it (otherwise if you decide to re-sync you'll
have two summarize).

> but this would
> be very problematic.
>

By default a backup of the original pictures is automatically made, If
you don't have already some back-up I strongly advise *not* to take
off this option so you can always come back to the originals if you
wish.

> On the other hand, the specification offers specific fields for
> places' description:
>
> 2:90 City
> Not repeatable, maximum 32 octets, consisting of graphic
> characters plus spaces.
> Identifies city of objectdata origin according to guidelines
> established by the provider.
> Examples:
> "Zürich"
> "Milano"
> "New York"
>

It doesn't look like I have the nearest city as a possible output of
the Geonames. I'll have to see if I can have it in another way
(analyzing population data, decide over which number it qualifies as a
city, etc).

> IMHO, if you need the geographical info to appear under the thumbnails
> in your photo app, you should try to change the displayed fields,
> rather than putting the info in caption when it belongs somewhere
> else...

I don't *need* anything, I don't use most of the feature request I add
in my evenings but I'm please to help if possible...

I'll see what I can do for the specific fields and also XMP that
someone else mentioned (it looks indeed very interesting)

> Of course, the IIM spec being deprecated, it would be great if this
> data could be also written in XMP ( spec available on http://www.iptc.org/IPTC4XMP/
> ), which has the same fields...
>
> Thanks for reading!

You're welcome and thanks for your detailed feedback.

francois

>
> Jul
>
>
> >
>

Reply all
Reply to author
Forward
0 new messages