Stuart Herbert | Gentoo

After Luca’s blog entry about Digikam, I decided to take a quick look at it this afternoon.

Installation is easy enough (this is Gentoo, after all ), but don’t forget to also install the media-plugins/digikamimageplugins package. Without the extras included there, Digikam’s somewhat castrated, and you won’t get to see what the package can really achieve. (I didn’t realise this package existed first time around, and I suspect I won’t be the only one. Adding a ‘plugins’ USE flag to media-gfx/digikam would be a very helpful hint to Gentoo users!)

Digikam seemed quick enough importing my picture library. Like F-Spot, whilst the import is going on, you can’t use Digikam for anything else. Picasa lets you access your existing albums whilst you are importing new images, but that’s hardly a killer feature

Although Digikam comes advertised as supporting RAW files, I had no success this afternoon. Digikam didn’t give me the option of importing Nikon NEF files from disk at all. There’s no external dependency on dcraw; Digikam ships with its own C++ port of Dave Coffin’s original C code. Picasa will at least import RAW files, even if the EXIF-stripping problem makes the imported image undesirable. I’m guessing that Digikam’s RAW support is currently confined to importing RAW files direct from a camera, rather than handling them on disk. The handbook also states that RAW support is limited to thumbnail viewing only; there’s no support for RAW files in the image editor.

The rotation tool can be found in the Image Plugins. Unlike Picasa, it doesn’t offer a freehand rotation feature. With this plugin, rotation happens in a dialog box, where you can specify the amount of desired rotation using a slider or by manually entering the required angle of rotation. A handy preview is shown, to help you get the image rotated just right. I found Picasa’s freehand rotation much nicer to use, partly because it’s really freehand, and partly because you’re not working on a smaller preview image. Digikam doesn’t overlay a grid at all, making it just little bit harder to get your horizon lined up truly level

Like Picasa, there’s no equivalent of Photoshop Element’s Healing Tool in the standard Digikam. The Inpainting Plugin is the closest Digikam has, but it’s most useful for painting over items in an otherwise clear sky. However, unlike Picasa, Digikam comes with a number of plugins (Unsharp Mask, Hot Pixels Correction, Lens Distortion Correction, Restoration, Refocus, Noise Reduction and Anti-Vignetting) which photographers will find very useful.

Digikam’s colour correction in many ways is better than Picasa. There’s great support for adjusting the levels of individual colour channels - a feature sorely lacking in Picasa. However you want to edit your colours, Digikam supports it … except for one. Photoshop Elements (and Picasa) allow you to adjust the colour balance by selecting an area of the image that is intended to be black, white, or grey. Elements analyses the colour tint of the selected area, and uses it to fix the colours in the whole image. It’s a real timesaver, and unfortunately I’ve not been able to find the same tool in Digikam. You can do the same adjustments “by hand”, by editing values in one of Digikam’s many colour editing dialog boxes; but this takes longer, and is more error-prone than having the package do it for you.

As a photo album, I feel that Digikam is weaker than Picasa and F-Spot. Like Picasa, Digikam respects the folders that your images are already organised in (+1 over F-Spot), but I feel that’s about its only good point. Scrolling performance felt worse than F-Spot, with Picasa the clear winner in performance (even though Picasa isn’t a native port). Digikam’s date view tagged nearly all the images by the time of import, rather than the file’s timestamp on disk. When browsing an album, zooming in and out (to increase/reduce the size of thumbnails shown) is via a toolbar, rather than via a slider. I couldn’t find a slideshow feature, but you can click the ‘Next’ button in the image editor to cycle through the

Digikam does have other things going for it. It’s snappy performance-wise. It’s indisputably a native Linux app, which means that (unlike Picasa) you can use it on arches other than x86. With the growing importance of the amd64 arch, that’s an important consideration. (I’m told that Picasa can’t run on amd64 at all, not even in a 32-bit chroot). Like Picasa (and unlike F-Spot) it hasn’t crashed on me yet. And, unlike Picasa, it has a plugin architecture and a growing range of plugins.

One thing’s for sure. With Digikam in the KDE camp, F-Spot very much a Gnone look-n-feel app, and Picasa in neither camp, Gentoo users have a real choice for managing their family snaps. All three apps have things going for them, and hopefully the authors of all three will be taking the best features from their competitors so that we all benefit in future. Digikam should have the advantage here over Picasa, because it’s not that far off (in some areas it’s already ahead), and in being open source it should be able to grow and improve in ways that Picasa’s closed-source (and WINE-based) reality will hinder. F-Spot’s starting from the back of the grid for me; despite being one of the poster children of the Mono project, I think it has some way to go in the image editing department before it’s competitive.

Me, I’m sticking with Photoshop Elements on Windows for now, and I’ll carry on using Picasa when I need a photo album manager on Linux. But I’ll be keeping an eye on Digikam, and when it can handle RAW files from my Nikon D200, I’ll definitely be having another look at it.

For Luis

I hear you over the native port issue; but the question I keep coming back to is this: F-Spot is written using managed code, which needs its own runtime (Mono) in order to function. How does that make it any more native than Picasa, which relies on WINE?

If it’s the Microsoft connection that makes you unhappy … F-Spot also owes its underlying technological heritage to Microsoft, does it not?

I have no numbers to back this up, but having imported the same image library into both F-Spot and Picasa, I’m much happier with Picasa. I find Picasa performs much faster, doesn’t crash at all (unlike F-Spot, alas), and it allows me to see the folders that I have already organised my image library into. Add to that the better editing toolsm and imho F-Spot has been well and truly knocked off any throne it may have been sitting on up to now.

There’s no ebuild for Picasa in Portage yet, but installing Picasa by yourself is trivial. Just download the self-extracting binary, chmod 755 it, and run it. It politely installs itself into /opt/picasa, and very shortly you’re up and running.

Is the hype around Picasa is just a little out of proportion with what Picasa itself can do? As a free photo album and basic photo editor, it’s fine, but to say that Picasa is a viable alternative to Adobe Photoshop Elements (the baby edition of Adobe Photoshop) … well, maybe that’s true for a lot of folks, but it’s not true for me. I’ll be sticking with Photoshop Elements on Windows for the time being, and if you want to know why, continue reading below.

(If you’re reading this article on Planet Gentoo, click on the title of this article to read the full article)

(more…)

NoMachine’s nxserver-1.5 (personal, business, and enterprise editions), and Fabian Franz’s freenx-0.5.0 snapshot are now out of package.mask and into ~arch. Hopefully it won’t be too long before I file the bugs to get these packages marked stable on various arches.

Many thanks to Jon Scruggs and Gentoo’s community of nxserver / nxclient users for putting together and testing these ebuilds. Jon in particular has done a great job of leading this work; I’m hoping he’ll be joining the ranks of Gentoo developers before too long.

(nxserver (commercial product) and freenx (GPL’d alternative) are the nearest equivalent on Linux to Microsoft’s Remote Desktop / Terminal Services. They allow you to access your Linux X11 desktop remotely, and work very well even over low-bandwidth links such as 802.11b and high-latency links such as satellite connections where stock X11 connections are unusable).

I’ve agreed to take on the job of building the ebuilds for Drupal 4.7 for the Gentoo web-apps team.

One of the nice features of Drupal 4.7 is that each of the nearly 200 optional modules comes with its own installation script. In theory, this will make it possible for Gentoo to provide a separate ebuild for each module, allowing site owners to mix and match modules to suit their individual needs.

Hopefully, I’ll get some experimental ebuilds into the webapps overlay shortly.

Thanks to Sebastian, I’ll be going to Zak’s PHP Vikinger unconference in June. This’ll be my first trip to Norway (heck, it’s my first trip to mainland Europe), although I doubt there’ll be any time to do the tourist thing this time around This’ll make quite the contrast to the last PHP conference I attended (Marco’s one and so far only php|cruise).

Kristi’s coming too … she’s going to do the tourist thing for both of us.

PHP Vikinger is (obviously enough) a PHP conference, but if anyone who’s going wants to discuss anything at all about PHP on Gentoo, let me know in advance and that’ll help me be prepared for it.

Today’s a public holiday over here in the UK, and I’ve spent most of it drafting an initial project page for the Gentoo Overlays project, and drafting an initial policy document. It looked like a nice sunny day out the window too, but instead I’ve been wading through my gentoo-dev ML archive, trying to make sure the policy reflects what was discussed earlier in the year.

Thanks to Antarus and Christel, we also have our own channel #gentoo-overlays on IRC.

I’ve spoken with wrobel this morning, and we’re going to be recommending that people use wrobel’s excellent layman app for accessing overlays hosted on overlays.g.o.

The debate about which distributed VCS’s to support - and how on earth we’re going to manage to do so - is continuing in #gentoo-overlays. If you have an opinion, drop by and let us know!

Phase 1 of overlays.g.o will launch with trac & subversion as the offered service. Let’s get that up and running, whilst we look at what alternatives we can offer.

The next step is (still) for me to email Lance with instructions on how we want trac & subversion setup on the box. I was hoping to get that finished today, but I’ll have to finish that later this week. Things are busy for infra atm anyway, so don’t expect to see overlays.g.o launched for a little while yet!