XMP to solve tags name and Tags Path record in pictures metadata...

[Gilles Caulier-4]

Hi all,

Like it have been reported in this room more than one time in the pass, especially by Daniel Bauer, we have a problem to store the digiKam tags in pictures metadata.

*** THE PASS ***

digiKam from KDE3 branch only support IPTC has user friendly photograph metadata. IPTC/IIM to be more precise, only support officialy non UTF-8 characters encoding and have a lots of restriction about strings size to embed in metadata.

digiKam from KDE3 branch only store Tags Path list as IPTC keywords (ASCII + 64 char size). The tag name is never saved as well somewhere.
To be clear a Tags Path is the list of path to describe Tags assigned to a picture. For example :

Places/pyrénées
gilles/adrien
gilles/adrien/testphoto
Dynax 5D
Places/pyrénées/pic du midi
Tests Pictures/holidays

This way is used to restore a picture tags tree on database during import (like comments, rating, date).

But this way provide a problem when you export a picture to flickr for ex, when the IPTC keywords are interpreted as well like tag item. The whole path name will be used as Flickr tag name.

*** THE FUTURE ***

Now, with digiKam for KDE4, we support XMP !

I have solved this issue in my computer to store the all Tags Path in a dedicaced Xmp namespace named... digiKam.

The Tag name will be store in a standard Xmp tag (not listed in example below, because it's not yet implemented in my computer (:=))), and the Tags Path list in a private Xmp tag (see below). There is a screenshot of digiKam running with this issue :

http://digikam3rdparty.free.fr/Screenshots/digikamKDE4_11.png

The Xmp resume is given below :

File name: photo-000048.jpg (XMP Schema)

>>> xmp <<<
Create Date : 2006:12:29 11:36:26
Creator Tool : digiKam-0.10.0-svn
Metadata Date : 2006:12:29 11:36:26
Modify Date : 2006:12:29 11:36:26
Rating : 3

>>> dc <<<
Description : Photo taken at "Pic du Midi"

>>> digiKam <<<
TagsList : Places/pyrénées, gilles/adrien, gilles/adrien/testphoto, Dynax 5D, Places/pyrénées/pic du midi, Tests Pictures/hollidays

>>> exif <<<
DateTimeOriginal : 2006:12:29 11:36:26
PixelXDimension : 3016
PixelYDimension : 2008
UserComment : Photo taken at "Pic du Midi"

>>> photoshop <<<
DateCreated : 2006:12:29 11:36:26

>>> tiff <<<
ImageLength : 2008
ImageWidth : 3016
Make : KONICA MINOLTA
Model : DYNAX 5D

And the raw Xmp data are :

<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 4.1.1">
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns# ">
  <rdf:Description rdf:about=""
    xmlns:xap="http://ns.adobe.com/xap/1.0/"
    xmlns:tiff=" http://ns.adobe.com/tiff/1.0/"
    xmlns:exif="http://ns.adobe.com/exif/1.0/"
    xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/ "
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:digiKam="http://www.digikam.org/"
   xap:CreatorTool=" digiKam-0.10.0-svn"
   xap:ModifyDate="2006:12:29 11:36:26"
   xap:CreateDate="2006:12:29 11:36:26"
   xap:MetadataDate="2006:12:29 11:36:26"
   xap:Rating="3"
   tiff:ImageWidth="3016"
   tiff:ImageLength="2008"
   tiff:Make="KONICA MINOLTA "
   tiff:Model="DYNAX 5D"
   exif:PixelXDimension="3016"
   exif:PixelYDimension="2008"
   exif:DateTimeOriginal="2006:12:29 11:36:26"
   photoshop:DateCreated="2006:12:29 11:36:26">
   <exif:UserComment>
    <rdf:Alt>
     <rdf:li xml:lang="x-default">Photo taken at "Pic du Midi"</rdf:li>
    </rdf:Alt>
   </exif:UserComment>
   <dc:Description>
    <rdf:Alt>
     <rdf:li xml:lang="x-default">Photo taken at "Pic du Midi"</rdf:li>
    </rdf:Alt>
   </dc:Description>
   <digiKam:TagsList>
    <rdf:Seq>
     <rdf:li>Places/pyrénées</rdf:li>
     <rdf:li>gilles/adrien</rdf:li>
     <rdf:li>gilles/adrien/testphoto</rdf:li>
     <rdf:li>Dynax 5D</rdf:li>
     <rdf:li>Places/pyrénées/pic du midi</rdf:li>
     <rdf:li>Tests Pictures/hollidays</rdf:li>
    </rdf:Seq>
   </digiKam:TagsList>
  </rdf:Description>
 </rdf:RDF>
</x:xmpmeta>

As Xmp use UTF-8 endoding nothing is lost ! Also, the strings size are not limited ! The only limitation (for JPEG only) is the JFIF APP1 section used to store Xmp packet wich is limited to... 64Kb (PNG chunk and TIFF tag don't have this limitation.)

Nota : With the new future Database structure, we will store certainly more private informations in Xmp digiKam namespace... Marcel, we can do what we want (:=))) Xmp rock...

But i have a question about how to save the a tag path. Currently the separator is a '/'. This can be a problem if user use this character in a tag name because it will break the tags tree in a future import (backup/restore). If somebody has an alternative to prevent this problem, let's me hear...

Thanks in advance for you constructive remarks...

Gilles




_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Dnia poniedziałek 01 październik 2007, Gilles Caulier napisał:
>     xmlns:xap="http://ns.adobe.com/xap/1.0/"
>     xmlns:tiff="http://ns.adobe.com/tiff/1.0/"
>     xmlns:exif="http://ns.adobe.com/exif/1.0/"
>     xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/"
>     xmlns:dc="http://purl.org/dc/elements/1.1/"
>     xmlns:digiKam="http://www.digikam.org/"

Shouldn't path be more precise?

>
> As Xmp use UTF-8 endoding nothing is lost ! Also, the strings size are
> not limited ! The only limitation (for JPEG only) is the JFIF APP1
> section used to store Xmp packet wich is limited to... 64Kb (PNG chunk
> and TIFF tag don't have this limitation.)
>
> Nota : With the new future Database structure, we will store certainly
> more private informations in Xmp digiKam namespace... Marcel, we can do
> what we want (:=))) Xmp rock...

Future looks very promising :)
>
> But i have a question about how to save the a tag path. Currently the
> separator is a '/'. This can be a problem if user use this character in
> a tag name because it will break the tags tree in a future import
> (backup/restore). If somebody has an alternative to prevent this
> problem, let's me hear...
>
> Thanks in advance for you constructive remarks...

Maybe some "phishing"?

Unicode provides several types of slash, among them:

2044 ??? FRACTION SLASH
2215 ??? DIVISION SLASH

Comparing to well known solidus:

002F / SOLIDUS

Since XMP fully supports utf-8 we could use them. But there is one big
problem (as seen above): we may be not sure if user has font with proper
glyphs. Of course it is possible to do some display time substitute but
with that it would be probably better to use some special sequence of
chars, beginning eg with :: and ending with {%this is digikam tags path
separator%} :)

Well, after a moment of thinking... why stop at phishing-like solutions?
Just use real arrows:

279D ??? TRIANGLE-HEADED RIGHTWARDS ARROW

I put it in some random string in libksirtet.po and works quite nice
on my system.  While I am working on KDE from SVN (3.5 branch), and Qt
3.4.3 the rest of my system is 2 years old - including fonts.

If you prefer good old ASCII:

:: - geek friendly, may be not so understandable for "masses"
\  - I hate this Win-path look ;)
|  - hmm, not bad but IMO suggests equality of terms on both sides
>  - risky

Feature wish: auto synchronisation of appropriate  digiKam tags with
more common XMP schemas like DC, or IPTC Core.

m.


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/10/1, Mikolaj Machowski <[hidden email]>:

Dnia poniedziałek 01 październik 2007, Gilles Caulier napisał:
>     xmlns:xap="http://ns.adobe.com/xap/1.0/"
>     xmlns:tiff=" http://ns.adobe.com/tiff/1.0/"
>     xmlns:exif="http://ns.adobe.com/exif/1.0/"
>     xmlns:photoshop=" http://ns.adobe.com/photoshop/1.0/"
>     xmlns:dc="http://purl.org/dc/elements/1.1/"
>     xmlns:digiKam=" http://www.digikam.org/"

Shouldn't path be more precise?

Excepted for digikam.org, where we can host a dedicaced page where users can found the descrition of the provate schema, all others are official and provided by specifications from adobe. For all request please mail to Adobe support (:=)))
 

>
> As Xmp use UTF-8 endoding nothing is lost ! Also, the strings size are
> not limited ! The only limitation (for JPEG only) is the JFIF APP1
> section used to store Xmp packet wich is limited to... 64Kb (PNG chunk
> and TIFF tag don't have this limitation.)
>
> Nota : With the new future Database structure, we will store certainly
> more private informations in Xmp digiKam namespace... Marcel, we can do
> what we want (:=))) Xmp rock...

Future looks very promising :)
>
> But i have a question about how to save the a tag path. Currently the
> separator is a '/'. This can be a problem if user use this character in
> a tag name because it will break the tags tree in a future import
> (backup/restore). If somebody has an alternative to prevent this
> problem, let's me hear...
>
> Thanks in advance for you constructive remarks...

Maybe some "phishing"?

Unicode provides several types of slash, among them:

2044    ???     FRACTION SLASH
2215    ???     DIVISION SLASH

This can be fine.
 

Comparing to well known solidus:

002F    /       SOLIDUS

Since XMP fully supports utf-8 we could use them. But there is one big
problem (as seen above): we may be not sure if user has font with proper
glyphs. Of course it is possible to do some display time substitute but
with that it would be probably better to use some special sequence of
chars, beginning eg with :: and ending with {%this is digikam tags path
separator%} :)

no; the separator is never displayed somewhere in digiKam it used internally to "separate" all branches of the Tags Album treeview. In fact the right separator char must be used to not be confused with the real text (Tag names)
 

Well, after a moment of thinking... why stop at phishing-like solutions?
Just use real arrows:

279D    ???     TRIANGLE-HEADED RIGHTWARDS ARROW

I put it in some random string in libksirtet.po and works quite nice
on my system.  While I am working on KDE from SVN (3.5 branch), and Qt
3.4.3 the rest of my system is 2 years old - including fonts.

If you prefer good old ASCII:

:: - geek friendly, may be not so understandable for "masses"

I love this one. It's like C++ namespace. I think it's not used with natural languages. Someone can confirm ?
 

\  - I hate this Win-path look ;)

me too

|  - hmm, not bad but IMO suggests equality of terms on both sides

yes

>  - risky

yes

Feature wish: auto synchronisation of appropriate  digiKam tags with
more common XMP schemas like DC, or IPTC Core.

Already don in svn (:=))) Just missing 2 methods to sync Exif/Iptc with Xmp, because Xmp can host all standard Exif/Iptc tags.

The only tags witch cann ot be sync is makernote. A possible solution is to host markernotes byte array as binary string in a dedicaced Xmp tag. but it doesn't exist in norm. The way to save markernot in Xmp is important, especially with TIFF file format. libtiff is weird to handle/manage all Exif tags. When we convert a RAW file to TIFF, all Exif/Markernotes tags diseapear. Until than Exiv2 support tiff writing mode, this can be an alternative...

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Dnia poniedziałek 01 październik 2007, Gilles Caulier napisał:

> 2007/10/1, Mikolaj Machowski <[hidden email]>:
> > Dnia poniedziałek 01 październik 2007, Gilles Caulier napisał:
> > >     xmlns:dc="http://purl.org/dc/elements/1.1/"
> > >     xmlns:digiKam="http://www.digikam.org/"
> >
> > Shouldn't path be more precise?
> Excepted for digikam.org, where we can host a dedicaced page where users
> can found the descrition of the provate schema, all others are official
> and provided by specifications from adobe. For all request please mail
> to Adobe support (:=)))

Well, I was commenting on digikam.org,  the  rest was left as comparison
(all the 1.0, 1.1 ;)

> > > But i have a question about how to save the a tag path. Currently
> > > the separator is a '/'. This can be a problem if user use this
> > > character in a tag name because it will break the tags tree in a
> > > future import (backup/restore). If somebody has an alternative to
> > > prevent this problem, let's me hear...
> > >
> > > Thanks in advance for you constructive remarks...
> >
> > Maybe some "phishing"?
> >
> > Unicode provides several types of slash, among them:
> >
> > 2044    ???     FRACTION SLASH
> > 2215    ???     DIVISION SLASH
>
> This can be fine.

Hmm. See below.

>
> Comparing to well known solidus:
> > 002F    /       SOLIDUS
> >
> > Since XMP fully supports utf-8 we could use them. But there is one big
> > problem (as seen above): we may be not sure if user has font with
> > proper glyphs. Of course it is possible to do some display time
> > substitute but with that it would be probably better to use some
> > special sequence of chars, beginning eg with :: and ending with {%this
> > is digikam tags path separator%} :)
>
> no; the separator is never displayed somewhere in digiKam it used
> internally to "separate" all branches of the Tags Album treeview. In
> fact the right separator char must be used to not be confused with the
> real text (Tag names)

In that case it is probably better use really different path separator
(as arrow below) or just plain ASCII where :: seems favorite :)

> > Well, after a moment of thinking... why stop at phishing-like
> > solutions? Just use real arrows:
> >
> > 279D    ???     TRIANGLE-HEADED RIGHTWARDS ARROW
> >
> > I put it in some random string in libksirtet.po and works quite nice
> > on my system.  While I am working on KDE from SVN (3.5 branch), and Qt
> > 3.4.3 the rest of my system is 2 years old - including fonts.
> >
> > If you prefer good old ASCII:
> > :: - geek friendly, may be not so understandable for "masses"
>
> I love this one. It's like C++ namespace. I think it's not used with
> natural languages. Someone can confirm ?

>> Feature wish: auto synchronisation of appropriate  digiKam tags with
>> more common XMP schemas like DC, or IPTC Core.
>
> Already don in svn (:=))) Just missing 2 methods to sync Exif/Iptc with
> Xmp, because Xmp can host all standard Exif/Iptc tags.
>
> The only tags witch cann ot be sync is makernote. A possible solution is
> to host markernotes byte array as binary string in a dedicaced Xmp tag.
> but it doesn't exist in norm.

Binary XML is evil ;) As you wrote in several occasions (in
apprehension) - leave Makernotes as they are and don't touch them
if not really necessary.

Personally I am interested *exclusively* in contextual metadata like
covered in Dublin Core and IPTC Core.

> The way to save markernot in Xmp is
> important, especially with TIFF file format. libtiff is weird to
> handle/manage all Exif tags. When we convert a RAW file to TIFF, all
> Exif/Markernotes tags diseapear. Until than Exiv2 support tiff writing
> mode, this can be an alternative...

Maybe Andreas could tell how distant is future of full support of
metadata in TIFF - if not very maybe better is to leave this out from
Digikam?

m.

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Julien Narboux-2]

Hi,
>
> no; the separator is never displayed somewhere in digiKam it used
> internally to "separate" all branches of the Tags Album treeview. In
> fact the right separator char must be used to not be confused with the
> real text (Tag names)
>  
As this information is only meant to be used by Digikam, isn't it easier
to just put tag names between quotes :

"tag1"/"tag2"/"tag3"

Or even better why not use an XML structure to store the tree of tags ?
A digikam tag would have a name and a list of children.
Then there is no need for a parser which looks for the slashes and so on...
If think it is the power of xml.

My 2 cents,

Julien
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/10/1, Mikolaj Machowski <[hidden email]>:

Dnia poniedziałek 01 październik 2007, Gilles Caulier napisał:

> 2007/10/1, Mikolaj Machowski <[hidden email] >:
> > Dnia poniedziałek 01 październik 2007, Gilles Caulier napisał:
> > >     xmlns:dc="<a href="http://purl.org/dc/elements/1.1/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://purl.org/dc/elements/1.1/"
> > >     xmlns:digiKam=" <a href="http://www.digikam.org/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.digikam.org/ "
> >
> > Shouldn't path be more precise?
> Excepted for <a href="http://digikam.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">digikam.org, where we can host a dedicaced page where users
> can found the descrition of the provate schema, all others are official
> and provided by specifications from adobe. For all request please mail
> to Adobe support (:=)))

Well, I was commenting on <a href="http://digikam.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> digikam.org,  the  rest was left as comparison
(all the 1.0, 1.1 ;)

ok 

Just for the fun, look like Micro$oft use XMP metadata with jpeg files under M$ Vista to index pictures. M$ use a dedicaced XMP schema to record private tags.
This schema provide an URL to the spec. like the Adode XMP paper ask in this case, but the url is... invalid (:=)))). Try with this picture :

<a href="http://digikam3rdparty.free.fr/TEST_IMAGES/METADATA/Vista/Autumn" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://digikam3rdparty.free.fr/TEST_IMAGES/METADATA/Vista/Autumn Leaves.jpg

[gilles@localhost Vista]$ exiv2 -px Autumn\ Leaves.jpg
Xmp.dc.creator                               XmpSeq      1  Peter Miller
Xmp.dc.title                                 LangAlt     1  lang="x-default" Feuilles d'érable en automne.
Xmp.dc.subject                               XmpBag      3  Exemple, Paysage, Ceci est un test pour digiKam
Xmp.tiff.artist                              XmpText    12  Peter Miller
Xmp.tiff.copyright                           LangAlt     1  lang="x-default" (c) Peter Miller/Iconica/Getty Images
Xmp.MicrosoftPhoto.Rating                     XmpText     2  50
Xmp.MicrosoftPhoto.LastKeywordXMP            XmpBag      3  Exemple, Paysage, Ceci est un test pour digiKam
Xmp.MicrosoftPhoto.LensManufacturer          XmpText    41  ceci est le champ Fabricant de l'Objectif
Xmp.MicrosoftPhoto.FlashManufacturer         XmpText    37  ceci est le champs Fabricant du flash
Xmp.MicrosoftPhoto.LensModel                 XmpText    40  ceci est le champs Modéle de l'Objectif
Xmp.MicrosoftPhoto.FlashModel                 XmpText    35  Ceci est le champs Modéle du flash
Xmp.MicrosoftPhoto.CameraSerialNumber        XmpText    32  Ceci est le No de serie de l'APN
Xmp.xmp.Rating                               XmpText     1  3
Xmp.exif.DateTimeOriginal                    XmpText    20  2005-11-05T01:12:05Z
Xmp.xmpMM.InstanceID                         XmpText    41  uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b

To get the Xmp packet, just use Exiv2 command line tool :

exiv2 -eX Autumn\ Leaves.jpg

a new Autumn\ Leaves.xmp file will be created with this content :

<?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?>
<xmp:xmpmeta xmlns:xmp="adobe:ns:meta/"><rdf:RDF xmlns:rdf=" http://www.w3.org/1999/02/22-rdf-syntax-ns#"><rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b" xmlns:dc=" http://purl.org/dc/elements/1.1/"><dc:creator><rdf:Seq xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><rdf:li>Peter Miller</rdf:li></rdf:Seq>
                        </dc:creator></rdf:Description><rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b" xmlns:tiff="http://ns.adobe.com/tiff/1.0/ "><tiff:artist>Peter Miller</tiff:artist><tiff:copyright><rdf:Alt xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><rdf:li xml:lang="x-default">(c) Peter Miller/Iconica/Getty Images</rdf:li></rdf:Alt>
                        </tiff:copyright></rdf:Description><rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b" xmlns:MicrosoftPhoto=" http://ns.microsoft.com/photo/1.0"><MicrosoftPhoto:Rating>50</MicrosoftPhoto:Rating></rdf:Description><rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b" xmlns:xmp=" http://ns.adobe.com/xap/1.0/"><xmp:Rating>3</xmp:Rating></rdf:Description><rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b" xmlns:exif=" http://ns.adobe.com/exif/1.0/"><exif:DateTimeOriginal>2005-11-05T01:12:05Z</exif:DateTimeOriginal></rdf:Description><rdf:Description xmlns:dc=" http://purl.org/dc/elements/1.1/"><dc:title><rdf:Alt xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns# "><rdf:li xml:lang="x-default">Feuilles d'érable en automne.</rdf:li></rdf:Alt>
                        </dc:title><dc:subject><rdf:Bag xmlns:rdf=" http://www.w3.org/1999/02/22-rdf-syntax-ns#"><rdf:li>Exemple</rdf:li><rdf:li>Paysage</rdf:li><rdf:li>Ceci est un test pour digiKam</rdf:li></rdf:Bag>
                        </dc:subject></rdf:Description><rdf:Description xmlns:MicrosoftPhoto=" http://ns.microsoft.com/photo/1.0"><MicrosoftPhoto:LastKeywordXMP><rdf:Bag xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns# "><rdf:li>Exemple</rdf:li><rdf:li>Paysage</rdf:li><rdf:li>Ceci est un test pour digiKam</rdf:li></rdf:Bag>
                        </MicrosoftPhoto:LastKeywordXMP></rdf:Description><rdf:Description xmlns:MicrosoftPhoto=" http://ns.microsoft.com/photo/1.0"><MicrosoftPhoto:LensManufacturer>ceci est le champ Fabricant de l'Objectif</MicrosoftPhoto:LensManufacturer><MicrosoftPhoto:FlashManufacturer>ceci est le champs Fabricant du flash</MicrosoftPhoto:FlashManufacturer><MicrosoftPhoto:LensModel>ceci est le champs Modéle de l'Objectif</MicrosoftPhoto:LensModel><MicrosoftPhoto:FlashModel>Ceci est le champs Modéle du flash</MicrosoftPhoto:FlashModel><MicrosoftPhoto:CameraSerialNumber>Ceci est le No de serie de l'APN</MicrosoftPhoto:CameraSerialNumber></rdf:Description></rdf:RDF></xmp:xmpmeta>
<?xpacket end='w'?>

The url to the namespace (ns) definition from M$ is 

http://ns.microsoft.com/photo/1.0

Thanks to M$ to provide dumy url (:=)))

> > > But i have a question about how to save the a tag path. Currently
> > > the separator is a '/'. This can be a problem if user use this
> > > character in a tag name because it will break the tags tree in a
> > > future import (backup/restore). If somebody has an alternative to
> > > prevent this problem, let's me hear...
> > >
> > > Thanks in advance for you constructive remarks...
> >
> > Maybe some "phishing"?
> >
> > Unicode provides several types of slash, among them:
> >
> > 2044    ???     FRACTION SLASH
> > 2215    ???     DIVISION SLASH
>
> This can be fine.

Hmm. See below.
>

> Comparing to well known solidus:
> > 002F    /       SOLIDUS
> >
> > Since XMP fully supports utf-8 we could use them. But there is one big
> > problem (as seen above): we may be not sure if user has font with
> > proper glyphs. Of course it is possible to do some display time
> > substitute but with that it would be probably better to use some
> > special sequence of chars, beginning eg with :: and ending with {%this
> > is digikam tags path separator%} :)
>
> no; the separator is never displayed somewhere in digiKam it used
> internally to "separate" all branches of the Tags Album treeview. In

> fact the right separator char must be used to not be confused with the
> real text (Tag names)

In that case it is probably better use really different path separator
(as arrow below) or just plain ASCII where :: seems favorite :)

> > Well, after a moment of thinking... why stop at phishing-like
> > solutions? Just use real arrows:
> >
> > 279D    ???     TRIANGLE-HEADED RIGHTWARDS ARROW
> >
> > I put it in some random string in libksirtet.po and works quite nice
> > on my system.  While I am working on KDE from SVN (3.5 branch), and Qt
> > 3.4.3 the rest of my system is 2 years old - including fonts.
> >
> > If you prefer good old ASCII:
> > :: - geek friendly, may be not so understandable for "masses"
>
> I love this one. It's like C++ namespace. I think it's not used with
> natural languages. Someone can confirm ?

>> Feature wish: auto synchronisation of appropriate  digiKam tags with
>> more common XMP schemas like DC, or IPTC Core.
>
> Already don in svn (:=))) Just missing 2 methods to sync Exif/Iptc with
> Xmp, because Xmp can host all standard Exif/Iptc tags.
>
> The only tags witch cann ot be sync is makernote. A possible solution is
> to host markernotes byte array as binary string in a dedicaced Xmp tag.
> but it doesn't exist in norm.

Binary XML is evil ;) As you wrote in several occasions (in
apprehension) - leave Makernotes as they are and don't touch them
if not really necessary.

Personally I am interested *exclusively* in contextual metadata like
covered in Dublin Core and IPTC Core.

sure but including binary data in a xml packet is supported by the Adobe paper. Look for example the thumbnail Xmp tag:
 
http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html#xmp

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/10/2, Julien Narboux <[hidden email]>:

Hi,
>
> no; the separator is never displayed somewhere in digiKam it used
> internally to "separate" all branches of the Tags Album treeview. In
> fact the right separator char must be used to not be confused with the
> real text (Tag names)
>
As this information is only meant to be used by Digikam, isn't it easier
to just put tag names between quotes :

"tag1"/"tag2"/"tag3"

Or even better why not use an XML structure to store the tree of tags ?
A digikam tag would have a name and a list of children.
Then there is no need for a parser which looks for the slashes and so on...
If think it is the power of xml.

Right. i will take a look if i can find a
 

My 2 cents,

Julien
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/10/2, Julien Narboux <[hidden email]>:

Hi,
>
> no; the separator is never displayed somewhere in digiKam it used
> internally to "separate" all branches of the Tags Album treeview. In
> fact the right separator char must be used to not be confused with the
> real text (Tag names)
>
As this information is only meant to be used by Digikam, isn't it easier
to just put tag names between quotes :

"tag1"/"tag2"/"tag3"

Or even better why not use an XML structure to store the tree of tags ?
A digikam tag would have a name and a list of children.
Then there is no need for a parser which looks for the slashes and so on...
If think it is the power of xml.

Right. i will take a look if i can find a way to use Xmp structure type

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Colin Guthrie-6]

Gilles Caulier wrote:
> http://ns.microsoft.com/photo/1.0
>
> Thanks to M$ to provide dumy url (:=)))

It's annoying but it does not have to be a real URL. It's just a URI and
it doesn't even have to exist. It's handy when it does right enough :)

Col

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

> But i have a question about how to save the a tag path. Currently the
> separator is a '/'. This can be a problem if user use this character in
> a tag name because it will break the tags tree in a future import
> (backup/restore). If somebody has an alternative to prevent this
> problem, let's me hear...
>
> Thanks in advance for you constructive remarks...

Maybe some "phishing"?

Unicode provides several types of slash, among them:

2044    ???     FRACTION SLASH
2215    ???     DIVISION SLASH

Comparing to well known solidus:

002F    /       SOLIDUS

Since XMP fully supports utf-8 we could use them. But there is one big
problem (as seen above): we may be not sure if user has font with proper
glyphs. Of course it is possible to do some display time substitute but
with that it would be probably better to use some special sequence of
chars, beginning eg with :: and ending with {%this is digikam tags path
separator%} :)

Well, after a moment of thinking... why stop at phishing-like solutions?
Just use real arrows:

279D    ???     TRIANGLE-HEADED RIGHTWARDS ARROW

I put it in some random string in libksirtet.po and works quite nice
on my system.  While I am working on KDE from SVN (3.5 branch), and Qt
3.4.3 the rest of my system is 2 years old - including fonts.

If you prefer good old ASCII:

:: - geek friendly, may be not so understandable for "masses"
\  - I hate this Win-path look ;)
|  - hmm, not bad but IMO suggests equality of terms on both sides
>  - risky

Mik, are you seen than we have a bug report in B.K.O about this subject (:=))):

http://bugs.kde.org/show_bug.cgi?id=149966

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

> The only tags witch cann ot be sync is makernote. A possible solution is
> to host markernotes byte array as binary string in a dedicaced Xmp tag.
> but it doesn't exist in norm.

Binary XML is evil ;) As you wrote in several occasions (in
apprehension) - leave Makernotes as they are and don't touch them
if not really necessary.

Personally I am interested *exclusively* in contextual metadata like
covered in Dublin Core and IPTC Core.

> The way to save markernot in Xmp is
> important, especially with TIFF file format. libtiff is weird to
> handle/manage all Exif tags. When we convert a RAW file to TIFF, all
> Exif/Markernotes tags diseapear. Until than Exiv2 support tiff writing
> mode, this can be an alternative...

Hey Mik, do you remember this entry about TIFF and Exif (:=))):

http://bugs.kde.org/show_bug.cgi?id=146714

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Dnia wtorek 02 październik 2007, Gilles Caulier napisał:

> > > The only tags witch cann ot be sync is makernote. A possible
> > > solution is to host markernotes byte array as binary string in a
> > > dedicaced Xmp tag. but it doesn't exist in norm.
> >
> > Binary XML is evil ;) As you wrote in several occasions (in
> > apprehension) - leave Makernotes as they are and don't touch them
> > if not really necessary.
> >
> > Personally I am interested *exclusively* in contextual metadata like
> > covered in Dublin Core and IPTC Core.
> >
> > > The way to save markernot in Xmp is
> > > important, especially with TIFF file format. libtiff is weird to
> > > handle/manage all Exif tags. When we convert a RAW file to TIFF, all
> > > Exif/Markernotes tags diseapear. Until than Exiv2 support tiff
> > > writing mode, this can be an alternative...
>
> Hey Mik, do you remember this entry about TIFF and Exif (:=))):
>
> http://bugs.kde.org/show_bug.cgi?id=146714
>

Well,

Mik@home is interested in everything,
Mik@work is interested only in contextual metadata :)

m.

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

>
> Right. i will take a look if i can find a way to use Xmp structure type

What about XMP ordered array (seq)?
See page 17 of the specification.

Marcel

>
> Gilles


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/10/2, Marcel Wiesweg <[hidden email]>:

>
> Right. i will take a look if i can find a way to use Xmp structure type

What about XMP ordered array (seq)?
See page 17 of the specification.

Hi Marcel. You is back from holidays (:=)))

This is what i think to use...

Note :my Xmp patch to compile fine digiKam from trunk is here :

http://digikam3rdparty.free.fr/misc.tarballs/xmptagslist.patch

... if i'm not too wrong current trunk implementation is broken duing my last changes from svn into libkexiv2

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel