Towards a simplified mono workflow, and more Bibble wibbles

(I originally wrote a long screed about the gradual cessation of my photography due to the huge backlog of images waiting to be processed, but I'll save that whine for another day. This is an extract based on finding a way to churn through less important images with less effort.)

What I Need Is: a quick way to convert a digital image to (pleasing) monochrome, optimise levels, sharpen, tone it and scale it for web output. This is mainly for my photoblog, Unpopped, which was originally supposed to be a low-maintenance way to explore new topics and subjects but has lately either sucked up inordinate amounts of time in precise image treatments or ground to a halt due to an absent workforce.

Oddly, the answer turned out to be Bibble, which I'd previously tended to dismiss because of the rather eccentric UI and the lack of precision editing capabilities. The UI issues remain, but Bibble is actually good at the thing it's designed to do: process images in batch. And, with the recent addition of some good monochrome plugins, it can turn out a decent B&W digital result.

The solution is simply to develop suitable settings in Bibble, save them and apply them via a batch queue. "Suitable" might be:

• Auto levels (or Perfectly Clear);
• Moderate sharpening (skip noise reduction - converted to mono, it will look like grain, and scaled down it will probably be smoothed out anyway);
• Optionally, a standard crop size;
• Optionally, output scaling to web size;
• Negative vignette correction to darken the corners of the image;
• Using the Andy plugin, apply a suitable film choice and contrast (it's easy to overdo this);
• Using the Tony plugin, apply a slight hint of ink and/or paper toning (e.g. cool toned paper, warm toned ink).

I find that digital images often benefit from one third to one half stop underexposure as well, to preserve the highlights and increase their drama. Save these settings as a group, then create a batch queue that applies them and saves the output to a relative subdirectory. If you've selected scaling, then save the output in TIFF format and use the ImageMagick convert -unsharp option to convert each file to JPEG with some output sharpening applied for a final image. Result: instant B&W digital images of a passable standard without the hassle of hand-printing each one (equivalent to lab-processed chromogenic prints). If you've scaled them, they're ready for web upload. If you want prints, upload the full size output images to a lab.

The danger, of course, is that one thinks "Maybe I'll just tweak the curve to darken that sky, and apply a touch of fill light while I'm at it, or perhaps...", and the next thing you're firing up LightZone. And then you're back where you started; too many captures, not enough time. I don't claim this method will produce beautifully rich and tasteful monochrome prints equivalent to the best darkroom work, but for me it means the difference between being paralysed by overproduction and having any work to show for all that shooting at all - if you're not producing at least some presentable images, what's the point of continuing to press the shutter?

Thankfully, this means I've found a niche role for Bibble in my workflow. The program continues to frustrate when used for any appreciable task. A short list of flaws:

• Did I mention, the interface is frankly mad? Enable the all-knowing Perfectly Clear algorithm, and then try tweaking the result with highlight recovery or something similar; Perfectly Clear is immediately disabled. I realise that it's supposed to be a one-stop solution towards optimising the image, but this behaviour isn't explained anywhere. Time and again, Bibble does the unexpected thing.
• The behaviour of Perfectly Clear is anything but. Supposedly it applies a "simple but powerful set of image optimizations" with one click, including exposure, colour, contrast and sharpening. But if I then adjust Bibble's individual controls for those factors, where am I starting from? The base image? The Perfectly Clear-chosen setting? Or are they additive? Is this why it becomes unselected when any further changes are made? (But then, why can it be re-enabled without affecting the altered settings?) It would be plainer if Perfectly Clear explicitly changed all the Bibble controls according to the "optimal" settings, leaving the user to tweak them further if desired. Or, if this isn't technically feasible, provide a new function that auto-adjusts the controls.
• One revelation that explained a lot: Bibble manages its own windows within the main frame. The Browser view? That's a window within the Bibble window; the tool tabs are outside it. Double-click a thumbnail to bring up the full-size image? That creates a new Image window that overlays the browser - move things around a bit and you'll find a title bar with a close button. I.e. Bibble has a Photoshop-style UI, but because the subwindows tend to be larger than the available viewport, this isn't obvious (you typically can't see the edges of the windows because they're hidden).
• At one stage, every time I started Bibble I got three duplicate B&W plugin tabs appearing, which I would immediately close using the X icon at top right - and then wonder why they reappeared on the next initialisation. I should have been selecting "Remove" from the tool menu - not obvious.
• Try copying the (unchanged) White Balance setting from one image to another; it appears to copy the WB mode (e.g. "As shot") rather than the actual colour temperature. In a literal sense, this would be correct - but it's not what was intended.
• The image rotation setting is ambiguous. By default, Bibble autorotates each image according to the EXIF orientation data, changing the Rotate setting to match what it did (e.g. "90 CW"). But if you copy the rotate setting to another image, it overwrites autorotation with the hardcoded setting, which may not be appropriate. This can cause no end of grief in batch operations, particularly when height or width-based scaling is applied too. "Autorotate" should be an explicit setting, meaning "do whatever the orientation field indicates".
• The output sizing fields in a batch queue set both width and height explicitly, rather than letting you set one and sizing the other proportionally. (And how do "width" and "height" apply to differently-oriented images anyway? Suppose I want "the longest edge" to always be a set size, regardless of where it is?)
• Despite claims to the contrary, and the presence of an enabled "Export IPTC" setting, Bibble appears to strip IPTC data from the output. (It did so consistently with a test NEF file to which IPTC fields had been added, and I've never seen this data remain in any other output.)
• The "Save" dialogue remembers the last-used directory, rather than starting from the same parent as the original image. OK, this might be a "feature", but it's bloody annoying when you want to keep source and edited images in the same place. (This behaviour is configurable in LZ.)
• Generally, whenever I quit Bibble, it crashes. This isn't a showstopper - I was exiting anyway - but it doesn't suggest the most stable program. (And yes, it has been known to crash mid-session too.)

Pretty much all the major annoyances with Bibble could be addressed if Bibble Labs simply let a usability expert loose on the program for a while, along with a few controlled test groups, then went away and implemented all their recommendations. That would do much to close the numerous yawning gaps between expected and actual behaviours.

Other bubbles

• Pluginmeister Sean Puckett's Andy and Tony plugins for Bibble.

Short review of Mapivi

After my last round-up of Digital Asset Management applications on Linux, Martin Herrmann sent me an email about his own program, Mapivi, currently at v0.9.1. After an initial adjustment period, I've since started migrating my image management to this application.

Mapivi is written in Perl/Tk. I found the default font choice was too large initially, resulting in windows that wouldn't fit on the screen, but this was quickly cured via the preferences. It has an interface split into multiple panes, which can be reconfigured in various ways via keyboard shortcuts.

The Good

• Mapivi's IPTC support is first-rate. It allows you to set most if not all the standard fields, including ByLine and Location info. It supports hierarchical keyword tagging via the "join" option, which means that an image tagged, say, "Family.Rixon.Ade" will appear in searches for either the person name, the family name or all family-related images. There's a choice of two IPTC editing dialogues, either "Simple" or "Professional"; I found the simple one captured all the detail I required.
• There's a huge feature list; it supports virtually every operation you'd want to apply to an image (or group of images), including some rudimentary manipulations based on the ImageMagick tools. I tend to do this kind of thing in a proper editor, but the option's there if you want to try some quick changes.
• Image display is quite nice, with the option of EXIF data overlaid on the preview.
• There's a clever "tag cloud" display, to indicate the relative occurrences of different tags.
• Performance is reasonable, with the option to tune various aspects such as the number of thumbnail generation subprocesses.

(There's a lot more to it than this, but these were the highlights for me.)

The Not-so-good

• IPTC and tag editing feels a little clunky. As far as I'm aware, there's no drag-and-drop capability alá jBrout (possibly a limitation of Tk). You'll spend a lot of time scrolling up and down the tag list (which is alphabetical), and expanding or shrinking hierarchies. You can save IPTC "templates" and then merge them with a batch of images, but if you wish to customise the template, you have to apply it and then re-edit the IPTC data; this causes two (time-consuming) image write operations. It would be nice if a template could be loaded into the IPTC edit dialogue directly, as a starting point. Nicer too if the template names, or the most-recently used ones, could be selected directly from the menu.
• Mapivi supports IPTC "categories", but the FAQ advises that these are deprecated in favour of keywords and should be avoided; I only read this after I started using them, but fortunately not too late to abandon their use. It would be a kindness if this feature was hidden unless explicitly enabled.
• Again before reading the FAQ properly, I used an accented character in an IPTC location field - big mistake. So far, I haven't been able to remove or replace that data in some of the affected files, and ExifTool thinks the IPTC data is broken. Maybe Mapivi should strip out or convert any non 7-bit ASCII from the fields before inserting them.
• It would be nice if it were possible to maximise the number of thumbnails displayed (e.g. in a matrix). (This may be a supported configuration; I haven't looked into it closely enough yet. The only thumbnail display option appears to be a vertical list.) With the default view, there's a trade-off between the size of the preview pane and the amount of data visible next to each thumbnail, since they compete for window space. (Note that the preview can be disabled and images opened in separate windows via a middle button click.)
• A minor personal nit: installation is trivial (just unpack the archive and run mapivi from within it) but doesn't appear to conform to the typical GNU-style bin/lib/share layout (everything is in one directory, which can't be split). I wonder how you'd package Mapivi into a system RPM or DEB archive? (This may explain the apparent absence of Mapivi packages for distros.)
• Only JPEG support at present, although Martin indicated that he was working to integrate Image::ExifTool to support more formats; achieving this would put Mapivi way out in front.

Apart from the interface issues, my beefs with Mapivi are minor. Given the feature set and capabilities of this software, it's hard to conceive of using anything else for a Linux DAM solution at present.

On a related note, I also took another look at digiKam which, from v0.9.0, now supports IPTC tagging. Unfortunately, that was about the only IPTC feature it supported and even that support was minimal (you can view IPTC data but not edit it, and the support feels tacked-on). It still uses the annoying paradigm of wanting to "own" all your images under one directory and then "import" (copy) any new ones from outside, although allegedly it has support for files stored separately on offline media (the documentation doesn't appear to cover this). (You can tell it that its "albums library" has the same path as your existing image archive, and it will scan the directory, marking each subdirectory as an "album".) To be fair, it has full 16 bit support, a nice set of plugins and wide raw format support via dcraw. Even so, it still wouldn't be my choice at present.