Silverlight 4.0 的最佳 Jpeg 编码器

发布于 2024-10-05 18:19:09 字数 93 浏览 0 评论 0原文

我想将 Writablebitmap 转换为 Jpeg 流,看起来没有平台支持,而且我可以在网络上看到一堆开源编码器库,我想听听您的意见,就性能和性能而言,推荐哪个可靠性。

I want to convert Writablebitmap to Jpeg stream, and it looks like there is no platform support as well as I can see a bunch of opensource Encoder libraries on web, I want to get your opinion on which is the recommended one in terms of performance and reliability.

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

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

发布评论

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

评论(3

笛声青案梦长安 2024-10-12 18:19:09

我在 FJCore 方面获得了良好的体验。
我不久前也在博客上介绍过它 http://kodierer .blogspot.com/2009/11/convert-encode-and-decode-silverlight.html

I made good experience with FJCore.
I also blogged about it a while ago http://kodierer.blogspot.com/2009/11/convert-encode-and-decode-silverlight.html

江南月 2024-10-12 18:19:09

我在 FJCore 和 LibJpeg.Net 上花费了相当多的时间。 FJCore 更容易使用,因为它是从 Java 移植过来的,并且有一个与您期望在 C# 中看到的对象模型有些相似的对象模型。然而,LibJpeg.NET 是迄今为止更完整的库(它基于非正式规范的 libjpeg),并且它也明显更快。举一个例子,FJCore 使用一种简单的逆离散余弦变换实现,其中涉及每个 8x8 块的 1024 次乘法和额外的 1024 次加法。相比之下,LibJpeg.NET 使用高性能 AAN 算法,仅需要 144 次乘法和 464 次加法(参见 http://datasheets.chipdb.org/Intel/x86/MMX/MMX/AP528.HTM#AAN 算法)。此外,FJCore 在使用内存方面相当低效,不断地重新创建可以轻松重用的对象。同时,由于 FJCore 的优化较少,因此更容易被黑客攻击。

对于我当前的项目(涉及为 Silverlight 编写视频编解码器),我使用 FJCore 作为起点,修复了一大堆低效率的问题,用 LibJpeg.NET 的算法替换了它的 IDCT 算法,最后得到了一些东西我的性能大约是原来的 10 倍。

I've spent quite a bit of time with both FJCore and LibJpeg.Net. FJCore is easier to use, since it was ported over from Java, and has an object model that vaguely resembles what you'd expect to see in C#. However, LibJpeg.NET is by far the more complete library (it's based on the informally canonical libjpeg), and it's significantly faster as well. To give one example, FJCore uses a naive implementation of an inverse discrete cosine transform that involves something like 1024 multiplications and an additional 1024 additions for each 8x8 block. In contrast, LibJpeg.NET uses the high performance AAN algorithm which only takes 144 multiplications and 464 additions (see http://datasheets.chipdb.org/Intel/x86/MMX/MMX/AP528.HTM#AAN Algorithm). In addition, FJCore is fairly inefficient in how it uses memory, constantly recreating objects that could easily be re-used. At the same time, because FJCore has fewer optimizations, it's significantly easier to hack.

For my current project (which involves writing a video codec for Silverlight), I used FJCore as a starting point, fixed a whole bunch of its inefficiencies, replaced its IDCT algorithm with the one from LibJpeg.NET, and ended up with something that gave me about 10x the original performance.

葮薆情 2024-10-12 18:19:09

Ken 为什么不将更新的代码提交到 FJCore 源呢?

http://code.google.com/p/fjcore/

Ken why don't you submit your updated code to the FJCore source?

http://code.google.com/p/fjcore/

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