Phoblographer's review of the x100s

With that in mind, we’re bound to get questions of whether someone should get a mirrorless camera or the X100s–and this little camera is wiping the floor with Micro Four Thirds options right now in terms of sensor performance.

Sigh. I don’t think I’m going to be able to resist trying the X100s. Sounds like AF is still not as good as m43 options, but it might be better enough, and IQ may be better enough too. I still look back on my X-E1 files and am pretty amazed.

Fun with VIM: autocmd part 2

More to write about after spending a weekend hacking on vim plugins.

Autocmd is probably one of the most powerful features of vim, but also one of the easiest to mis-use. If you ever end up copy-and-pasting someone else’s autocmd examples, beware!

Here’s one that I had in my .vimrc forever

autocmd BufRead,BufNewFile,BufAdd *.php setlocal ft=php

Looks sane enough. Turns out BufAdd is a bad idea here. From the docs:

NOTE: When this autocommand is executed, the current buffer “%” may be different from the buffer being created “<afile>”

Oops, this means that this command will run in the context of the current buffer, not the new buffer being created. In practice, this meant that sometimes when I opened php files, the file I was currently looking at would get it’s filetype set to php, which was super confusing.

Fun with VIM: autocmd

Here’s a fun gotcha. I had this snippet in my vimrc, which kills trailing whitespace in buffers full of programming code, right before the buffer gets written out…

autocmd FileType c,css,cabal,cpp,haskell,javascript,php,python,readme,text
  \ autocmd BufWritePre <buffer>
  \ :call setline(1,map(getline(1,"$"),'substitute(v:val,"\\s\\+$","","")'))

Which is all well and good. Except when your kind of anal like me, and you end up editing your vimrc often, and you have a keymap just for re-executing your vimrc. The fun thing about autocmd’s is that they don’t replace previous autocmd (there’s no way for vim to tell that things should be replaced, since there’s no naming). So each time I re-ran my vimrc, yet another filetype hook which sets up the pre-write hook.

That’s not so bad in it of itself, except that elsewhere in my vimrc, I had similarly accumulating autocmds which set the filetype based on the buffer. Lots of refreshes and reloads later, I discovered that some files literally had hundreds of passes of the white-space munging routine attached to it, causing saves to take 10+ seconds.

Anyhow, long story short, if you like autocmds (and who doesn’t!?) make sure you use the augroup facility to group them together, name them, and clear old ones out each time you define a bunch in a script. This will keep things from accumulating and leading to weird problems.

Here’s an example:

augroup kill_trailing_whitespace
  au!
  autocmd FileType c,css,cabal,cpp,haskell,javascript,php,python,readme,text
    \ autocmd BufWritePre <buffer>
    \ :call setline(1,map(getline(1,"$"),'substitute(v:val,"\\s\\+$","","")'))
augroup END

Perhaps I spoke too soon about Mountain lion. I discovered a pretty bad bug where the OS doesn’t remember the arrangement of your external monitors. Seems pretty bad, especially since they’re up to .2 and haven’t fixed it yet.

Surface pro

Interesting review of the surface pro by the penny arcade, who finds it a pretty good option for a content production use case, mainly because it has a proper digitizer.

The more I read these, it’s interesting to note how people tend to talk about how surfaces don’t make good laptops, because of the kickstand design. Maybe the surface is really a desktop / tablet hybrid. All your mobile stuff you do in tablet mode. All your other stuff in desktop mode, as in, on a desk (or table). None of this typing on the couch non-sense.

I find it an interesting way to think about the design. A trade off that may almost make sense in many ways.

It looks like the experience is not universal, but the 10.8 upgrade for me was really awesome. I went from 10.7.latest to 10.8.2. Things are faster, and it made my battery life on my 2011 mbp go way up.

Maybe the trick is to only go with even 10.x releases? There’s somewhat of a tick/tock pattern emerging.

Fujifilm X-E1 impressions

I’ll make this short and sweet. The X-E1 excels in some situations, but falls way short in others. Unfortunately, it falls short in many of the scenarios I need it to be good in. I’ll explain.

As I imagine many parents do, I shoot a lot of photos of my kids. Kids run around. Kids are also indoors a lot. That means you want good low light performance, but also good autofocus.

I’ve been shooting for the last year with my Panasonic GH2. I’d say the GH2 has mediocre low-light performance, and good AF. With the X-E1, I was hoping for much better low-light performance, with comparable AF.

Lets be clear, the high-ISO performance on the X-E1 blows the GH2 out of the water. I’d say it’s on the order of at least 1 to 2 full stops of noise improvement. ISO6400 on the X-E1 looks like ISO1600 to ISO3200 on the GH2. Dynamic range is a lot better too. DxOMark ratings consistently show that MFT sensors get you about 11-12 stops of DR, where as APS-C sensors get you on the order of 13, and the X-E1 seems like it keeps to that trend (though, official DxOMark scores for the any of the X-trans sensor are not up yet).

When it comes to the autofocus, however, I can only say I was disappointed. In well-lit scenes, it works well enough, especially with the 18-55 kit zoom I got. Nothing super-fast, but adequate. In low light, however, the AF just often refuses to lock, which is the most frustrating thing ever. Imagine catching your child doing something and wanting to preserve that image forever, only to find that your camera refuses you child as a subject to focus on.

Switch to manual focus, you say? Well, I tried. Therein lies the second major flaw of this camera. In low light, the EVF is suuuuper laggy. It looks like they lower the shutter speed to be able to get a reasonably bright image, but in the process, you get all the motion blur and low frame rate which that implies. It’s impossible to focus on anything moving when your EVF is giving you 3fps. It’s even more comical with the MF assist zoom mode.

The GH2, in comparison, doesn’t suffer a drop in EVF in frame rate in low light. Sure, in extremely low light, it misses focus, or refuses to lock sometimes, but I’d say compared to the X-E1, it’s about 1/20th of the time, if not less. In terms of the frame rate, I think the GH2 prefers to just amp the signal coming out of the sensor (which brings in noise), which is a much better option (imho) then adjusting the shutter speed. Maybe that’s something they can fix in a FW update. But to some extent, it feels like maybe Fuji isn’t used to making EVF only cameras (afaict it’s the only X-series camera without a hybrid OVF/EVF) and it kinda shows. Unless your subject is completely still, this camera is pretty useless in low light.

In either case, if the X100s is any indication, Fuji knows that they have an issue, and they’re going down the hybrid AF approach to address it. Time will tell if they can better the situation in low light.

Anecdotally, the best shots I did get out of this camera were when I was walking around with my son in a park that had some hiking areas. Landscapes, closeups of plants, etc, all excel on this camera. Great color. Great DR. Great resolution.

As far as manual controls go, it’s a bit of a wash. After trying the X-E1 for a bit, and then going back to the GH2, I felt that there were definitely situations where having the aperture/shutter rings were really helpful. Other times, you really just want to fix one of the dimensions and go, for which the usual aperture-priority/shutter-priority modes work a bit better.

I’d be super tempted to try another X-series camera if they can fix the autofocus. But if your shooting patterns are anything like mine, I would stay away for now.

X-E1: reading between the pixels

As I noted in my earlier post, the X-trans sensor in the Fuji X-series cameras seems to have amazing noise performance even at high ISO.. to a degree that seems unreasonable. Apparently, others have noticed the same thing, and a plausible explanation is that the camera is applying noise reduction when generating the RAW image file. It’s hard to make general conclusions here, but this worries me. 

How do we know noise reduction algorithm isn’t making an unwanted tradeoff in the quality of the image? Especially since a PC has way more processing power than a camera does, such a strategy by Fuji forces the user into a single processing approach, which is against the spirit of the raw workflow. To wit, the link referenced above says noise performance looks pretty good up to ISO 1600, but above that, it becomes splotchy and the reviewer prefers the more “natural” noise look of the Nikon FF camera. 

In theory, such an approach could be justified if the camera has some information that a later processing step would not have, and access to this information resulted in a theoretically superior result than anything a post processor could generate. But this seems unlikely, as there’s no reason that the camera couldn’t record this extra information in the RAW file and a post processor would only need to simulate the same process. There is a remote possibility that such “information” is of such volume that it would be impractical to record for every shot. But this also seems unlikely, for if this were the case, the processor in the camera would have also be powerful enough to munge through this extra data. 

The other implications are clearer: there’s nothing special about the electronic setup of the X-Trans sensor. It’s probably seeing just as much per-pixel noise as other APS-C sensors with the same number of pixels. It may have some algorithmic advantage due to the lack of a AA filter, or its funny non-Bayer filter arrangement, but any such advantage is being cooked into the output of the camera (JPG obviously, but RAW too).

I suppose there are legitimate reasons that a company might do this:

  1. They want to keep their noise processing algorithms a secret, and what better way to do that than keep it in-camera.
  2. They don’t want to have users rely on the post-processing software to implementing a very finely-tuned processing scheme, which would likely be suboptimal in some way, and thus make the product look bad overall. For a product that seems to pay such attention to it’s JPG output quality, this makes sense.
  3. They want to game the reviews, where they know reviewers are going to be pixel peeping at results from both JPG and RAW output and comparing to other cameras. This in turn may sway potential buyers, who don’t know how to interpret the data.

Whatever the actual reason, this approach makes for some confusion when evaluating the X-series products against the competition. I suspect the behavior is surprising to most users of raw files, as the expectation is that the RAW format contains a most direct representation of what was recorded on the imaging sensor, with no processing applied. In the larger context of all the issues Fuji has been having with raw processor support, another small issue like this is unsurprising. It seems like Fuji clearly underestimated how important the RAW workflow was for their intended audience, and is now only making amends (e.g. rumors of working with Adobe et al for better raw support).

On a separate front, this set of articles linked from fujirumors.com was of particular interest. Chromasoft, a developer of some iOS-based raw processing software, delves deep into the x-trans sensor. Of particular note was the bit:

So my conclusion is, sorry to say, that the Fuji X-Pro1 X-Trans sensor doesn’t deliver the Fuji promise of outperforming similarly sized sensors. In fact, it underperforms similar DX sensored cameras - with the official SILKPIX raw developer, the underperformance is too slight to be noticeable under normal circumstances, but is still there if you look closely.

This is not to say that the Fuji X-Pro1 is a bad camera - far from it - the camera has great lenses, a really attractive viewfinder and design, and in many ways the sensor is great, with low noise and clean data, in the class of the recent Sony and Nikon sensors. If you use it with the official raw converter, it’s within a whisker of the competition. But in my opinion, it would have been a better camera with a conventional two-by-two sensor layout.

A pretty bold statement to say the least. On some level, I trust this guy’s opinion since he likely understands the intricacies of the demosaicing process way better than your average camera reviewer/blogger. On the other hand, he is just one guy, and on the other side, there is a team of Fuji engineers doing similar analysis and making explicit tradeoffs. It’s possible that the the X-Trans + AA-less design, while not resulting in improved resolution compared to other APS-C sensors, does confer other advantages, such as enabling a novel noise reduction technique, and/or as the marketing material says: avoiding moiré w/o the use of extra optical components.

Only time will tell, but I do hope that eventually Fuji come clean about what’s going on. If their RAF files have some noise processing applied, they should at least admit to the fact. It doesn’t necessarily make it a worse camera. iIn fact, given that Fuji has the greatest interest and making sure both NR and demosaicing work well for their special sensor, I’d be fine if the camera just generated TIFF files, where Fuji does all the work, but we still have the bit-depth to play with the images in post. It would be most interesting if the cameras were also modified such that RAF files really contained all raw data including any other parameters that are used as inputs to the hypothetical NR engine. This, of course, does not guarantee better images for all users.. without knowing the economics of the market, it’s hard to say for sure that raw processor developers would want to invest as much time as Fuji has to improve the output. 

For more information on the X-E1, check out my link collection. 

Top