Bug 190055

This planed with Batch Queue Manager, but not yet implemented.

Also, it will only be done for more common metadata, not all.

Gilles Caulier

(In reply to comment #1)
> This planed with Batch Queue Manager, but not yet implemented.
> 
> Also, it will only be done for more common metadata, not all.
> 
> Gilles Caulier

Cool. I hope that "location" fields (city, country,...) will be part of fields taken in account by Batch Queue Manager (GPS infos are less useful than "location" fields to do a search so I fullfil them even I have gps coordinates).

Well i plan to include all field relevant for web publishing, as (c), author, etc... All pro photo management programs from Win32 work like this.

Gilles Caulier

(In reply to comment #3)
> Well i plan to include all field relevant for web publishing, as (c), author,
> etc... All pro photo management programs from Win32 work like this.

I don't know if you consider "location" fields as relevant for web publishing but I tried Idimager and Imatch (two of the best Win32 photo management programs) and both allow to apply "location" field changes on multiple photos.

Yes, location is one.

If you want to list all important metadata tags relevant of web publishing, let's me hear.

But, take a care : we cannot do the same complex interface than MetadataEdit kipi-plugin in digiKam BQM. A judicious selection must be done before.

Gilles Caulier

mahikeulbody,

I'm back in this file now.

In current implementation from svn (1.0.0-beta2), Metadata template support is implemented.

Currently we only support few metadata informations:

http://farm4.static.flickr.com/3554/3681594976_972305d4db_o.png

And more can be added. Please list me which informations you need exactly...

Marcel,

If i'm not too wrong, we can add new template info in database without to change DB schema. Right ? (or i missunderstand something when we talk about it by IRC (:=)))

Can you explain to me how to do it exactly ?

Gilles

Cool !

I would like keywords, caption, location, city, région (I don't remember the english field name and I am not at home), country (and country code ?).

But may be other people would like to add others fields within a template...

Thanks for all this nice work !

For captions and Tags, it's already implemented in caption and Tags sidebar. No need to add it to Template. But a tool to apply Captions and Tags info in Batch must be done later, if i remember Marcel whish...

For Location, City, Region : do you mean all XMP "contact" informations ? Look XMP editor tool from kipi-plugins :

http://farm4.static.flickr.com/3566/3680875127_b544cd3b43_o.png

Note: look like you can Batch Template, using new Batch Queue Manager from digiKam core :

http://farm3.static.flickr.com/2661/3680885801_3f70e36b56_o.png

Gilles Caulier

No, it is not about contact fields. I am at work right now so I cannot check it but I am almost sure that it is within 'origin'.

To be more explicit, I mean all informations related to the "location" of the picture.

For the fields listed below I had intended to store information in the ImageProperties table. If you want I can write a thin wrapper class in the style of ImageCopyright for these fields. Of course we can add more; the fields below are iirc the digest of reading the IPTC Core / XMP standard.


IPTC names:

Country/Primary Location Name
CountryCode/Primary Location Code
City
Sublocation
Province/State
Object Attribute Reference
Original Transmission Reference
-
Subject Reference

XMP names:

photoshop:Country
Iptc4xmpCore:CountryCode
photostop:City
Iptc4xmpCore:Location
photoshop:State
Iptc4xmpCore:IntellectualGenre
photoshop:TransmissionReference
Iptc4xmpCore:Scene
Iptc4xmpCore:SubjectCode

To mahikeulbody #10:

>all informations related to the "location" of the picture

GPS info is not enough ?

Anyway, XMP editor dialog is a good reference again :

http://farm3.static.flickr.com/2514/3681861372_f16d408dbc_o.png

Gilles Caulier

To Marcel #11:

Yes, fine for me.

Mik, 

Perhaps you has other information to store as Template here. 

But please, take a care that we won't to store all XMP data in Database. Take the right choice with no duplicate values.

Gilles Caulier

Well, perfect solution would be to use all tags supported by exiv2, less perfect but still very useful are all tags used in metadata KIPI-plugin.

But I understand choise is even more limited?

1) Support fully all Rights Management tags including contact info: just copy tags from Credits part in metadata KIPI-plugin. BTW - there are "Byline", "Byline title", not "Authors" like in Template editor. Wording should be unified across application and in KIPI-plugin it is more correct.

2) Location tags (World Region, Region, Subregion, City, Country). No, GPS tags aren't enough. GPS data is pointing to point, Location is more general.

3) Keywords, categories - these are somewhat redundant and only one of them is stored in database, right?

Look like Adobe template editor is horrible. To much technical :

http://www.completedigitalphotography.com/?p=478

Lightroom mix editable and read only field :

http://web.mac.com/sidjervis/iWeb/Lightroom%20Extra/Metadata%20Presets.html

Gilles

@15, Gilles

Template editor from first link isn't bad. This *is* very technical subject. With this design they pack maximum info in minimum space.

Another attempt is FotoStation where template editor just uses regular editor window with the same layout and possibilities.

Solution from second link also has its merits: in this way he can compose big portion of important data in one place. In digiKam all those data is dispersed across 3 panels + to edit some of this data user has to go through menu, submenu and not so simply dialog. In LR it is possible to combine this in one panel.

Don't know if this link will work:
http://books.google.com/books?id=3HcJOv10MzgC&pg=PA136&lpg=PA136&dq=lightroom+metadata+templates&source=bl&ots=ZlKzy4DqsF&sig=d4CGektebd-TgEFZT84FQuaHPhs&hl=en&ei=2jdNSpn_H4GqsAbe0pmkBA&sa=X&oi=book_result&ct=result&resnum=9

On page 137 you have screen of how this panel is composed - simpler than in Bridge from your first link.

Scratch my points from #14.

As far as I understand from what people expect from templates in digiKam (me included), current aproach will not fulfill those wishes.

Please: finish implementation of Rights Managements stuff (so one point from #14 is "rescued") but stop at that.

Instead it should be done from KIPI-plugin side - make templates working there. Of course it has drawbacks: no smooth integration in "pure digiKam" workflow (import, BQM) but instead support all metadata which is supported by KIPI-plugin and that is much more than is supported by digiKam database.

@14:

1) Contact info is indeed missing. 
Naming of by-line is not consistent:
Photoshop Author; IPTC By-line; DC creator; dc:creator in XMP
Photoshop AuthorsPosition; IPTC By-line Title; photoshop:AuthorsPosition in XMP

2) Please see my comment #11. When choosing a metadata field for storing it in the DB, we need a clear definition from which XMP, IPTC or Exif tags it is read and written and which names and definition it has in Photoshop, IPTC, Dublin Core and XMP.
For this there is the "Metadata mapping" tab in the DBSCHEMA.ods spreadsheet.

3) Keywords is where we store our tags.
"Category: As this metadata element was earmarked as deprecated already for IIM 4.1 it was not adopted. But it is still synchronised with the XMP property “photoshop:Category” and hence available for future use – but outside the IPTC Core." (IPTC4XMPCore spec)

In current implementation from svn, Metadata Template support now Rights, Contact and Location informations from XMP/IPTC.

http://farm3.static.flickr.com/2533/3694738327_622f537bbf_o.png
http://farm3.static.flickr.com/2554/3695547434_c7e8abe431_o.png
http://farm3.static.flickr.com/2665/3694738887_cf645c5397_o.png

Gilles Caulier

SVN commit 994015 by cgilles:

Metadata Template : Added IPTC subjects Codes support.
CCBUGS: 190055


 M  +3 -0      database/imageinfo.cpp  
 M  +6 -0      dmetadata/dmetadata.cpp  
 M  +30 -14    dmetadata/template.cpp  
 M  +9 -3      dmetadata/template.h  
 M  +13 -33    template/iptcsubject.cpp  
 M  +1 -4      template/iptcsubject.h  
 M  +26 -0     template/templatemanager.cpp  
 M  +24 -0     template/templatepanel.cpp  
 M  +2 -1      template/templatepanel.h  
 M  +14 -0     template/templateviewer.cpp  


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

New screenshot, with IPTC Subjects code support : 

http://farm3.static.flickr.com/2515/3704796021_7cde8fe0a3_o.png

Gilles Caulier

Will it be possible to change these metadata filelds directly from the right sidebar or it will be needed to dial template dialog, create template and then apply metadata (as it's now in 1.0b2)?

>Will it be possible to change these metadata filelds directly from the right
>sidebar 

not yet. it's a viewer for the moment.

But metadataedit kipi-plugins still there. You can edit all field like you want, but not in batch.

>or it will be needed to dial template dialog, create template and then
>apply metadata (as it's now in 1.0b2)?

yes. making template is perfect for workflow. you create a set of templates for different situations. The advantage is to be able to batch template in batch queue manager.

Gilles Caulier

(In reply to comment #23)
> >Will it be possible to change these metadata filelds directly from the right
> >sidebar 
> 
> not yet. it's a viewer for the moment.

I'm quite happy for that "not yet".

> 
> But metadataedit kipi-plugins still there. You can edit all field like you
> want, but not in batch.

One image at time is too limiting. 

> 
> >or it will be needed to dial template dialog, create template and then
> >apply metadata (as it's now in 1.0b2)?
> 
> yes. making template is perfect for workflow. you create a set of templates for
> different situations. The advantage is to be able to batch template in batch
> queue manager.

I agree, especially when the "Rights" set of fields is concerned. These repeats in patterns and here the templates are logical and very beneficial approach.

Though the "Location" datas don't appear repeatedly in such patterns as "Rights" and there are extremely too much of variants of country>city>province>sublocation possible. I can hardly imagine to create template for every place I go to take photographs. While there are  some cases when photographer goes again and again to the same places I suppose more often the photographer - once he is satisfied with the job he made on one place - goes to another new spot to snap what's there. And that's why the palces don't repat so much as author do...

Anyway if the editing from sidebar is on the development radar, I think I can live some time with extra clicks to dial and apply templates just for one use only...

I tried new metadata templates in beta3 release and I have trouble with that. The applying the template actually affects even these fields which are not set in the template. So for example if I want to apply my Rights and Contact metadatas for all my images, I will erase all Location informations which I was building for years! This I find totally unacceptable.

There should be some checkbox in templates which will allow to set which metadata field will be subject to change when applying template. Otherwise there is litte use for the function and even more it poses great risk of data loss.

I'm agree to add checkbox on each option from template. Photoshop has the same feature.

Marcel, this make the puzzle a little bit complex to compare template from image and database in metadatahub. Typicaly, in comparison operator:


http://lxr.kde.org/source/extragear/graphics/digikam/libs/dmetadata/template.cpp#46

... i see 2 solutions :

1/ using boolean operator as well.
2/ check string and stringlist for null.

What's the best way for you ?

Gilles

I am not quite sure what you mean with "boolean operator".

Generally, to solve this like for comment and tags, I think metadatahub should store the status (invalid, available, disjoint) for each field of the template. (That's how it's done for tags: Status is individual for each single tag). Only fields with status "available" are written. Fields are "available" if they have been identical for all loaded images or when the user edits them. In the example above, the status for "location" fields is "disjoint" and they wont be written.

For implementation, we can use MetadataHubPriv::loadSingleValue for each single field of the template instead of the template as a whole.
When passing to DMetadata and the database classes for writing, it would come handy to have a "TemplateMask" class specifying which values to write. Maybe a class having a bool value for each Template member variable.

One checkbox isn't enough to give full flexibility.
Personally I would like system like this:

if template field is empty
:if metadata field doesnt exist
::do nothing, even don't create those field
:if metadata field exist and is empty
::do nothing
:if metadata field exist and is not empty
::do nothing
if template field is not empty
:if metadata field doesnt exist
::create field and fill it
:if metadata field exist and is empty
::fill this field
:if metadata field exists and is not empty
::if use "Apply"[*] action
:::replace contents of metadata field with template
::if use "Add"[*] action
:::ignore this field (existing metadata overcomes template metadata)
::if use "Append"[*] action
:::add content of template field after existing content

[*] In all other cases behavior of these three buttons is the same. Note: those buttons would be in Caption->Information panel, not templates configuration dialog. In this way one template could be used in various ways.

This doesn't give full flexibility - this can be only achieved by adding menu after each template field dropdown menu with choices like: Ignore, Replace, Add after, Insert before which could considerably increase complexity of interface.

Mik, which field in Template is suitable for "Append"? I would imagine that the copyright fields and the location info is "atomic" in that you either keep it or replace it.

> Mik, which field in Template is suitable for "Append"? I would
> imagine that the copyright fields and the location info is "atomic" in that
> you either keep it or replace it.

Sorry, I was bit too fast: this could be used mostly for 
captions/titles/headlines and this type of metadata (FotoStation influence).

But it could be used for copyright strings, usage restrictions, instructions.

(In reply to comment #25)
> The applying the template actually affects even these fields which are not set
> in the template. So for example if I want to apply my Rights and Contact
> metadatas for all my images, I will erase all Location informations which I was
> building for years! This I find totally unacceptable.
> 
> There should be some checkbox in templates which will allow to set which
> metadata field will be subject to change when applying template. Otherwise
> there is litte use for the function and even more it poses great risk of data
> loss.

I would like to second this point.  I had expected to create a template for rights / contact information and others for common locations as an example.  I could then apply the rights template on import and then apply location templates as I review my photos.  What I found was that my rights information was removed when I applied a location template.

It is silly to use templates just to apply something like 'city' to multiple photos at once. What if I manage photos from thousands of cities? I will need thousands of templates? (Yes, I would have to keep all templates, in case, for example, I ever change all the copyright restriction verbiage, etc.) Not a good way.

The Solution: The right-hand caption/tag sidebar's 'information' tab can be an editor, not just a viewer. Or An Alternative: the kipi metadata editor window has an "apply to all selected images" button option.

Second, it is very bad that template fields that are not used in a template will overwrite pre-existing metadata. Not an intuitive/expected behavior. I feel sorry for someone who unwarily uses a template to set copyright info, only to find that many hours of work on location metadata is *lost* (perhaps *forever* if they have no other memory/record of where each photo was taken).

The Solution: Add Check-boxes next to all fields in templates. The "Apply-template" action then only changes a field if it is Checked in template. (The Kipi metadata editor already has Check-boxes...why not also the template editor?)

In my opinion, these are big problems. I offer my sincere thanks to Gilles and all others who work on Digikam for your great work. But, I really believe this needs to be a top priority to improve. These suggested changes would not even change the GUI much, but even if they did, any user who is bothering to work on metadata will prefer useability and efficiency over aesthetics of, and complexity of, the GUI. I am a person who actually enjoys making donations to software projects that I use a lot. But I do not use Digikam anymore because of these two reasons. I wish I could, as it is so good in other ways...

*** This bug has been marked as a duplicate of bug 144858 ***