faq
flatforty
contribute
subscribe
configure
search
rdf
main
|
Posted by m. and Gilles on Wednesday 02/Apr/2008, @08:30
from the all-your-pics-belong-to-us dept.
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.
<
|
>
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
|
Over 40 comments listed.
Printing out index only. |
stab at KDE 4.0 release?
by John on Wednesday 02/Apr/2008, @09:18
|
> 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 :)
|
[
Reply To This | View ]
|
|
|
Google Maps Integration
by Martin Fitzpatrick on Wednesday 02/Apr/2008, @09:41
|
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!
|
[
Reply To This | View ]
|
|
|
openSUSE
by Anon on Wednesday 02/Apr/2008, @10:40
|
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.
|
[
Reply To This | View ]
|
|
|
Thubbar?
by Fri13 on Wednesday 02/Apr/2008, @10:55
|
"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 :-)
|
[
Reply To This | View ]
|
|
|
Wow!
by Joergen Ramskov on Wednesday 02/Apr/2008, @12:47
|
Looks like Digikam is going to ROCK when it arrives for KDE4.
|
[
Reply To This | View ]
|
|
|
Just thanks
by LB on Wednesday 02/Apr/2008, @12:56
|
I really love Digikam, thanks!!!
|
[
Reply To This | View ]
|
Phonon ?
by DanaKil on Wednesday 02/Apr/2008, @13:29
|
hi :)
any plan to use Phonon for the embeded video preview ?
|
[
Reply To This | View ]
|
|
|
Version numbers
by Anon on Wednesday 02/Apr/2008, @13:32
|
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.
|
[
Reply To This | View ]
|
|
|
16-bits is nice for pros, but...
by kwilliam on Wednesday 02/Apr/2008, @13:49
|
... 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.)
|
[
Reply To This | View ]
|
|
|
Database? Metadata? Strigi/Nepomuk integration?
by Yuriy Kozlov on Wednesday 02/Apr/2008, @13:54
|
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.
|
[
Reply To This | View ]
|
|
|
Few more screenshots
by m. on Wednesday 02/Apr/2008, @14:15
|
Few more screenshots of new Search interface by Marcel:
http://digikam3rdparty.free.fr/Screenshots/NewSearchTools/
|
[
Reply To This | View ]
|
KDE 4.1?
by Jeremy on Wednesday 02/Apr/2008, @14:35
|
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.
|
[
Reply To This | View ]
|
|
|
image version control
by Martin on Wednesday 02/Apr/2008, @16:11
|
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
|
[
Reply To This | View ]
|
|
|
RAW: the wrong way to do it
by anon photographer on Wednesday 02/Apr/2008, @18:13
|
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
|
[
Reply To This | View ]
|
|
|
Confused? - Amarok??
by Max on Thursday 03/Apr/2008, @00:41
|
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...
|
[
Reply To This | View ]
|
|
|
gallery plugin
by richlv on Thursday 03/Apr/2008, @01:20
|
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 ;)
|
[
Reply To This | View ]
|
|
|
16bit? Heh
by Alexandre on Thursday 03/Apr/2008, @05:00
|
> Digikam is also the first open source photography tool with 16-bit colour depth support
This is simply not true. You guys forgot Cinepaint.
|
[
Reply To This | View ]
|
|
|
Sidebars
by Parminder Ramesh on Friday 04/Apr/2008, @01:30
|
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
|
[
Reply To This | View ]
|
scaling hell
by pisa on Tuesday 08/Apr/2008, @05:11
|
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.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|