作者 主题:低RAM嵌入式数据压缩的最佳库/算法? (Read 4721 times)

0位成员和2位客人正在查看此主题。

离线 马丁·F

  • 定期贡献者
  • *
  • 帖子:128
  • 国家: dk
低RAM嵌入式数据压缩的最佳库/算法?
« 上: 十月01,2019,06:08:52下午»
大家好,

We'希望在我们的数据记录器上实现流式数据压缩。

数据记录器以非常高的频率(生成1 MB /分钟的时间序列数据)记录车辆数据,该数据存储在内部SD卡中。数据包括时间序列数据的原始CAN总线形式,例如车速,RPM等。我们以二进制格式记录此数据-在此处查看示例: //uploadfiles.io/khxs13bt

目前我们'希望在我们的设备上实现嵌入式压缩-而且我们're trying to 科幻nd the 最好 suitable libraries/starting points.

算法要求(已更新):
-在运行300 MHz的ARM Cortex-M7上实现
-算法无法使用堆(malloc)
-支持快速关闭,最大〜50 ms(如果使用大输出/工作缓冲区,则可能无法工作)
-闪存使用<100kb(闪存可能会存储静态字典)
-公羊用法<30kb
-目标压缩率>测试数据文件的40%
-系统当前以30%的空闲时间运行。压缩目标空闲时间>20%
-压缩整个文件
-无损压缩

We'对以下方面的建议特别感兴趣:
-合适的压缩库(我们've例如看着LZ4)
-好的文章/文学,例如不同库的基准或新的有希望的技术/算法
-可能与此类嵌入式压缩特别相关的特定压缩概念/方法
-专家,例如来自学术界,可能会引起一些争吵
-图书馆&与词典使用有关的概念

您的意见将不胜感激-谢谢!

马丁
« 上次编辑:2019年10月2日,上午07:55:39 by 马丁·F »
 

离线 西瓦斯塔加

  • 超级贡献者
  • ***
  • 帖子:3299
  • 国家: 科幻
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下方面回复#1: 十月01,2019,07:20:37下午»
考虑zlib,它非常著名,使用非常广泛。开源,可用工具。我认为通过编译时参数限制搜索窗口,您可以获得大约20-30kB的内存空间。您可以流式传输它,您需要一个缓冲区来容纳块,但是您可以自己决定块的大小。

您可以通过简单地压缩当前数据集以给出一阶近似值来近似类zlib的通用数据压缩率(zlib具有减少的内存占用和减少的压缩级别设置(以节省CPU)将表现得稍差一些,但是问题的起因是相同)。如果您的数据包含大量传感器噪音,则您期望30-40%的压缩率是正确的。如果您的数据有很多重复,相似的值,并且只有很少的噪音,则可以 容易 压缩率超过90%。测试一下。

那最坏的情况呢?您是否可以接受这样的事实,即您的压缩比有时会降低,甚至会略微增大尺寸?或者,您只是想最大程度地延长两次SD卡读取之间的服务时间,因此,只有平均水平才有意义,'t critical.

 

离线 硅向导

  • 超级贡献者
  • ***
  • 帖子:5738
  • 国家: fr
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下问题上回复#2: 十月01,2019,07:28:50下午»
考虑zlib,它非常著名,使用非常广泛。开源,可用工具。我认为通过编译时参数限制搜索窗口,您可以获得大约20-30kB的内存空间。

Are you sure? You may be right, but remembering having to 我们 e zlib a couple years ago, and deal with its source 码, 我的 科幻rst impression would be that I'd真的怀疑……或者可能需要认真剥离和配置它。

 

离线 Nctnico

  • 超级贡献者
  • ***
  • 帖子:20299
  • 国家: nl
    • NCT发展
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下方面回复#3: 十月01,2019,07:30:43下午»
过去,我对车辆数据所做的操作(尽管速率较低,但时间较长)是以XML-ish格式存储为文本的数据,并且仅在更改后才填充字段。否则为逗号。这样,与二进制数据相比,我得到的数据要少得多。我不 '不能准确回忆压缩率,但我很有意义(例如50%IIRC)。因为只存储数字,所以可以将ASCII压缩为5位而不是8位。
« 上次编辑:2019年10月1日,下午7:33:18通过nctnico »
有小谎言,有大谎言,然后示波器的屏幕​​上有东西。
 

离线 硅向导

  • 超级贡献者
  • ***
  • 帖子:5738
  • 国家: fr
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下方面回复#4: 十月01,2019,07:46:49下午»
Well, 对于 text data, 我们 ing just a simple Huffman algorithm (very lightweight) can get you something in the 30% to 50% on average. Takes almost nothing both in 码 and data. Could be enough. Now if it'的纯二进制数据,这实际上取决于内容。

当然,对于记录的数据,一种简单的方法可以是利用以下事实:连续的测量可能非常接近?因此,您可以基于此设计自己的压缩方式。记录物理测量的数据记录器很少会产生完全随机的数据...
 

离线 西瓦斯塔加

  • 超级贡献者
  • ***
  • 帖子:3299
  • 国家: 科幻
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下问题上回复#5: 十月01,2019,08:02:03下午»
考虑zlib,它非常著名,使用非常广泛。开源,可用工具。我认为通过编译时参数限制搜索窗口,您可以获得大约20-30kB的内存空间。

Are you sure? You may be right, but remembering having to 我们 e zlib a couple years ago, and deal with its source 码, 我的 科幻rst impression would be that I'd真的怀疑……或者可能需要认真剥离和配置它。

I'm引用此:

引用
压缩的内存要求取决于两个参数windowBits和memLevel:

   缩小内存使用量(字节)=(1<<(windowBits + 2))+(1<< (memLevel+9))

对于默认值15和8,这分别是256 KB。可以在编译时通过MAX_WBITS和MAX_MEM_LEVEL宏将windowBits和memLevel设置为较低的值,但这只是以压缩效率为代价。

解压缩的内存需求仅取决于windowBits,但是从某种意义上讲,这是一个更严格的限制:尽管使用较小的窗口压缩的数据流将只比它们以其他方式压缩的数据流大一点,但是减小的窗口大小意味着进行压缩用较大窗口压缩的流根本无法解压缩。话说回来:

   扩大内存使用量(字节)=(1<<windowBits)+ 1440 * 2 * sizeof(int)
( //zlib.net/zlib_tech.html )

假设减压是'如果需要板载,则应该有20-30kB的RAM。例如,我不知道将windowBits = 8和memLevel = 5设置为有害的压缩率。它's worth trying. These parameters can be adjusted runtime, example 码 to test it on a workstation is approx. 20 lines of 码.

Zlib是我见过的最简单的库之一。从零到可行解决方案的首次实施不到两个小时。这就是为什么在定制之前值得尝试的原因。

关键是,如果数据是原始CAN帧,'会包含相同的重复ID,可能会包含很多始终为零的MSb,标志字段等等。'即使使用有限的搜索窗口和有限的块大小(由于CAN帧很小,并且车载CAN系统获得了成功),也可以使用通用算法(如zlib)非常好地压缩'无法获得来自数十亿个不同来源的数据,最多只能有十二个)。任何自定义解决方案要么是重新实现一些经典的通用压缩,要么是添加大量运行时解释和数据解析以更有效地存储数据。

如果 you do parse all of the data anyway, then reorganizing it might be the 最好 bet.
« 上次编辑:Siwastaja发表于2019年10月1日,08:09:10 pm »
 

离线 马丁·F

  • 定期贡献者
  • *
  • 帖子:128
  • 国家: dk
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下方面回复#6: 十月01,2019,08:13:35下午»
你好,我们又见面了,

非常感谢您提供的所有宝贵意见!我们设置中的一个挑战是我们'无法使用堆,因此无法使用malloc。
我认为zlib使用我们的堆'我已经聚集了,但是让我知道我是否'这个帐户错了。

再次感谢!
« 上次编辑:2019年10月1日,晚上08:17:36 by 马丁·F »
 

离线 Nctnico

  • 超级贡献者
  • ***
  • 帖子:20299
  • 国家: nl
    • NCT发展
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下方面回复#7: 十月01,2019,08:20:44下午»
Well, 对于 text data, 我们 ing just a simple Huffman algorithm (very lightweight) can get you something in the 30% to 50% on average. Takes almost nothing both in 码 and data. Could be enough. Now if it'的纯二进制数据,这实际上取决于内容。
I'我不是在谈论压缩文本。一世'm在谈论使用文本作为减少数据量的一种方式。在二进制中,一个4字节的数字将始终占用4个字节。即使没有'如果更改,则是否可以压缩完全取决于周围的数据。假设您有一个包含6个4字节数字(总共24个字节)的二进制记录,我使用的文本格式如下:
码: [选择]
1234;56473;587596;226;5859;492|
;;;;;|
1236;56472;;;;|
第一条记录已完成。在第二条记录中,没有任何变化,在第三条记录中,仅前两个字段已更改。总共使用52个字符而不是72个字节。将52个字符转换为4位(0..9和2个额外的字符作为字段分隔符和记录分隔符),您需要26个字节,压缩率超过60%。像任何压缩算法一样,实际压缩将取决于数据,但是如果您需要占用空间少且处理开销低的内容,那么这很简单& effective way.

@Martin F:我认为现有的压缩库将很难在微控制器上使用,因为您'将需要大量的内存(闪存和RAM)和堆。我一直在尝试压缩FPGA图像。
« 上次编辑:2019年10月1日,08:24:08 pm由nctnico »
有小谎言,有大谎言,然后示波器的屏幕​​上有东西。
 

离线 西瓦斯塔加

  • 超级贡献者
  • ***
  • 帖子:3299
  • 国家: 科幻
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下方面回复#8: 十月01,2019,08:36:46下午»
Well, 对于 text data, 我们 ing just a simple Huffman algorithm (very lightweight) can get you something in the 30% to 50% on average. Takes almost nothing both in 码 and data. Could be enough. Now if it'的纯二进制数据,这实际上取决于内容。
I'我不是在谈论压缩文本。一世'm在谈论使用文本作为减少数据量的一种方式。在二进制中,一个4字节的数字将始终占用4个字节。即使没有'如果更改,则是否可以压缩完全取决于周围的数据。假设您有一个包含6个4字节数字(总共24个字节)的二进制记录,我使用的文本格式如下:
码: [选择]
1234;56473;587596;226;5859;492|
;;;;;|
1236;56472;;;;|
第一条记录已完成。在第二条记录中,没有任何变化,在第三条记录中,仅前两个字段已更改。总共使用52个字符而不是72个字节。将52个字符转换为4位(0..9和2个额外的字符作为字段分隔符和记录分隔符),您需要26个字节,压缩率超过60%。像任何压缩算法一样,实际压缩将取决于数据,但是如果您需要占用空间少且处理开销低的内容,那么这很简单& effective way.

@Martin F:我认为现有的压缩库将很难在微控制器上使用,因为您'将需要大量的内存(闪存和RAM)和堆。我一直在尝试压缩FPGA图像。

您正在利用其数据集中的一个特殊功能,该功能主要包含小数字,但有一些奇特的大离群值。当然,在这种情况下,使用ASCII所产生的额外开销可能比您实现的压缩少。

您可以通过许多其他方式来实现相同的想法,而无需使用ASCII(二进制),因此结果将更小。例如,这:
如果值为<65535,将其写成16位(2字节)。
如果值为>= 65535,首先写入65535(后面还有4个字节的标识符),然后再写入所有4个字节。

结果,典型的"median"case将占用2个字节(而不是ASCII解决方案中的5个字节),最坏的情况将占用5个字节(而ASCII版本为11个字节)。

您的第一个6项数据集是全32位数字的24字节,ASCII表示形式的30字节(它已经增长,没有像您想的那样缩小),而在我建议的编码中为15字节。

您的数据量减少来自于"not changed"压缩。同样的二进制解决方案显然更小。

您仅通过保存更改的字段来应用时间压缩的想法是合理的,并且得到了广泛使用,但是我很难理解您如何将其归因于 使用ASCII,尤其是 XML格式-ism(您的编码显然不会't have, thank god) ???

请注意,在传感器读数嘈杂的情况下,这种简单的方案只有在'有关某些传感器比其他传感器采样更多的信息,以及您的日志记录方案迫使您进行等时写入。实际上,可以列出存在的值和不存在的值(而不是始终用逗号分隔所有内容)的记录器可能会更小。特别是如果您可以将数据ID设置为8位。

通常在车辆数据记录中,我'd推测,传感器的测量值落在很小的范围内,因此不需要32位值。这就是重新排列思想的线索:如果仍然解析数据,则可能能够将RPM设置为14位。如果你 发生 要具有仅包含1或2位的8位宽的标志字段,您可以将它们置于16位RPM值的始终为零的MSb中。但是,如果您只想将原始CAN数据流转储到卡上,则必须解析所有内容以进行重新排列,这可能是不必要的负担,即使是简单的通用压缩算法也可以解决您的麻烦,而无需进行大量定制工作。
« 最后编辑:Siwastaja于2019年10月1日,08:49:03 pm »
 

离线 马丁·F

  • 定期贡献者
  • *
  • 帖子:128
  • 国家: dk
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下问题上回复#9: 十月01,2019,08:42:57下午»
还有一点需要注意:我们确实认识到现有的库可能是一个挑战,因为我们无法使用堆,并且由于RAM限制为20-30 kB,因此某些人对基本算法也很感兴趣。

Ie if there’s a base algorithm that would make sense 对于 our type of data and setup, as well as perhaps some suggestions 对于 concepts to combine with this in 要么der to achieve what we’re looking 对于 - then we’d probably be able to 码 this up from scratch in C in relatively short time.

特别是对于我们来说,如果有一些前沿技术和算法可能特别适合此类应用程序,那将是很有趣的。我们也尝试向学术界寻求投入,尽管它也是一个丛林,很难将好东西与其他东西分开。
 

离线 Nctnico

  • 超级贡献者
  • ***
  • 帖子:20299
  • 国家: nl
    • NCT发展
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下问题上回复#10: 十月01,2019,08:54:20下午»
请注意,在传感器读数嘈杂的情况下,这种简单的方案只有在'关于某些传感器的采样频率比其他传感器高
并不是的。来自噪声传感器的数据获胜't压缩任何一种方式。毕竟你可以't压缩噪音。所有压缩算法的共同点是分配最短的算法'code'出现最多的数据模式。但是,在某些情况下,使用针对数据量身定制的算法比标准压缩算法更有效。 Xilinx配置数据就是一个很好的例子。如果您通过通用压缩算法进行操作,您将获得'得到很大的压缩。使用经过优化的算法,可以获得更好的结果;即使算法本身不是'非常复杂。来自传感器的数据是类似的情况。您可以利用数据由行组成的事实。通用压缩算法获胜'真的很在乎这一点,只是将其视为随机数据的一大块。
« 上次编辑:2019年10月1日,08:59:51 pm由nctnico »
有小谎言,有大谎言,然后示波器的屏幕​​上有东西。
 

离线 西瓦斯塔加

  • 超级贡献者
  • ***
  • 帖子:3299
  • 国家: 科幻
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下方面回复#11: 十月01,2019,08:59:15下午»
请注意,在传感器读数嘈杂的情况下,这种简单的方案只有在'关于某些传感器的采样频率比其他传感器高
并不是的。来自噪声传感器的数据获胜't压缩任何一种方式。毕竟你可以't compress noise.

真傻数据如下:
1000
1001
999
1005

压缩得很好。效果如何,取决于算法,但是除非完全烂掉,否则它将大大压缩。

但这不'通过简单的压缩"is changed?" algorithm.

如果您的传感器仅发出100%白噪声,那您是对的。这样可以't be compressed.

 

离线 Nctnico

  • 超级贡献者
  • ***
  • 帖子:20299
  • 国家: nl
    • NCT发展
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下问题上回复#12: 十月01,2019,09:02:01下午»
请注意,在传感器读数嘈杂的情况下,这种简单的方案只有在'关于某些传感器的采样频率比其他传感器高
并不是的。来自噪声传感器的数据获胜't压缩任何一种方式。毕竟你可以't compress noise.

真傻数据如下:
1000
1001
999
1005

压缩得很好。效果如何,取决于算法,但是除非完全烂掉,否则它将大大压缩。
试试看,你'll see it isn'提出通用算法很容易。我参加了一些有关压缩算法BTW的课程。

第一步是分析数据,并查看如何进行压缩。
有小谎言,有大谎言,然后示波器的屏幕​​上有东西。
 

离线 西瓦斯塔加

  • 超级贡献者
  • ***
  • 帖子:3299
  • 国家: 科幻
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下问题上回复#13: 十月01,2019,09:03:19下午»
码: [选择]
[email protected] ~/Desktop $ xxd -p 7f34b296_00000009_00000008.mf4 | grep "ff" -o | wc -l
1049531
[email protected] ~/Desktop $ xxd -p 7f34b296_00000009_00000008.mf4 | grep "00" -o | wc -l
2518089

快速浏览一下数据,似乎零和255个字节占用了大约。您数据的40%。
 

离线 马丁·F

  • 定期贡献者
  • *
  • 帖子:128
  • 国家: dk
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下问题上回复#14: 十月01,2019,09:06:38下午»
没错,00和FF在数据中非常常见,因此在压缩中可能会有一些选择来利用它
 

离线 西瓦斯塔加

  • 超级贡献者
  • ***
  • 帖子:3299
  • 国家: 科幻
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下问题上回复#15: 十月01,2019,09:13:34下午»
所有压缩算法的共同点是分配最短的算法'code'出现最多的数据模式。但是,在某些情况下,使用针对数据量身定制的算法比标准压缩算法更有效。 Xilinx配置数据就是一个很好的例子。如果您通过通用压缩算法进行操作,您将获得'得到很大的压缩。使用经过优化的算法,可以获得更好的结果;即使算法本身不是't very complicated.

可以确认这一点,我建议您查看数据(如果易于获得)。 (通过可用,我的意思是,您解析该MCU上的CAN数据包,并以有意义的变量(例如rpm,speed等)读取数据。)

OTOH,如果您只需要记录所有CAN流量并满足将来的消息需求,'不知道,分析和理解所有内容可能太乏味了。如果仍然需要查看所有数据,则一定要以特定的方式对其进行压缩。无需实际压缩的简单重组(以二进制格式,而不是ASCII或XML格式)可能已经解决了这种情况。通过重组,我的意思是效率低下的选择的位宽和数据字段,如果您确定它们不会引起人们的兴趣,可以将它们组合甚至剥离掉。

该数据集具有来自某种CAN记录设备的标头,因此我'我有点假设他们在"raw" logging. 如果 数据包含完整的CAN数据包报头和具有高分辨率的时间戳,显然要做的是删除大部分报头并减少时间戳位的数量,甚至允许其环绕(您可以在计算期间环绕的数量)解码,假设没有长时间的静默期)。
« 上次编辑:2019年10月1日,9:17:47 pm通过Siwastaja »
 

离线 rstofer

  • 超级贡献者
  • ***
  • 帖子:7765
  • 国家: 我们
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下回复#16: 十月01,2019,09:41:05下午»
您是否考虑过行程编码?  如果 the data doesn't change, it isn't written. 写入时,在实际数据值之前有一个长度计数。
 
以下用户对此帖子表示感谢: 基拉

离线 可调

  • 常客
  • **
  • 帖子:295
  • 国家: 我们
  • 盐'n' pepper beard
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下方面回复#17: 十月01,2019,09:42:21下午»
还有一点需要注意:我们确实认识到现有的库可能是一个挑战,因为我们无法使用堆,并且由于RAM限制为20-30 kB,因此某些人对基本算法也很感兴趣。
You can verify by visual inspection that zlib only 我们 es dynamic memory allocation when building and tearing down the state object and buffers at the start and end of the (in|de)flate functions, does not allocate more while the (in|de)flation is in progress, and does not reallocate at all. You could modify the 码 to replace the dynamic allocations with static buffers quite 容易 if your coding standards so require. It'的许可证极度许可(公共领域),因此没有人需要看您对它做了什么。 ;)

The zlib deflate algorithm is documented in an IETF RFC if you still prefer not to 我们 e zlib 码.
"在Arduino上,天地上的事物比您的哲学梦想中的要多。"
 

线上 机电一体化

  • 超级贡献者
  • ***
  • 帖子:10261
  • 国家: 我的
  • 重新评估指令...
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下方面回复#18: 十月01,2019,10:12:52下午»
最好? i dont know but this is another //liblzg.bitsnbites.eu/ 我想知道什么是最好的,你  have to try few schemes, including your own custom made specific to your data pattern. dictionary based is the famous general purpose to give better average compression rate but the 码 is not so simple. to know how good is the scheme, you may try to compare with well known application such as winzip, your 8MB data compressed to 2MB 我们 ing winzip here, so that can be 我们 ed as benchmark. the 8MB compressed to about 5MB 我们 ing 我的 super crappy simple (FIN) compressor 37% rate so within your spec range ; D iirc的256字节滑动表,可以通过增加表大小来改进... http://www.darkridge.com/~jpr5/mirror/alg/node175.html 但有时"best"不仅由压缩率决定,还需要其他一些方面,例如程序或内存大小,压缩所需的时间,甚至一个字节损坏也可以恢复数据吗?等等。
It'很难开始生活..自然的特征..物理定律是伟大的美的数学理论...您可能想知道为什么?我们的知识表明,自然是如此构成的。我们只需要接受它。可以这样说来描述这种情况...(Paul Dirac)
 

线上 布鲁斯胡特

  • 超级贡献者
  • ***
  • 职位:1890
  • 国家: nz
  • 前身为SiFive,Samsung R&D
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下问题上回复#19: 十月01,2019,10:44:49下午»
lz4,你说你've已经看过,仍然是最好的低CPU低内存使用压缩器。  You'不要使用它来接近它"a simple huffman"压缩机。 zlib可以得到一个 压缩效果好一点,但要花很多CPU和内存。
 

线上 布鲁斯胡特

  • 超级贡献者
  • ***
  • 职位:1890
  • 国家: nz
  • 前身为SiFive,Samsung R&D
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 回复#20: 十月01,2019,11:06:54下午»
lz4,你说你've已经看过,仍然是最好的低CPU低内存使用压缩器。  You'不要使用它来接近它"a simple huffman"压缩机。 zlib可以得到一个 压缩效果好一点,但要花很多CPU和内存。

lz4 -1在0.025s内将您的8660615字节文件减少为4004159字节。
lz4 -9在0.057秒内将您的8660615字节文件减少为3047573字节。
gzip在0.328秒内将您的8660615字节文件减少为2839987字节。
gzip -9在2.454秒内将您的8660615字节文件减少为2661840字节。
bzip2在0.556秒内将您的8660615字节文件减少为2465104字节。

lz4可以非常快速地将文件大小减少50%至60%。是的,其他算法可以比lz4 -9额外获得7%到12%的压缩,或者比lz4 -1额外获得20%的压缩,但是要花费大量的时间和内存。

我没有 '您可以尝试使用lz4库,但可以决定要使用多少RAM。使用20-30 kb没问题。使用更少的内存意味着您可能会放弃一些机会来重用历史中更远的字符串,但是我不知道'认为这会对您的数据产生重大影响。

 

离线 马丁·F

  • 定期贡献者
  • *
  • 帖子:128
  • 国家: dk
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下回复#21: 十月02,2019,07:14:05上午»
你好,我们又见面了,

LZ4也可以选择。我们've also looked at e.g. Zstandard and c-blosc2, but we 科幻nd it a bit difficult to identify the 最好 option.

还要注意,如果我们使用滚动字典,我们'仅限20-30 kb RAM使用。但是,另一种选择是使用静态字典,然后我们将根据数据样本对其进行训练。静态字典的优势在于我们可以利用设备闪存,其中'd能够分配100-150 kb-即可以使用更大的字典。

如果我们沿静态字典路线走下去,您是否对这方面最好的库提出了建议-仍然是例如LZ4 / Zstandard或类似产品,还是其他产品?另外,您是否知道建议的调整/优化以最佳利用例如嵌入式设备上用于实时流压缩目的的100 kb静态字典?

再次感谢,
马丁
 

离线 仓鼠

  • 超级贡献者
  • ***
  • 帖子:2352
  • 国家: nz
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下回复#22: 十月02,2019,07:27:15上午»
通用压缩得到通用结果。数据感知压缩通常可以将原始数据转换为更好的数据,

例如,如果将GPS位置数据转换为偶有参考点和大量增量的数据流,则压缩效果会更好。

当GPS接收机移动时,与不断变化的经纬度面​​包屑流相比,增量更可能是相同的(并且压缩效果更好)。
不要凝视深渊,以免您被公认为深渊领域专家,他们希望您继续凝视那该死的东西。
 

线上 机电一体化

  • 超级贡献者
  • ***
  • 帖子:10261
  • 国家: 我的
  • 重新评估指令...
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下回复#23: 十月02,2019,09:33:28上午»
如果我们沿静态字典路线走下去,您是否对这方面最好的库提出了建议-仍然是例如LZ4 / Zstandard或类似产品,还是其他产品?另外,您是否知道建议的调整/优化以最佳利用例如嵌入式设备上用于实时流压缩目的的100 kb静态字典?
那些基于动态变化的字典的算法会努力工作,实时从先前的输入数据中为连续不断发展的字典/表生成最佳代码,这是一种动态的霍夫曼代码生成方式,但是不会产生数据模式急剧变化的最佳代码,除非您给出相当大的存储空间。此外,如果编码数据位即使稍有变化,也无法在解码期间重建同一表,此后的解码数据将无法识别。如果您可以构建静态表/库,那就更好了,您将不需要复杂的算法(例如LZx或类似的算法),则只需要为静态库预先计算的最佳霍夫曼代码,因此您'事先要有一个静态的霍夫曼代码,然后所需要做的就是在编码输出上以1对1映射,并在解码期间以1对1重新映射(反向),相当快的O(1)操作,没有人能击败。并且在接收机端仍然可以在一定程度上重建损坏的编码数据。问题是当您更改修订版或将其升级到不同的数据模式,并且需要不同的静态表/词典以避免次优压缩率时,解码器需要知道数据正在使用哪个修订版。您仍然可以拥有最快的编码器,但解码器有点slightly肿。但是由于系统通常会在编码器效率上投入很多精力,因此解码器并不是什么大问题。嗯
« 上次编辑:2019年10月2日,上午9:37:03通过Mechatrommer »
It'很难开始生活..自然的特征..物理定律是伟大的美的数学理论...您可能想知道为什么?我们的知识表明,自然是如此构成的。我们只需要接受它。可以这样说来描述这种情况...(Paul Dirac)
 

离线 硅向导

  • 超级贡献者
  • ***
  • 帖子:5738
  • 国家: fr
回复:用于低RAM嵌入式数据压缩的最佳库/算法?
« 在以下回复#24: 十月02,2019,12:10:43下午»
只是有关传感器噪声的注释。它是否真正阻碍压缩取决于压缩方案,当然还取决于噪声的带宽。宽带噪声是最坏的情况-它'接近完全随机的数据,但是您很少会从传感器那里获得数据-但是会产生少量噪声'如果您使用仅编码值差异的某种压缩方案,通常会遇到很大的问题。关键只是噪声幅度,而不是是否存在噪声。当然,某些方案如RLE赢得了'即使噪声幅度很低,它也无法很好地处理嘈杂的数据,但是其他方案(如仅编码差异)也可以。与ADPCM等类似。

您可以设计一种压缩方案,将几种方法结合在一起。

最后,如果可以让zlib或LZ4产生>40% compression, and 科幻t within 30KB RAM and 100KB 码 (including possible predefined tables), That'会很有趣。唐't hesitate to post 科幻gures if you can. For RAM 我们 age, it seems possible from what has been noted above, but I still wonder whether this is not optimistic as to the real total RAM 我们 age, including all local variables etc... but the thing I wonder about the most is 码 size. So, it'会很有趣。
 


分享我

掘客  脸书  SlashDot  美味的  Technorati  推特  谷歌  雅虎
中频