图片熵计算
我的录音机遇到了一些严重的问题。有些人仍在将其与模拟调谐器一起使用，如果没有信号存在，模拟调谐器往往会吐出“雪花”。
问题是，当噪声输入编码器时，它会完全疯狂，首先消耗所有 CPU，然后最终冻结。由于记录器的要点是无论如何都要保持正常运行，因此我必须弄清楚如何继续执行此操作，因此编码器不会暴露于它无法处理的数据。
因此，我们的想法是创建“熵检测器”——一个简单而小的例程，它将遍历帧缓冲区数据并计算熵指数，即图片中的数据实际上是随机的。
例程的结果将是一个数字，0 表示完全背景图片，1 表示完全随机图片（即雪）。
例程本身应该只是向前扫描，很少有可以很好地适应寄存器的局部变量。
我可以使用 zlib 或 7z api 来完成这样的任务，但我真的很想自己做点东西。
有什么想法吗？
I've run into some nasty problem with my recorder. Some people are still using it with analog tuners, and analog tuners have a tendency to spit out 'snow' if there is no signal present.
The Problem is that when noise is fed into the encoder, it goes completely crazy and first consumes all CPU then ultimately freezes. Since main point od the recorder is to stay up and running no matter what, I have to figure out how to proceed with this, so encoder won't be exposed to the data it can't handle.
So, idea is to create 'entropy detector' - a simple and small routine that will go through the frame buffer data and calculate entropy index i.e. how the data in the picture is actually random.
Result from the routine would be a number, that will be 0 for completely back picture, and 1 for completely random picture - snow, that is.
Routine in itself should be forward scanning only, with few local variables that would fit into registers nicely.
I could use zlib or 7z api for such task, but I would really want to cook something on my own.
Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
PNG 的工作方式（大约）：对于每个像素，将其值替换为该像素的值减去其剩余像素的值。从右到左执行此操作。
然后，您可以通过制作一个值现在出现频率的表格来计算熵（每个字符的位数），从这些绝对值中得出相对值，并将每个元素的 log2(n)*n 的结果相加。
哦，您必须分别对每个颜色通道（r、g、b）执行此操作。
对于结果，取通道每个字符位数的平均值，并将其除以 2^8（假设每种颜色有 8 位）。
PNG works this way (approximately): For each pixel, replace its value by the value that it had minus the value of the pixel left to it. Do this from right to left.
Then you can calculate the entropy (bits per character) by making a table of how often which value appears now, making relative values out of these absolute ones and adding the results of log2(n)*n for each element.
Oh, and you have to do this for each color channel (r, g, b) seperately.
For the result, take the average of the bits per character for the channels and divide it by 2^8 (assuming that you have 8 bit per color).