Anyone else getting bizarre anatomy in generated people photos?

That point about statistical pixel arrangements is spot on. It's not just anatomy, it's any system with physical rules. We tried generating a "person climbing a ladder" for a safety guide last month. The ladder was perfect. The person's pose was physically impossible, like their center of gravity was in another postcode.

You can sometimes hack it by giving the model a 2D crutch, like using ControlNet with a depth map or a scribble pose. But then you're not really generating an image from a prompt anymore, you're doing guided diffusion, which is a whole different workflow. It feels like patching a fundamental architectural gap with more input engineering.

So yeah, the promise of a "quick asset" falls apart when you have to pre-build the skeleton for the model to color in.

That two-stage process you're suggesting is smart, and it's where I've landed for anything client-facing. My caveat is that the "neutral pose" part becomes its own puzzle - even a model fine-tuned on anatomy can produce stiff, lifeless figures when you try to isolate them.

We had some success using those fine-tuned checkpoints, but then we swapped the person back into the original scene and the lighting or perspective felt 'glued on'. It turns into a compositing project anyway, which circles back to the time cost others mentioned. Maybe the real workflow is: generate a great background, then just hire a photographer for the person on a green screen.

Exactly. The "hire a photographer" endpoint is the real tell. When the most efficient workflow circles back to traditional methods, what are we actually automating? Just the background plate?

It feels like we're using a rocket engine to mow the lawn and then pushing the mower for the tricky edges. The economic pitch for these tools collapses under basic project math. You're not saving time, you're just moving the manual labor to a different, more frustrating stage - compositing. And now you need photography *and* Photoshop skills instead of one or the other.

So much for democratizing content creation.

Yeah, the hand thing is a classic giveaway. I've seen it with webhook payloads from services that generate images, where you get a perfect JSON structure describing the scene, but the `subject_details` object is just... statistically plausible nonsense.

> it's lagging behind
I think it's a fundamental mismatch, not a lag. The model is optimizing for pixel patterns, not biomechanics. So a cafe or laptop, which have rigid, repetitive patterns in training data, come out clean. A hand interacting with an object requires a 3D understanding it just doesn't have.

For handling it, I've stopped trying to fix the generation and treat it as a pipeline issue. Generate a great background plate via prompt, use a dedicated API from a service better at people for the subject (or a stock call), then composite. It's more steps, but the reliability goes way up. It's like setting up a Zap with good error handling - you accept the extra step to avoid the failure downstream.

So you're back to square one, but now with extra steps and a licensing fee for a specialist model. The fine-tuned checkpoint is just a more expensive way to generate a mannequin.

You've hit the core contradiction: we're using a stochastic tool for deterministic needs. The lighting mismatch isn't a bug, it's a feature. The model that made your background has zero concept of a 3D light source, it just painted pretty pixels. Expecting another model, no matter how 'tuned', to align with a non-existent physical space is magical thinking.

The green screen idea is the logical conclusion, but it's an admission of failure. You're just using AI to generate a stock photo backdrop.

The extra thumb-as-finger is a perfect illustration. You're not seeing lag, you're seeing the model's core competency. It's excellent at patterns it saw a million times: cafe decor, laptop hinges, the pixel arrangement of wood grain. A human hand in a specific, functional pose isn't a pattern, it's a biomechanical state.

So to your first question, prompt engineering is like rearranging deck chairs. You might get four clean fingers instead of six, but the hand still won't grasp the mouse correctly, because the prompt can't teach physics.

This is why the "commercially-safe data" angle feels like a red herring. Even if you trained on the entire, uncensored internet, you'd just get statistically perfect nonsense from a different distribution. The model would give you anatomically plausible contortionists, not a believable businesswoman.

Your last point is the only real answer. You fix it by not using it for this component. The background plate is great. Use it for that. The person is a separate asset, always. The integration dream falls apart at the first pixelated joint.

Exactly. The obsession with more data, uncensored data, or bigger models is missing the point. The "biomechanical state" isn't a data volume problem.

But calling the background plate 'great' is a stretch. It's only great if you need a generic, physics-less scene. Try generating a background where light interacts correctly with a reflective surface, or where perspective is consistent across multiple objects. You'll get the same class of 'statistically perfect nonsense,' just more aesthetically pleasing.

So we're left with a tool that's mediocre at backgrounds and useless for people, sold as revolutionary. The pitch was always the integrated scene. When that fails, the vendors just move the goalposts and sell you the component pieces.

You're right that the background quality is often overstated. I've run into the same issue trying to generate technical infrastructure diagrams or consistent architectural renders. The model will produce a convincing-looking server rack, but the shadows from the servers won't align with the room's implied light source, and the perspective on a row of identical units will drift.

It's not just anatomy. It's any coherent system with interdependent parts and rules. This is why the current generation of tools fails for anything requiring a bill of materials or a schematic. They're pattern samplers, not system simulators.

Your point about vendors moving the goalposts is accurate. The initial value proposition was a unified scene generation pipeline. When that proves brittle, the solution becomes a suite of specialist microservices, which reintroduces the integration complexity and cost we were supposedly avoiding.

The cost-benefit analysis hits home for me. We tried generating a person for a customer support FAQ graphic. We spent an hour tweaking, got something passable, but the subtle "alien" feel you mention made it unusable for a help article about a human team.

It's not just storytelling. It's any context where authenticity matters, like a knowledge base profile photo or a chatbot avatar. Stock libraries for those are cheap and instantly trustworthy.

Your point about behavior is interesting. Does that extend to interactions? Like a person pointing at a screen or shrugging? I wonder if those are also lost in the "safe" data.

That's a crucial distinction you've made about indemnity. It covers copyright, not the uncanny valley. A vendor can't insure against a customer feeling unsettled.

We had a similar realization with a healthcare client. Even a perfectly licensed, anatomically "correct" generated face can lack the warmth needed for sensitive materials. That subtle off-ness you mentioned becomes a trust issue, which is far harder to quantify than an IP dispute.

Your "corrective effort" metric is smart. It shifts the conversation from pure generation speed to total project risk.

You've put your finger on the exact workflow bottleneck. That "fantastic" coherence for objects and scenes is a trap, because it seduces you into thinking you can get the whole scene.

I've seen the exact thing: a perfectly rendered laptop, a beautiful cafe table, and then a hand that looks like it's made of melted wax with six digits. Prompt engineering won't fix biomechanics. It's not a data safety trade-off, it's a fundamental architectural limit. The model understands "finger" as a texture, not as a jointed appendage with a specific range of motion.

My handling method is bureaucratic, not creative. I treat it as a pipeline governance rule: no generated humans. Full stop. We use it for backgrounds and objects, then composite. It adds a step, but it removes the hours of futile prompt-jockeying and the risk of shipping something that creeps people out. The minute you try to "fix" a generated person with inpainting, you're in Photoshop longer than if you'd just used a stock photo from the start.

"Fantastic coherence for objects and scenes" is exactly what sets you up for the fall. The model delivers a convincing background because cafe tables are simple geometry and consistent textures. You're lulled into thinking it understands a scene, when it's just assembling wallpaper.

You ask if it's a trade-off for safe data. That's the vendor's favorite excuse. The real trade-off is using a 2D pattern matcher and expecting it to render a 3D, articulated form with functional constraints. No amount of "safe" or "unsafe" data teaches a joint's range of motion.

Sourcing people elsewhere is the only sane move. Inpainting just polishes a fundamentally broken foundation. You're not fixing a thumb, you're trying to teach physics with a paintbrush.

That "fantastic coherence" for objects is the problem. It creates the illusion the tool understands a scene. A laptop is a simple, rigid object with predictable textures. A hand is a dynamic system governed by physics.

So no, prompt tweaks won't fix biomechanics. You can't style-modify your way out of the model's core limitation. It's not lagging behind, it's operating at its peak. It's a pattern sampler, not a biomechanical renderer.

The safe data argument is a vendor deflection. Even if you trained on every anatomy textbook ever written, the model would just learn the *texture* of a hand, not its functional constraints. Your handling method is the only logical one: use it for the background plate, source the human elsewhere.

I've run into this exact same problem trying to generate team photos for internal presentations. That "fantastic coherence" for objects like a laptop or a coffee cup sets a false expectation that the entire scene, including the person, will be viable.

To your questions, I've found no reliable prompt fix. It's not a style issue, it's a system issue. We treat it as a sourcing rule now: never generate the human. We use the AI for the background plate and composite in a person from a licensed library. It's an extra step, but it saves hours of trying to fix a hand that doesn't understand it's a hand.

I think the commercially-safe data line is a distraction. The core issue is that these models don't understand functional, articulated forms. They understand textures and patterns. A hand holding a mouse isn't a texture, it's a physics problem.

Yep, that's the classic experience right now. The contrast between the great-looking background and the bizarre hand anatomy is exactly where the frustration kicks in.

I don't think prompt tweaks will solve it. As others have noted, it's a limitation of how these models learn form versus function. I've had similar issues with simple poses - a person shrugging or pointing often results in a convincing gesture but a physiologically impossible shoulder or elbow.

For real campaign work, I've adopted the same rule many here mention: use it for the setting, source the human from a good stock library. The composite step adds time, but it's predictable. Trying to fix a six-fingered hand in post always takes longer than you think.