Musings on Photography

SizeFixer Update

Posted in Uncategorized by Paul Butzi on August 18, 2007

 Imgs 040807-7-500

I sent off my questions and problems with the review copy of SizeFixer to Fixerlabs exactly a week ago. I’ve still got no response from Fixerlabs, which doesn’t fill me with confidence about the outfit. If they can’t be bothered to answer questions for someone they’ve asked to review the product, what will they be like when a mere customer needs help?
In any case, I thought it would be worthwhile to go ahead and detail some of my impressions of SizeFixer XL – things which don’t really require answers to my questions.

Using the discount code provided by Fixerlabs, I ordered a copy of SizeFixer XL for the Mac. The product that was delivered to me was version 1.0.0r7 on the CD-ROM, and identifies as version 1.0.0 in the ‘about’ dialog. The software is compiled for the PowerPC, so on an Intel Mac, it runs under Rosetta (the powerpc emulation for Intel Mac. The documentation that comes with the product consists of a directory which contains a set of html files; 10 files at roughly 800 words per file. I consider this pretty skimpy documentation for a product like this, especially at this price point ($295 US). (you can view the documentation online here.)

My biggest problem with the software is that, according to the documentation, the algorithm used will only work if it’s run against the unmodified data straight from the camera. Although at least some discussion on the web talks about running the software on raw files, they mean raw in the sense that it’s unedited, not raw in the sense that it’s the camera raw file. So you’re basically running SizeFixer, which is a standalone app, on a tiff that your camera raw processing software generates from the raw file. You’re specifically warned to do no sharpening in the raw conversion, because it will cause SizeFixer problems.

The reason given for this is that, according to the documentation, SizeFixer uses the known attributes of the lens to do a better job upsizing the image. The conceptual problem I have is that FixerLabs list supported cameras on their website, but not supported lenses. Surely, if the software needed to know what lens was used, it would be combination of both lens and camera that needed to be supported, and yet there’s no list of supported lenses. This was one of the areas I asked FixerLabs to clarify.

A bigger problem is integrating SizeFixer into my workflow. Currently, for most images, I convert the camera raw file in Adobe Camera Raw, with the output piped directly into Photoshop CS3. It’s a convenient workflow, in that it doesn’t involve lots of file opens and closes to get going on an image – I just double click on it in Bridge, Adobe Camera Raw opens the file, and when I tell ACR to go, the results are opened in Photoshop straight away. Putting SizeFixer XL into the workflow would require a step where I take the ACR output, save it as a tiff, run SizeFixer XL, and then open the resulting tiff, and proceed. That’s not fatal but it’s a bit of a hassle when it could be avoided just by structuring SizeFixer XL as a photoshop plugin, in the same way Noise Ninja is.

Even worse, though, is this: the size adjustment must be done up front, before any photo editing. This means that you can’t do all the adjusting on the image at native resolution, then adjust the size and do the final sharpening just prior to making a print. That’s a serious problem for me; it means that I must pick a final print size, run SizeFixer, and then edit the image. If I want to make a print a different size, I need to start over from the raw file, scale the image to the new size, then duplicate all the edits on the new file, and finally make the print in the new size. This is, as far as I’m concerned, a fatal flaw unless a workflow can be worked out that lets you apply a set of image edits repeatedly to different sized versions of the image. It’s possible to do this with some layers, but things like spotting, etc. can’t be done this way.

Another problem is that, perhaps because the software is running under Rosetta, it can’t exploit the multiprocessor nature of my Mac Pro. When SizeFixer is doing it’s thing, it pegs one CPU at 100%; the other three sit idle. That’s a serious, serious problem, given that upsizing a full image from my EOS 5d from native size to 22″x33″ at 360 dpi takes roughly 4 hours. Yes, really, four hours. There’s no batch mode, either, so I can’t give SizeFixer XL a list of files to upsize, get it started, and then go off to sleep overnight and come back in the morning (leaving aside for a moment that it could only get two files done while I sleep anyway).

Converting SizeFixer from a powerpc app to a universal binary would presumably fix part of the speed problem. Threading the software so that it parallelizes the work is another obvious step – those two things would probably improve the speed on my Mac Pro by a factor of six to eight. That drops uprezzing a 5d image to 22×33 from a four hour task to something between 30 minutes and one hour. Still a big problem, but not the showstopper that the current hopeless performance is.

One other issue that raises flags for me: the current release of SizeFixer XL for windows appears to be 1.2.1r8. The current release for the Mac is 1.0.0r8, and is not a universal binary. That makes me think that the Mac version is stagnant, never a good sign.

Given the workflow problems, I won’t be doing more testing until I get some solid answers to the questions I’ve sent to FixerLabs. Frankly, the product doesn’t look very promising at this point, especially at the price point.

Comments Off on SizeFixer Update

%d bloggers like this: