Since some people in the question comments repeatedly told me it was rather trivial, I actually did it: An application that sorts the images in the current directory by leaving the actual head-to-head comparison to the user.1
Written in C# for .NET 2. Works on Mono (tested on Linux so far), too. Requires dcraw on the PATH (compiled executable for Windows or OS X can be downloaded here).
Currently the user interaction is very rudimentary. This is probably subject to change. Also the code is an evil mess as usual with such a hack-job.
The application has to be started in a directory that contains the images to sort. It then proceeds to load all images it can find and handle (JPEG, GIF, PNG, BMP are supported natively, all other formats are either supported by dcraw or skipped if not). Keep the number of images reasonable, as every image is preloaded in memory to speed up display – I tried starting it on a folder with around 600 images and terminated it at around 2 GiB memory usage.
After that you get a two-pane view with an image on the left and on the right. Click on the one that you consider the best of the two. You will then get two new images. Continue until done. You can close the program if you want, it will resume where you left off.
After all necessary comparisons have been done2 the result can be seen:
It has the sorted list of images on the left with the highest-ranked at the top and the lowest-ranked at the bottom.
- Allow selecting the images to sort.
- Solve the issue that portrait pictures are always displayed in landscape orientation (at least for raw images. dcraw allows rotation but cannot do so automatically and I don't see an easy way of finding that out externally).
- Reduce memory usage for large numbers of images.
- Shuffle the images beforehand so bursts of nearly identical images are less likely to be compared directly against each other.
- Change synchronization between the sorting thread and the UI to no longer rely on
Thread.Sleep and polling but to use proper synchronization methods.
- Add a 1:1 preview (or at least a larger one). Currently this cannot be used to judge things on the pixel level.
It's 5:26 here, so I stop hacking on that now.
Source code can be found in my SVN repository and is released under the MIT license. I welcome patches ;-)
Images in above screenshots are my own.
1 Of course it wasn't as trivial as others would want to make me believe. After a long struggle with Libraw, I simply went the dcraw route. Not pretty, but works with minimal amount of code.
2 This is in the order of n log2 n where n is the number of pictures compared – so, for 20 pictures you can expect something around 20 × 4.3 ≈ 85 comparisons – I know, it's not a small number. For the 300 images you mentioned you'd get around 2400. The actual number that has to be performed manually is (a) different (since complexities omit the linear factor) and (b) as far as I observed so far, smaller. To avoid inconsistencies the user will never be prompted twice on the same two images (either order) and never prompted with the same image on both sides.