Duke the Photographer wants you!
When you are forced to stop or slow down, as I'm being forced to due to my illness still evolving slowly, you have more time to spend just thinking (yep, this is just a try to catch the good in bad moments). For instance, you can look at the big picture of what you're doing, instead of focusing at a single activity, and see whether things are going in the (supposed) proper direction. In these days I realized that in the latest years I started up a lot of projects (that later went into opensource). Their primary purpose was to experiment with some technologies, and they were successful in this. But as they reach a critical mass and can be useful to others, it's a shame when they starve. And there's a project of mine that's really starving - being its latest release a 1.0.RC5 dated to November 2006; and it has been in RC stage for one year now... It's jrawio and it's a Java Image I/O plugin for camera raw files. With this blog, I'm explicitly calling for volunteers to join it.Just a few words about jrawio. A "camera raw" or "raw image format" is a special file format for encoding digital photos. Instead of a regular file format, such as TIFF or JPEG, which - apart compression - contains the actual pixel data that should be shown on a display, a "camera raw" format just contains the dump from the digital sensor of the camera. A lot of computation is required to transform it into a viewable picture - some say that it's much like a "digital negative" that must be developed for viewing.
While this is a disadvantage from a computational perspective, it opens a lot of creative possibilities for the photographer, as in the classic "wet" development - no wonders it's the kind of format used by all professionals and most advanced amateurs. Now, the real trouble is that (apart from Adobe's DNG) there is no standard for "camera raw" formats: every manufacturer uses its own and, bad news, almost none documents it (you can go deeper in this argument looking at the OpenRAW initiative).
What can you do if you want to develop an open source application dealing with "camera raw" files? Up to a couple of years ago, there was just no choice: the only existing software was dcraw.c by Dave Coffin. Now, Dave's software is just invaluable: it supports hundreds of cameras and it's continuously evolving. Due to the lack of official documentation, it is the only centralized reference point to understand how bits are laid out for a given format and how you have to process it. Officially or not, Dave's software is used by a lot of commercial software for "camera raw" manipulation.
One of the problems of dcraw.c is that it's a single C file made of several hundreds lines. This makes integration harder, even though there's people that have successfully wrapped it into a Java JNI interface; but since one of the biggest advantage of a "camera raw" format is to tweak the development parameters, this is really a bad approach in my opinion. Recently (Sep 2006) another independent project has been started, libopenraw by Hubert Figuiere - which is a good thing for the C/C++ world. But in my opinion, the best solution for Java is a pure Java approach. That's why in 2003 I started a pure Java implementation, named nefio (it was only focused on Nikon's NEF format), which last year has turned into jrawio, which supports a lot of manufacturers' formats.
jrawio is a well-written plugin for Java Image I/O (the standard API for imaging I/O) and it's officially a subproject of imageio. My ambition is to keep on its development and submit it for inclusion in the Java distribution (Java 7, if time allows). Now, I'm going to enumerate which are the project troubles and thus the areas I'm asking for help:
- you have to test it with a lot of sample files, ideally many for every single camera model. A couple of years ago it was hard to find them; but thanks to Google and some photographers' communities, now it's not hard to get them. Up to now I've managed in collecting more than 1GB of samples - but they must be increased. This large number of samples is giving troubles to testing: for instance, to check that all metadata is properly read, there's a huge reference file that must be matched against, and it's so large to require more than 1GB when loaded in memory. This has actually blocked testing in the latest months. An alternate approach should be studied.
- While the processing pipeline is virtually complete, I'm not an imaging expert and I don't know which parameters should be placed inside the various filters (e.g. color space transformations, sharpening, etc). Also, some automated tests to compare results against the output of standard applications should be written. People with an image processing background would be useful here.
- The Java Image I/O API wasn't designed with "camera raw" files in mind, and thus it's possible that it requires a little extension to specify "development" parameters
That's all. If you are interested, you can:
- Post a comment here
- Subscribe and mail to the firstname.lastname@example.org mailing list (if you rather prefer a forum, let me know and I'll create it).
- Contact me directly at fabrizio dot giudici at tidalwave dot it
Note: if we didn't get in touch with the above methods, please don't request a role in the jrawio project using the menu of dev.java.net! People have done this for other dev.java.net projects of mine, but for unknown reasons - including my incapacity - nine times out of ten I wasn't able to get in contact with them and include them into the project. So, first contact me and only later eventually ask to join the project.
PS If there will be a good response, we could even think in a broader perspective. The experience we would collect about treating "camera raw" files could be useful to other projects too, including those not made in Java. Exactly one year ago I thought about a specific opensource initiative only for documents, but I had to freeze it when I realized I hadn't the time to manage it. With the help of other people it could be resumed. If you're interested in it, there's a draft web site at http://www.rawdarkroom.org.