DEV Community: Barak Kedem

AI dating photos: a likeness review is not a beauty contest

Barak Kedem — Wed, 07 Oct 2026 16:53:30 +0000

A sharp, attractive generated portrait can still be the wrong photograph. The face may be plausible without being the person who supplied the reference photos.

I build CMeIn, an app for generating photos of yourself. Our upload flow checks normal photos against five poses and requires at least two poses before generation. That is an input constraint, not proof that the output preserves identity. The distinction matters when designing a review process for AI dating photos.

Here is a review rubric I would use before calling an output suitable. It is a proposed checklist, not a benchmark result or a claim that we have automated these checks.

Separate four questions

Is the image technically usable? Check focus, lighting, hands and obvious visual artifacts.
Does the face match the references? Compare face shape, hairline, nose, jaw and stable distinguishing features. Do not substitute attractiveness for similarity.
Does the wider body still represent the person? A matching face does not excuse an invented build or a changed apparent age.
Does the scene imply something untrue? A convincing mountain photo can still suggest an activity the person never does.

Those questions should not collapse into one score. A high score for image quality cannot compensate for a failed likeness check.

An illustrative review record

Imagine a generated cafe image with convincing light and a clean background, but a narrower jaw than either reference. The useful record is not "good image, 8/10." It is "technical quality: usable; likeness: reject; reason: jaw shape differs." That gives the reviewer a decision they can explain without pretending that a subjective rating is a scientific measure.

This example is hypothetical. I am not describing a customer or reporting a measured error rate.

Compare the same things

Put the reference and output side by side at similar face sizes. Compare more than one reference angle where possible. If the expression or camera angle makes a feature hard to judge, mark it uncertain rather than assuming success. A person who knows the subject can help, but their opinion is still a review, not a formal identity guarantee.

Do not measure success only by whether the image looks generated. "Could pass as a photograph" and "looks like the person" are different acceptance criteria.

Keep the failure useful

A rejection should say what needs attention: another source angle, clearer input, a different output, or using a real photograph instead. Adding more versions of the same front-facing input may not solve a missing-view problem.

The product context for this rubric is here: https://cmein.com/ai-dating-photos

The practical takeaway is simple: design the review so a beautiful wrong face can fail. Otherwise the process rewards polish while quietly dropping the requirement the user cared about.

This article was drafted with AI assistance.

Why we check five poses before generating an AI photo of you

Barak Kedem — Tue, 06 Oct 2026 17:10:59 +0000

If an AI photo does not look like you, the model usually did not have enough of your face to work from. This is a short note on one design decision in CMeIn, the AI photo app I build.

The problem

Generation from one image, or from several near-identical ones, gives the model a single view of a face. Everything else is guessed, and guesses drift. The result looks like a stranger wearing a bit of you.

The check

You upload two or more normal photos, not selfies. The app checks them against five poses: straight on, turned left, turned right, and the two profiles. It needs at least two covered before it generates anything. If poses are missing, it tells you before you spend credits.

Why it is a gate, not a suggestion

Telling users to "upload varied photos" does not work. Most uploads are three similar front-facing shots. Measuring the pose and reporting what is missing gives a clear action: add a photo from another angle.

Trade-offs

It adds friction before the first result.
It cannot guarantee likeness. It reduces one cause of drift.
It cannot fix poor source photos.

What comes after

You pick one of more than 4,500 scenes, or describe your own, and photos come back in minutes. CMeIn's stated aim is that the face stays yours, with no smoothing or reshaping. Check any result against your own photos.

https://cmein.com/

Blur image

Barak Kedem — Mon, 05 Oct 2026 03:04:20 +0000

Redacting an image properly: blur, pixelate or solid box

If you share screenshots, you need a redaction habit. Not all obscuring methods protect what you think they do.

Three modes, three guarantees. Blur softens an area. It is fine for a face in a crowd, but a light blur over text can sometimes be guessed. Pixelate replaces the area with large squares; at high strength it is better than blur for text and numbers. Solid covers the area with plain colour. Nothing of the original is left underneath, so use it for card numbers, addresses, documents and passwords.

What ends up in the file. In CMeIn's blur tool the downloaded file contains only the edited pixels. The original under a blurred or covered area is not hidden in the file as a layer, and hidden details such as the location the photo was taken are not carried over.

A checklist before you post a screenshot: use Solid for secrets; use Pixelate at high strength for names and numbers; check the preview at full size; and strip location metadata (done automatically here).

It runs in your browser: the image never leaves your device. JPG, PNG or WebP up to 30 MB. Free, no account.

https://cmein.com/blur-image

Photo Products: Why the Scene Matters as Much as the Face

Barak Kedem — Sat, 03 Oct 2026 19:55:07 +0000

Putting someone in front of a mountain is one problem. Making the image feel like a person doing something on that mountain is another.

That distinction is central to CMeIn, the AI photo product I run. It also raises a useful product-design question: when an image model can change almost anything, what should the product ask it to change?

Start with the person, then choose the scene

CMeIn generates photos from a user's reference images. The goal is to keep the person recognisable while changing the scene, rather than making a more polished but less accurate version of their face or body.

The user journey is straightforward: upload reference photos, choose a scene or describe one, generate an image, and download the result.

The reference-photo step is part of the product experience. The interface checks coverage of five face angles and asks for at least two before generation. Instead of leaving users to guess what to upload, it tells them which angles are missing.

The public catalogue currently describes more than 4,500 scenes. Examples range from a cafe table and a Sunday-morning kitchen to a mountain trail, a bar with friends, a work desk, a site visit, and a conference floor. Users can also describe a custom scene.

Variety matters, but the design question is not simply how many backgrounds are available. It is whether the situation helps someone express what they want the image to communicate.

A place is not the whole picture

On the CMeIn blog, we use "social composition" for a framework with two parts:

Social convention: the person is participating in a social situation where something is happening.
Social leadership: posture and the attention of others make that person the focus of the interaction.

For example, a hiking photo can show someone handing out trail mix while the group turns toward them. The mountain is the location. The action and the arrangement of people are the composition.

This is our product framing, not a scientific claim that a particular photo will increase dating matches.

There is also an important boundary: a generated image is not evidence that someone visited a location, attended an event, or has the friends shown in it. Keeping a face recognisable does not make an invented scene a real memory.

New scenes and targeted edits are different jobs

The blog describes "picturemaxxing" as adjusting posture and posing in an existing photo while aiming to keep the face, clothes, setting, and other people unchanged. The product also uses the name "Pose Maxing" for a feature.

The broader product lesson is that generating a new scene and correcting a pose need different expectations. One invites a new setting. The other asks for a limited change. An interface should help users understand that difference rather than hide both behind a generic Generate button.

The technology, at a high level

The stack includes AI, Java, React, Spring, Redis, and a database. Agile is part of the development approach, rather than a runtime component.

The point of listing the stack is to give context, not to turn this into an architecture walkthrough. The more useful question is how technology serves the experience: clear reference-photo guidance, meaningful scene choices, recognisable results, and control over sharing.

No particular Redis role, database engine, model version, or performance result is claimed here. Those details belong in a separate technical account when there is something specific to explain.

User control is a product capability

Generated photos are described as private by default. Users can download their results and optionally share selected images for feedback.

Creation and sharing are different decisions. Choosing to generate an image should not silently mean choosing to publish it.

CMeIn is available through the browser and iPhone and Android apps, with the same account, photos, and credit balance across them. That makes consistency part of the product promise: switching devices should not mean starting over.

The product outside the app

CMeIn's external social activity includes Facebook pages, Threads, Instagram, and YouTube. The content is comedic dating videos, not a technical tutorial series.

The videos and the product share a dating context, but the landing page still needs to explain the tool. Someone arriving from a joke should be able to understand what reference photos are for, what they can generate, and what remains under their control.

That is a useful handoff to evaluate. Video views, visits, signups, and completed generations are different stages, not interchangeable proof that the product works. I am not claiming channel results or conversion figures here.

The takeaway

An AI photo product needs more than a large scene catalogue and a list of technologies. It needs a clear answer to three questions: what can change, what should stay recognisable, and who decides where the result is shown?

Those questions connect the product experience to engineering without requiring every user to understand the infrastructure behind it.