Image Generation Feedback: Failed Attempts and Better Safe Fallbacks

I would like to provide feedback on ChatGPT’s image-generation and editing experience, particularly how failed generations, safety restrictions, and limited image attempts interact.

The main issue is not that restrictions exist. It is that when a generation fails, users are often given too little information to understand why, while the failed attempt may still count against a limited allowance.

For iterative editing, this can feel like playing Guess Who while blindfolded. The user may not know whether the problem came from the source image, the wording of the edit, the generator’s interpretation, or a post-generation safety check. Each attempt becomes another guess with a cost attached.

There is also a disconnect between user intent and generated output. Even when a requested edit is subtle, the generator can sometimes take excessive creative freedom and produce something more extreme than requested. That output may then be rejected by a later safety system, even though the user never asked for the problematic result.

This concern is especially relevant because OpenAI’s own image-editor documentation notes that selections are not always precise and edits may extend beyond the area selected. If the system itself can modify more than the user intended, it becomes even more important for the generator to evaluate and refine its own result before a downstream safety check rejects an output the user did not actually request.

Ideally, the generator should check its output against both the user’s instructions and the applicable safety limits before presenting it. If the image overshoots the request, it should refine the result back toward the intended edit rather than allowing the generation to fail at a later stage.

The system should also aim to produce the closest acceptable result instead of broadly rejecting an entire request when one element creates a problem. If part of an edit cannot be completed, the system should modify or omit that portion and complete the rest whenever possible.

This problem becomes even more significant in professional use. For a hobbyist, repeated failures waste limited generations, time, and subscription value. For someone using ChatGPT to produce marketing material, concept art, presentation assets, storyboards, product imagery, or other work-related content, the same failure loop can become a direct operational cost. Time spent repeatedly rewriting prompts without knowing what caused the failure is time that cannot be reliably budgeted or recovered.

A professional creative tool does not necessarily need to succeed every time, but it should fail predictably and recoverably. A message such as “this portion cannot be generated, so it was adjusted in this way” allows the user to continue working. Repeated rejection with little actionable guidance does not.

I have also encountered broad rejection of non-explicit, PG-13-level content involving anatomy, fitted or wet clothing, body contours, cinematic framing, or mild sensuality.

There is a significant creative space between sterile imagery and explicit sexual content. The system should be capable of handling that space more precisely.

At the same time, safeguards involving recognizable real people, impersonation, and non-consensual intimate imagery should remain strict. Identity and consent risk can be treated separately from the level of sensuality in an image, allowing more nuanced handling of fictional, original, or non-identifiable adult characters without weakening protections for real people.

The improvements I would most like to see are:

• Failed generations that return no usable image should not consume the same limited allowance as successful generations.

• Refusals should provide basic category-level guidance explaining whether the issue came from the source image, requested edit, generated result, or another safety limitation.

• The generator should automatically correct outputs that go further than the user requested.

• Safe portions of a request should still be completed whenever possible.

• Repeated failures should trigger guidance or an automatic safe fallback before more attempts are consumed.

• Non-explicit sensual content involving fictional or non-identifiable adult characters should be handled with greater precision, while strong identity and consent protections remain in place for real people.

Image safety does not need to disappear for the experience to improve. The system simply needs to fail more gracefully, provide enough information for users to recover, and actively guide requests toward the closest acceptable result.

A limited image attempt should ideally represent an image successfully delivered to the user, not the cost of discovering another invisible boundary.

この投稿にはかなり賛同できる。特にこちらの経験から補強できるのは、「失敗の原因がユーザーから観測できないのに、試行コストだけはユーザーが負担する」点だと思う。コメントなら、元投稿を繰り返さず、自分の実例を足すのがよい。

コメント案

I strongly agree with this, especially the point about failed attempts providing too little information while still consuming a limited generation allowance.

In my experience, there is another problem that makes this particularly difficult to troubleshoot: the user often cannot tell which layer actually caused the failure.

Was the request itself rejected?
Did the language model misunderstand the instruction?
Did the image generator produce something unintended?
Did the generator significantly alter the requested composition or body proportions?
Or was an otherwise completed output rejected by a downstream safety system?

From the user’s side, these can all look like the same thing: the requested image was not delivered.

This becomes especially costly when the generator itself introduces the problematic element. I have had cases where I requested something ordinary, the generator deviated from the request, and the resulting output then became the source of the problem. Rewriting the prompt does not necessarily solve this because the user does not know whether they are correcting their own instruction or trying to compensate for undocumented model behavior.

I therefore think a good fallback system needs diagnostic transparency, not just softer rejection.

At minimum, when a generation fails, it would be useful to distinguish between:

  • the request being incompatible with a safety requirement;
  • generation failing technically;
  • the generated result failing a post-generation check;
  • the system being unable to satisfy some requested constraint.

And I strongly agree that, where possible, the system should return the closest compliant result rather than simply consuming an attempt and returning nothing.

There is an important asymmetry here: the system has much more information than the user about what happened internally, but currently the user is often the one forced to diagnose the failure through repeated paid or limited attempts.

For iterative image work, that makes experimentation unnecessarily expensive and turns debugging into guesswork.

I would much rather receive:

“I could not preserve X because of Y, so I preserved A, B, and C and modified X.”

than receive no usable output and have to guess which part of the request caused the failure.

For professional or experimental workflows, recoverability and actionable failure information are almost as important as generation quality itself.