是否有比 JPEG 更快的有损压缩?

发布于 2024-10-09 18:22:53 字数 131 浏览 9 评论 0原文

是否有比 JPEG 更快且得到良好支持的压缩算法?我了解 jpeg2000,但据我所知,它实际上并没有那么快。

编辑:用于压缩。

Edit2:它应该在 Linux 32 位上运行,理想情况下应该是 C 或 C++。

Is there a compression algorithm that is faster than JPEG yet well supported? I know about jpeg2000 but from what I've heard it's not really that much faster.

Edit: for compressing.

Edit2: It should run on Linux 32 bit and ideally it should be in C or C++.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

天涯沦落人 2024-10-16 18:22:53

Jpeg 编码和解码应该非常快。您将很难找到更快的算法。如果速度很慢,您的问题可能不是格式而是编码器的错误实现。尝试使用 ffmpeg 项目中的 libavcodec 编码器。

Jpeg encoding and decoding should be extremely fast. You'll have a hard time finding a faster algorithm. If it's slow, your problem is probably not the format but a bad implementation of the encoder. Try the encoder from libavcodec in the ffmpeg project.

寻梦旅人 2024-10-16 18:22:53

您的目标架构上有可用的 MMX/SSE2 指令吗?如果是这样,您可以尝试 libjpeg-turbo。或者,您可以使用 zlib 之类的东西压缩图像,然后将实际的缩减卸载到另一台机器吗?图像的实际有损压缩是否必须在嵌入式设备本身上进行?

Do you have MMX/SSE2 instructions available on your target architecture? If so, you might try libjpeg-turbo. Alternatively, can you compress the images with something like zlib and then offload the actual reduction to another machine? Is it imperative that actual lossy compression of the images take place on the embedded device itself?

聽兲甴掵 2024-10-16 18:22:53

在什么背景下?在 PC 或便携式设备上?

根据我的经验,您可以使用 JPEG、JPEG2000、PNG 和……呃,这就是在广泛的上下文中“良好支持”的图像类型(有损与否!)

(万岁,GIF 即将退出历史舞台。 )

In what context? On a PC or a portable device?

From my experience you've got JPEG, JPEG2000, PNG, and ... uh, that's about it for "well-supported" image types in a broad context (lossy or not!)

(Hooray that GIF is on its way out.)

生寂 2024-10-16 18:22:53

JPEG2000 一点也不快。 jpeg 的编码或解码速度不够快吗?仅对 jpeg 执行 4x4 FDCT 和 IDCT 可能会快很多。

很难找到有关 IJG libjpeg 的任何文档,但如果您使用它,请尝试降低质量设置,它可能会使其更快,而且似乎还有一个快速 FDCT 选项。

有人提到 libjpeg-turbo 使用 SIMD 指令并且与常规 libjpeg 兼容。如果这是您的选择,我认为您应该尝试一下。

JPEG2000 isn't faster at all. Is it encoding or decoding that's not fast enough with jpeg? You could probably be alot faster by doing only 4x4 FDCT and IDCT on jpeg.

It's hard to find any documentation on IJG libjpeg, but if you use that, try lowering the quality setting, it might make it faster, also there seems to be a fast FDCT option.

Someone mentioned libjpeg-turbo that uses SIMD instructions and is compatible with the regular libjpeg. If that's an option for you, I think you should try it.

遮了一弯 2024-10-16 18:22:53

我认为基于小波的压缩算法通常比使用 DCT 的压缩算法慢。也许您应该看看 JPEG XR 和 WebP 格式。

I think wavelet-based compression algorithms are in general slower than the ones using DCT. Maybe you should take a look at the JPEG XR and WebP formats.

梦幻的心爱 2024-10-16 18:22:53

如果不需要完整的图像保真度,您可以简单地将图像大小调整为较小的图像。将每个 2x2 块平均为一个像素将很快将尺寸减小到 1/4。

You could simply resize the image to a smaller one if you don't require the full image fidelity. Averaging every 2x2 block into a single pixel will reduce the size to 1/4 very quickly.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文