govips' generic Export sent libvips a zero for some settings pixa left out, so PNG had no compression and WebP effort 0. Each format now has its own export with its settings named, as JPEG XL has had since #230:
GIF: effort 7, libvips' default, which it already had.
JPEG: unchanged.
Saving an 8192x8192 noise image on this host with one libvips thread, as pixad does, at a load of about 100 on 48 cores: WebP 36 to 45 s at effort 4 (3 s at 0), AVIF 228 s at effort 4, 56 s at 2, 12 s at 1, PNG 9 s, against the default downstream_timeout of 60 s.
Deviation: AVIF is at effort 1, as libvips' default is far past downstream_timeout and 2 fits only barely. Every AVIF output changes.
Judgement call: WebP keeps libvips' default, which fits but leaves about 15 s for the fetch and decode.
Judgement call: govips sends the AVIF effort only with a bit depth, set to 8; a 16-bit source, saved with 12 bits until now, gets 8.
GIF and JPEG output does not change, so they have no new test: one could not fail first.
README.md does not describe encoder settings and is unchanged.
Model: opus-5-5
govips' generic `Export` sent libvips a zero for some settings pixa left out, so PNG had no compression and WebP effort 0. Each format now has its own export with its settings named, as JPEG XL has had since https://git.eeqj.de/sneak/pixa/pulls/230:
- PNG: compression 6, libvips' default (was 0).
- WebP: effort 4, libvips' default (was 0).
- AVIF: effort 1 (was libvips' default, 4), 8 bits per sample.
- GIF: effort 7, libvips' default, which it already had.
- JPEG: unchanged.
Saving an 8192x8192 noise image on this host with one libvips thread, as pixad does, at a load of about 100 on 48 cores: WebP 36 to 45 s at effort 4 (3 s at 0), AVIF 228 s at effort 4, 56 s at 2, 12 s at 1, PNG 9 s, against the default `downstream_timeout` of 60 s.
- Deviation: AVIF is at effort 1, as libvips' default is far past `downstream_timeout` and 2 fits only barely. Every AVIF output changes.
- Judgement call: WebP keeps libvips' default, which fits but leaves about 15 s for the fetch and decode.
- Judgement call: govips sends the AVIF effort only with a bit depth, set to 8; a 16-bit source, saved with 12 bits until now, gets 8.
- GIF and JPEG output does not change, so they have no new test: one could not fail first.
- `README.md` does not describe encoder settings and is unchanged.
Model: opus-5-5
internal/imageprocessor/imageprocessor.go:600 (also TODO.md:41-42 and the PR body): AVIF is now always saved with 8 bits per sample, so every 16-bit source, which libvips saves with 12, loses its extra precision, and no measured reason is given. govips needing a bit depth alongside the effort explains why one must be set, not why it is 8, and the definition of done in #232 keeps libvips' defaults unless there is a measured reason. Acceptable: 12 bits for a 16-bit image and 8 for any other, as libvips chooses, with a 16-bit source in the worst-case timing; or keep 8 and state the measured reason in the PR body and the code comment. Either way the TODO.md sentence should say what was decided and why, not that the govips constraint forces 8.
internal/imageprocessor/encoder_settings_internal_test.go:109: the 64x48 test image comes out the same size at effort 2 as at effort 1, so TestImageProcessor_AVIFAtEffort1 cannot tell them apart, and 2 is the effort the PR rejects as too slow for downstream_timeout. Acceptable: a source, still small enough to keep the test fast, on which efforts 1 and 2 give different sizes.
Judgement calls accepted:
AVIF at effort 1 rather than libvips' 4, on the measured reason given.
WebP at libvips' default effort, 4.
Not verified: the 8192x8192 timings in the PR body.
Model: opus-5-5
Findings:
1. `internal/imageprocessor/imageprocessor.go:600` (also `TODO.md:41-42` and the PR body): AVIF is now always saved with 8 bits per sample, so every 16-bit source, which libvips saves with 12, loses its extra precision, and no measured reason is given. govips needing a bit depth alongside the effort explains why one must be set, not why it is 8, and the definition of done in https://git.eeqj.de/sneak/pixa/issues/232 keeps libvips' defaults unless there is a measured reason. Acceptable: 12 bits for a 16-bit image and 8 for any other, as libvips chooses, with a 16-bit source in the worst-case timing; or keep 8 and state the measured reason in the PR body and the code comment. Either way the `TODO.md` sentence should say what was decided and why, not that the govips constraint forces 8.
2. `internal/imageprocessor/encoder_settings_internal_test.go:109`: the 64x48 test image comes out the same size at effort 2 as at effort 1, so `TestImageProcessor_AVIFAtEffort1` cannot tell them apart, and 2 is the effort the PR rejects as too slow for `downstream_timeout`. Acceptable: a source, still small enough to keep the test fast, on which efforts 1 and 2 give different sizes.
Judgement calls accepted:
- AVIF at effort 1 rather than libvips' 4, on the measured reason given.
- WebP at libvips' default effort, 4.
Not verified: the 8192x8192 timings in the PR body.
Model: opus-5-5
Each output format now has its own govips export with its settings
named, in place of govips' generic Export, which sent libvips a zero for
some settings it was not given: PNG had no compression and WebP effort
0. PNG now gets libvips' default compression, 6, and WebP its default
effort, 4. GIF was already at libvips' default effort, and JPEG output
is unchanged.
AVIF was at libvips' default effort, 4, which takes minutes for an
8192x8192 image with one libvips thread, far past the default
downstream_timeout; effort 1 takes about 12 seconds. A 16-bit source,
which libvips would save with 12 bits per sample, gets 8: at effort 1,
12 bits take about 54 seconds.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
govips' generic
Exportsent libvips a zero for some settings pixa left out, so PNG had no compression and WebP effort 0. Each format now has its own export with its settings named, as JPEG XL has had since #230:Saving an 8192x8192 noise image on this host with one libvips thread, as pixad does, at a load of about 100 on 48 cores: WebP 36 to 45 s at effort 4 (3 s at 0), AVIF 228 s at effort 4, 56 s at 2, 12 s at 1, PNG 9 s, against the default
downstream_timeoutof 60 s.downstream_timeoutand 2 fits only barely. Every AVIF output changes.README.mddoes not describe encoder settings and is unchanged.Model: opus-5-5
Findings:
internal/imageprocessor/imageprocessor.go:600(alsoTODO.md:41-42and the PR body): AVIF is now always saved with 8 bits per sample, so every 16-bit source, which libvips saves with 12, loses its extra precision, and no measured reason is given. govips needing a bit depth alongside the effort explains why one must be set, not why it is 8, and the definition of done in #232 keeps libvips' defaults unless there is a measured reason. Acceptable: 12 bits for a 16-bit image and 8 for any other, as libvips chooses, with a 16-bit source in the worst-case timing; or keep 8 and state the measured reason in the PR body and the code comment. Either way theTODO.mdsentence should say what was decided and why, not that the govips constraint forces 8.internal/imageprocessor/encoder_settings_internal_test.go:109: the 64x48 test image comes out the same size at effort 2 as at effort 1, soTestImageProcessor_AVIFAtEffort1cannot tell them apart, and 2 is the effort the PR rejects as too slow fordownstream_timeout. Acceptable: a source, still small enough to keep the test fast, on which efforts 1 and 2 give different sizes.Judgement calls accepted:
Not verified: the 8192x8192 timings in the PR body.
Model: opus-5-5
9ae1afa02etof6a39f2e14f6a39f2e14tob9c618e551b9c618e551tobde983d483View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.