编辑我在下面保留了我面临的更复杂的问题,但我的问题np.take
可以更好地总结如下。假设您有一个img
形状数组(planes, rows)
,还有另一个lut
形状数组(planes, 256)
,并且您想使用它们来创建一个新out
的形状数组(planes, rows)
,其中out[p,j] = lut[p, img[p, j]]
. 这可以通过花哨的索引来实现,如下所示:
In [4]: %timeit lut[np.arange(planes).reshape(-1, 1), img]
1000 loops, best of 3: 471 us per loop
但是,如果不是花哨的索引,而是使用 take 和 python 循环,则planes
可以大大加快速度:
In [6]: %timeit for _ in (lut[j].take(img[j]) for j in xrange(planes)) : pass
10000 loops, best of 3: 59 us per loop
可以lut
并且img
以某种方式重新排列,以便在没有 python 循环的情况下进行整个操作,而是使用numpy.take
(或替代方法)而不是传统的花式索引来保持速度优势?
原始问题
我有一组要在图像上使用的查找表 (LUT)。保存 LUT 的数组是有形的(planes, 256, n)
,而图像是有形的(planes, rows, cols)
。两者都是,与LUTdtype = 'uint8'
的轴相匹配。256
这个想法是从LUT的第p
-平面运行图像的第-平面通过每个LUT。n
p
如果我的lut
和img
是以下:
planes, rows, cols, n = 3, 4000, 4000, 4
lut = np.random.randint(-2**31, 2**31 - 1,
size=(planes * 256 * n // 4,)).view('uint8')
lut = lut.reshape(planes, 256, n)
img = np.random.randint(-2**31, 2**31 - 1,
size=(planes * rows * cols // 4,)).view('uint8')
img = img.reshape(planes, rows, cols)
使用像这样的精美索引后,我可以实现我的目标
out = lut[np.arange(planes).reshape(-1, 1, 1), img]
这给了我一个 shape 数组(planes, rows, cols, n)
,其中out[i, :, :, j]
保存了穿过LUT 的 -thi
平面的-th LUT 的-th 平面......img
j
i
一切都很好,除了这个:
In [2]: %timeit lut[np.arange(planes).reshape(-1, 1, 1), img]
1 loops, best of 3: 5.65 s per loop
这是完全不可接受的,特别是因为我有以下所有看起来不太好看的替代品,np.take
而不是运行得更快:
单个平面上的单个 LUT 运行速度大约 x70:
In [2]: %timeit np.take(lut[0, :, 0], img[0]) 10 loops, best of 3: 78.5 ms per loop
运行所有所需组合的 python 循环几乎快 x6 完成:
In [2]: %timeit for _ in (np.take(lut[j, :, k], img[j]) for j in xrange(planes) for k in xrange(n)) : pass 1 loops, best of 3: 947 ms per loop
即使在 LUT 和图像中运行所有平面组合,然后丢弃
planes**2 - planes
不需要的平面组合,也比花哨的索引更快:In [2]: %timeit np.take(lut, img, axis=1)[np.arange(planes), np.arange(planes)] 1 loops, best of 3: 3.79 s per loop
我能想到的最快的组合是一个 python 循环在平面上迭代并更快地完成 x13:
In [2]: %timeit for _ in (np.take(lut[j], img[j], axis=0) for j in xrange(planes)) : pass 1 loops, best of 3: 434 ms per loop
当然,问题是如果np.take
没有任何 python 循环就没有办法做到这一点?理想情况下,需要的任何重塑或调整大小都应该发生在 LUT 上,而不是图像上,但我对你们能想出的任何事情持开放态度......