[SciPy-User] Help optimizing an algorithm

Chris Weisiger cweisiger@msg.ucsf....
Thu Jan 31 10:14:40 CST 2013


I think that map_coordinates sounds promising; I'll definitely give it a
look-see. Thanks for the advice! Going to OpenGL probably won't be required.

I gave scipy.interpolate.interp1d a shot, incidentally, and it gave me
about a 50% speedup (from ~20s to ~11s to correct one 528x512 image). We'd
still be talking hours to correct an entire dataset, though.

The camera we're talking about here is a CMOS camera. I think our
particular one is unusually bad (it was one of the first of its model), but
from what I've heard most, if not all, high-dynamic-range CMOS cameras
suffer from some degree of nonlinearity. The problem is that they use two
different amplifiers, one for low photon counts and the other for high
counts. The region where they "hand off" between each other is where the
large nonlinearity is visible. The other smaller nonlinear region I
mentioned is a very minor effect right at the bottom of the camera's
sensitivity. Honestly I don't know that it's worth worrying about much
(uncorrected, you'd be off by under half a count in the vast majority of
pixels), but I'm writing my code to be generic so it can handle any kind of
monotonic nonlinearity.

Here's the results of two of the most nonlinear pixels from my first run,
incidentally:
http://derakon.dyndns.org/~chriswei/temp2/firstAttemptLinearization.png

Clearly I have a bug somewhere causing the first few datapoints to be way
off, but I think I know what's going on there. The overall approach is
sound, anyway.

-Chris


On Wed, Jan 30, 2013 at 9:17 PM, Zachary Pincus <zachary.pincus@yale.edu>wrote:

> > Another thing I should note is that the nonlinearity in the camera
> response is fairly localized -- there's one region about 20 counts wide,
> and another about 500 counts wide, and the rest of the response is
> basically linear. So outside of those two regions, we can just linearly
> interpolate and be confident we're getting the right value.
>
> Aah, just noticed this. In that case, then the per-pixel lookup table
> might still work. Do one simple lookup with a single transfer function as I
> initially described, and then patch that output just in the error-prone
> regions with per-pixel lookup results, using much smaller x,y-sized lookup
> tables (either via fancy indexing, or scipy.ndimage.map_coordinates).
>
> Of course, if map_coordinates is fast enough for the whole image (and it
> should be), then there's no advantage to doing the above as it's a bit less
> general and more hacky.
>
> Zach
> _______________________________________________
> SciPy-User mailing list
> SciPy-User@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-user/attachments/20130131/d0eaff91/attachment-0001.html 


More information about the SciPy-User mailing list