Bug 134206

Summary: rethink about: Iptc.Application2.Urgency <==> digiKam Rating
Product: [Applications] digikam Reporter: Moritz <moritz.esser>
Component: Metadata-IptcAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In: 0.10.0
Sentry Crash Report:

Description Moritz 2006-09-17 14:49:24 UTC
Version:           0.9.0 beta2 (using KDE KDE 3.5.4)
Installed from:    Unlisted Binary Package

Digikam 0.9.0beta supports IPTC urgency. That's a great thing, because any photograph could send you a bunch images (with iptc ratings) and you could see his ratings as stars in digikam.
But in digikam, there is an interpretation of the IPTC urgency to the digikam star rating:

Iptc.Application2.Urgency <==> digiKam Rating links:
digiKam     IPTC
Rating      Urgency
0 star  <=>  8          // Least important
1 star  <=>  7
1 star  <=>  6
2 star  <=>  5
3 star  <=>  4
4 star  <=>  3
4 star  <=>  2
5 star  <=>  1          // Most important

I think this is not usefull, because a user can't see a difference (on first view) between an imported urgency 2 and 3 image. (And vice versa!) This behavior will exclude digikam users from non-digikam companies.
I got two solutions: support 8 stars and be better than a lot of other tools or interpretate urgency 6, 7 and 8 as 1 star as a lot of other tools do.
Comment 1 Moritz 2006-09-17 15:00:11 UTC
--- digikam/libs/dmetadata/dmetadata.cpp        (Revision 585584)
+++ digikam/libs/dmetadata/dmetadata.cpp        (Arbeitskopie)
@@ -1155,9 +1155,9 @@
 0 star  <=>  8          // Least important
 1 star  <=>  7
 1 star  <==  6
-2 star  <=>  5
-3 star  <=>  4
-4 star  <==  3
+1 star  <=>  5
+2 star  <=>  4
+3 star  <==  3
 4 star  <=>  2
 5 star  <=>  1          // Most important
 */
@@ -1184,11 +1184,11 @@
                 else if (IptcUrgency == QString("2"))
                     return 4;
                 else if (IptcUrgency == QString("3"))
-                    return 4;
+                    return 3;
                 else if (IptcUrgency == QString("4"))
-                    return 3;
+                    return 2;
                 else if (IptcUrgency == QString("5"))
-                    return 2;
+                    return 1;
                 else if (IptcUrgency == QString("6"))
                     return 1;
                 else if (IptcUrgency == QString("7"))
Comment 2 Moritz 2006-09-17 15:07:34 UTC
@@ -1229,16 +1229,16 @@
                 urgencyTag = QString("8");
                 break;
             case 1:
-                urgencyTag = QString("7");
+                urgencyTag = QString("5");
                 break;
             case 2:
-                urgencyTag = QString("5");
+                urgencyTag = QString("4");
                 break;
             case 3:
-                urgencyTag = QString("4");
+                urgencyTag = QString("3");
                 break;
             case 4:
-                urgencyTag = QString("3");
+                urgencyTag = QString("2");
                 break;
             case 5:
                 urgencyTag = QString("1");
Comment 3 Mikolaj Machowski 2006-09-17 20:10:27 UTC
I think 8 stars is too much. They will not fit nicely in interface.
Better solution (and already existing in KDE-space) would be small stars
(half stars) a la Amarok.

m.
Comment 4 Moritz 2006-09-18 09:48:55 UTC
Well actually it will only be seven stars, because urgency 8 will be sero stars. So it's two stars more than now.
A half-star rating is hard to manage either:
HalfStars     IPTC
Rating        Urgency
0 star    <=>  8          // Least important
1 star    <=>  7
1,5 star  <=>  6
2 star    <=>  5
2,5 star  <=>  4
3 star    <=>  3
3,5 star  <=>  2
4 star    <=>  1          // Most important 

I know Apple Aperture and Adobe Lightroom use both 5 stars. It might be confusing to have a different number of stars: i.e. discussing about images with a colleague on the phone.
Comment 5 Mikolaj Machowski 2006-09-18 13:03:34 UTC
Rating can be dissolved:

 0 star    <=>  8          // Least important
 0,5 star  <=>  8
 1 star    <=>  7
 1,5 star  <=>  7
 2 star    <=>  6
 2,5 star  <=>  6
 3 star    <=>  5
 3,5 star  <=>  4
 4 star    <=>  3
 4,5 star  <=>  2
 5 star    <=>  1         // Most importand

Problem with that solution are possible conflicts when exporting and
importing images again. Someone will give 1,5 star, export it, later it
returns and Digikam gives it 1 star. 
Comment 6 caulier.gilles 2006-11-30 16:15:42 UTC
Moritz,

5 stars is the "standard" used in photography. No need to create a specific Rating rule in digiKam witch can perturb users.

The question is : how Aperture, Lightroom, and others photo managment prog. set IPTC Urgency tag accordinly to Rating information ?

Gilles Caulier
Comment 7 Arnd Baecker 2006-11-30 18:35:16 UTC
In Scott Kelby's
"The photoshop CS2 book for digital photographers":
he describes the rating system of Adobe Bridge.
According to the screen shot one has
 Rating
  no star    CTRL-0
  *          CTRL-1
  ...
  *****      CTRL-5

 Label
  Red        CTRL-6
  Yellow     CTRL-7
  Green      CTRL-8
  Blue       CTRL-9
  Purple

He refers to red being the best-of-the-best photos
(i.e. best of the 5 star ones)
and purple for the "worst best photos".
((rating a red 5-star "a pop-up menu appears,
where you can choose Submit to National Geographic (kidding)" ;-)

I don't own Photoshop, so I cannot test how these
are translated into IPTC settings (e.g. would Red correspond
to 6 and Purple to 10 ?)

Further googling did not help to find anything definitive on this,
just the same type of problem
http://www.breezesys.com/forum/archive/index.php?t-405.html
and other possible interpretations of labels
http://www.damuseful.com/pages/rankandfile.html

Somehow I like the idea of red labels, though I am less
sure about the others ...

Best, Arnd
Comment 8 Hubert Figuiere 2006-11-30 19:08:46 UTC
Ligthroom stores the rating in the XMP sidecar the following way:

  <rdf:Description rdf:about=""
    xmlns:xap="http://ns.adobe.com/xap/1.0/">
   <xap:ModifyDate>2006-10-29T04:24:26-05:00</xap:ModifyDate>
   <xap:Rating>3</xap:Rating>
  </rdf:Description>


In short it does not use IPTC. I would refer to the XMP specification. Photoshop is likely to do the same.
Comment 9 caulier.gilles 2006-11-30 19:14:28 UTC
If i remember, Iptc.Application2.Urgency have been removed from IPTC=>XMP transitional. This tag is considerate like obsolete with XMP.

But, we talking about applications witch support old IPTC not new XMP (:=)))...

Gilles
Comment 10 Moritz 2006-12-01 13:52:12 UTC
IMHO the interpretation of the rating is okay, as long as two different IPTC-ratings will give you the same count of stars in digikam. (See reasons above)

As far as I see, every software developer (Adobe, Apple, ACDSoft) is doing it it's own way.
Comment 11 Arnd Baecker 2006-12-05 08:38:17 UTC
I came across this text on associating metadata to photos,
http://download.microsoft.com/download/b/d/a/bdab83cc-660e-4377-9641-47b68ed6f32f/ch02.pdf

At the end of the chapter it is written, that
IPTC field Urgency has been deprecated
(i.e., it is not part of the new IPTC core).

As references
  http://www.theDAMbook.com
  http://www.controlledvocabulary.com
are given. There is a really a lot of information.
Maybe the links are helpful,
  http://www.thedambook.com/pages/links.html
which for example leads to (seems worth a read ...)
  http://www.updig.org/guidelines/index.php
and the link to IPTC core for XMP,
  http://www.iptc.org/IPTC4XMP/
And at last, there is a link (at the right hand side) to a pdf
http://www.iptc.org/std/Iptc4xmpCore/1.0/documentation/Iptc4xmpCore_1.0-doc-CpanelsUserGuide_13.pdf
in which one finds a table on page 20
in which the IPTC Urgency is deprecated
in IPTC core (for XMP?).

I will this to the meta-data experts here ...

Best, Arnd
Comment 12 Moritz 2007-02-22 13:46:29 UTC
As far as I've read there is no specification how to use IPTC rating and the count of stars.
Maybe it's the best solution to make it configurable (in a file or maybe in the preferences). What do you think?
Comment 13 caulier.gilles 2007-03-11 17:43:27 UTC
Ok, i have find the solution for now, useing Exif tags...

digiKam do not yet support XMP. We need to find a fine alternative.

After to have inverstiguate under M$ Vista, and especially how the pictures metadata are managed by the M$ photo management program, I can said than M$ use XMP and "Exif tags", but never IPTC/IIM :

The rating is stored in a private Exif.Image.Rating Tag, number 0x4746. it a simple short value stored in this tag : 0 star = 0, 1 star = 1, ..., 5 star = 5.

An another tag Exif.Image.RatingPercent is a dupplicate of this one but the value is in percent : 0 start = 0%, ..., 5 star = 100%

I can use this tags in the both way than we use the Iptc.Application2.Urgency.

Also, like the Iptc.Application2.Urgency is now considerated like obsolete in IPTC spec., we can forget this IPTC tag to store Rating.

The advantage to use this M$ Exif.Image.Rating tag is than digiKam will be compatible with the M$ Vista Photo Manager. A photo imported form digiKAm to Vista will be show with the right Rating in M$ Photo manager. And the reverse case is also valid.

What do you think about ?

Gilles
Comment 14 caulier.gilles 2007-03-11 17:46:03 UTC
Note : the Exif.Image.Rating and Exif.Image.RatingPercents tags driven by M$ are already know by ExifTool :

http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html

I have add these tags recently in Exiv2 tags database... digiKam is now ready to use this tags if you are agree...

Gilles
Comment 15 caulier.gilles 2007-10-02 09:33:41 UTC
Ok, now, with digiKam for KDE4 we support XMP where we have a tag to store Rating informations. Also, I will disable the code to store rating in IPTC Urgency tag.

Gilles
Comment 16 caulier.gilles 2007-10-03 12:27:43 UTC
SVN commit 720609 by cgilles:

digiKam from trunk (KDE4) : XMP metadata management with database.

This is the first stage to control XMP metadata contents with Database contents and vis versa. This code handle XMP with current Database schema witch still the same than 0.9.x.

Marcel work currently on the new databse schema describe on the OpenOffice document available at this url :

http://websvn.kde.org/trunk/extragear/graphics/digikam/DBSCHEMA.ODS?view=log

The code will be adapted later by Marcel to handle more XMP tags according with this new schema.

This is the list of current changes :

- Preparing code to handle strings hosted in different languages (comments for example, dixit B.K.O #98462).
- Handle all Xmp.exif and Xmp.tiff tags has Exif metadata content to get photo informations set by camera.
- Do not set Iptc.Urgency tag with Rating value, but use standard Xmp.Rating tags instead. Import of Iptc.Urgency 
as Rating still running if Xmp metadata are not available. (B.K.O: 134206).
- Preparing code to handle Xmp strings set different authors(comments for example, dixit B.K.O #134476).
- Set the Tags name as Xmp.subject (keywords).
- Set the Copyright/Authors information in Xmp tags (schema inspired from Adobe Photoshop 7.0).
- Store Tags Path List into a dedicaced digiKam.org Xmp namespace as a sequence of strings. Do not use Iptc.Keywords for that. Import from Iptc still running if Xmp metadata is not available. This way is very important to restore properlly in database all tags assigned to an imported picture. There is not strings size limitation with Xmp and char encoding is always UTF-8. Nothing will be lost now.
- Xmp is always stored in pictures format witch support this metadata format : jpeg, png, and tiff.

All these changes require to update libkexiv2 and Exiv2 from trunk to compile and run digiKam properlly.

CCMAIL: digikam-devel@kde.org
CCMAIL: marcel.wiesweg@gmx.de

BUG: 134206
BUG: 149966

CCBUGS: 98462
CCBUGS: 132362
CCBUGS: 91811
CCBUGS: 134476
CCBUGS: 136260
CCBUGS: 146714




 M  +59 -44    digikam/metadatahub.cpp  
 M  +1 -1      libs/database/collectionscanner.cpp  
 M  +127 -71   libs/dmetadata/dmetadata.cpp  
 M  +5 -4      libs/dmetadata/dmetadata.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=720609