Random error 'IMAGE_OTHER' for gemini-2.5-flash-image-preview

Gemini API
, ,
1

Hey everyone,

I’m running into an intermittent issue with the gemini-2.5-flash-image-preview model and hoping someone can shed some light on it. The issue was not existent 2-3 weeks ago, and has been getting worse.
Example:
1: ”%photo% “generate 3d image avatar of main character in animated form”
2 ”main character, dressed in explorer’s attire, stepping into the shadowy forest”

The Problem

Sometimes (not always) I get this error when generating images:

finish_reason=<FinishReason.IMAGE_OTHER: ‘IMAGE_OTHER’>

No other error message, no prompt_feedback, just IMAGE_OTHER. The weird part is it’s completely random - same input that worked fine 5 minutes ago suddenly fails.

What I’m doing

I’m building an app that creates cartoon-style avatars from photos and uses them in illustrated stories. Nothing inappropriate - just family-friendly content with non-realistic art styles.

Input is typically:

- A regular photo (~1290 image tokens)

- Text prompt for the style (~64 text tokens)

What I’ve tried

- The token counts look normal

- Same inputs work sometimes, fail other times

- No pattern I can identify

Questions

1. What does IMAGE_OTHER actually mean? The docs just say “other image-related reasons” which isn’t super helpful for debugging.

2. Could this be a false positive on safety filters? The content is pretty tame.

3. Is there a recommended retry strategy for this?

4. Any way to get more diagnostic info about why a specific request failed?

Has anyone else run into this? Any ideas what might be causing the intermittent behavior?

Thanks!

2

Same here. But can not find any solution yet

3

I was considering whether it is the tokens building up, from using the same chat. But what is weird here is that I don’t see to be able to see a pattern.

I was considering rebuilding my flow, such that instead of reusing the same chat - for consistency - I would flush the chat and start over for each request. But since I need consistency, I would need to upload one image every time.

It feels suboptimal and will get quite complex. Do you guys think that would help?

4

Man.. this is Google’s safety filter, which for the past two or three days has been blocking prompts with face transfer or, as you write, 1:1. The aim is to eliminate deepfakes/restrict them. I also regret this.

5

Here are the filters. Once configured correctly, it will work as before. Safety and content filters  |  Generative AI on Vertex AI  |  Google Cloud

6

Model

I understand this is frustrating, especially with the intermittent nature of the issue. While I can’t directly access the backend logs for specific IMAGE_OTHER errors, I can offer some insights and potential strategies based on common causes and best practices.

First, let’s address your questions:

  1. What does IMAGE_OTHER actually mean?
    You’re right, “other image-related reasons” isn’t very helpful. In general API contexts, “OTHER” often indicates a catch-all for errors that don’t fit into more specific categories. This could include a wide range of issues such as:

  • Transient infrastructure issues: A momentary glitch on the server side, network issues, or resource contention. This is often the case with intermittent errors.

  • Internal processing failures: An unexpected error during the image generation pipeline itself, which could be related to memory, computation limits, or an unhandled exception in the model’s internal logic.

  • Subtle input variations: Even if your explicit token counts are normal, there might be very subtle aspects of the input image or prompt (e.g., specific pixel arrangements, complex object relationships) that trigger an edge case in the model’s processing on some attempts but not others.

  • Race conditions or load-related issues: If the model is under heavy load, it might fail to process certain requests due to timeouts or resource limitations that aren’t always present.

  1. Could this be a false positive on safety filters? The content is pretty tame.
    It’s certainly possible for safety filters to produce false positives, especially with image models. While you describe your content as family-friendly, image filters can sometimes be very sensitive and might flag patterns, shapes, or combinations of elements that, to a human, are innocuous. The intermittency makes this less likely to be the sole cause (as a clear safety violation would likely fail consistently), but it could be a contributing factor if certain visual elements in your photos or generated scene sometimes cross a threshold. The lack of prompt_feedback specifically mentioning safety is a good sign that it’s not a direct, explicit safety filter rejection, but IMAGE_OTHER could still encompass internal safety mechanisms that don’t always provide specific feedback.

  2. Is there a recommended retry strategy for this?
    Yes, for intermittent errors like IMAGE_OTHER, a retry with exponential backoff is generally the recommended strategy.

  • Exponential backoff: This means you wait for a short period (e.g., 1 second), then if it fails again, wait for a longer period (e.g., 2 seconds), then 4 seconds, 8 seconds, and so on, up to a maximum number of retries or a maximum wait time. This prevents you from hammering the API if there’s a sustained issue and gives the backend time to recover.

  • Jitter: Add a small amount of random delay (jitter) to your backoff times. This helps prevent all your retries from hitting the server at the exact same moment if many clients are retrying simultaneously.

  • Maximum retries: Set a reasonable limit (e.g., 3-5 retries). If it consistently fails after multiple retries with backoff, it’s likely a more persistent issue that retrying won’t solve.

Example Retry Logic (conceptual Python):

codePython

import time
import random

def call_gemini_image_generation(photo_data, text_prompt):
    # Your actual API call here
    # For demonstration:
    if random.random() < 0.3: # Simulate intermittent failure 30% of the time
        raise Exception("IMAGE_OTHER simulated error")
    return "Image generated successfully!"

def generate_image_with_retry(photo_data, text_prompt, max_retries=5, initial_delay=1):
    for i in range(max_retries):
        try:
            result = call_gemini_image_generation(photo_data, text_prompt)
            print(f"Attempt {i+1}: Success!")
            return result
        except Exception as e:
            if "IMAGE_OTHER" in str(e): # Check for the specific error
                print(f"Attempt {i+1}: Failed with IMAGE_OTHER. Retrying...")
                delay = initial_delay * (2 ** i) + random.uniform(0, 0.5) # Exponential backoff with jitter
                time.sleep(delay)
            else:
                print(f"Attempt {i+1}: Failed with unexpected error: {e}")
                raise # Re-raise other errors immediately
    print("Max retries reached. Image generation failed.")
    return None

# Example usage
# generate_image_with_retry(my_photo_data, "generate 3d image avatar of main character in animated form")
  1. Any way to get more diagnostic info about why a specific request failed?
    Unfortunately, for IMAGE_OTHER, direct detailed diagnostic info is rarely exposed to the end-user API caller. This is a common pattern for large-scale API services, as exposing internal error codes or logs could reveal implementation details or be too voluminous for practical consumption.

5.However, you can try these approaches to infer more about the failures:*

  • Correlation with specific inputs: Keep detailed logs of exactly what photo and text prompt led to a failure. Over time, even without explicit error messages, you might spot patterns. For example, “It always fails when the photo has a busy background,” or “It often fails when I ask for a specific, complex object.”

  • Simplify inputs: When you get a failure, try simplifying the text prompt or even using a simpler base image (if applicable) to see if that resolves the issue. This can help isolate whether the complexity of the input is a factor.

  • Incremental changes: If you have an input that consistently fails, try making very small, incremental changes to it and test each change. This can be tedious but might reveal a sensitive spot.

  • Monitor your usage metrics: If the API provides any usage dashboards or health metrics, monitor them during periods of failure. This might show if there are spikes in errors across the board, indicating a broader service issue, versus isolated failures specific to your requests.

  • Report to Google Cloud Support: If this becomes a consistent and high-impact problem, especially if it’s new behavior, filing a detailed bug report or support ticket with Google Cloud Support is your best bet. Provide them with:

    • Exact timestamps of failed requests.

    • The full input (image data and text prompt) for failed requests.

    • The specific error message (IMAGE_OTHER).

    • Your project ID.

    • Any observations about when it started or what conditions seem to precede failures.

Other Potential Considerations:

  • API Version: Are you locked to a specific API version, or are you using a latest tag that might be getting updated with new model versions that have different characteristics? If possible, try explicitly using a version you know worked well.

  • Rate Limits: While not usually producing IMAGE_OTHER, ensure you’re not inadvertently hitting any unspoken rate limits, especially if your app scales up.

  • Input Image Characteristics: While 1290 tokens is within limits, consider if specific image properties (e.g., very high resolution, unusual aspect ratios, specific file formats) might sometimes cause issues. If you’re doing any preprocessing (resizing, re-encoding), ensure it’s consistent.

Given that it’s flash-image-preview, it’s still a preview model, meaning it’s under active development and may have more instability or changes in behavior than stable releases.

For now, implementing a robust retry strategy with exponential backoff is your most effective immediate mitigation.

Apakah ada pertanyaan lain

7

Hey, I think the same. I am testing with directly inappropriate prompt and I get IMAGE_SAFETY everytime which is intended. When I test with slightly inappropriate prompt which might fall into a bit of a gray area I get IMAGE_OTHER.

I started to test this because I have nano banana image editing tool in my ios app and I saw on my logs that people started to get IMAGE_OTHER errors more oftenly and got refunded.

On directly inappropriate prompts I don’t refund their used tokens since it’s users fault. I don’t know if I should refund for IMAGE_OTHER since it’s very unclear. Google should make it more clear I think.

9

Hi, this is a good response. But how should I view this issue?

As it is a preview model, should I consider that this will most likely be fixed? Or should I find a better solution and just move on?

My generation is based on visual-descriptions that fits a family-friendly story book, but if it randomly fails, its hard to put into production as I don’t really know what to expect here. The texts will be different, and slight manipulation to change a word to something else is not something I can reliably reproduce.

In particular; some days it seems to work. Some days no request goes through. And I am using the same testing input while developing. There is a very large degree of random variation here.

11

In my case I was receiving IMAGE_OTHER because my payload was with:
“mime_type”: “image/png”
and I was sending a .jpg.
:melting_face:

13

am facing same error. any solution?

15

Same issue here - is it definitely the safety filters or could it just be an unknown internal error?

16

Same here. It’s pretty random. Locally it’s always working but on staging or prod, we see that error 20% of the time using same input and prompt.

Tried with safety filters, random retry timing (between 1 to 4s) but didn’t succeed.

Any ideas?