I've been looking for a good backup solution on linux for quite a while now. I've looked at (perhaps too briefly) backup2l, bacula and amanda. While these are all good, well written programs that support full and incremental backups nicely, there's something I feel is missing... I like to backup my stuff onto DVDs (used to be CDs...) I know DVDs aren't the best media for archiving data onto, but it sure is convenient. Everybody has a DVD or CD burner. Most people don't have tape drives, and buying an extra set of hard drives to back stuff onto isn't possible for me, or many other people I expect. The problem is that with all of the programs I've looked at, it wants to do a 'full' backup, or it wants to do an 'incremental' backup. It can't do both. So, as a result, one day I need 10 DVDs for the 'full' backup, and the next day I need 1/10 of a DVD for the incremental. The first is inconvenient and time consuming, the second is wasteful. What I'd really like is a system that filled up one DVD with data. Always. Every time I run it, it fills up exactly one DVD. It should first backup new files, or files that have changed recently. Then it should start backing up files that haven't changed, in order of age since the last time they were backed up. If there is too much new data to fit on one DVD then I should get a warning. If, on average, 95% of a DVD is taken up with new data and it's going to take 10 years to get around to backing up all of the unchanging files, then I should get a warning. Then I can pop in another DVD :) The system should also keep indexes of what files are backed up onto which discs, and make it relatively simple to restore files. It should also be able to do backups over a network. Just for fun you could throw in parity data for the backup archives to make it possible to recover from small media damage. So if anybody out there knows of software that does this, drop me a line :) Otherwise I'm tempted to try writing it myself...

I was really impressed with the 20 minute wiki demo using TurboGears , so I spent a little bit of time today trying to get it running on my laptop, which is running Debian (sid). While I really like the motivation behind EasyInstall / setuptools / eggs, the implementation isn't quite there yet... I spent quite a bit of time fighting with it since I didn't want to install these packages into /usr/lib/python2.4/site-packages. My first thought was to install this stuff into my home directory somehow...Well, I never figured out if that was possible...It seems that python doesn't look at .pth files outside of certain directories, resulting in errors like this when trying to run turbogears-admin: Traceback (most recent call last): File "/home/catlee/python2.4/site-packages/turbogears-admin.py", line 4, in ? import pkg_resources ImportError: No module named pkg_resources So, the way I got it working was to give myself write permissions on /usr/local/lib/python2.4/site-packages, create ~/.pydistutils.cfg with this: [easy_install] install-dir=/usr/local/lib/python2.4/site-packages site-dirs=/usr/local/lib/python2.4/site-packages script-dir=/home/catlee/bin and then run the ez_setup.py bootstrap script to install TurboGears. Everything seems to work for now....

I was writing a tool in python to automatically move images into a directory hierarchy based on the stored EXIF date...Everything was working great until I decided that I should run it on ALL of my images, even those which were already in the correct location. The program as written did something like this: - Oh, you want to move file /pics/2004-12-21/dscn001.jpg? Ok, where should it go? - Based on the date, it should be renamed to /pics/2004-12-21/dscn001.jpg - Does that already exist? Yup! - Do the SHA-1 sums match? Yup! - Therefore I must have copied the file there before, delete the original! That last step, by the way, was added to prevent duplicate images from accumulating all over my hard drive. It works great when the "source" and "destination" files are actually different! Good thing I've got backups. The only problem is that it takes forever to recover as they're all on CDs.

A recent Ask Slashdot story, Professional Photographers Using Linux?, got me thinking about what I'd like to see on Linux in terms of image editing. I use Linux 99% of the time (the only time I boot into windows is to do my taxes...maybe I'll see if QuickTax will work with wine this year), and although far from being a professional photographer, I'd still like to see Linux become a viable platform for professional image editing. In no particular order:

• Colour profile support across the board. GIMP needs to support it, the display drivers need to support it, the printer drivers need to support it. Drivers for calibration tools like the Spyder would be the next step.
• More than 8-bits per channel in GIMP. 16 would be nice, floating point as an option would be better (RAM is cheap, right?).
• A killer workflow / image management app. I'm hoping f-spot fits the bill.
• More polished photo-oriented tools in GIMP. Preview on the unsharp mask would be great. Preview of the dcraw input would be great. Being able to tweak the values of a particular operation afterwards would be wicked. Think editing an operation's parameters in the undo list and having those changes take effect and propagate forwards. Being able to create customized toolbars / dialogs with my commonly used operations would also be great. Right now the top 3 operations I do are: levels adjustment, unsharp mask, and resize / crop. It takes quite a few button clicks to get to these operations right now.

caveat: I haven't tried GIMP 2.2 yet (if it's not in debian unstable, chances are I won't check it out), so some of these things may be done already. They may even be there in 2.0 and I just haven't found them yet! If that is the case, could somebody point the way for me?

Garrett's question at linuxart, What do you do with your images? has generated quite the discussion. Many excellent suggestions being made, including the use of XMP to store the metadata for your images directly within the image files. The advantages of using XMP are that you can move your files around outside of F-Spot (or whatever other image management app), and still maintain information that you've entered about the description, location, etc. Backups become simpler because you don't have to save the metadata seperately. Two possible issues that I can see are:

• All image manipulation must be done in an XMP-aware app, or at least applications that don't blow away the XMP data.
• Support of RAW formats - Adobe's XMP documentation doesn't specifically mention any RAW formats, which makes me wonder if it's possible to use XMP in formats like Nikon's .NEF (which does seem to be a TIFF format, so maybe there's hope).

This does seem like a 180° about face from my last post, but as long as there's an original, unmodified copy of the image somewhere that I can easily revert to, then I'm happy.

<rant> My images are sacrosanct. I do not want image management software to store comments, tags, descriptions or anything else that did not come from my camera inside the image. If you absolutely feel the need to do this in your software, then at least make a copy of the original image. I always want to be able to go back to the virgin image as it first was transferred from my camera. </rant>

The F-Spot project really interests me. I think I first noticed it from Garret's blog. F-Spot plans to do (according to the wiki) many of the things that I've been trying to hack into my photo management app. One area that I'd like to see more focus on in F-Spot is backups. I've been implementing a system that backs up (as part of a generic exporting system) all of your pictures to CDs or DVDs of different sizes. The CD would also contain (enough to fill up the disc):

• The complete index of all the pictures you've taken (dates, comments, categories, etc.)
• Thumbnails for images (those on the CD, and those not on the CD)
• Images that haven't been backed up in a while (configurable - I figured I'd start with LRBU - Least Recently Backed Up)
• Recovery data for individual images, or entire CDs. I was thinking of using parchive (probably v2) to generate the recovery data.

All of the above are useful to ensure that no image is ever lost. Losing a CD shouldn't be catastrophic. Nor should losing your hard drive. Storing the complete index on every backup made means that even if your hard drive gets eaten by your dog, you won't lose all of the time spent organizing pictures into categories, adding descriptions, etc. Storing thumbnails of images that are present on the disc just makes browsing the disc faster. It should be possible to turn any of these options off, or change the ratio of thumbnails to extra backups to recovery data. A few other features that would make F-Spot the killer app for me:

• Flexible directory structure for storing images. I like all of my images to be in folders that identify the date the image was taken. So I've got folders named "2004-10-11", "2004-10-07", etc. But I'm sure that everybody has their own preference, so this should be configurable.
• Batch date adjustment. I often forget to update the clock on my camera when I travel, so as a result the dates stored in the EXIF headers of the image are in EST. It would be great to be able to select a bunch of images and say "offset the time by -1 hour." If your camera's clock was completely off (but still consistent with itself), it would be great to select a bunch of pictures, choose one of them for which you know the date and time, and the program would figure out the correct time offset and apply it to your selected images.

Maybe I'll have to learn C# so I can start helping out with F-Spot myself :)

Unfortunately I've run into this a few times. As Tollef Fog Heen mentions, this is so totally broken. I understand the reason for it...The DB4 library requires write access to the repository files so that it can lock them...Even for a read-only operation. Hopefully the FSFS backend will fix this.

Joe's rant about his shiny new PVR makes me wonder how feasible it would be to get one of the many free alternatives out there working with a digital tuner... Personally I don't think digital TV is worth it right now, at least not with Rogers. All the channels I like are only available in analog, and all the spiffy new digital specialty channels seem like people trying desperatly hard to come up with content to fill all this newfound digital bandwidth. So if you're just talking analog, I think it's far more worth it to buy your own PC with a huge harddrive, a few TV tuners and a TV out card. That way you have control over the software, you can use whatever remote you like (using lirc), and are not limited to just watching TV. Wow, all this from a guy who doesn't even have cable right now...

I always get excited when a new release of python is announced. There are always all sorts of goodies to play around with. One of things I've been following for a while is PEP 318 which provides an easier way to specify class methods / static methods / whatever other kind of method you want. Basically syntactic sugar for wrapping methods. I have to say that among the various proposals for exactly what the syntax should be, the "@decorator" syntax is my least favourite. The '@' character has a definite un-pythonic feel, rather it feels closer to perl or ruby. Having the decorator specified on the preceeding line also doesn't make sense to me...A decorator is part of the function declaration, so it should be on the same line. The pre- or post-argument [decorator,...] syntax really appeals to me, it puts the list of decorators on the same line as the function declaration, and it obviously something other than the list of arguments to the function. Other 2.4 goodies that appeal to me include some nifty keywords to the list sort method ("key" in particular) and generator expressions. Now if only the path module would make it into the standard python library... Just my humble python-user's opinion.