## Summary `OpenAiBasedProviderClientBase::textToImage()` calls `base64_decode()` a second time on data it has already decoded, so the `ImageFile` it returns holds corrupt bytes instead of the generated image. The failure is silent: the mime-type guard immediately above inspects the *correct* bytes and passes, and the corrupt bytes are handed out afterwards, so callers get a successful response and write unusable files. The same line also throws away the mime type it just validated in favour of a hardcoded `image/png`. This is a regression. Before commit bc860ac9 ("Let providers select allowed text-to-speech and text-to-image file formats", 2026-06-23, also on `1.2.x`/`1.3.x`/`1.4.x` as a cherry-pick of 57dd477f) the line read `new ImageFile(base64_decode($data['b64_json']), 'image/png', 'generated.png')` — a single, correct decode. That commit introduced the `$image_content` variable and the mime detection but left the now-redundant `base64_decode()` call in the constructor argument. `ai_provider_openai` is unaffected, because `OpenAiProvider::textToImage()` overrides the base method and already does the right thing — which is also the shape of the fix proposed below. Every provider that inherits the base implementation is affected; `ai_provider_litellm` (1.2.x, 1.3.x) extends `OpenAiBasedProviderClientBase` directly and advertises `text_to_image`, so image generation through LiteLLM is broken. ## Steps to reproduce Against a provider (no override of the base method — e.g. LiteLLM): 1. Install `drupal/ai` 1.4.4 or later (or any 1.5.x / 2.x) plus a provider that inherits `OpenAiBasedProviderClientBase::textToImage()`, such as `drupal/ai_provider_litellm`, and set it as the Text-to-Image provider. 2. Generate an image — via *AI API Explorer → Text to Image*, or `$provider->textToImage(new TextToImageInput('a red bicycle'), $model_id)`. 3. Write the result to disk: `file_put_contents('/tmp/out.png', $output->getNormalized()[0]->getBinary());` 4. Inspect the file: `file /tmp/out.png` and `xxd -l 8 /tmp/out.png`. 5. Repeat with a completely different prompt and compare the first bytes of the two files. Provider-free reproduction of the same decode path (no API key or provider needed — this is the exact transformation the line performs on the API's `b64_json` value): ```php $png = file_get_contents('core/misc/druplicon.png'); $b64 = base64_encode($png); // what the API returns in b64_json $once = base64_decode($b64, TRUE); // what $image_content holds — correct $twice = base64_decode($once); // what is handed to ImageFile printf("correct: %d bytes, header %s\n", strlen($once), bin2hex(substr($once, 0, 8))); printf("shipped: %d bytes, header %s, finfo %s\n", strlen($twice), bin2hex(substr($twice, 0, 4)), (new finfo(FILEINFO_MIME_TYPE))->buffer($twice)); ``` ## Expected result `ImageFile::getBinary()` returns the image bytes as the API sent them: a valid PNG starting with the magic `89504e470d0a1a0a`, which viewers open and `file` reports as `PNG image data`. `ImageFile::getMimeType()` returns the mime type that `detectMimeType()` validated. ## Actual result `getBinary()` returns unusable data. `file` reports `data`, viewers reject it, and the first bytes are `3cd1881c…` instead of the PNG magic. The response itself reports success — no exception, no log entry. The clearest tell: **the corrupt prefix is identical for every image.** PNG magic is constant, so its base64 form is constant, so decoding it a second time always produces the same leading bytes. Two different generated images from the site this was found on, and the standalone snippet above run over two different PNGs, all start `3cd1881c`, with `finfo` reporting `application/octet-stream`. Byte counts differ (the second decode keeps roughly a quarter of the input), so the payload is not merely mislabelled — most of it is gone. Measured on a real generation before and after the one-line fix: 21,830 bytes / header `3cd1881c…` / not an image → 117,163 bytes / header `89504e470d0a1a0a` / valid 1024×1024 PNG that renders correctly. ## Proposed resolution Pass the already-decoded bytes and the validated mime type through, the way `OpenAiProvider::textToImage()` already does: ```php $file_ext = static::ALLOWED_IMAGE_MIME_TYPES[$mime_type]; $images[] = new ImageFile($image_content, $mime_type, 'generated.' . $file_ext); ``` Using `$mime_type` and its extension rather than the hardcoded `image/png` / `generated.png` also fixes the second half of the problem: `ALLOWED_IMAGE_MIME_TYPES` permits `image/jpeg` and `image/webp`, and today a JPEG or WebP response is labelled and named as a PNG. There is no test coverage for this path — `TextToImageInterfaceTest` exercises the `echoai` mock provider, and `OpenAiBasedProviderClientBaseTest` covers only exception handling and the fiber branch. A unit test asserting that `textToImage()` returns the input bytes unchanged (and the detected mime type) for a base64-encoded fixture image would have caught this and would prevent it coming back. ## Environment - Drupal version: 11.4.6 - Module version: 1.4.8 (line also present on `1.x` HEAD `337cbff3`, `1.5.0-rc3`, `2.x`, `2.0.x`, `1.3.x`, `1.2.x`; first affected releases are 1.4.4 and 1.3.10) - PHP version: 8.4 - Provider: LiteLLM (`drupal/ai_provider_litellm` 1.3.1) - Last known working version: 1.4.3 / 1.3.9 — the double decode arrived with bc860ac9 (2026-06-23) ### Error messages or logs None. That is the point of the report: the tool call succeeds, nothing is logged, and the corruption is only visible in the written file. --- AI Assisted Issue: this issue was generated with AI assistance, but was reviewed and refined by the creator.