Digikam Plans for KDE 4
Wednesday, 2 April 2008 | Mgilles
Readers of the KDE Commit-Digest have probably noticed that Gilles Caulier is again on top with number of commits. On what does he work so furiously? Gilles is the main developer of Digikam which is under transition from KDE 3 to KDE 4 whilst simultaneously adding new features. Read more to know more about the future of advanced digital photo management for KDE and Linux.
There are many improvements including a cleaner user interface, improved performance, a new thumbnail bar, XMP support, ability to run on Mac OS X, GPS tagging using Google Maps, multiple album collections supporting collections on network shares and removable media, and auto gamma and white balance with RAW. Digikam is also the first open source photography tool with 16-bit colour depth support. Gilles Caulier tells all.
We have plans to release 0.10.0 in September, if all goes well.
Regression tests will take a while. I would not provide a "stable" release full of bugs.
As you can see, porting of Qt 3/KDE 3 application like Digikam, K3B or Amarok to Qt 4/KDE 4 is not a simple task. Because changes in the API are huge, all elements must be tested, and some parts even re-written. The advantage of this approach is review of all old code with refactorisation, simplification and various other improvements.
Digikam 0.10 is still in alpha. I advise against use of it in production, at least until the first release candidate.
There are also kipi-plugins and all shared libraries where Marcel and me are working hard to port to native QT 4/KDE 4:
- libkdcraw (including new 16 bits color depth auto-gamma/auto white balance)
- libexiv2 (including new full XMP metadata support)
- libkipi (partially re-written and cleaned).
- 7 kipi-plugins fully ported by me (SendImages, RAWConverter, JPEGLossLess, FlashExport, TimeAdjust, MetadataEdit, and AcquireImage).
I present here a few screenshots of Digikam for KDE 4 in action.
As you can see, a lot of work has been done to design a clean interface, moving away from the traditional dialog requiring to build a search step-by-step with comboboxes, and towards a page which offers the available options at a glance, at the same time retaining the ability to create complex searches. With this approach we hope to create something more user friendly. It is not finished yet, the UI in the screenshot can be considered a preview, but we want to finalise this interface for the Beta 1 release.
The need to redesign the search interface came with the rewrite and improvement of our database schema. Now, much more photo metadata information will be stored and will be available for searching. For example, GPS information will now be stored in the database, which means that read-only files (think of your RAW images) can as well be geo-coded.
In Digikam for KDE 4, thumbnail kio-slave disappears. All thumbnail images are now generated using multi-threading (another part implemented by Marcel) If you have already played with Showfoto, you have certainly seen a thumbbar. The KDE 3 implementation used kioslaves without a memory cache mechanism. It was slow. The new mechanism is faster and can be included everywhere in Digikam without a decrease in performance. I have included the thumbbar in the Image Editor (F4) and in the AlbumGUI with Preview mode (F3). The same cache is used everywhere.
In KDE 4, XMP is fully supported. I have improved the Metadata Editor kipi-plugin and rewritten all dialog pages to be more user friendly, and to be more similar to other tools available under Mac OS X or Windows.
Gustavo Boiko, have ported some parts of Digikam to compile as a native application under Mac OS X.
For KDE 4, I have fixed libkipi to become a pure image collection interface: no widgets, no dialogs, no translations. All GUI components have to be re-implemented in kipi-host using the right model/view implementation. For Digikam, I have already implemented all of them. The advantage is really visible here: the tree view used for all physical/virtual albums in Digikam can be used as well with all kipi-plugins (KDE 3 only provide a flat albums list, which is not really suitable).
For KDE 4, I have also implemented a new tool to edit a GPS track list of several images at the same time. This tool uses Google Maps, but there are plans to use Marble if necessary, especially when the user does not have network access.
With KDE 4, multiple root album paths are supported, including removable media and network repositories. There will be no problems with using Digikam with a NFS server to host your images.
Full colour theme interface: this was also backported to KDE 3. Now colour schemes are applied everywhere within the GUI. With dark themes (my preferred scheme), Digikam looks similar to professional software available commercially.
This is a very important feature: auto-gamma and auto-white balance with all RAW file format using 16-bit colour depth! Before, 16-bit colour depth support required use of colour management to have a suitable image in the editor. Without colour management, the user would see only a black hole image. This is due to limitations of the dcraw library, which does not provide a homogenous interface between 8-bit and 16-bit colour depth workflow.
In these screenshots, you can compare the same RAW image decoded:
- On the left by dcraw in 8 bits colour depth and converted to PNG. Auto-gamma and auto white balance is performed automatically by dcraw.
- On the middle by Digikam in 16 bits colour depth using libkdcraw with a dedicated auto-gamma and auto-white-balance performed in Digikam core.
- On the right by the LightZone... As you can see, Digikam is not bad!
Digikam is now able to play with all RAW images in 16-bit colour depth without to use complex colour management settings: in your workflow RAW pictures can be handled like JPEG files. This is a very productive and fast method: for example, LightZone uses this style of workflow. Note that this feature was also backported to KDE 3.
I would like to remind to everyone that Digikam has been the first suitable open source photo-management program with support for 16-bit colour depth pictures as well! Even GIMP or F-Spot do not support it! Cinepaint can do it, but seriously, who will use it to play with pictures? Of course we have Krita to also work with layers. We want Digikam with Krita to be considered the perfect photo suite.
On a final note, we would like Digikam to take part in Google Summer of Code: here is a list of potential projects.
Comments:
stab at KDE 4.0 release? - John - 2008-04-02
> I would not provide a "stable" release full of bugs. looks like some KDE devs didn't like the 4.0 release full of bugs either :)
Re: stab at KDE 4.0 release? - Caulier Gilles - 2008-04-02
Absolutely (:=))) Gilles Caulier
Re: stab at KDE 4.0 release? - Aaron Seigo - 2008-04-03
the irony is that a little further below you complain (rightfully) about how it wasn't possible to develop against the always moving libs from last summer (pre-4.0). 4.0 specifically, purposefully addressed that issue by getting the core functionality moved to "stabilize! complete features!" rather than "more new developments!". the expectation was that this would allow application developers such as yourself to get your efforts on track instead of being continuously held up by a never ending library development party.
Re: stab at KDE 4.0 release? - Anon - 2008-04-02
4.0 is not a stable release. It is a development release. 4.1 will be the first stable release.
Re: stab at KDE 4.0 release? - Gilles Caulier - 2008-04-02
And what about printing interface ??? In digiKam for KDE4 i have disable all KDEPrint support because all api become obsolete/unmaintened (fix me i'm wrong) KDE 4.1 will re-enable it or find alternative (using QT 4.4 for ex.) Can you said than KDE 4.1 will be the first release ready to use in production if printing interface cannot be used ? Gilles Caulier
Re: stab at KDE 4.0 release? - Aaron Seigo - 2008-04-03
printing already works in trunk/, so there's no need to wonder idly anymore. it uses the printing support from Qt 4.4 and it's progressing rather nicely.
Re: stab at KDE 4.0 release? - Gilles Caulier - 2008-04-03
Thanks for the info Aaron. I wil review digiKam printing code in this case. Gilles Caulier
Re: stab at KDE 4.0 release? - Erunno - 2008-04-03
Well, then why is KDE filed under the "Stable" section on kde.org? And why does the release annoucement for 4.0 not contain any warning about this being a relase targeted mainly at developers? Not that I intend to beat a dead horse but I'm also somewhat allergic to revisionism. And I don't count developer ramblings on obscure blogs and mailings lists. kde.org being the main internet portal for KDE is as official as it gets. And it states that 4.0 was stable although reality disagreed on a regular basis. Anyway, 4.1 looks like it's going to be a solid release and with 4.2 most applications should be finally ported.
Re: stab at KDE 4.0 release? - Gilles Caulier - 2008-04-03
When i have started to port digiKam to KDE4 at July 2007, i have seen imediately several problem in core libraries. I don't speak about full desktop which for me have been unsuitable at the date. This duing a lots of major changes in API. For big a big library as KDE, the list of regression tests is simply huge... This is why is have never planed to try to plan digiKam 0.10.0 for the first KDE 4.0 release. It been impossible to have a stable appplication. You have right. KDE 4.1 will be better, and certainly KDE 4.2 the first release which can be used in production. This is not a critic. It's just the reallity. And if you look into the pass, the same situation have been seen with KDE 2.x to KDE 3.x transition. Gilles Caulier
Re: stab at KDE 4.0 release? - Aaron Seigo - 2008-04-03
> For big a big library as KDE, the list of regression tests is simply huge... thankfully the number of real regressions has been rather small. there are some important ones, mostly that we knew about already due to technical issues we ran into (the ssl and proxy issues are good examples o those). > It been impossible to have a stable appplication. it may have impossible for digikam, i can see that, but dozens of apps shipped for 4.0 and were quite stable. that said, you're quite right about "chasing a moving API" being a major blocker for application developers. getting 4.0 out the door was a vitally important step for addressing that and increasing the stability / lowering the regression counts in the core libs. this happens best when drastic new changes aren't happening any more, more applications stress it and more users do different things with it. it's far more pleasant and realistic to develop apps against the kde4 libs at this point. as such, i think we'll see a bloom of applications in the 4.1-4.2 timeframe, digikam being a good example of that with it's release date of september.
Google Maps Integration - Martin Fitzpatrick - 2008-04-02
Reading the note about the Google Maps/Marble integration made me think - is there an underlying system (one of the new KDE4 backends) that handles map integration? It would be better if the choice of map 'server' was determined system wide and applications queried through a single API. That way any application needing to show map information, positioning etc. could do it in a simple unified way - and this could be easily configured to individual (or local) preferences. Also, a more general question - is there a KDE4 API for access to any other data sources like these? btw. Digikam looks very nice... as does the KDE4/dark theme (where is this available?). Keep up the good work!
Re: Google Maps Integration - Sebastian Kuegler - 2008-04-02
Having a "Map Application" is already quite a step forward. As Marble supports the KML format (the one that's also used by GoogleEarth), it can probably be integrated with other "Map Applications" as well. One step at a time, though :-)
Re: Google Maps Integration - Martin Fitzpatrick - 2008-04-02
Hah of course :) I like what I see - it just set my mind whirring! I really like the way that KDE4 has moved towards abstracting data services to the applications, opens up a lot of possibilities. It would be nice if there were some kind of subsystem which could accept plugins/data sources and present them to applications. Maybe there already is... I'll be the first to admit I don't really know what I'm talking about ;) But, yes, patience... patience..
Re: Google Maps Integration - Gilles Caulier - 2008-04-03
Here, i have started to play with marble widget integration in digiKam right side-bar for geolocation of photo : http://digikam3rdparty.free.fr/Screenshots/marbleintegrationforphotogeolocation.png Gilles Caulier
Re: Google Maps Integration - sebas - 2008-04-03
Yay! I would imagine the following use cases for this: - tagging a series of photos with geolocations - selecting an area in marble and show all the photos that have been tagged with that area
Re: Google Maps Integration - Gilles Caulier - 2008-04-03
Yes, This will be the second pass : to have a Search GUI based on marble to be able to find a photo using a map. It's in my TODO list... Gilles Caulier
Re: Google Maps Integration - sebas - 2008-04-03
Thanks. That's actually a possible usecase I've used while presenting Marble. Of course it's something I'd love to use. Awesome to see you're planning to implement this. :-)
Re: Google Maps Integration - Gilles Caulier - 2008-04-03
Marble integration in digiKam right side bar is now complete on my computer. I will polish the code and commit this evening. The screenshot have been updated: http://digikam3rdparty.free.fr/Screenshots/marbleintegrationforphotogeolocation.png Next stage is to build an interface to "Search photo on a map"... Gilles Caulier
Re: Google Maps Integration - Gilles Caulier - 2008-04-03
Done in svn with Rev. 793334. Gilles Caulier
Re: Google Maps Integration - Gilles Caulier - 2008-04-04
New blog entry about marble geolocation in digiKam have been created: http://www.digikam.org/?q=node/306 Gilles Caulier
Re: Google Maps Integration - Fri13 - 2008-04-02
"btw. Digikam looks very nice... as does the KDE4/dark theme (where is this available?)." If im correct, that isn't a KDE4 color schema, it's Digikam own. Last stable version Digikam has supported limited color schemas, where user could select only a preview background, selected/non-selected image background and foreground and text effects for special text (labels and tags and rating). But now Digikam has new theme possibilities what allow to change digikam window color to anykind you like, without effecting to other KDE applications. Example, you can have blue-white color schema on KDE but then make a own color schema with digikam own theme tool and apply it so digikam window is using colors what you selected, not blue-white what is applyid from KDE control panel. This is very important feature to bring digikam as a professional application because colors should be so much middle gray as possible and this has be impossible.
Re: Google Maps Integration - Martin Fitzpatrick - 2008-04-02
"If im correct, that isn't a KDE4 color schema, it's Digikam own." Thanks for the info, had never occurred to me that this would be useful in photo/image apps, but looking at the screenshots I can see why. I guess if it's just colour changes I can apply them through the normal KDE appearance settings as well. My eyes are going to be very grateful I think... (although the browser is going to look weird :) Thanks again.
Re: Google Maps Integration - Fri13 - 2008-04-03
Middle gray is 127, 127, 127 (RGB 0-255 settings) but because it's computer monitor what has backlight and not gray-card what reflects light, it might be better to have 64, 64, 64 colors. Middle gray is needed because other wise other surrounded colors affecst the photograph colors and it's "developing" is harder. I were once in a great studio where was own room for Photograph manipulation, there were 15 PC's in that room, whole big room was painted with middle gray, all stuff there was middle gray and there were special lighting what were calibrated once a week and few times a week every monitor were calibrated (all monitors were those 10-14bit and not normal 8bit monitors). And then admins allowed normal users to use wallpaper what user liked. And users were having photoshops etc open and their MacOSX default Blue background really were a shiny blue DOT in that room and I was shocked that they didn't understand that one of new students problem to have too warm images was simple as that, WRONG WALLPAPER in color controlled room :-D With middle gray, all colors will be seen much easier and neutral as possible.
Re: Google Maps Integration - Kevin Kofler - 2008-04-05
What's the point of such an abstraction? Why not just use Marble directly and drop support for the proprietary Google Maps (now that we have a Free alternative in KDE)?
Re: Google Maps Integration - Gilles Caulier - 2008-04-05
Resolution of maps in Marble are limited. If you want more details, we need advanced tool. googlemaps is fine. Gilles Caulier
openSUSE - Anon - 2008-04-02
Does anybody know where openSUSE (11.0 factory) users can find the new digikam? It seems neither to be available as single package nor in some extragear-RPM. This is strange, as for any other KDE4 package than Digikam (and, equally unfortunately, k3B) openSUSE offers superb support and up to date packages., even of development versions. Only for these two apps, my favorites beside Amarok, you can't use a KDE4 version.
Re: openSUSE - Emmanuel Lepage Vallée - 2008-04-02
They are still in alpha state, it is not very common (for any distribution) to provide alpha quality software by default. You can create a kde-devel account and compile them from svn everyday, like I do. That not hard at all, and you have cutting edge apps everyday. By the way, three more screenshot I took from digikam (compiled today) http://img143.imageshack.us/img143/1347/snapshot2eg3.png http://img399.imageshack.us/img399/9470/snapshot3fa2.jpg http://img258.imageshack.us/img258/3431/snapshot4zm2.png
Re: openSUSE - Gilles Caulier - 2008-04-02
Whow, nice photos... and i can see than i'm not alone to love black color scheme theme (:=)))) Gilles Caulier
Re: openSUSE - Fri13 - 2008-04-03
There is again new suggestion for selecting files, currently i use double click mode and i like ctrl+shift modes because those works for everything else too, on SVG editing, image editing and text editing, not just file management. It's just very dificult way to get something better when there is so many posibilies what use one way but cant work with others. http://ppenz.blogspot.com/2008/04/selecting-items.html
Re: openSUSE - nice - 2008-04-03
you rock, n1 photos !!!
Re: openSUSE - Anon - 2008-04-03
"They are still in alpha state, it is not very common (for any distribution) to provide alpha quality software by default." Obviously you have either not used openSUSE or not read my posting ;). openSUSE DOES provide quite commonly a wide rande of KDE4-and-apps-RPMs, mostly unstable development versions (e.g. a pretty usable KDE4.1 snapshot repository, updated every few days). That means the average openSUSE user does NOT have to use a SVN account, nor to compile any program, but must only add a "KDE:UNSTABLE" repository to the system. See http://download.opensuse.org/repositories/KDE:/KDE4:/UNSTABLE:/ However, while there are lots of other software pieces, from pretty usable to "crashing all the time" state in this repo, I cannot find neither Digikam nor K3B (which is told to be quite usable already).
Thubbar? - Fri13 - 2008-04-02
"I have included the thumbbar in the Image Editor (F4) and in the AlbumGUI with Preview mode (F3). The same cache is used everywhere." Is there still possible to use current view style and not thubbar? I mean that old where are thumbnails and when user double clicks image, it gets open to editor or big preview? I like this new thubbar but I like current style too :-)
Re: Thubbar? - Gilles Caulier - 2008-04-02
Yes, in editor, View/Show Thumbnails menu option. In Algum GUI, i have forget to add this option. I will fix it. Of course, you can reduce to minimal size the widget separator betview icon view and thumbbar. Gilles Caulier
Re: Thubbar? - Gilles Caulier - 2008-04-02
Done in svn with rev. #793002 Gilles Caulier
Re: Thubbar? - Fri13 - 2008-04-03
Nice! DigiKam just looks more and more very professional application, it has be very pro as in usage but now it looks too!
Wow! - Joergen Ramskov - 2008-04-02
Looks like Digikam is going to ROCK when it arrives for KDE4.
Re: Wow! - Gilles Caulier - 2008-04-02
Here you can see more screenshots of new Advanced Search dialog. http://digikam3rdparty.free.fr/Screenshots/NewSearchTools/ Gilles Caulier
Just thanks - LB - 2008-04-02
I really love Digikam, thanks!!!
Phonon ? - DanaKil - 2008-04-02
hi :) any plan to use Phonon for the embeded video preview ?
Re: Phonon ? - Gilles Caulier - 2008-04-02
Already done in svn... Gilles Caulier
Version numbers - Anon - 2008-04-02
What about going from version 0.9.0 to 1.0.0 instead of 0.10.0? I would reflect the mature state that DigiKam is in, so it would definitely be justified. Just like K3b - time was overdue. I know that version numbers are controversial sometimes and that some will criticize your chosen number as hype-driven and being purely for marketing reasons if you put the number too high. (Well some people will always nag if you don't prefix with two zeros and have an -alpha appendix if they experience a crash and if you don't have the feature list of commercial alternatives). And at release time it certainly would give you extra marketing - big version jump instead of simple port is more newsworthy for many more sites. You could surely reach more photographers and increase your userbase, especially if you have a Mac/Windows port ready, and with the KDE4 port I'm sure that the codebase is ready for that. And you could show people that they can trust the app and that basic features are not a problem. Not only that, with so many pro level features that stage is long behind.
Re: Version numbers - Gilles Caulier - 2008-04-02
This subject have been already discuted on digiKam mailing list. I'm not favorable to toogle now to 1.0.0 version... A fondamental feature is not yet implemented : a powerfull backup/restore tool. Gilles Caulier
Re: Version numbers - Vide - 2008-04-06
With all the respect due, and even if others "pro" apps on other platform have this fuction, I don't think this is what makes Digikam a 1.0 program or just a 0.10. Backup/restore policies should be something outside the scope of a user program and should be part of the "operating system". What's my point? That Digikam is such a great program and that the KDE4 port will be a gigantic leap that deserve a 1.0 version in any case :)
16-bits is nice for pros, but... - kwilliam - 2008-04-02
... for Joes like me, I'd rather see the tagging GUI improved. Using the mouse to click checkboxes is so slow! It would be better to have a good autocompletion feature so tagging could be done entirely from the keyboard. Also, I'd like to see tagging where tags correspond to an actual X,Y location on the photo. (Obviously that would require the mouse, but for just one click it's worth the time.) If that was supported, it would be possible to upload directly to Flickr or Facebook from Digicam! It's frustrating to have to tag everything locally AND on online, so for large albums I usually don't bother tagging them locally. The Facebook API is all there (http://developers.facebook.com/documentation.php?v=1.0&doc=photoupload) we just need to support X,Y coordinates for tags. Any Google Summer of Coder's want to take that on? (I'm already invested in another idea this summer.)
Re: 16-bits is nice for pros, but... - DanaKil - 2008-04-02
I agree that, at least double-click on a tag (or maybe even single clic) could check/uncheck a tag in the tags treeview (yep, the checkbox is small) Another idea : a shortcut that can apply the last applied tag to the current picture
Re: 16-bits is nice for pros, but... - Gilles Caulier - 2008-04-02
Same here. I work currently on keyboard shortcut to assign tags on image (like kmail do with folder assignement) Gilles Caulier
Re: 16-bits is nice for pros, but... - DanaKil - 2008-04-02
you could add a button at the bottom of the tags treeview with something like "Set a shortcut for the current selection of tags" (so I can choose some tags for a picture, assign a shortcut for this set of tags and then easily apply all these tags in one shortcut) just an other idea (I know dot.kde is not bugzilla but well...) : when I tags a lot of picture, I often works in thumbnails mode and select all pictures that I wants to be tagged with a particular set of tags. And often, I release "ctrl" for the multiple selection and lose all my selected images (and then I cry). Maybe you can add in the Edit menu a mode to easily select multiples pictures : no need to keep ctrl pressed, when you click a picture, it is added to the selection, if you click on it again, it is substracted from the selection
Re: 16-bits is nice for pros, but... - jospoortvliet - 2008-04-03
Maybe the way Dolphin does allow you to select several items by using a small icon overlaying the item might be a solution.
Re: 16-bits is nice for pros, but... - Gilles Caulier - 2008-04-03
Yes, there is an entry in digiKam bugzilla. Marcel will take a look when he port all icon view to Qt4 model/view (this part still use Qt3 transition classes). It's planed later than 0.10.0 release Gilles Caulier
Re: 16-bits is nice for pros, but... - Gilles Caulier - 2008-04-02
I'm currenty working on, for KDE3 and KDE4 version. Look this entry : http://bugs.kde.org/show_bug.cgi?id=114465 On the "Caption and Tags right sidebar, there is a new fied where you can type tags hierarchies (yes, more than one at the same time) using only keyboard. Auto-completion is supported : http://bugs.kde.org/attachment.cgi?id=24102&action=view The Tag Edit dialog have been improved in the same way. Look here : http://bugs.kde.org/attachment.cgi?id=24136&action=view Gilles Caulier
Database? Metadata? Strigi/Nepomuk integration? - Yuriy Kozlov - 2008-04-02
Thanks for the great work on Digikam! Since you discussed a new database schema and more metadata, I was wondering if this is all being stored (and searchable) using Nepomuk and Strigi or if Digikam is maintaining its own database? It would be great if all metadata in Digikam, including tags, ratings, as well as camera information, could be shared with the rest of the desktop. For example, Dolphin now has tags and ratings for files. For pictures, this should be the same ratings you see in Digikam, or whatever other photo application one might be using. I'm actually wondering the same thing about Amarok. This is the kind of integration I look forward to seeing throughout KDE 4.
Re: Database? Metadata? Strigi/Nepomuk integration? - Gilles Caulier - 2008-04-02
Nepomuk integration is planed for the future, but it's not the priority actually : it's time to stabilize source code to be able to release for september. Gilles Caulier
Re: Database? Metadata? Strigi/Nepomuk integration? - DigiKam lover - 2008-04-03
I'm sorry to hear that. Please reconsider as it is one of KDE's key features to offer broad integration. It is one of the features what makes it shine compared to other Desktops. Database applications like DigiKam should promote this feature as soon as possible. DigiKam on the other hand will only gain in importance, insight, influence and momentum. Anyway keep up the great work!
Re: Database? Metadata? Strigi/Nepomuk integration? - Fri13 - 2008-04-07
I dont see reason to horry nepomuk integration. I think digiKam has great handling with photographs with it's own ratings and tags. Later nepomuk support would be nice but now I dont see any reason for it. Because I dont see Digikam as a tool for "normal joe" who just browse wallpapers and other images what avarage joe downloads from internet. DigiKam is for professional/hobby photographers , who keeps digikam running anyway when needed to handle big amounts of photographs and easily to manage those. Later that nepomuk integration can be nice but.... Mayby I'm just wrong person to judge that with my photograph library what includes tens of thousands of photos and browsing those with nepomuk sounds bad because I need to have tags and comments on photos and albums what I dont want to find when doing desktop search.
Re: Database? Metadata? Strigi/Nepomuk integration? - Gilles Caulier - 2008-04-07
I'm totally agree with this viewpoint. There is not urgency to include Nepomuk support for 0.10.0 release. Of course, later, when new digiKam core Database interface will be stabilized, something can be done to connect digiKam database to nepomuk. But in all case, later 0.10.0 relesase... Gilles Caulier
Re: Database? Metadata? Strigi/Nepomuk integration - DigiKamLover - 2008-04-07
No need to hurry indeed, BUT... ther are at least 4 people requesting it (read "KDE 4.1?", so you are basically the only one who thinks "browsing those with nepomuk sound bad"
Re: Database? Metadata? Strigi/Nepomuk integration? - outolumo - 2008-04-08
Great work! I for one am looking forward to stable KDE4 release :-) As for Nepomuk integration, I'm really waiting for that as well, because I understand that it will not only offer the infrastructure to do the indexing (tagging) and allows for the same lightspeed categrization and search we are used to with digiKam, but also allows tight integration with other apps in the platform: marble with the GPS -data, akonadi integration etc. So far my major reason for not using digiKam to its full capacity has been the problem, that its not se well integrated with the desktop. For example, I have some 6,000 photos, for which digiKam is great editor, but I'd like integrate a hoard of non-photos with slightly different needs to the same system. And I want to tag them all, and I want to tag audiofiles and keynotes in the same system. Somehow I just don't see why I should manage my .mp3 and .xcf -files with digiKam. And if I have to tag these all, why use digiKam. It's a fine editor but lacking integration keeps me from using it more. I would think that from the developer's perspective using existing tools is a good idea, because then one can concentrate on the essential. From the user point of view being able to swicth from one tool - digiKam - that is great for one thing, to another, say Dolphin, Marble or Gwenview, which has different strenghts, is a motivation to use the stuff. At the moment the issue seems to be that XMP is malformed RDF, and thus 1-10% of the XMP metadata is in danger of being lost in conversion to RDF. The sooner we get a uniform access to the metadata, the better. Therefore I really look forward to integrating all these great new digiKam features into the wider desktop, so that I can keep on using it when the stable KDE4 release comes out in the fall.
Re: Database? Metadata? Strigi/Nepomuk integration - andy - 2008-04-03
What I fail to get is why it is important that applications ship with KDE4.x. aptitude install digikam should work, no?
Re: Database? Metadata? Strigi/Nepomuk integration - cruzki - 2008-04-03
Yes, but you lost the advertising of a full release. And worse, you can miss the release of digikam if you are not trakking the web or similar.
Re: Database? Metadata? Strigi/Nepomuk integration - andy - 2008-04-03
apt-get update ??
Few more screenshots - m. - 2008-04-02
Few more screenshots of new Search interface by Marcel: http://digikam3rdparty.free.fr/Screenshots/NewSearchTools/
KDE 4.1? - Jeremy - 2008-04-02
Looking at the photos, I am very impressed on the work of digikam. Will Digikam make it into the release of KDE 4.1? They said September and I thought KDE 4.1 was due in 2 months but I could have my dates wrong. lol. And freaking great work, Digikam pops with the black color scheme.
Re: KDE 4.1? - Jeremy - 2008-04-02
Forgot to ask, but how is the integration with Nepomuk? I saw the five star ratings already and I'm excited. :D
Re: KDE 4.1? - DanaKil - 2008-04-02
not done yet, the rating is internal to digiKam look here for a response : http://dot.kde.org/1207150254/1207169696/ :)
Re: KDE 4.1? - Gilles Caulier - 2008-04-02
Neopumuk : see my previous comments about this subject. Also, digiKam support rating since many year (:=))). We don't need neopumuk for that... Note : i sync KDE3 and KDE4 version when it's possible. 0.9.4 version will come before this summer with a lots of improvements like simpler entry of tags, or a new time-line tool. See my blog entry for details : http://www.digikam.org/?q=blog/3 Gilles Caulier
Re: KDE 4.1? - nice - 2008-04-03
i vote for nepomuk integration too :-) will be really cool if it recognizes people on photos... many digikam from today can do this feature ! , would this be possible ?
Re: KDE 4.1? - Riddle - 2008-04-05
I vote for Nepomuk, too. It'll make DigiKam smaller, and better integrated.
Re: KDE 4.1? - dk - 2008-04-05
x2! It would be a great addition!
Re: KDE 4.1? - Gilles Caulier - 2008-04-02
>Will Digikam make it into the release of KDE 4.1? Impossible. There still too many regression tests to do. Sorry... Gilles Caulier
Re: KDE 4.1? - Jeremy - 2008-04-03
Meh, completely fine with me. I rather you finish the development then release it too early. I'm not a fan of the release early(when buggy) and release often(when should've been released).
image version control - Martin - 2008-04-03
The #1 thing I'd like to see in Digikam is some form of version control, that lets you go crazy and touch up your pictures while preserving, at least, the original picture. These issues were discussed at length here[1], but all that came out of that particular bug was a confirmation dialog when saving an image from the image editor. Don't laugh now, but this is the most important thing that is keeping me from migrating my parents to Linux. Here is the scenario, that would apply not just to parents but to any user lacking very strong self-discipline: They find a picture that they like, so they fix it up a little. Apply red eye. Crop it. Tweak the colors and contrast. Make it look better on the screen. That's what Digikam invites you to do. Now they decide that they *really* like the picture, so they ask me to come over and help them make the most of it for printing. And then it is ruined, because of the sloppy, lossy editing that they already did. And that's not their fault, imho, but that of the software that is too unforgiving. [1] http://bugs.kde.org/show_bug.cgi?id=103350
Re: image version control - m. - 2008-04-03
That is planned as "next big thing". 0.10 has already so many great features that need testing, testing, testing. Versioning thing has to be rock stable and reliable, it will require much effort.
RAW: the wrong way to do it - anon photographer - 2008-04-03
Honestly, if you guys need RAW users to jump onto digikam, then you need to learn why on earth one uses RAW. The way digikam works on RAW files is plain wrong. You are planning all this for the average shooter, but the average user doesn't use RAW, because he/she just doesn't need the overhead of work and diskspace. Those that do use RAW, honestly, don't do autowhitebalance. One ofthe main purposes of RAW is precisely being able to manually correct white balance when the camera's autowhitebalance goes wrong, being able to fix highlights and shadows, curves... without loosing quality "thanks" to the camera's extra processing. When I see shots like this one: http://digikam3rdparty.free.fr/Screenshots/RAW16bitsAutogamma/1.png First, I read "it's not bad!". Well, it is bad, real bad. The left shots from digikam are washed out,flat, not contrasty at all. Lightzone one looks properly exposed and all lines are rather defined, contrasty. Then, I wonder why you had hidden the righthand toolbar from lightzone. I'd love to know how you are comparing results, ie, what you exactly did to them, why Lightzone gets it right and why showfoto didn't. So the issue is only about accuracy? No. Then, what's wrong? digikam's workflow to process RAWs is all wrong, and anyone using RAW workflows should possibly know why. I give a couple hints in the following lines: 1) Digikam opens the raw photo applying the _settings_ found n the digikam menu. If you, like most photographers do, are processing 800 shots and each requires a different setting, you can't go and change the digikam settings in the menu each time you want to open a file, it's toooooo slow. You can't just apply a default white balance and then set white balance _again_ in showfoto. You are doubly processing the image and thus loosing quality. 2) When tweaking raw files, precission is also important. One needs to tweak images once and again until one gets it right... apply sharpness 1, 1.1, no, 0.9... if I wanted to do this in showfoto, it would require me to process->undo->process->undo->process->undo each time, and each time opening and closing the dialog from the menu. Really slow. 3) It'd take me a whole month to process 100 shots using digikam/showfoto's procedure shown on the previous comment. The average raw shooter takes around 1000 shots for a session and needs to process those in a single day, not spend a whole month on it. it's about fast batch processing. If it were this slow with any other apps, people would end up using jpeg instead. So honestly, if you want to do RAW, you guys need to learn what RAW is for, and how real users use it. Showfoto coders seem to ignore users here, unlike other opensource projects around. Sometimes coders just forget that they need to approach their customers/users to check what they really neeed... My 2 cents. u
Re: RAW: the wrong way to do it - anon photographer - 2008-04-03
Good thing to know though, that they are actually learning from other good projects like Lightzone
Re: RAW: the wrong way to do it - Fri13 - 2008-04-03
"Then, what's wrong? digikam's workflow to process RAWs is all wrong, and anyone using RAW workflows should possibly know why. I give a couple hints in the following lines:" I would like to see rawstudio ideas taken to DigiKam's RAW editor, where you can have thubbar (already) showing all images and then make a three different versions from one image and fast switch them to see if one is better than other. And let this window/application to mark those good versions and then apply it to images what are in database. I like the idea that first user just imports images to database, add's few info like albumb name, and then from database, is started the real RAW processing where user open all images and can set one setting for all or process everyone with own custom settings. Mayby biggest "flaw" what i can find from digikam is it's editing window, possibilities are GREAT but own window for every edit function and preview window is small by default etc. Mayby i would do somekind mockup for it. If would be possible to get showfoto work so it's editing goes in it's own window, or is it somekind technical limit?
Re: RAW: the wrong way to do it - anon photographer - 2008-04-03
>I would like to see rawstudio ideas taken to DigiKam's RAW editor, where you >can have thubbar (already) showing all images and then make a three different >versions from one image and fast switch them to see if one is better than >other. Yes, the thumbnail bar is the common method used on all otheer RAW processors, including commercial ones like bibble pro (by Bibble labs), lightzone (by lightcraft), lightroom (by Adobe), Aperture (by Apple), rawtherapee ()... Also common, even on the still-baby rawstudio, that you can copy paste settinsg from one photo to another leaving the raw file untouched, and without generating the final jpegs yet. But this doesn't seem to be in their plans, given the structure they are following
Re: RAW: the wrong way to do it - Gilles Caulier - 2008-04-03
>When I see shots like this one: > http://digikam3rdparty.free.fr/Screenshots/RAW16bitsAutogamma/1.png > First, I read "it's not bad!". Well, it is bad, real bad. The left shots from >digikam are washed out,flat, not contrasty at all. Lightzone one looks >properly exposed and all lines are rather defined, contrasty. It's not too bad. I said again : http://digikam3rdparty.free.fr/Screenshots/RAW16bitsAutogamma/1-preview(JPEG).png ==> the preview of JPEG image embeded in RAW file. No auto gamma/Wb are set here. The image is displayed as well. http://digikam3rdparty.free.fr/Screenshots/RAW16bitsAutogamma/1-editor(RAW).png ==> the RAW image decoded in digiKam with 16 bits color depth + auto-WB + auto-gamma. It's look very similar no ??? >So the issue is only about accuracy? No. > Then, what's wrong? digikam's workflow to process RAWs is all wrong, and >anyone using RAW workflows should possibly know why. Certainly no. There is 2 RAW workflow : 1/ a fast way with all auto settings for less important pictures. 2/ a slow way using color management where users can adjust all (gamma, WB, etc..) Both are possible in digiKam ! >So honestly, if you want to do RAW, you guys need to learn what RAW is for, >and how real users use it. Showfoto coders seem to ignore users here, unlike >other opensource projects around. >Sometimes coders just forget that they need to approach their customers/users >to check what they really neeed... And you forget than i'm _also_ a photographer and i _always_ use RAW format to take pictures. Thanks for the tip, but i don't need to really read something like that... My 3 cts! Gilles Caulier
Re: RAW: the wrong way to do it - anon photographer - 2008-04-03
>==> the preview of JPEG image embeded in RAW file. No auto gamma/Wb are set here. The image is displayed as well. okay, this was confusing. Certainly embedded jpeg files cannot be compared to a processed image. >2/ a slow way using color management where users can adjust all (gamma, WB, etc..) Even slower?? The process about processing RAW is slow by itself. The point is making it fast by applying a proper workflow. Btw, I tried that plugin, I hope you get it right, since it wasn't doing anything last time I gave it a test. >And you forget than i'm _also_ a photographer and i _always_ use RAW format >to take pictures. If you are using RAW on a daily basis, you sure noticed the way digikam works with RAW files isn't usable. I was questioning you guys on why you follow this way of coding. You know (since you use RAW often), that it's not comfortable. Just too slow for a daily usage. Right now there are much better free alternatives like rawtherapee, ufraw or rawstudio for this task. I myself even, and other coders (yes, I do code, and I have done code for digikam), have addressed at you issues in the past and even offered code for doing a proper RAW workflow. But you seem to ignore all of us. Why so? If you really want to promote RAW in digikam, maybe some tweaks must be done and help from others offered in the past accepted.
Re: RAW: the wrong way to do it - Gilles Caulier - 2008-04-03
>If you are using RAW on a daily basis, you sure noticed the way digikam works >with RAW files isn't usable It perhaps unsuitable for you, not for me... > I myself even, and other coders (yes, I do code, and I have done code for >digikam), have addressed at you issues in the past and even offered code for >doing a proper RAW workflow. But you seem to ignore all of us. Why so? Really. I don't remember somebody like you to post patch or any coding help. Try again... Gilles Caulier
Re: RAW: the wrong way to do it - Alexandre - 2008-04-03
> Certainly no. There is 2 RAW workflow : There a more of them in reality :) > 1/ a fast way with all auto settings for less important pictures. Yes > 2/ a slow way using color management where users can adjust all (gamma, WB, etc..) Using what? Gilles, for heaven's sake please tell me you did mean something else :) Terminology is the key :) Though I don't buy into the previous guy's harshness regarding workflow, I tend to agree that digikam basically lacks proper workflow. - can digikam load >2 pictures simultaneously on light table? (I do remember, you said it takes too much CPU/memory or whatever :)) - can digikam generate cache (full-size previews) so that a picture would not load every time from a RAW file? - can digikam copy/paste processing parameters? - does digikam allow non-destructive cropping/straightening/WB/etc. with batch export? Well, I'd say - "no" to all of the above. This is a pity. What is even more pity is that digikam relies on the aged model of dialogs whereas everybody (and rightfully so) is moving to sidebars with expanders. Cropping via dialog is so 90s! :) Seriously, digikam has most of pieces in place to become a great RAW workflow product. It just needs better UI + some functionality. Currently I'm bound to use Rawstudio for sorting, UFRaw for actual processing and F-Spot for managing the library. This is a nightmare. This should be stopped. P.S. Please do something to make cyrillic XMP tags work properly ;-) P.P.S. I hope to see you at LGM3 ;-)
Re: RAW: the wrong way to do it - Gilles Caulier - 2008-04-03
> P.P.S. I hope to see you at LGM3 ;-) No. I have no money to pay travel + hotel from France to Polish. Sorry Gilles Caulier
Re: RAW: the wrong way to do it - Boudewijn Rempt - 2008-04-03
Have you asked KDE e.V. for sponsorship? And if the e.V. board declined (and if so, I really want to know why!), the LGM organizers themselves? They are now holding a big donation drive to be able to sponsor as man developers as possible: http://pledgie.com/campaigns/613.
Re: RAW: the wrong way to do it - Gilles Caulier - 2008-04-06
Boudewijn, I have sent an email saturday to KDE e.V about this subject. No response yet... Gilles Caulier
Re: RAW: the wrong way to do it - Tobias - 2008-04-04
If it just the money, please ask the KDE e.V., Boudewijn Rempt (Krita) is sponsored by the e.V. too.
Re: RAW: the wrong way to do it - Gilles Caulier - 2008-04-03
> P.S. Please do something to make cyrillic XMP tags work properly ;-) XMP != IPTC. XMP use native UTF-8 encoding. There is no problem with Cyrillic char normally... Gilles Caulier
Confused? - Amarok?? - Max - 2008-04-03
I'm confused. I thought Amarok was rewritten from scratch for version 2.0. Wasn't it? Please clear it up. Maybe even a separate Amarok update post. I'd rather see false rumors floating around Amarok. A lot, and I mean A LOT of people are waiting and looking forward to this great change that is Amarok 2.0. Quite a few people on campus are predicting that it will be BIGGER THAN WINAMP used to be before AOL let Winamp fall by the wayside. Finally something that will blow iTunes out of the water...
Re: Confused? - Amarok?? - Max - 2008-04-03
I meant "I rather NOT see false rumors floating around." Gosh, I'm tired. bedtime..
gallery plugin - richlv - 2008-04-03
what are the plans on gallery integration plugin ? what i would ideally like to see, a complete sync of digikam/gallery, so any changes in digikam can be synced to gallery instance, any comments in gallery can be synced to digikam etc ;)
Re: gallery plugin - Colin Guthrie - 2008-04-03
Hi, Well, I've had a hard time of it of late and there has been little progress. I apologise for that. It's still somewhat in flux to be honest. With KDE4 there are so many new techniques and technologies that I'm really struggling to work out the most appropriate way to do this. I've raised a couple of questions to other developers in the past about the use of such techniques but I've not had a huge response (not that I've really pushed it hard as I have not got the time right now to do much about it anyway). My current lines of thinking are such. 1) I want a nice sync framework that goes beyond Gallery and applies to other web services e.g. Facebook, Flickr etc. etc. as well as e.g. a file or a CD ROM for achieve. The principle is in itself applicable to a lot of things. 2) Other approaches are out there and I want to make sure myself (or others) pick the right model for this with regards to Digikam/KIPI and (more widely) KDE4. A good example of this is Conduit. It is a separate program aimed mostly at Gnome (although there is some vestiges of a Konduit project, it's pretty hard to find out any info about). It integrates to libopensync and can upload FSpot pictures to e.g. Flickr and Facebook etc. I quite like this approach and it may be worth doing. 3) Nepomuk. To me this is the biggest interest but I'm not fully appreciative about what is is capable of at present, but I have a "feeling" this is the right way to go. However, this is a *huge* change IMO and not one that is likely to happen overnight. To explain: Nepomuk is a PIM (personal information management) abstraction in KDE4. It's designed such that you can build e.g. contact systems and email clients on top of Nepomuk and it makes your personal data available via predefined interfaces. This allows lots of interesting things to be done in applications and with e.g. plasmoids etc. too. I attended the Nepomuk talk at Akademy and was quite impressed by the principles. The talk focused on the traditional PIM information like contacts and emails. I asked a question enquiring where the developers saw the boundaries of this API as it could be applied to applications such as Amarok or Digikam. They devs responsed saying that indeed this was possible, but they've not targetted these apps at the moment as it was early days. I'm pleased to say that the Amarok crowd now have a GSoC project that aims to build in Nepomuk support there so things are happening along the lines I envisaged (hopefully this project will be a success!) In my mind we could create a Nepomuk profile for "Images and Videos". We could then impelment a Filesystem backend for this and retarget Digikam to use this. In theory Digikam could then have "accounts" (just like an email application has multiple IMAP accounts) and you could plug in a Nepomuk backend for Facebook, Gallery etc. etc. This would be IMO the holy grail implementation and it's this dream that's (in part) causing me not to progress with the work done to date. Hopefully I'll find time to explore the options properly with the main devs, but this approach changes a lot of the fundamentals of Digikam and KIPI as a whole and I feel I'm certainly not qualified or capable (both technically and time wise) to push this approach. Hopefully some of the core devs will take up some of the ideas and either implement them or blow them clean out of the water. Either way it would let me move on!! Cheers Col
Re: gallery plugin - Colin Guthrie - 2008-04-03
I have to reply to correct myself. Having been "out of the loop" for a while I've talked myself into misremembering project names etc. The project I saw at Akadamy that I thought would be interesting for DigiKam/Amarok is actually Akonadi: http://akademy2007.kde.org/conference/talks/55.php I'm totally confused now, as I have posted several messages with incorrect premises relating to nepomuk when it's not relevant to what I had in mind!!! Damn all these silly project names and damn my crap memory.... Will have to reread things soon to see where it's at! Col
16bit? Heh - Alexandre - 2008-04-03
> Digikam is also the first open source photography tool with 16-bit colour depth support This is simply not true. You guys forgot Cinepaint.
Re: 16bit? Heh - Gilles Caulier - 2008-04-03
16 bits color depth is already supported since 0.9.0 stable release, not only current one ! 0.9.0 have been released at 2006-18-12... Gilles Caulier
Re: 16bit? Heh - Alexandre - 2008-04-04
Gilles, I do know it's been around since 0.9.0. I even wrote a thorough illustrated review of that version in RU :) But Cinepaint is around for a quite longer time ;-)
Re: 16bit? Heh - Boudewijn Rempt - 2008-04-04
And Krita (with 1.5.0, 11-4-2006). But digikam still rocks!
Re: 16bit? Heh - Alexandre - 2008-04-07
True :)
Sidebars - Parminder Ramesh - 2008-04-04
Thanks very much for this - looks much more powerful than f-spot! Just wondering, is it possible to replace the sidebars with the weird text rotated 90 degrees with something better, like an okular-style sidebar? Other than that, the new interface is fantastic! Thanks, Parm
scaling hell - pisa - 2008-04-08
Is it now possible to scale a small image to fit the screen (with anti-aliasing) by default? The gwenview guys seem to not know how this is done and you have to zoom in yourself at every image (very annoying considering collection of >10000 pics) and even so, only at fixed intervals (150%, 200%). THIS IS UNACCEPTABLE. You can add all the maps in the world and still not achieve your core functionality of displaying the damn inages WELL.
Re: scaling hell - Boudewijn Rempt - 2008-04-08
First, this article is about Digikam, not Gwenview. Second, the tone of your comment is unacceptable. Nobody will want to spend their free time implementing things you shout for, which means you will have to offer your own time to implement it. And, given your incivility, you will then have a hard time finding people prepared to interact with you enough to accept your patch.
Re: scaling hell - Anon - 2008-04-08
Are you always this rude to people who give you things for free? Seriously, what personality disorder do you suffer from, precisely, that makes you think this is a) acceptable behaviour, full stop and b) behaviour likely to endear you to the developers you are entreating?
Re: scaling hell - Gilles Caulier - 2008-04-08
TO DOT.KDE.ORG administrator. We _working_ for Open-Source here. Has lead digiKam developper, i think it's UNACCEPTABLE to read an hurting message like this in this thread! ==> DOT.KDE.ORG need a moderator !!! Gilles Caulier
Re: scaling hell - Holyshit - 2008-04-08
Your messages are reading like LOLCATs. Maybe LOLCODE is for you. http://lolcode.com/ CAN HAS A BOOK TO LEARN HOW TO SPELL ENGLISH ? KTHX
Re: scaling hell - cm - 2008-04-08
Please go away and leave the KDE developers alone.
Re: scaling hell - Holyshit - 2008-04-14
Illiterate developers are illiterate. News at 11.