Hi, thanks for Oxipng!
I saw further down in the readme that Oxipng was being used in the
middle of a sentence with a capital O, so I adjusted the other lowercase
usages (other than the usages in backticks, which may instead refer to
the command line program itself) from "oxipng" to also use "Oxipng"
Fix#610
- [x] Native cross-compilation support in Dockerfile. Only `linux/amd64`
and `linux/arm64` supported and tested (Tier 1 platform support from
Rust)
- [x] Cache support for cargo downloads and compilation results in
Dockerfile
- [x] Open Container's
[annotations](https://github.com/opencontainers/image-spec/blob/main/annotations.md)
in Dockerfile
- [x] GitHub Actions workflow to build the image for both platforms,
publishing to ghcr.io on tags and master branch pushes.
- [x] Disable use of GitHub Actions cache for tags build, allow manually
triggering the workflow with or without cache.
- [x] [Attestation
artifacts](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds)
for builds
- [x] Add basic informations about the use of the Docker image in README
I also changed the WORKDIR from `/src` to `/work`, because if got me
confused with the use of the src folder for the project source in the
first stage of the Dockerfile. It doesn't impact anything anyways since
you can mount the file where you want and have the program options point
to it.
**How to test?**
_After checking out the branch and making sure you have QEMU installed
to build/test_
```shell
# Docker sadly doesn't have yet the way to have locally a tag with multiple platforms
# despite being able to pass multiple platforms to the build command, so we have to use two distinct tags.
docker build --platform=linux/amd64 --tag test-oxipng-amd:latest --load .
docker build --platform=linux/arm64 --tag test-oxipng-arm:latest --load .
docker run --rm test-oxipng-amd:latest --version
docker run --rm test-oxipng-arm:latest --version
# Run on some files
docker run --rm -it -v $(pwd):/work test-oxipng-amd:latest -a /work/tests/files/apng_file.png
docker run --rm -it -v $(pwd):/work test-oxipng-arm:latest -a /work/tests/files/apng_file.png
# Remove the images
docker image rm test-oxipng-amd:latest
docker image rm test-oxipng-arm:latest
```
For the workflow, see the GitHub Actions logs. If you want to test the
ghcr.io publishing you can merge the branch into a fork and see the
result.
---------
Co-authored-by: Alejandro González <me@alegon.dev>
PR #596 brought forward automatic generation of Linux manual pages for
Oxipng, which is executed every time Oxipng is built. However, while
building manpages on every build is convenient for Oxipng development
and doing so didn't catch my attention initially, it introduces
noticeable inefficiencies for crates using Oxipng as a library: during
their build, Oxipng manpages are also built, even though most dependent
crates won't use such artifacts, as they are not considered part of the
public Oxipng crate API or even appropriate for non-human consumption.
Moreover, generating manpages depends on `clap`, which is a heavyweight
dependency: according to a fresh `cargo build --timings --release` on my
development workstation, its `clap_builder` dependency is the third most
time consuming unit to build, totalling 1.5 s (out of 11.7 s, or 12.8%).
And there is no way for dependent crates to turn this off:
[`build-dependencies` cannot be conditional on crate
features](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#platform-specific-dependencies).
Potentially using other `cfg` hacks to either enable or disable manpage
generation is unergonomic, if not outright disallowed. Besides reducing
their compilation time cost, dependent crates may also want to trim the
size of their dependency tree, avoiding unnecessary dependency downloads
in the process.
Therefore, a better solution to conditionally build manpages in a way
convenient for both Oxipng maintainers and downstream consumers is
needed. My proposal implemented in this PR is to leverage the
[`cargo-xtask`](https://github.com/matklad/cargo-xtask) convention to
define an auxiliary crate to move the manpage generation logic and
dependencies to, which is not part of the `oxipng` crate published on
`crates.io`. That way Oxipng maintainers and packagers can still
generate manpages at request with ease, without any automation being
noticeable to uninterested crate consumers. And as a side benefit,
Oxipng maintainers can also benefit from slightly faster iteration times
due to the lack of a build script for the main crate.
The new `mangen` xtask can be run at any time with `cargo xtask mangen`.
The generated manpages are now available at
`target/xtask/mangen/manpages`. Existing deployment scripts were updated
accordingly.
Allow the creation of PNGs with uncompressed deflate streams via level 0
of libdeflate. If you want a glorified BMP with delta filters, this
change will make your dreams come true 🙂.
This PR extends the `--zopfli` argument with an optional iteration
count. In my case, I have a bunch of very small images (a few kB or
less), and I often like to use hundreds of iterations to squeeze off the
last several bytes. (I know that this crate isn't intended for
brute-force optimization, but I've found that some of its
transformations and filter strategies can be more creative than
`zopflipng`.) But this is also useful in the opposite direction, for
allowing Zopfli compression on large images where 15 iterations would be
prohibitive.
After testing more thoroughly on my box, it turned out that the libgcc
linking workaround should indeed fix our build errors, but on CI that
did not happen because the `RUSTFLAGS` environment variable is set,
which takes precedence over any configuration at `.cargo/config.toml`.
Therefore, let's also add the workaround to `RUSTFLAGS` on the CI
workflow definition.
This should be a satisfactory enough stopgap solution that does not
require ourselves to be pinned to a specific nightly or drop these
builds until https://github.com/rust-lang/rust/issues/128401 is sorted
out.
It's easy to miss them out if CI is not aborted on a Clippy lint, and
this behavior change was an unintended regression when CodeQL
integration was added, so let's change it back.
I have identified two potential improvements for how we perform static analysis
on our code in our CI pipeline:
- The `giraffate/clippy-action` we currently use has not been updated to Node
20, and GitHub has repeatedly indicated that they will phase out actions that
do not support the latest Node versions. Despite my efforts to help with the
update by submitting a pull request upstream, it has been ignored for months
despite its perceived ease of review, raising concerns about the ongoing
maintenance of the action. This situation suggests we should explore
alternative methods for integrating Clippy with GitHub's UI.
- As evidenced by PR 632, thoroughly testing Rust crates for every possible
feature combination is often overlooked due to the tedious nature of the task.
Our current CI setup only checks two feature combinations, which is far from
comprehensive.
To address the first improvement, these changes drop `clippy-action` entirely in
favor of utilizing GitHub's native CodeQL SARIF (Static Analysis Results
Interchange Format) file integration. Since Clippy cannot directly output lints
in SARIF, `clippy-sarif` is used to convert Clippy's JSON output to SARIF.
Additionally, `sarif-fmt` is added to turn SARIF into a human-friendly display
format in the workflow run logs.
For the second improvement, let's use `cargo hack` with the `--feature-powerset`
flag to run Clippy for every possible feature combination. This approach strikes
a good balance between CI runtime and thoroughness, as the number of feature
combinations grows superlinearly with the number of features: running `cargo
nextest` for every powerset element would lead to excessively long CI times.
Fixes#619.
Interlacing still defaults to 0 when `--nx` is not specified and can
still be explicitly set even if it is (e.g. `-i 0 --nx` will still
deinterlace).
This PR adds the modified zeng ("mzeng") palette sorting method, in
addition to the existing luma and battiato methods. Speed is very
similar to the battiato method with slightly better results on average.
Resulting sizes from two different image sets (all indexed or able to be
indexed):
| | master | PR |
|-|-|-|
| Set 1 | 29,647,156 | 29,555,697 |
| Set 2 | 23,732,133 | 23,570,862 |
Additionally, I've added a new "first colour" heuristic for both the
mzeng and battiato methods: We use the most popular colour overall, but
only if it covers at least 15% of the image. This provided 13k savings
on Set 2 vs the edge colour heuristic (which is still used in the luma
sort).
Repology is a free service that monitors the packaging status of
projects in lots of package repositories, and offers a nice API to
generate badges with a summary of what OxiPNG versions are available in
what repositories. Let's introduce that to our README to make it easier
for users to decide whether to use a package manager of their
convenience, and visibilize the work package maintainers do with OxiPNG.
GitHub introduced free macOS ARM runners on January, and my experience
using them in other projects to improve CI times and be able to actually
run tests on Apple Silicon Macs has been positive. Let's use them in
OxiPNG to hopefully speed up CI a bit, and finally be able to run the
test suite on AArch64 macOS.
