duangsuse::Echo
717 subscribers
4.26K photos
130 videos
583 files
6.48K links
import this:
美而不丑、明而不暗、短而不凡、长而不乱,扁平不宽,读而后码,行之天下,勿托地上天国。
异常勿吞,难过勿过,叹一真理。效率是很重要,盲目最是低效。
简明是可靠的先验,不是可靠的祭品。
知其变,守其恒,为天下式;穷其变,知不穷,得地上势。知变守恒却穷变知新,我认真理,我不认真。

技术相干订阅~
另外有 throws 闲杂频道 @dsuset
转载频道 @dsusep
极小可能会有批评zf的消息 如有不适可退出
suse小站(面向运气编程): https://WOJS.org/#/
Download Telegram
本苏居然又默写式给重写了一遍…… 没有参照任何原来的代码
montage.py
4.7 KB
就这么随便写在了 ~/图片/ 文件夹里……#Python #code ,不过下次应该试试 average color 了
新的代码主要分为 solveItemLayout, drawTextMontage, averageColorUnlessIsBackground 三个
Forwarded from dnaugsuz
🤔我感觉用 FoldReducerAveragerMapFold 还是不够优雅,虽然已经解耦很多了

不知道有没有更快的方法,我要对一个色块进行统计,大致就是平均色(单单这个直接用 img.resize((m, n), Image.ANTIALIAS) 即可)
但还包括对指定背景色的模糊匹配判定,目前的算法是求所有 channel 的 absdiff ,然后有个 threshold 再去看 count < n_pixels*ratio 来的,不知道有没有更快的算法

有没有熟悉计算机2D绘制的大佬可以给建议(
Forwarded from dnaugsuz
Fold&Reducer 是“设计模式”,这种东西混在位图处理算法里略略感觉有点不是地方,虽然不用的话代码我看着难受(草
Forwarded from dnaugsuz
其实我觉得直接在平均色上,进行背景色块的判断也比较可取,但准确度可能稍微低了那么一点…… 这个不知道有没有道理。(背景色的 montage 子图是不绘制的)

模糊匹配是在 Image 上 filter (absdiff keyColor) < keyThres 的,然后再判一个 ratio (一般都是 1/2 )
求了平均值后再 absdiff 精度大概也一样吧?
Forwarded from dnaugsuz
Python 的 Pillow 提供了 Image.from_array 可以和 numpy 无缝交互,但 cv2.UMat 就没办法和 PIL 的 Image 好好说话了,难不成要自己写 ImageFromUMat / ImageBackUMat (迫真)
这个是新操作,完全利用简单的平均色完成的;代码当然也很简洁,已经提交 GitHub
感觉色值精度还高一些
Forwarded from Aelita Lyoko
https://t.me/dsuse/13572
可以先从umat转换到numpy,再转换到pil
因为umat的数据可能会在显卡之类的外部设备上,不是普通的主机内存数据

显卡之类的设备内存空间的数据要先通过pcie总线拷贝回主机内存空间,然后才能转换到其他库的内存上去

很少有显卡设备上的数据在两个不同库之间发来发去的,我觉得原因应该是因为显卡内存块是有上下文ctx的,而主机内存里的数据,只要alloc和free对应使用相同版本的实现一般就不会有问题
Forwarded from Aelita Lyoko
py抽象得有点过分,所以不知道缘由的话很难明白为什么会这样设计
如果用过opencv的c++接口你就会明白mat和umat的不同之处了
Forwarded from dnaugsuz
感谢热心的大佬
Forwarded from dnaugsuz
其实我晚上下去散步的时候结合之前看到的一些代码也想到了这个无厘头的方式,不过把它当笑话了
毕竟 UMat <-> ndarray <-> Image 感觉有点太嵌套了
Forwarded from dnaugsuz
我只知道 cv::Mat 好像不是个指针的样子,U 的意思是 unified ?
duangsuse::Echo
Photo
非常容易移植到 OpenCV,只有 font, font_size, scale, spacing 和 text, image 这几个参数
我只需要把 ImageDraw 抽象一个就好了

其实移植到 Java 的 java.awt.image.BufferedImagejava.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计算那种吧?还在起步实验阶段的样子