TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Libspng – C library for reading and writing PNG files

159 点作者 randy408将近 6 年前

13 条评论

derefr将近 6 年前
I gotta say, it’s great that someone is making this attempt, however it turns out. PNG has been in a uniquely bad position re: “monoculture”, with libpng being not just the “reference implementation”, but the <i>only</i> implementation anyone bothers to use.<p>But libpng was intended as <i>only</i> a reference implementation—a rigid adherent to the PNG standard, for the sake of having a “runnable version” of the PNG standard—and was never particularly optimized for production use-cases, or code readability&#x2F;maintainability&#x2F;low attack surface, or any other criteria you might like to have. Libpng is optimized for one thing only: allowing other PNG implementations to build spec-compatibility test suites by testing against libpng behaviour.<p>Because of this rigid adherence, libpng doesn’t implement—and will never implement—any features that <i>aren’t</i> in the base PNG spec, like APNG.<p>And since everyone <i>uses</i> libpng as their PNG implementation (for <i>some</i> reason), nobody ends up adopting these extra features. (Sure, all the major browsers except Edge support APNG, but does your image editor? Does your IoT thermostat whose OS uses PNG image assets? Does your game console? Nah. Because these all just compile in libpng. And <i>this</i> is what kills support for features like APNG in the crib.)<p>That was never the PNG Working Group’s intent, of course. They don’t want to restrict the development of extra PNG features (yes, even though they developed MNG and might see features like APNG as “competing” with MNG, they don’t really care.) They keep libpng the way it is, not for ideological reasons, but simply because they don’t care about doing anything with libpng that moves it away from “reference implementation of the base PNG spec” territory. (And why would they? Their job as the PNG Working Group is to produce the PNG base spec. It’s supposed to be everyone <i>else’s</i> job, in the ecosystem, to produce conformant implementations. They even gave you libpng to make that easier!)<p>So, like I said, I’m glad someone is finally writing an alternative implementation (in C), such that the projects that currently use libpng could reasonably choose to switch to libspng. It’s the same feeling I get from seeing LibreSSL and BoringSSL: that an ecosystem that was essentially “dead” and stuck in a set of bad choices due to everyone sticking with one unchanging reference impl, is now coming alive again.
评论 #20758819 未加载
评论 #20758608 未加载
Ono-Sendai将近 6 年前
Some performance tests decoding PNGs:<p>Platform: Windows 10, Visual Studio 2019, RelWithDebInfo config, Intel Core i7-8700K. Compiled with -DSPNG_SSE=3.<p><pre><code> testing loading image: D:\art\cryptovoxels\ortho overview.png (32-bit, large) libSPNG decode took 0.2221 s libPNG decode took 0.2373 s libSPNG decode took 0.2215 s libPNG decode took 0.2364 s testing loading image: D:\art\dof_test_output.png (32-bit) libSPNG decode took 0.01101 s libPNG decode took 0.01225 s libSPNG decode took 0.01096 s libPNG decode took 0.01205 s testing loading image: D:\art\skymodel2_test3\top2 CPU.png (24-bit) libSPNG decode took 0.008874 s libPNG decode took 0.009399 s </code></pre> So Libspng seems slightly faster, but certainly not 35% faster, in these tests.
评论 #20756968 未加载
评论 #20756863 未加载
评论 #20759257 未加载
floor_将近 6 年前
I find stb_image single file format and lack of dependencies to be extremely convenient.
评论 #20756635 未加载
评论 #20756570 未加载
kodablah将近 6 年前
I wonder how these libraries compare to using something like image-rs [0] w&#x2F; a custom-exported C FFI extern? I have used that library&#x27;s PNG decoder&#x2F;encoder in WASM and it seems simple and small and fast. I think it&#x27;d be worthy to include in the next bench round since it&#x27;s only a bit of glue code away from a &quot;C library&quot; too.<p>0 - <a href="https:&#x2F;&#x2F;github.com&#x2F;image-rs&#x2F;image" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;image-rs&#x2F;image</a>
anaphor将近 6 年前
How does this compare to something like <a href="https:&#x2F;&#x2F;github.com&#x2F;nothings&#x2F;stb&#x2F;blob&#x2F;master&#x2F;stb_image.h" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nothings&#x2F;stb&#x2F;blob&#x2F;master&#x2F;stb_image.h</a> ?<p>Is it just that it has more features and can handle weird edge cases?
评论 #20758765 未加载
Ono-Sendai将近 6 年前
Doesn&#x27;t compile &#x27;out of the box&#x27; in Visual Studio 2019.
评论 #20756533 未加载
评论 #20756569 未加载
ape4将近 6 年前
Just to say the obvious: by using zlib it gets future speed improvements and bug fixes &quot;for free&quot;.
wyldfire将近 6 年前
FYI, randy: `fmt` is not declared in `Decode example - libspng`.
评论 #20756638 未加载
peapicker将近 6 年前
Looks like it only does reading at this point - I can find docs or entry points in the code for writing png.
megous将近 6 年前
Thanks for including ARM optimizations and using meson. I&#x27;ll try to use this with my tablet UI app.
Ono-Sendai将近 6 年前
Question: do you have to decode to a 4-channel format, e.g. with alpha? What about decoding to just RGB?
评论 #20756885 未加载
your-nanny将近 6 年前
I don&#x27;t program C languages, but I can&#x27;t help but feel that naming your incompatible library libspng you are introducing a source of potential confusion.<p>edit: Thank you cormacrelf for the explanation re: lib being mandatory. Thank you OP for explaining your rationale.
评论 #20756044 未加载
评论 #20755978 未加载
评论 #20756307 未加载
评论 #20756190 未加载
bhouston将近 6 年前
libpng is so slow to compress. A large 2000x2000 png will actually take about 1 second to compress. This is basically forever for a user experience.
评论 #20756029 未加载
评论 #20759742 未加载
评论 #20756240 未加载