Skip to content

Releases: godicom-dev/golibjpeg

v1.3.0

Choose a tag to compare

@github-actions github-actions released this 24 Aug 10:54
28fa34d

Platform matrix

Every desktop platform is now covered, up from four:

OS amd64 arm64
Linux
macOS new
Windows new

darwin/amd64 is cross-compiled on the arm64 runner and tested through Rosetta 2;
windows/arm64 is cross-compiled with MSVC's ARM64 toolchain and tested on a real
windows-11-arm runner, so purego's Windows ARM64 path is exercised for real
rather than only cross-built.

Importing this module is now safe everywhere

Loading the native library used to happen in init(), so on a platform with no
prebuilt library the process died at startup — before main ran, with no way for
the caller to handle it. The library now loads lazily on first use, and every
entry point returns an error wrapping ErrUnsupportedPlatform instead:

img, err := golibjpeg.DecodeImage(data, golibjpeg.ColourTransformNone)
if errors.Is(err, golibjpeg.ErrUnsupportedPlatform) {
	// no library for this GOOS/GOARCH; err names which one
}

A 32-bit target, js/wasm, a BSD — the module still compiles and importing it
stays safe. Only the compressed transfer syntaxes fail. A read-only or noexec
TMPDIR now surfaces the same way, as an error from the first call.

The cross-build CI job compiles for windows/386, linux/386, linux/arm,
linux/riscv64, linux/ppc64le, js/wasm and wasip1/wasm so this keeps
holding.

One embedded library per binary

The six libraries total about 10 MB, but a binary only ever carries the one it can
load — every //go:embed sits behind a per-platform build tag. The new checks
CI job asserts that set for each platform with go list -f '{{.EmbedFiles}}',
because one careless libs/* glob or one forgotten build tag would put all six
into every binary and nothing else would notice. go get still downloads all six
(they are one module), but that is paid once in the module cache, not per build
and not per user binary.

The orphaned golibjpeg_386.dll — left behind when 386 support was dropped, no
longer embedded by anything — is deleted.

Behaviour change

StatusError.Error() no longer doubles the parentheses after the operation name.
It read

libjpeg error code '-1038' returned from Decode()(): ...

and now reads returned from Decode(): , matching the RuntimeError messages
pylibjpeg-libjpeg raises from the same code paths. Code matching on the exact
error string needs updating; errors.As(err, &*StatusError{}) and the Code,
Op and Detail fields are unaffected.

Also

  • go vet ./... is clean and now gated in CI. go test runs only a subset of vet
    checks, and unsafeptr is not among them, which is how two real findings sat
    under a green CI. The fix deletes the hand-rolled char* conversion entirely:
    purego binds a C char* return to a Go string itself, NULL included.
  • The error-detail path had no test coverage at all, which is what let the above
    go unnoticed. It has one now.

v1.2.1

Choose a tag to compare

@xbmlz xbmlz released this 07 Aug 03:16

Fix prebuilt Linux/Windows native libraries missing golibjpeg_encode (v1.2.0 regression).

v1.2.0

Choose a tag to compare

@xbmlz xbmlz released this 07 Aug 02:58
9dde23c

What's new

  • Encode API: Encode, EncodePixelData, EncodeOptions, and FrameType for JPEG baseline, JPEG lossless, and JPEG-LS (including near-lossless via ErrorBound).
  • Native golibjpeg_encode C ABI; CI-built prebuilt libraries for all supported platforms.

Notes

  • JPEG XT remains decode-only; HDR/residual encode is not included.
  • Pixel layout matches decode: little-endian, color-by-pixel, planar-interleaved.

v1.1.2

Choose a tag to compare

@github-actions github-actions released this 02 Jul 16:06
chore: go 1.26 minimum