[SciPy-User] Help optimizing an algorithm
Thu Jan 31 11:39:25 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.
Good luck with that, and let me know if you have any questions on this front.
> 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.
I presume you've seen this article about some of the sCMOS cameras, but if not:
They mention the dual amplifier gain issues, and also point out some potential trouble spots (toward the end in the "unexpected findings" section) with the low-gain amplifier at least for the (unidentified) camera they used. Worth knowing about...
> Here's the results of two of the most nonlinear pixels from my first run, incidentally:
> 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.
Yeah, that looks decent. Good luck getting the processing working at useful speeds!
> On Wed, Jan 30, 2013 at 9:17 PM, Zachary Pincus <firstname.lastname@example.org> 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.
> SciPy-User mailing list
> SciPy-User mailing list
More information about the SciPy-User