Skip to content
Notifications
Clear all

Anyone else having issues with hands and text after the latest API change?

3 Posts
3 Users
0 Reactions
1 Views
(@crm_hopper_alt)
Estimable Member
Joined: 2 months ago
Posts: 100
Topic starter   [#17831]

Alright, let's cut to the chase. We all know DALL-E 3 has the structural integrity of a Jenga tower when it comes to rendering hands and text. But something feels *different* since the last API tweak a couple weeks back. It's not just the usual "seven-fingered maestro" problem anymore.

My team's workflow for generating placeholder graphics for internal sales decks is now hitting a wall. We've got a standard prompt structure we've used for months:

* **Before:** `"A businessperson in a modern office, holding a tablet showing a graph going upwards, text on the graph reads 'Q4 Growth'"`
* **Result (then):** Mostly passable. Graph text might be gibberish, but the hands were *usually* attached correctly.
* **Result (now):** The hands are now more likely to be abstract flesh mittens merging with the tablet bezel, and the graph text is actively *avoided*β€”like it's now penalized more heavily. We're seeing more "a graph with upward trending lines" but zero attempt at the requested text.

It feels like they've cranked up some "safety" or "naturalism" weight to avoid text generation, and it's having a knock-on effect on composition, especially for objects held in hands. Anyone else seeing this, or are we just hitting a weird prompt edge case?

Tried the usual dance:
- Explicitly stating "perfectly rendered hands"
- Using "sign that says 'Q4 Growth'"
- Different style modifiers (photo, illustration, vector)

The outputs are "cleaner" in a corporate stock art way, but they're also missing the specific, functional details we prompt for. Classic case of "fixing" one problem (garbled text) and breaking three other things. 🫠


been there, migrated that


   
Quote
(@isabellaw)
Eminent Member
Joined: 4 days ago
Posts: 21
 

You're describing exactly what I've been tracking in my logs. I was trying to generate some simple infographic elements, and I noticed the same shift. It's not just a random fail, it feels like a systematic change in priority.

My testing last week showed that even hinting at "text on a screen" now makes the model overly cautious about the entire hand-object interaction. It seems to treat them as a single, problematic unit. I got better results by splitting the concept into two separate prompts, like "a hand holding a blank tablet" and then "a simple line graph overlay for a tablet screen," but that kills the workflow efficiency.

Have you tried any specific prompt tweaks that seem to push back against this new weighting, or is it just a universal drop in quality?



   
ReplyQuote
(@amandaf)
Estimable Member
Joined: 7 days ago
Posts: 73
 

You're not imagining it. I've seen a lot more flagged content in the moderation queue specifically around "text on objects" since that API update, especially with screens. The system seems to be interpreting any text request as a potential ToS violation attempt, which breaks the entire object interaction.

Your workaround of splitting the prompt is the current band-aid, but it shouldn't be necessary for something as basic as graph labels. Have you submitted a bug report through official channels? Without that paper trail, they'll assume it's just the usual hand/text noise.


β€”AF


   
ReplyQuote