Releases: tayloraswift/swift-png
4.4.6
Contributors
Assets 2
4.4.5
What's Changed
- validate docs by @tayloraswift in #75
- Support older Apple platforms by @stackotter in #76
New Contributors
- @stackotter made their first contribution in #76
Full Changelog: 4.4.4...4.4.5
Contributors
Assets 2
4.4.4
this release works around a source compatibility bug in the Swift compiler, enabling the library to be used with the Xcode 17 beta. this release is a temporary accommodation for macOS users that will no longer be necessary after the Swift 6.0 release, as the upstream bug has already been fixed.
4.4.1
this release patches a critical vulnerability that occurs when the DEFLATE backend attempts to compress very short inputs (less than 3 bytes) causing a runtime crash.
for applications using the library for PNG compression, the attack is only effective if the server is asked to compress a 1x1 pixel grayscale image, as all other types of PNG images create data streams that are longer than 2 bytes.
all Swift PNG users are advised to upgrade to 4.4.1 immediately.
4.4
Swift PNG 4.4 adds gzip compression and decompression tools to the LZ77 module, and updates the documentation with examples of how to use gzip compression in your app.
Internally, Swift PNG 4.4 also adopts nested protocols (SE-0404), which makes the documentation easier to navigate but should be an API-transparent change, as all of these protocols were already informally namespaced via typealiases.
Swift PNG 4.4 requires Swift 5.10 or newer.
Why use Swift PNG’s gzip implementation?
Swift PNG’s native Swift gzip implementation is not as fast as some existing C libraries which are found on many systems. However, a lot of optimization work went into the LZ77 module long ago, and the Swift version should not be significantly slower than an equivalent C library.
Applications that compress large volumes of data and do little else may be better off calling a system C library instead of using LZ77. However the complexity of marshaling data through a C library can often be a disincentive to using compression in more peripheral use cases, and having a convenient, portable Swift library available that still performs reasonably well can help make applications more efficient overall.
Why is the gzip library still part of Swift PNG?
The compression backend was written long ago exclusively for Swift PNG, and the decision to expose it to external clients was only made recently. The PNG library helps us test the correctness of the gzip backend, as the PNG format is little more than a wrapper around an LZ77 data stream.
Applications that depend on the LZ77 target only will not pull in PNG-related code.
How can I help?
Rewriting the project’s benchmarks to use the more-modern package-benchmark framework would help us gain better visibility into how the library is performing relative to system C libraries. PRs that add benchmark integrations to the project are likely to be merged.
4.3.0
This release is almost entirely focused on documentation, as much of the library’s existing docs had rotted due to evolution of tooling. We have rewritten the package’s examples and tutorials and repaired scores of broken doccomments, and the package’s documentation is now available on swiftinit.org.
4.1
This release is focused on separating out the LZ77/DEFLATE implementation from the rest of the library, and making it available for use as a general-purpose data compressor. The package now vends a separate library target, LZ77, which exposes the DEFLATE implementation.
Currently, only the deflate wrapper format is supported, although we plan on supporting the gzip wrapper format in a future release. An example of how to use the new API can be found in the BasicCompression.swift snippet.
While preparing this release, it was discovered that SIMD-accelerated encoding backend was broken on Apple Silicon; a problem that was only uncovered upon upgrading the CI runners to macOS 14. This bug has been fixed in 4.1.
Swift PNG 4.0.1
Minor concurrency patch: Adds Sendable conformances to the built-in generic RGBA<T> and VA<T> types.
Swift PNG 4.0
Swift PNG
4.0.0
features
-
Powerful interfaces. Swift PNG’s expressive, strongly-typed APIs make working with PNG images easy for beginners and advanced users alike. If your code compiles, you’re already most of the way there. Power users can take advantage of custom indexing, manual decoding workflows, and user-defined color targets.
-
Superior compression. Swift PNG supports minimum cost path-based DEFLATE optimization, which is why it offers four additional compression levels beyond what libpng supports. Swift PNG outperforms libpng at its highest compression setting by significant margins for almost all types of input images.
-
Competitive performance. Swift PNG offers competitive performance compared to libpng. On appropriate CPU architectures, the Swift PNG encoder makes use of hardware-accelerated hash tables for even greater performance.
-
Pure Swift, all the way down. Aside from having no external dependencies, Swift PNG is powered by its own, native Swift DEFLATE implementation. This means Swift PNG works on any platform that Swift itself works on. It also means that Swift PNG’s performance improves as the Swift compiler matures.
-
Batteries included. Swift PNG comes with built-in color targets with support for premultiplied alpha. Convolution and deconvolution helper functions make implementing custom color targets a breeze.
On MacOS and Linux, Swift PNG has built-in file system support, allowing you to compress or decompress an image, given a filepath, in a single function call. Other platforms can take advantage of Swift PNG’s protocol-oriented IO to implement their own data loading.
-
First-class iPhone optimization support. Swift PNG requires no custom setup or third-party plugins to handle iPhone-optimized PNG images. iPhone-optimized images just work, on all platforms. Reproduce
pngcrush’s output with bit width-aware alpha premultiplication, for seamless integration anywhere in your application stack. -
Comprehensive metadata support. Swift PNG can parse and validate all public PNG chunks, which are accessible as strongly-typed metadata records.
-
Modern error handling. Swift PNG has a fully stateless and Swift-native error-handling system.