如果我的窗口处于32位颜色深度模式,那么下面的代码从窗口中获取一个漂亮的PIL图像:
def image_grab_native(window):
hwnd = win32gui.GetDesktopWindow()
left, top, right, bot = get_rect(window)
w = right - left
h = bot - top
hwndDC = win32gui.GetWindowDC(hwnd)
mfcDC = win32ui.CreateDCFromHandle(hwndDC)
saveDC = mfcDC.CreateCompatibleDC()
saveBitMap = win32ui.CreateBitmap()
saveBitMap.CreateCompatibleBitmap(mfcDC, w, h)
saveDC.SelectObject(saveBitMap)
saveDC.BitBlt((0, 0), (w, h), mfcDC, (left, top), win32con.SRCCOPY)
bmpinfo = saveBitMap.GetInfo()
bmpstr = saveBitMap.GetBitmapBits(True)
im = Image.frombuffer(
'RGB',
(bmpinfo['bmWidth'], bmpinfo['bmHeight']),
bmpstr, 'raw', 'BGRX', 0, 1)
win32gui.DeleteObject(saveBitMap.GetHandle())
saveDC.DeleteDC()
mfcDC.DeleteDC()
win32gui.ReleaseDC(hwnd, hwndDC)
return im
但是,在16位模式下运行时,我收到错误:
>>> image_grab_native(win)
Traceback (most recent call last):
File "<pyshell#3>", line 1, in <module>
image_grab_native(win)
File "C:\claudiu\bumhunter\finderbot\ezpoker\utils\win32.py", line 204, in image_grab_native
bmpstr, 'raw', 'BGRX', 0, 1)
File "c:\python25\lib\site-packages\PIL\Image.py", line 1808, in frombuffer
return apply(fromstring, (mode, size, data, decoder_name, args))
File "c:\python25\lib\site-packages\PIL\Image.py", line 1747, in fromstring
im.fromstring(data, decoder_name, args)
File "c:\python25\lib\site-packages\PIL\Image.py", line 575, in fromstring
raise ValueError("not enough image data")
ValueError: not enough image data
我应该如何形成frombuffer
调用才能在16位模式下工作?另外,如何使此功能在任何位深度模式下工作,而不是说必须将其作为参数传递?
更新:从this question我知道我必须使用“BGR; 16”而不是“BGRX”作为第二模式参数。它需要一个正确的图片,无论是否指定步幅。问题是某些值的像素值略有偏差:
x y native ImageGrab
280 0 (213, 210, 205) (214, 211, 206)
280 20 (156, 153, 156) (156, 154, 156)
280 40 (213, 210, 205) (214, 211, 206)
300 0 (213, 210, 205) (214, 211, 206)
只是从同一窗口获取的值的示例。屏幕截图看起来与肉眼完全相同,但我必须做一些像素操作..我想要使用本机方法的原因是它更快一点,并且当在具有双显示器的虚拟机内运行时表现更好。 (我知道,这是非常随意的复杂)。
答案 0 :(得分:2)
对于stride
参数,您需要以字节为单位给出行大小。你的像素是16位,所以你可能天真地假设stride = 2*bmpinfo['bmWidth']
;不幸的是,Windows添加了填充以使步幅达到32位的偶数倍。这意味着您必须将其四舍五入到下一个最高倍数4:stride = (stride + 3) / 4) * 4
。
documentation未提及16位原始格式,因此您必须检查Unpack.c模块以查看可用的内容。
你会注意到的最后一件事是,Windows喜欢将其位图颠倒过来。
编辑:您可以轻松解释最终的小问题 - 未精确定义从16位到24位的转换,两次不同转换之间的逐个差异完全正常。在转换数据后调整数据并不困难,因为我确信差异是基于值的不变。