Looking for Pentax and Kodak RAW sample files

I am currently working on improved RAW photo format support for forthcoming A Better Finder Rename 7.6 and A Better Finder Attributes 4.4.

The biggest problem at the moment is that I have found it difficult to obtain sample images taken with different cameras.

So far I have been able to successfully test with the following file formats:

  • jpeg (with EXIF)
  • crw (Canon)
  • cr2 (Canon)
  • thm (Canon)
  • nef (Nikon)
  • tiff (camera)
  • raf (Fuji)
  • orf (Olympus)
  • mrw (Minolta)
  • dng (Adobe)
  • srf (Sony)

I think the code should also be able to work with:

  • dcr (Kodak)
  • Panasonic RAW format files

The problem is that I can seem to find any .DCR or Panasonic RAW sample files to test with anywhere on the internet.

If anybody has got a Kodak or Panasonic camera that use these file formats, could you please send me a file or two via email?

You don’t need to worry about the attachment size at my end. Should the files be too large for your mail reader to send I can arrange FTP access to my site for you.

I would really appreciate your help.

Best regards,


A Better Finder Rename 7.5 tidbits

With today’s 7.5 release ABFR is now getting towards the mid-way point to the next major upgrade and it is time to take stock of what’s happened since.

Version 7, of course, was a complete rewrite and that allowed a major step forward to be made. After close to a decade of pretty-much-monthly updates it was high time to do some clean up work.

Looking through the change history since the 7.0 release, a lot of the 14 (!) releases dealt with the fact that version 7 is a stand-alone application as well as a contextual menu item.

The ongoing “Should the Rename Button Quit the Application or Clear the Preview?” saga reared its ugly head again in the recent About this Particular Macintosh (Verdict: “Very Nice!”) review.. if I had one email from everybody who thinks that it should or should not quit, I’d have a lot of emails.. well actually I do.

In version 7.4.5, I thought I had finally settled this dispute by making the behavior configurable along the “Have your cake and eat it” ideology. Now I start getting emails that argue that having to tick or un-tick the check box to change the behavior is a bit sluggish.. ah, well.. how about making both options available via the “File” menu..

Having your cake and eating it with a shortcut key

.. and throwing in a keyboard shortcut while we are at it.

When I rewrote ABFR I left out a few of the more exotic features, some because I reasoned that “nobody is using this stuff”, others were pushed out of the initial scope to make time for more generally useful features.

Version 7.5 should now complete the transition by adding the last missing feature from version 6.9.6: alphabetical sequences are back!

The reasoning behind them is that sequence numbers can take up a lot of space in a file name, e.g. you need 9 digits for the first 10 billion sequence numbers (0..9,999,999,999).

I think this is fine for most people given that your file name can be up to 255 characters long, but it is true that using the 26 letters of the alphabet instead of only 10 digits (suckers) is more compact yet 🙂

In other news, Apple apparently has removed the ability to read mp4 tags of (moderately) “Fair Play”-encoded files from Quicktime and thus the mp3 tag renaming feature no longer works with m4p files. Thanks Apple!

Apple now also seem to be using “bundles” (i.e. files that are actually folders such as OS X applications) for document files in GarageBand and A Better Finder Rename now makes sure that it doesn’t ruin your files by renaming the contents of the bundle as well as the top-level folder.

The “File List” features also see some minor user-requested improvements and that’s all until next month..

ATP Review A Better Finder Rename: Very Nice!

“About this Particular Macintosh” is a phrase that many veteran Mac users will recognize. In OS 9 it was the menu item that let you produce a profile of your Mac.

The eponymous site and e-zine ATP has been around for so long that it has become part of the Macintosh “ecosystem”. I was obviously delighted when they contacted me a while ago to review the latest version of A Better Finder Rename.

The result is an in-depth review in this month’s issue.

The Verdict:


Ok, I’ll try to wipe that smile off my face 🙂

Fun with regular expressions

Regular expressions are amongst the most powerful text manipulation features around. Most dynamic websites that you see around the web are based on programming languages that incorporate regular expression support, such as PHP, Perl, etc. Harvesting this power for file renaming tasks, however, is not so very straight forward. A Better Finder Rename has supported regular expressions for a couple of years now. When the feature was first introduced, I tried to help users figure out what is going on by providing a preview of the various substitution groups of the first file to be renamed. This was miles better than no special preview at all, but fell short of what I really had in mind. Version 7.0 was supposed to have the “new improved” regular expression preview, but the scope of the release just kept growing; mostly due to the mountains of great feedback that I received from my private beta testing group (thanks guys!). Still version 7.0 was a great step forward, even with one or two planned features not making it. Fans of the program will know that I add a new feature pretty much every month and have done so for the past 10 years, so the day had to come when the missing feature would finally make it. Mission accomplished with version 7.3.5 out today. So why are regular expressions so hard? and why are they so powerful? The answer to both is the same: it’s programming with text. Programming is hard; programming is powerful. Regular expressions are a “pattern manipulation language” and their syntax is both super “tight” and profoundly cryptic. Just the way that Unix geeks love things to be. Manipulating text with “reg ex” is a matter of first identifying groups of letters (or “symbols”) in the existing text (i.e. the current file name) and then rearranging the groups and perhaps adding letters (“symbols”) to the “output”. Let’s see a brief example: regx_preview_thumb1.gif As you can see the current name is “hello world” and we simply want to swap both words. First we need to identify the two words. We do this with the pattern “(.*) (.*)”. What does this mean? Well a “.” is a placeholder for any symbol. A ” ” (space) is a placeholder for a space and an “*” means that there may be 0 or more occurences of the last symbol. So “.* .*” is a pattern that matches any text that has a space somewhere. So for instance, “the cat”, “the mouse” and “the cat and the mouse” all match the pattern “.* .*” because they have a space somewhere. “the_mouse” does not match because it does not have a space. A Better Finder Rename will simply do nothing for a current file name that does not match the pattern. In other words, “the_mouse” file will be left untouched. In the screenshot you can see that our pattern is not just “.* .*”, but “(.*) (.*)”. The brackets match nothing but simply enclose a substitution group. These substitution groups can be used in the substitution expression to refer back to what was matched. Each substitution group has a “name”: \1 is the first substitution group, \2 the second, etc. A Better Finder Rename supports up to 8 substitution groups. In our example, we split “hello world” into two substitution groups: \1 which is “hello” and \2 which is “world”. In the substitution field we have put “\2 \1”, which translates into “the contents of the second substitution group, followed by a space, followed by the first substitution group”. In other words, “swap the first and the second words” of the file name. This is of course barely touching the surface of the regular expressions. Things become more interesting when you start “programming” in earnest. Say we want to swap the position of the numbers at the end of some image files in a “clever” way: regex_full_preview_2.gif We are only interested in the numbers, so we say “match all uppercase or lowercase letters” at the beginning of the name up to the first number and put all the numbers into the substitution group \1″. We then use the numbers substitution group in our substitution expression. Voila. Obviously, it isn’t really possible to cover regular expressions in detail in a blog entry. Whole books have been written on the subject. The manual page for the feature has some more details on the syntax, the built-in support and a selection of further reading materials, including some useful books. Most of you will go “oh no this is far too complicated for me” at this point. That’s ok, this is an advanced feature for advanced users: there are plenty of easy to use features in the program and you can achieve most frequent file renaming operations without regular expressions. For the “advanced users” amongst you, however, this will alert you to the presence of the feature and might motivate you to learn a little more..

Poll: Should the “Apply” button become the default button in A Better Finder Rename?

Seasoned A Better Finder Rename users will probably remember the good old days when A Better Finder Rename was “only” a context menu that was neatly hidden away in the Finder contextual menu.

With version 7.0, however, A Better Finder Rename became a full blown “stand-alone” application that may also be launchied via the context menu. This meant that some user interface rework had to be done. Throughout this, I tried to disrupt the working habits of existing users as little as possible.

New users, who have never known the “context menu only” A Better Finder Rename find some of its behaviour a little odd however.

Chief amongst these annoyances is the behaviour of the default “Rename” button. This, most new users feel, should simply peform the rename and stay open. I tend to agree. It’s only logical..

The problem is that when A Better Finder Rename was only a context menu item, it made more sense that it would be behave like the “Get Info” dialog: You make your changes and then the dialog closes, the Finder window shows you the new file names. Neat.

This is the reason why even the latest version 7.3 (for new users “inexplicably”) quits just after peforming the rename.

With the new version I have added an “Apply” button, which performs the rename, empties the preview list and stays open.


Now it is represented to me that this should be the default behaviour, ie. I should get rid of the “Rename” button behaviour and make the “Apply” button’s behaviour the default. Hitting the return key will apply the changes, but not quit the application.

This is of course the request of a user who has not spent the last decade hitting the return key to perform a one key stroke “rename and quit”. My highly scientific “one user poll” shows that 100 percent of existing users don’t want that.

How is a software developer to know which option to choose? Why, he could just ask his users..

So please cast your vote below:

I will probably only change the behaviour if there is a strong (two thirds?) vote in favour of the change..

Changes ahead for the A Better Finder series in 2006

2005 was a year of transition for the A Better Finder series of tools. Most of the year was spent migrating the 60,000+ lines of code of A Better Finder Rename 6 to the brave new world of Objective-C and Cocoa.

I took the opportunity to add many long-requested features, such a detachable preview window, multiple rename steps, etc.. One of the most important changes was to introduce drag & drop installation. The kind people at MindVision have provided me with their InstallerVise installer maker for ten years, but the product was beginning to show its age and its Mac OS 9 legacy.

Enter the 2005 drag & drop style installer. Today all you need to do to install A Better Finder Rename 7 is to take its icon from the disk volume and drop it where you want it. Double-click to start and you're finished. For multi-user installations, simply place the program in the Applications folder and let every user decide which optional features they want to install. This new drag & drop installation is now making its way across the entire product line:

already work on the same principle.

This leaves A Better Finder Select and A Better Finder Creators & Types. Once upon a time, both of these products covered a niche left open by the Mac OS 9 Finder. Today both of them have somewhat lost their raison d'être.

"A Better Finder Creators & Types" allows die-hard Mac OS 9 fans to continue using creator and type codes to associate documents to applications, but this approach, while still supported under Mac OS X, is no longer the recommended way of doing things and does not work with newer applications.

A Better Finder Select allows you to filter out certain files before passing them to other A Better Finder products or it allows you to select them in the Finder; it's functionality is partially covered in the Finder and is at its most useful as a front-end to the other products in the A Better Finder Series.

Is it still really useful to keep them as separate applications? I don't think so. That's why in 2006:

  • A Better Finder Creator & Types' features will be integrated into the new A Better Finder Attributes 4
  • A Better Finder Select's filtering features will be integrated into the preview window of both Attributes 4 and Rename 7
  • A Better Finder Select's ability to pre-select files in the Finder will be integrated into Attributes 4

If you disagree with these arrangements, please post a comment or contact me via email. It is not too late yet 🙂

The advantages I see for you, the user, is that you will have less application clutter, less installation, a smaller download and last but not least will be able to filter out files in the preview window.

Obviously, with the end-of-line of Select and Creators & Types, I'll be offering free cross-grades to the owners of these "late" products.

A Better Finder Rename 7.2.5 Performance Beta

There can be little doubt that version 7 of A Better Finder Rename was a giant step ahead for the product in almost every respect.

The major area where that was perhaps not the case was in performance terms. As long as you are renaming only a couple of hundred files, performance is more than adequate, but for people dealing with many thousands of files the performance of version 7 was a step backwards. This came as a late and unpleasant surprise, because version 7's code base is just so much cleaner and more streamlined than that of version 6, which was beginning to show its age.

This is why I have taken some time out from developing new features to get to the bottom of this performance problem. This investigation has detected a couple of facts:

  • sorting is a real killer, especially when mp3 or exif tags are involved
  • feedback is just as important as raw speed
  • there is no way around the fact that doing the same thing one thousand times takes one thousand times longer than only doing it once

In this first iteration of getting a faster, nimbler renamer, I have concentrated on these points: 

  1. the program now only does the bare minimum processing while you're honing your settings. This makes for a fast and responsive preview even with tens of thousands of files. The preview only displays the first 250 items (that's around 10-15 screenfulls), enough to give you a real good impression of what the end result is going to be, not enough to bring the preview to a grinding halt. The heavy duty processing starts only once you hit the "OK" button.
  2. everything that can possibly be cached is cached. EXIF dates and the like are only read once and the system remembers them without re-reading them every time. This can result in a factor 10-100 performance improvement on large sorts.
  3. provide feedback on what's happening. Previous versions just went off to do their thing, leaving you to wonder what, if anything was going on. The new version provides a progress dialog that shows you how much work is actually going on behind the scenes and how much longer is going to be required to do it.
  4. I have found and eliminated a couple of bottlenecks in the program that result in improved overall performance

As a result of those changes, version 7.2.5b1 feels and behaves completely differently when confronted with huge renames. Yes, doing 2000 files will still take twice as long as renaming 1000, but the preview remains responsive and it's fun to see your Mac race through ten thousand name computations, sorting, validation, etc.

The downside of these improvements is that I've had to make fairly hefty changes to the structure of the program, including multi-threading its execution. Multi-threading, in particular, makes the complexity of a program explode because it causes all kinds of potential error conditions: deadlocks, racing conditions, etc.

This is why I've decided to release a beta version first to validate that my changes haven't broken anything that used to work just fine.

You can download the beta from the product download page . I trust you will find it a big improvement with large file sets.

Please do report any problems you may find; it's tempting to think "somebody else will or has already alerted the developer", but all too often nobody does. I can only fix bugs I know about and the best way of getting rid of them is to report them directly to me at: reiff@publicspace.net