Direct answer
Before making an image opaque, identify the input contract and decoded representation. PNG stores unassociated color plus alpha; Android Bitmap storage may be premultiplied. Bitmap.getPixel and getPixels are non-premultiplied ARGB views in sRGB, not wide-gamut raw-pixel evidence. copyPixelsToBuffer copies stored bytes packed by Bitmap.Config; it does not attach the bitmap's color-space metadata. Record Config, width, height, rowBytes, getColorSpace, and isPremultiplied beside the buffer. Config.HARDWARE does not support getPixel, getPixels, or copyPixelsToBuffer; detect it first and use a controlled software copy only if that path is supported, otherwise mark raw inspection unavailable. If the documented inference input accepts alpha, preserve that channel and verify the exact handoff instead of flattening it unnecessarily. If the consumer requires opaque input, choose both a matte and target color space before composing. Do not assume transparent pixels should become black or white: fully transparent PNG pixels may contain invisible RGB that appears after alpha is discarded. Color-space metadata is separate from pixel conversion. Android Bitmap.setColorSpace changes how values are interpreted without changing their pixels. Use a documented transform such as ColorSpace.Connector when a known source must move to a required target; record both spaces and the implementation. Do not infer that all inputs are sRGB or that a model supports wide-gamut or HDR data. Declare the alpha-compositing transfer function as well as the target space. The PNG specification says compositing should use intensity samples, not gamma-encoded samples. For colorimetric linear-light compositing, convert to a linear working space, composite with the matte, then encode. Verify a platform drawing path; do not assume Canvas is linear-light. JPEG represents opaque pixels and cannot preserve alpha. When needed, composite in the declared target space onto a named matte before encoding, then decode and compare against a predeclared loss tolerance. Test each stage separately so changed input is traceable. This method makes no accuracy or Cove-defect claim.
A transparent diagram changes after export
An Android developer receives a transparent PNG diagram with translucent labels and sends it through a vision pipeline. The preview looks correct, but a JPEG copy shows dark edges and the downstream result differs. The target model contract and the exact Android bitmap representation have not yet been recorded.
Decision
Trace the decoded alpha and color-space state, identify whether the consumer accepts alpha, and create an explicit opaque target only when required. Test matte selection, value conversion, and lossy encoding as separate transformations.
Expected outcome
The team can reproduce the exact pixels handed to the inference boundary and explain which conversion was applied. The result is limited to the fixture, Android path, encoder, and documented target input contract.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Synthetic alpha and color fixtures
- Source and target pixel representations
- Encoder round-trip tolerance and input contract
Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.
Implementation workflow
- Pin the input and consumer contract. Record source format, dimensions, PNG color and alpha metadata, Android version, decoder path, Bitmap.Config, getColorSpace, hasAlpha, isPremultiplied, and the documented model input format. Do not infer the consumer contract from an extension or a successful preview.
- Compare decoded and exposed pixel values. Use tiny opaque, transparent, partial-alpha, and hidden-RGB fixtures. getPixel/getPixels return non-premultiplied sRGB; copyPixelsToBuffer returns packed stored bytes without color-space metadata. Record Config, rowBytes, dimensions, ColorSpace, and premultiplication separately; detect Config.HARDWARE before CPU reads and inspect only a controlled software copy.
- Choose whether alpha is preserved or composited. If the documented input accepts alpha, preserve and test that path. If the consumer requires opacity, choose a named matte and target color space before composition. Never let an encoder or default background silently decide the result.
- Convert and composite in the target space. Record source/target ColorSpace and transfer function. If colorimetric linear-light compositing is required, transform to a linear working space, composite with the matte, then encode the target. A Canvas path is acceptable only after this format-specific behavior is verified.
- Validate encoding and decoded output. If JPEG is required, flatten alpha first against the chosen matte, encode, decode, and compare to the pre-encode target. Define channel or perceptual tolerances for the lossy round trip; byte equality is not a valid expectation for JPEG.
- Keep a transformation-specific regression set. Test transparent edges, hidden RGB, half-alpha pixels, saturated colors, source and target color spaces, and JPEG round trips. Record each transform in order, preserve the original fixture, and do not attribute a changed model answer to alpha or color conversion without matching input evidence.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- The record names source/target ColorSpace, transfer function, alpha/premultiplication state, Config and row layout, pixel-access path, hardware/software access mode, and documented input contract; unknown format support remains unknown.
- An opaque path records its compositing domain and matte, converts pixel values when required, and composites before alpha is discarded or JPEG is encoded; alpha-preserving paths are tested separately when supported.
- The implementation does not treat Bitmap.setColorSpace as a value conversion, getPixel/getPixels as raw wide-gamut data, or a raw byte buffer as self-describing; HARDWARE access is checked before unsupported reads.
- JPEG round-trip assertions use a predeclared lossy tolerance, while transformation stages are tested separately and no inference accuracy or Cove defect is claimed.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Preserve alpha | Pass the alpha-bearing representation only when the documented consumer accepts it | Avoids flattening, but does not prove every model or runtime supports alpha input. |
| Composite to opaque | Record the target color space, then blend against an explicit matte before encoding | Produces deterministic opaque pixels; both target space and background can affect downstream interpretation. |
| Retag color space | Change Bitmap color-space metadata only when values already match that space | Bitmap.setColorSpace changes interpretation, not the underlying pixel values. |
| Convert then JPEG encode | Transform pixels, composite alpha, encode, decode, and compare | JPEG drops alpha and is lossy; define target format and tolerance before evaluating inference. |
Failure patterns to prevent
- Treating color-space retagging as conversion
- Dropping alpha without an explicit matte
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
Release checklist
- ☐ The primary query is answered without an unsupported number.
- ☐ Every artifact and runtime is pinned.
- ☐ The representative task and failure policy are explicit.
- ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
- ☐ User-content and network boundaries are documented.
- ☐ Result wording applies only to the recorded configuration.
- ☐ The page links to raw method or evidence when results are added.
Sources and related evidence
- Android Bitmap API: alpha, pixel access, color-space metadata, and JPEG compression
- Android ColorSpace API: explicit color-space connectors and transforms
- Android Canvas API: bitmap drawing and compositing operations
- W3C Portable Network Graphics specification: alpha channel representation
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
What does a raw Bitmap pixel buffer tell me?
copyPixelsToBuffer returns bytes packed by Bitmap.Config and stored as-is; the buffer does not carry color-space or row-layout metadata. Record Config, rowBytes, dimensions, ColorSpace, and isPremultiplied separately. getPixel/getPixels instead return non-premultiplied sRGB ARGB values.
Does Bitmap.setColorSpace convert the pixel values?
No. Android documents it as changing the color-space interpretation without changing the underlying allocation. Use a real color-value transform when the input contract requires conversion, then verify the resulting pixels.
Can JPEG keep the transparent background?
No. Android documents that JPEG supports opaque pixels only. Choose and apply a matte before encoding, then test the decoded JPEG because compression is lossy.
Should alpha be blended directly in encoded sRGB values?
Not for colorimetric linear-light compositing. The PNG specification says to composite intensity samples rather than gamma-encoded values. Choose and record the transfer function and implementation, then verify tiny fixtures; do not assume every Canvas path uses linear-light blending.
Can I read pixels directly from a Config.HARDWARE bitmap?
Android documents that getPixel, getPixels, and copyPixelsToBuffer throw for hardware-configured bitmaps. Detect this state first; use a controlled software copy only if that copy path is supported, or report raw inspection unavailable.
Can this establish that Cove accepts wide-gamut or alpha input?
No. It is a preparation and validation method. Check the exact model or API contract and the app's actual conversion path; a PNG decoder or Bitmap capability does not establish inference support.