[compat] Drop ImageMagick_jll pin, require ImageMagick 1.4#85
Merged
Conversation
The `ImageMagick_jll = "= 6.9.10"` pin was added in 2024 as a workaround for JuliaIO/ImageMagick.jl#206 (PNG/TIFF decoding broke on 6.9.12). The upstream issue was closed 2024-10-12 and ImageMagick.jl v1.4+ moved to ImageMagick_jll 7.x. The lingering pin was also actively harmful on Apple Silicon: 6.9.10-12+3 ships no aarch64-apple-darwin artifact, so the platform selector returns nothing, no wrapper is included, `libwand` stays undefined, and ImageMagick.__init__() crashes with `UndefVarError: libwand` at libmagickwand.jl:27 before any test runs. The macOS-latest/aarch64 CI job has been red ever since the runner flipped to Apple Silicon. Resolution now picks ImageMagick v1.4.2 + ImageMagick_jll 7.x, which has aarch64-darwin binaries. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After dropping the `= 6.9.10` pin, ImageMagick_jll 7.x decodes PNGs with
asymmetric default colorspace handling: for some (bit_depth, color_type)
combinations it returns raw gAMA-unencoded samples, for others (notably
8-bit Gray and GrayA) it applies the file gAMA via libpng. PNG is lossless,
so both behaviors are valid interpretations — they just disagree about
whether to emit display-encoded or linear-light values.
Concretely:
- 8-bit Gray / GrayA / 16-bit GrayA → IM applies gAMA → matches PNGFiles
with gamma=nothing (libpng-applied transform)
- 16-bit Gray / RGB / RGBA / non-tRNS palette (any depth) → IM returns
raw samples → matches PNGFiles with gamma=1.0 (no transform)
Rather than encode this matrix in the test, compute imdiff against *both*
canonical decodes (raw and libpng-encoded) and take the min. Passing means
PNGFiles agrees with at least one canonical interpretation, which is the
only invariant the PNG spec actually requires.
Three orthogonal IM 7.x issues that this fix does not address — handled
explicitly so they don't masquerade as failures:
1. Palette+tRNS PNGs (tbbn3p08, tbgn3p08, tbwn3p08, tbyn3p08, tp1n3p08)
produce imdiff ~1.3 regardless of gamma policy — a distinct palette /
tRNS interpretation difference unrelated to colorspace. Marked
@test_broken pending separate investigation.
2. ImageMagick.jl does not recognize the new "LinearGRAY" colorspace
string that IM 7.x returns for tbwn0g16.png, throwing during load.
The IM call is now wrapped in try/catch and dependent testsets skip
gracefully when IM returns nothing.
3. Synthetic alpha-paletted tests (ARGB/ABGR/RGBA_paletted, including
_float) use random data, so the magnitude of the palette+tRNS drift
varies per run. @test_skip avoids "unexpected pass" errors from
@test_broken on benign random seeds.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This reverts commit 49876aa.
ImageMagick_jll 7.x adds default alpha-channel pre-association on read
that ImageMagick.jl exposes via its standard load path. Empirically this
introduces three categories of divergence vs PNGFiles, none of which are
PNGFiles decode bugs:
- Transparent palette entries (α=0) have RGB zeroed (PNGFiles preserves
the file's RGB bytes per spec).
- Low-α palette entries (α<8) get the same zeroing.
- Mid-α palette entries (8≤α≤~20) get non-monotonic alpha quantization.
These are internal IM 7.x policy choices, not PNG-spec behaviors, and
they cause the existing oracle comparisons (test_pngsuite, the synthetic
alpha-paletted cases in test_paletted_images) to fail under the new JLL.
Solution: add `_im_load_raw` in test/utils.jl that bypasses the
pre-association by calling `MagickSetImageAlphaChannel(wand, Undefined)`
between `readimage` and `MagickExportImagePixels`. This is a drop-in
replacement for `ImageMagick.load` and also avoids the
"Cannot parse colorspace LinearGRAY" path in ImageMagick.jl's metadata
parsing, which IM 7.x triggers for `tbwn0g16.png`.
For test_pngsuite.jl, also switch the imdiff comparison to take the min
across {PNGFiles raw decode, PNGFiles libpng-encoded decode}. PNG is
lossless and both representations are valid; this lets the test reflect
agreement under either canonical policy that IM happens to pick for the
file's bit-depth and color-type combination.
With these changes the suite is fully green on ImageMagick_jll 7.x —
no @test_skip, no @test_broken, no loosened tolerances. 1836 pass, 0
fail, 0 errored, 0 broken locally.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Member
|
Is the work around needed due to #48 still being broken? |
Member
Author
|
Yeah I think so, that sounds like the same issue. |
Member
Author
|
@nhz2 does the fix here make sense to you (just using ImageMagick to load raw)? |
Member
|
No I don't know anything about ImageMagick or why this isn't more straightforward. But is seems fine to merge since this is just for testing. |
Member
Author
|
Cool, I'll just merge then since it should be easily revertable for testing |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
ImageMagick_jll = "= 6.9.10"pin, requireImageMagick = "1.4"instead._im_load_rawhelper intest/utils.jl: rawMagickWandload that callsMagickSetImageAlphaChannel(wand, UndefinedAlphaChannel)beforeMagickExportImagePixels, bypassingImageMagick_jll 7.x's default alpha pre-association.test/test_pngsuite.jlcompares againstmin(imdiff(raw_decode), imdiff(libpng_encoded_decode))to handle IM 7.x's per-file gamma policy asymmetry.Why
The
= 6.9.10pin was a 2024 workaround for JuliaIO/ImageMagick.jl#206 (closed 2024-10-12). Its lasting cost:ImageMagick_jll 6.9.10-12+3ships noaarch64-apple-darwinartifact, sousing ImageMagickcrashes withUndefVarError: libwandon Apple Silicon —macOS-latest/aarch64CI has been red since the runner flipped.Removing the pin unblocks aarch64-darwin but exposes
ImageMagick_jll 7.xdecode-side policy changes (alpha thresholding/quantization for low-α palette entries; asymmetric gAMA application for some grayscale combinations) that diverge from PNGFiles' faithful spec decode. The helper bypasses these in test infrastructure rather than masking them. As a side effect it also avoidsImageMagick.jl's "Cannot parse colorspace LinearGRAY" error ontbwn0g16.png.Result
1836 pass, 0 fail, 0 error, 0 broken, 0 skipped on Linux x64 / Windows x64 / macOS aarch64. No tolerances loosened, no tests skipped or marked broken.
🤖 Generated with Claude Code
Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com