Forwarded from dnaugsuz
🤔我感觉用
不知道有没有更快的方法，我要对一个色块进行统计，大致就是平均色（单单这个直接用
但还包括对指定背景色的模糊匹配判定，目前的算法是求所有 channel 的 absdiff ，然后有个 threshold 再去看
有没有熟悉计算机2D绘制的大佬可以给建议（
Fold 的 Reducer ， Averager 和 MapFold 还是不够优雅，虽然已经解耦很多了不知道有没有更快的方法，我要对一个色块进行统计，大致就是平均色（单单这个直接用
img.resize((m, n), Image.ANTIALIAS) 即可）但还包括对指定背景色的模糊匹配判定，目前的算法是求所有 channel 的 absdiff ，然后有个 threshold 再去看
count < n_pixels*ratio 来的，不知道有没有更快的算法有没有熟悉计算机2D绘制的大佬可以给建议（
Forwarded from dnaugsuz
Fold&Reducer 是“设计模式”，这种东西混在位图处理算法里略略感觉有点不是地方，虽然不用的话代码我看着难受（草
Forwarded from dnaugsuz
其实我觉得直接在平均色上，进行背景色块的判断也比较可取，但准确度可能稍微低了那么一点…… 这个不知道有没有道理。（背景色的 montage 子图是不绘制的）
模糊匹配是在
求了平均值后再 absdiff 精度大概也一样吧？
模糊匹配是在
Image 上 filter (absdiff keyColor) < keyThres 的，然后再判一个 ratio （一般都是 1/2 ）求了平均值后再 absdiff 精度大概也一样吧？
Forwarded from dnaugsuz
Python 的 Pillow 提供了 Image.from_array 可以和 numpy 无缝交互，但 cv2.UMat 就没办法和 PIL 的 Image 好好说话了，难不成要自己写 ImageFromUMat / ImageBackUMat （迫真）
Forwarded from Aelita Lyoko
https://t.me/dsuse/13572
可以先从umat转换到numpy，再转换到pil
因为umat的数据可能会在显卡之类的外部设备上，不是普通的主机内存数据
显卡之类的设备内存空间的数据要先通过pcie总线拷贝回主机内存空间，然后才能转换到其他库的内存上去
很少有显卡设备上的数据在两个不同库之间发来发去的，我觉得原因应该是因为显卡内存块是有上下文ctx的，而主机内存里的数据，只要alloc和free对应使用相同版本的实现一般就不会有问题
可以先从umat转换到numpy，再转换到pil
因为umat的数据可能会在显卡之类的外部设备上，不是普通的主机内存数据
显卡之类的设备内存空间的数据要先通过pcie总线拷贝回主机内存空间，然后才能转换到其他库的内存上去
很少有显卡设备上的数据在两个不同库之间发来发去的，我觉得原因应该是因为显卡内存块是有上下文ctx的，而主机内存里的数据，只要alloc和free对应使用相同版本的实现一般就不会有问题
Telegram
duangsuse::Echo
Python 的 Pillow 提供了 Image.from_array 可以和 numpy 无缝交互，但 cv2.UMat 就没办法和 PIL 的 Image 好好说话了，难不成要自己写 ImageFromUMat / ImageBackUMat （迫真）
Forwarded from Aelita Lyoko
py抽象得有点过分，所以不知道缘由的话很难明白为什么会这样设计
如果用过opencv的c++接口你就会明白mat和umat的不同之处了
如果用过opencv的c++接口你就会明白mat和umat的不同之处了
Forwarded from dnaugsuz
其实我晚上下去散步的时候结合之前看到的一些代码也想到了这个无厘头的方式，不过把它当笑话了
毕竟 UMat <-> ndarray <-> Image 感觉有点太嵌套了
毕竟 UMat <-> ndarray <-> Image 感觉有点太嵌套了
duangsuse::Echo
Photo
非常容易移植到 OpenCV，只有 font, font_size, scale, spacing 和 text, image 这几个参数
我只需要把 ImageDraw 抽象一个就好了
其实移植到 Java 的
我只需要把 ImageDraw 抽象一个就好了
其实移植到 Java 的
java.awt.image.BufferedImage 和 java.awt.Graphics 也一点也不困难，甚至可以用 C++ or JNI 的，但我觉得能用是最重要的，而且本来也该可以画些非字符的东西。Forwarded from Aelita Lyoko
其实opencv对图像这个矩阵的抽象有三代
opencv 1 是C语言风格实现，用的是 IplImage 和 CvMat 这个东西，就是个指向c结构体的指针，用各种函数的时候就要把这个指针传来传去
opencv 2 开始是C++风格实现，用的是Mat这个东西，本质上是一个c++类，通常在栈上，然后数据放在堆上，和std::vector是同样的设计风格，用各种函数的时候传的就是引用了
但是在这个时候，如果需要做GPU计算，比如opencl或者cuda，那么就得用专门的cv::ocl或者cv::cuda名字空间里面的东西，还得把数据的格式在主机内存和显卡内存直接转换来转换去的
opencv 3 开始就试图统一 主机内存和显卡内存，发明了UMat这个东西，这个东西和Mat的不同之处就是，UMat底层可能对应到主机内存或者显卡内存，所以限制了部分显卡内存里面没法实现的函数和操作，用起来的手感有点像是直接用ocl空间里面的东西
opencv 4 现在在搞计算图graph这个东西，目测是想搞lazy计算那种吧？还在起步实验阶段的样子
opencv 1 是C语言风格实现，用的是 IplImage 和 CvMat 这个东西，就是个指向c结构体的指针，用各种函数的时候就要把这个指针传来传去
opencv 2 开始是C++风格实现，用的是Mat这个东西，本质上是一个c++类，通常在栈上，然后数据放在堆上，和std::vector是同样的设计风格，用各种函数的时候传的就是引用了
但是在这个时候，如果需要做GPU计算，比如opencl或者cuda，那么就得用专门的cv::ocl或者cv::cuda名字空间里面的东西，还得把数据的格式在主机内存和显卡内存直接转换来转换去的
opencv 3 开始就试图统一 主机内存和显卡内存，发明了UMat这个东西，这个东西和Mat的不同之处就是，UMat底层可能对应到主机内存或者显卡内存，所以限制了部分显卡内存里面没法实现的函数和操作，用起来的手感有点像是直接用ocl空间里面的东西
opencv 4 现在在搞计算图graph这个东西，目测是想搞lazy计算那种吧？还在起步实验阶段的样子
def solveItemColorLayout(img, item_size, scale, spacing):#Python #code #CV 这段安排布局，算
(width, height) = img.size
(w_item, h_item) = tuple(int((item_size+sp)*scale) for sp in spacing)
(m_item, n_item) = tuple(int(v) for v in [width / w_item, height / h_item])
(padLeft, padTop) = tuple(int(v*scale / 2) for v in [(width % w_item), (height % h_item)])
imgable_area = img.crop((padLeft, padTop, img.width-padLeft, img.height-padTop))
img_average = imgable_area.resize((m_item, n_item), Image.ANTIALIAS)
for i in range(0, n_item):
for j in range(0, m_item):
(y, x) = (i*h_item, j*w_item)
yield (x, y, img_average.getpixel((j, i)) )
(w, h) (m, n) (padLeft, padTop) 的才是关键代码它也依赖
Image.size, Image.getpixel, Image.crop 和 Image.resize 然后就一把：
areas = solveItemColorLayout(scaledImage, cfg.font_size, cfg.scale, cfg.spacing)提供 font_size, scale, spacing 和 image, areas, seq, font, calc_color 即可
drawTextMontage(newImage, areas, cycle(cfg.text), cfg.font, calc_draw_color)
OpenCV 的画图根本不能用 truetype 这么自由，它的字体都是内置的！
如果想要给 OpenCV 脚本画的视频打时间轴，还得靠
expandRangeStarts 这个函数来展开一堆 [start, stop, value] 才可以