decode, inspect, edit, and encode png images in pure swift
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.
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.
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.
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.
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.
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.
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.
Minor concurrency patch: Adds Sendable conformances to the built-in generic RGBA<T> and VA<T> types.
Swift PNG
4.0.0
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.
This release addresses @_specialize warnings produced by compiler PR #30962 which affects users using the nightly 5.2+ builds.
This release fixes some compiler warnings due to compiler drift from Swift 4.2 to 5.2+, and with the agreement of all contributors, re-licenses the library under a weaker copyleft license, the Mozilla Public License 2.0.
The library has been completely rewritten since version 2.0.1 and now features a much streamlined and improved API, as well as ancillary PNG chunk support, and a wider variety of color format inputs and outputs. Grayscale–alpha and indexed color now have first-class status in the 3.0 API, and are fully integrated with all PNG color backends in the file format’s specification. The typing system has also been greatly strengthened, resulting in an API which returns far fewer optionals, provides more expressive enumerations, and has a much greater chance of catching errors at compile time.
This release adds a new overload to png_encode(path:raw_data:properties:chunk_size:) that takes a Swift UnsafeBufferPointer<UInt8> instead of an Array, to avoid having to recopy a foreign array into Swift managed memory.