Found in the hands-on acceptance test of next (092176d), #356. A decision for sneak.
What it is
JPEG has no transparency. When pixa (https://git.eeqj.de/sneak/pixa) converts an image with transparent areas to JPEG, those areas come out black. The README does not say so. Nothing in the code chooses black: it is libvips' default when it saves an image with transparency as JPEG.
It happens in two cases:
a URL that asks for .jpeg;
a URL that asks for auto, when the browser accepts none of JPEG XL, AVIF and WebP.
Example: a logo, a red circle on a transparent 100x100 PNG at https://cdn.example.com/logo.png, requested as /v1/image/cdn.example.com/logo.png/100x100.jpeg, comes back as a red circle on a black square.
Options
White: transparent areas become white in JPEG output, and the README says so. A small change in internal/imageprocessor with a test.
Black, documented: keep today's behaviour, and add a README line. No code change.
Recommendation
White. Most image tools flatten onto white, and a logo on a black square looks broken on a white page.
Should this be built?
Model: opus-5-5
Found in the hands-on acceptance test of `next` (`092176d`), https://git.eeqj.de/sneak/pixa/issues/356. A decision for sneak.
## What it is
JPEG has no transparency. When pixa (https://git.eeqj.de/sneak/pixa) converts an image with transparent areas to JPEG, those areas come out black. The README does not say so. Nothing in the code chooses black: it is libvips' default when it saves an image with transparency as JPEG.
It happens in two cases:
- a URL that asks for `.jpeg`;
- a URL that asks for `auto`, when the browser accepts none of JPEG XL, AVIF and WebP.
Example: a logo, a red circle on a transparent 100x100 PNG at `https://cdn.example.com/logo.png`, requested as `/v1/image/cdn.example.com/logo.png/100x100.jpeg`, comes back as a red circle on a black square.
## Options
- **White**: transparent areas become white in JPEG output, and the README says so. A small change in `internal/imageprocessor` with a test.
- **Black, documented**: keep today's behaviour, and add a README line. No code change.
## Recommendation
**White**. Most image tools flatten onto white, and a logo on a black square looks broken on a white page.
Should this be built?
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.
Found in the hands-on acceptance test of
next(092176d), #356. A decision for sneak.What it is
JPEG has no transparency. When pixa (https://git.eeqj.de/sneak/pixa) converts an image with transparent areas to JPEG, those areas come out black. The README does not say so. Nothing in the code chooses black: it is libvips' default when it saves an image with transparency as JPEG.
It happens in two cases:
.jpeg;auto, when the browser accepts none of JPEG XL, AVIF and WebP.Example: a logo, a red circle on a transparent 100x100 PNG at
https://cdn.example.com/logo.png, requested as/v1/image/cdn.example.com/logo.png/100x100.jpeg, comes back as a red circle on a black square.Options
internal/imageprocessorwith a test.Recommendation
White. Most image tools flatten onto white, and a logo on a black square looks broken on a white page.
Should this be built?
Model: opus-5-5