|
Description
Treviño
2008-01-10 07:08:03 UTC
Trevino, Using Tags and displaying it behing thumbnails instead file name is not enough. Look in Setup/Albums configuration dialog page for details... Also, using Tags, if you records tags as IPTC keywords (look Setup/Metatada for that), you will be able to display normally these tags in Flickr when you export picture to web service. Gilles Caulier I'm already doing that... But what I wanted to explain is that I'd like to define for each image both a Title and a Description not linked to the Image filename... I mean, maybe a metadata for it... Actually when I want to export photos I've to tag, geotag and comment them in Digikam, export and then define the titles from flickr itself... I think that a feature to define a title wouldn't be a bad thing. I know I could also rename my files to get this, I'd prefer to have a sequential name not directly linked to the photo content. I don't think I'm the only with this need... Hum, this will be a perfect job for XMP metatada... coming from next 0.10 release. We will take a care about it in the future... Gilles Ok, cool...! Could these informations be considered by nepomuk in kde4 too? So it will be easy also for other KDE4-applications to use these infos... The main motivation I'm asking this is that I think that both local files and remote ones should have the same metadata linked with them not to do the same work twice (or more). Another thing is that most web-based galleries (not only Flickr) have both a Name and a Description field that is not directly linked to the file name. An idea to get the maximum would be that of saving the filename as a tag (keyword) too, to be retrieved in future! Trevino, Are you tried digiKam 0.10.0 ? geolocation + XMP are now supported. Flickr export tool is also available and have been improved. Gilles Caulier I've not tried it yet, but according to what I've seen on the screenshots, it doesn't seem to support photo titles as newer tags, isn't it? Treviño, Can you test with digiKam 0.10.0 and kipi-plugins 0.3.0 ? Gilles Caulier (In reply to comment #7) > Treviño, > > Can you test with digiKam 0.10.0 and kipi-plugins 0.3.0 ? I'll try as soon as I can, now I've a slightly outdated version here (still running feisty :P), so I'll try later in my "bleeding edge" PC. Trevino, Please take a look into current implementation from svn where Metadata Template support have been implemented... Gilles Caulier Same here. Digikam 1.0.0. The new metadata template is very nice actually but it doesn't include picture title. Gilles, I think what Treviño is trying to do is to have the image title set automatically when it's uploaded to Flickr. Currently the Digikam kipi interface code always set the image title to the file name during upload. Why not just rename? Sometimes I took a dozen penguin pictures and I want all their titles to be "Penguin". My unoriginal titles are not allowed because I cannot have multiple files with the same name. Also, renaming changes the file sorting order. What he's trying to do can actually be accomplished by setting the "headline" IPTC tag in Image->Metadata->Edit IPTC. Flickr will then pick it up and set the title automatically. It's actually a pretty good workaround for the time-being. But it has a few drawbacks: 1. Unlike caption/comments, it's not synced with the XMP headline tag. Perfectionists will have to set it twice. 2. The menu item is buried too deep. Would be nice to be able to put that in the image description tab where the comments and tags are. 3. Some services (Zooomr) doesn't parse the IPTC headline tag. The title will be overridden by the file name. 4. Some services (Picasa) doesn't support titles. If the application itself is aware of titles and such, it can prepend the title in the comments area for a more graceful degradation on those web sites. 5. Would be nice to show the title in the main album view, together with the comments and tags. Actually I think I can help with the coding if you don't mind me being slower. I'm quite busy but I do want this feature rather badly. :-) And FYI, the kipi Picasa export plugin currently use a tags QMap with titles as keys to remember the tags during the upload process. If we add this feature, that will break because titles are no longer guaranteed unique. A fix will be to use a QHash with the pointer to the kjob as key. (Same as what I did to remember the metadata XML in Bug 199145.) That appears to be what QSignalMapper does internally. So I'd assume it's a reasonably correct approach... Created attachment 40522 [details]
Patch against Digikam SVN
Adds title support throughout Digikam.
Created attachment 40523 [details]
Patch against Kipi-plugins SVN
Adds use of title attribute to set title for Flickr and Picasa. (tested)
This adds title support throughout Digikam. There has been a lot of controversy over whether headline or title is "more right". XMP clearly has better support for title (the headline tag doesn't even get language variants) whereas IPTC clearly want you to use headlines (the title tag is very obscure and not even editable in most programs). Personally, I just rolled the dice and decided to follow Adobe Lightroom and use the title tags. Perhaps someone can make it configurable in the future if they don't like it. The title is used for filenames by many plugins and web services. (For e.g., Picasa will usee your title as filename on their server. Big problem if your titles are not unique.) To avoid problems, I'm conveying the titles to Kipi plugins as an attribute. I've made changes to the Flickr plugin to use that to set the title. The Picasa plugin has been changed to include it as the first line of caption before the original comments. Older or unmodified plugins will simply ignore that attribute. As a bonus, I've stolen some click message code from KLineEdit for the language edit controls in Digikam so the font color and style matches the decor of other click messages on KDE. (The original code sets the pen *AFTER* they drew the text. So the text looks like normal content instead of grayed out.) Let me know if you need me to adjust anything. Thanks clement for this big patch. I will try to review it for 1.2. Treviño, Can you test this patch against digiKam from trunk please ? Gilles Caulier Thanks indeed Siu for this patch. Most have been a lot of work to find all the relevant code! I skimmed through the patch and I approve it. As a summary, I'd say it adds as complete a support for Title as there is currently for Comment throughout digikam. The only thing to discuss is the UI in the right sidebar ImgDescEditTab. Question: Is it crowding the UI too much, isn't is already too packed? Sorry for the late reply. I've been really busy lately. Regarding the crowded UI, you know what? I was thinking about the same thing earlier when looking at it myself. There're a few things we can do. (in increasing order of difficulty and awesomeness.) 1. We can make a new language edit control that's single line instead of multi-line. Unlike captions, multi-line titles makes no sense. But the difference in screen real estate could be extremely small. 2. We can try hiding some of the other controls and adding a button to "show advanced details". For e.g., most people probably won't ever touch the author and date. 3. We could rearrange all the tabs. Make a basic tab for only the most common properties from all categories and tuck everything else under a dedicated tab of their respective categories. 4. We could make all tabs fully customizable. :-) Users can define their own tabs and customize what properties to show on each tab. Who knows? Author name might be useless to some and essential to others. This will allow digikam to fit in really well to anyone's arbitrary workflow and make us totally awesome. But might cost another ten thousand lines of code and many sleepless nights for the brave soul who dare to try. It all depends on how far we want to go on the UI clean up. :-) Single-line edit sounds like the easiest solution. And maybe adding another tab. Let's wait on Gilles' opinion. No updates on this for a while, will it be ready for 1.3.0? About the Picasa-plugin and adding the XMP:title to description: Cokmment #13 "The Picasa plugin has been changed to include it as the first line of caption before the original comments." As i have already put the image-title in the description it will, if i understand it correctly, put the title in the description twice. First inserted from title, then from my description. I'm not to keen on changing descriptions for 600+ individual images so it would be great if we could have an option wheather to put use the title as description or not. Does anyone have an update of this patch for 1.2.0? I have approx 1.2.0 at home but have not patched kipi-plugins yet. There needs to be a solution for the export plugins which can't use both title and caption too. I would like to use both fields and upload to both Flickr (which can support both), and Facebook (which can't). If title isn't used I can't write a single set of tags that suits both targets. Cleament, I would like to reveiw your patch for 1.3.0 release planed this week end. Problem : i cannot apply it against current svn trunk implementation. There is a lots of changes in source code since you last patch version Can you update it, please Thanks in advance for your help Gilles Caulier To Marcel #17:
> Single-line edit sounds like the easiest solution. And maybe adding another
> tab. Let's wait on Gilles' opinion.
I'm not sure if a new tab will be accepted by users. I remember to have tested a mock-up in the past, migrating Tags tree-view to a new horizontal tab hosted in Caption and Tags sidebar, and users complain about. The goal been to let's more free space to host multi-languages/authors support in this view.
Sound like a single line edit widget is enough for the moment. But i'm agree with you, this view become very overloaded...
Gilles Caulier
#17, #21: Okay. It's single line edit then. We can worry about the overload problem later since I'm still very busy right now. #20: Time this weekend seems kind of tight. But I'll see what I can do. Can't guarantee I can make it though. #18: I don't think you're correct about the duplicated title. Suppose you currently have your caption field like this: <title> <description> But your title field must be currently empty since it doesn't exist yet. This will currently export to flickr as: title field = filename caption field = title + description Picasa will get: caption field = title + description After the update, you get this: Flickr: title field = empty (but in my tests, flickr will put the filename in there when it's empty) caption field = title field + title + description = empty + title + description = title + description Picasa: caption field = title field + title + description = empty + title + description = title + description This gives you the exact same result as before for all cases. Remember that the new title field is empty until you put something in there. You can see title field + title in the above equation but since the new title field will never actually contain the title in pictures processed before this change, it gives you null, not title. This change should be fully backward compatible unless you've been doing something wacky... Like Hamish said, I believe the current approach is the right thing to do since it automagically degrades gracefully for services that doesn't support titles. Sorry. Still working on it. Having a lot of dependency issue here. Now kipi-plugins wants the SVN libkexiv2 and libkexiv2 reports missing KDE_ADD_LIBRARY macro in cmake unless I build the entire kdegraphics... Yuck yuck yuck. Probably need a couple more days. You don't need to compile whole kdegraphics. Just checkout root folder plus "/libs" + "/cmake". Run cmake from root dir. that all. Gilles Caulier Created attachment 55613 [details]
Patch against Kipi-plugins SVN
Updated patch to compile against current svn
Created attachment 55614 [details]
Patch against Digikam SVN
Updated patch to compile against current svn
Wanted to test this so I updated patches to compile with current svn. If title and description are joined for picasa should there be '-' in between (or some other separator). Or could the description be the first comment (when there is also a title)? Any progress on this? I can port this patch to 2.0 if needed. Yes, please port this code 2.0.0 from Git repository : https://projects.kde.org/projects/extragear/graphics/digikam/repository Gilles Caulier Created attachment 58038 [details]
Patch against Kipi-plugins GIT
Created attachment 58039 [details]
Patch against Digikam GIT
Created attachment 63105 [details]
Patch against Digikam GIT
- Compile against latest git
- Fix reading title from file metadata
Add new methods to be able to set visible lines of AltLangStrEdit widget. Binary compatibility still preserved (only new methods added Set depency to Exiv2 to 0.21 (last stable since a long time) Patch ABI/API ids M +45 -4 libkexiv2/altlangstredit.cpp M +4 -3 CMakeLists.txt M +7 -0 libkexiv2/altlangstredit.h http://commits.kde.org/libkexiv2/2e06800c9fc9b342e5c2ec55220555369760b192 Created attachment 63212 [details] Patch against digiKam git master updated Patch against digiKam git master updated : - Use new libkexiv2 AltLangStrEdit api to manage size of title editor. - Rearrange layout of setup icon-view to group file and digiKam properties together. Screenshot: http://www.flickr.com/photos/digikam/6092802922/sizes/o/in/photostream/ Still TODO : - icon-view filter do not manage image title. You cannot sort item by title string. - Search/Advanced Search tool do not manage image title. Petri, do you manage this missing features ? The goal is to apply patches just after 2.1.0 release, planed next sunday. Note : It still some code to review again from me... Gilles Caulier Created attachment 63217 [details]
Patch against digiKam git master updated (V3)
New update against git master. Now filter icon view by title is implemented. Still Search tool TODO...
Gilles Caulier
Not familiar with the search but I can take a look. Petri, For BD search i can do it if you want... Other question is about to import Title from new image in database. I see few code done in libs/database/imagescanner.cpp. But i don't tested yet. It work for you ? Gilles Caulier Yes, after handling metadataInfos.at(1) as a map title is read correctly when using "Reread metadata from Image". Not sure if using x-default there is correct though. Petri, Also, there are more kipi-plugins which much support title property as well. Facebook tool for ex : https://bugs.kde.org/show_bug.cgi?id=199317 and Gallery : https://bugs.kde.org/show_bug.cgi?id=221195 It will be nice to patch kipi-plugins in this way... Gilles Caulier Marcel, what do you think about "x-default" value used to populate title in DB (see comment #38) ? It's fine for you ? Gilles Caulier Marcel, It's not clear where to patch Database backend to handle title property in keyword searches. Any tips ? Gilles Caulier I'll take a look at Facebook and Gallery export. ... and me, to DB search implementation. I found it to imagequerybuilder.cpp... I test it, and i will update digiKam patch. Gilles Caulier Created attachment 63225 [details]
Patch against Kipi-plugins GIT
Facebook support added. Checking gallery later.
Created attachment 63226 [details] Patch against digiKam git master updated (V4) In this version, Title property is handle by digiKam search tool (simple or advanced). Note: Marcel, i fixed a bug in imagequerybuilder.cpp where DB is not query properly if we search title in comments table. I suspect a wrong Copy and paste in existing source code... Screenshot: http://www.flickr.com/photos/digikam/6095696513/sizes/o/in/photostream/ TODO : need to review rest of patch... Gilles Caulier Created attachment 63231 [details]
Patch against Kipi-plugins GIT
- Title support for gallery export
- "Comment sets Title", "Comment sets Description" were removed
(In reply to comment #46) > Created an attachment (id=63231) [details] > Patch against Kipi-plugins GIT > > - Title support for gallery export > - "Comment sets Title", "Comment sets Description" were removed You have duplicate lines "if (ev.hasXmp())", the second one must be a copy-paste mistake. How about adding the getImageTitle/getImageDescription functions into kipi-plugins/common or kexiv2 libraries? There is KIPI::ImageInfo.description(); but title() (and titleAndDescription() which would combine title and description correctly handling if either of those is empty) would be useful. In facebook plugin there is a comment // TODO : This method can be replaced by a call to Kipiinterface if it's called outside a separated thread. Is this still valid? Created attachment 63234 [details]
Patch against Kipi-plugins GIT
Fix typo
(In reply to comment #49) > Is this still valid? What "is valid"? The comment? I don't know. And I don't even know why we need to bother in what thread our code is running. Bad choice of words. I meant that is that code run from threads and are kipi functions thread safe (I guess that's what comment is about?)? Petri, In digiKam, it's fine, but not in other kipi hosts application, as Gwenview or KphotoAlbum. So, calling Kipi API to kipi host application is not thread safe. Gilles Caulier Git commit ca9faee96bc6c32ef547add820239e66c8f2c3e8 by Gilles Caulier. Committed on 30/08/2011 at 15:46. Pushed by cgilles into branch 'master'. set setTitle() and title() methods as deprecated. Use new methods setName() and name() instead. This is to prevent confusion with Title property available in digiKam with 2.2.0, which can be accessed through attributes methods Binary compatibility is respected. Adjust API and ABI id accordingly. Document better method form ImageInfo class M +91 -9 libkipi/imageinfo.h M +3 -2 CMakeLists.txt M +27 -75 libkipi/imageinfo.cpp M +22 -17 libkipi/imageinfoshared.h M +11 -4 libkipi/imageinfoshared.cpp http://commits.kde.org/libkipi/ca9faee96bc6c32ef547add820239e66c8f2c3e8 Created attachment 63235 [details]
Patch against digiKam git master updated (V5)
In this version, big changes have be done in kipi interface where i found a lots of missing attributes not shared with kipi-plugins.
I review also more other code. It's not yet complete.
Gilles Caulier
Bit confused... Flickr and Picasa plugins already use KIPI::ImageInfo and Facebook plugin does not. So which one is the correct way? It fine to use ImageInfo API in a plugin. It's the goal. But use it in main thread of plugin, not in a separated thread managed by a QThread based class. Look SendImages plugin for ex, which store relevant ImageInfo data to a dedicated container. The problem is that KIPI::ImageInfo will call Digikam::ImageInfo methods which will bring internal database. In case of SQlite database, it's not thread safe. Also, we don't have tested re-entrency in Database interface with kipi interface. And about other KIPI host applications, i have no idea about re-eentrency. support. Gilles Caulier Created attachment 63240 [details] Patch against digiKam git master updated (V6) Last version of digiKam patch fully reviewed. Marcel, it still some pending point to check. see my comment #40 Gilles Caulier Created attachment 63281 [details]
Patch against Kipi-plugins GIT
Use KIPI::ImageInfo in all modified plugins.
Perti, Look in My last digiKam patch, into KipiImageInfo class. Kipi ImageInfo api has changed for the future. All setTitle()/title() are deprecated now, and must be changed as setName()/name(). We need to take a care to libkipi version here to still compatible for a transition period. So calls to these method must be wrapped into precompiler branch everywhere into kipi-plugins like this : #if KIPI_VERSION >= 0x010300 // call KIPI::ImageInfo::setName() || KIPI::ImageInfo::name() #else // call KIPI::ImageInfo::setTitle() || KIPI::ImageInfo::title() #endif Note : I set these methods as KDE_DEPRECATED into libkipi from git master, but i don't know why only one call from BatchProcessImages kipi-plugin is tagged as deprecated at compilation time. There are of course more calls relevant in kipi-plugins (look with grep). Gilles Caulier After adding ADD_DEFINITIONS(${QT_DEFINITIONS} ${KDE4_DEFINITIONS}) to kipi-plugins CMakeLists.txt deprecated messages start to show (batchprocessing has this in it's CMakeLists.txt).
I can go through these on Saturday or Monday.
Ah... great. fine. Gilles Caulier Created attachment 63339 [details]
Patch against Kipi-plugins GIT
- deprecated functions ifdeffed
Petri, 2.2.0 is now open for commit in git master. Can you apply patches and close relevant files : #155374 #221195 #199317 ... i hope to don't forget one here. Please confirm (:=))) Thanks in advance Gilles Caulier Git commit 47f0a42313c50f65806dee7f381e8886b492e5c7 by Petri Damstén. Committed on 06/09/2011 at 12:59. Pushed by pdamsten into branch 'master'. Add image title support. BUG: 155374 M +9 -0 digikam/filters/textfilter.cpp M +6 -0 digikam/items/digikamimagedelegate.cpp M +6 -0 digikam/items/imagedelegate.cpp M +1 -0 digikam/items/imagedelegatepriv.h M +59 -3 digikam/metadata/metadatahub.cpp M +22 -2 digikam/metadata/metadatahub.h M +16 -0 digikam/utils/albumsettings.cpp M +3 -0 digikam/utils/albumsettings.h M +19 -20 libs/database/imagecomments.cpp M +7 -7 libs/database/imagecomments.h M +16 -0 libs/database/imageinfo.cpp M +10 -6 libs/database/imageinfo.h M +1 -0 libs/database/imageinfocache.cpp M +2 -0 libs/database/imageinfodata.h M +4 -1 libs/database/imagequerybuilder.cpp M +1 -1 libs/database/imagescanner.cpp M +89 -0 libs/dmetadata/dmetadata.cpp M +3 -0 libs/dmetadata/dmetadata.h M +69 -18 libs/imageproperties/imagedescedittab.cpp M +1 -0 libs/imageproperties/imagedescedittab.h M +7 -0 libs/models/imagefiltersettings.cpp M +5 -4 libs/models/imagefiltersettings.h M +7 -0 libs/widgets/itemview/itemviewimagedelegate.cpp M +1 -0 libs/widgets/itemview/itemviewimagedelegate.h M +161 -51 utilities/kipiiface/kipiimageinfo.cpp M +25 -18 utilities/kipiiface/kipiimageinfo.h M +24 -13 utilities/setup/setupalbumview.cpp M +2 -2 utilities/setup/setupmetadata.cpp http://commits.kde.org/digikam/47f0a42313c50f65806dee7f381e8886b492e5c7 Git commit 2e106152329b8887aa35fc9c6dbc0c29fb241f86 by Petri Damstén. Committed on 06/09/2011 at 13:06. Pushed by pdamsten into branch 'master'. - Image title support for flickr, picasa, facebook and gallery export. - libkipi api changes CCBUG: 155374 BUGS: 221195, 199317 M +2 -0 CMakeLists.txt M +0 -7 batchprocessimages/CMakeLists.txt M +5 -0 batchprocessimages/tools/renameimageswidget.cpp M +9 -44 facebook/fbwindow.cpp M +1 -1 facebook/fbwindow.h M +1 -1 flickrexport/flickrwindow.cpp M +7 -11 galleryexport/gallerytalker.cpp M +2 -2 galleryexport/gallerytalker.h M +7 -29 galleryexport/gallerywindow.cpp M +6 -1 htmlexport/imageelement.h M +9 -0 kmlexport/kmlexport.cpp M +15 -3 picasawebexport/picasawebwindow.cpp M +5 -0 yandexfotki/yfwindow.cpp http://commits.kde.org/kipi-plugins/2e106152329b8887aa35fc9c6dbc0c29fb241f86 |