Workflow — two steps forward, one half step back.

It suddenly hit me yesterday that the work that I was doing for thumbnailing images using CoreImage may actually be the breakthrough that I was looking for to add a basic raw workflow to my current jpeg one.

I’ve tried a few options in the past with some sample images, perhaps a total of 50 frames of raw vs. 17000 of jpeg. The goal for the workflow is to be able to pop a card into the reader, download, and create web sized and thumbnails from the full size images. Anything that is sufficiently good for hard copy or is going to recieve special treatment of exposure compensation, cropping, b&w, or photoshop in general is going to be processed again from the full sized image. The key here is to go from card to triage quickly and with no per image intervention.

  • Canon Camera Raw – This is a dsp equivalent, meaning that the results from this program are the same as from the camera. Slow, not mac like, and not especially suited to the ‘dump a card in and get a bunch of web usable images’ process.
  • Bibble – I used the trial pro version, found it slow on my machines, and while appropriate for batch operation, it needed some work on a per image basis. This may be good as a converter for the exceptional image workflow.
  • dcraw – Command line, open source. I have messed with this a bit, but the results have been strange at times. It’s certainly not a reliable default conversion with any of the defaults that I have found. That’s not to say that it can’t, I haven’t seen it in a couple hours of work. This is an example of a strange color balance or white point.

    processed by dcraw, either the default or camera reported white balance

  • CoreImage – Used in such products as iPhoto, Preview.app, Aperature, and mine. Turns out that it’s essentially a ‘for free’ thing once you’re reading in arbitrary format images, canon’s camera raw (.CRW) is just one of the supported formats. There isn’t the control that’s available in the others, but I suspect that the coreimage filters are intended to compensate for that, since the internal CoreImage representation is a floating point format, rather than the usual 8 or 16 bit per channel. Results are pretty good to my eye, certainly good enough for default conversions. This is the same image as above, converted with CoreImage instead. I’m not really sure about the accuracy of the metalic shimmering effect, but the overall look of the image is far closer to what I’d consider reality.

    processed by core image

    The only drawback that I’m seeing with using CoreImage raw conversions for the basic conversions is that I can’t find the orientation data in the file. It doesn’t seem to exist in the image source properties. I know it’s there somewhere, as I can’t imagine Canon just not including it in the raw file. I just can’t find it in CoreImage’s attributes.

    While I can’t find the orientation data, it exists, somewhere, because it’s doing the right thing. Those cat pictures were taken vertically in raw and not manually rotated, yet they came out correctly.

  • No comments

    No comments yet. Be the first.

    Leave a reply

    You must be logged in to post a comment.