ElanoryaJewelry AI
Using your own model photo instead of a catalogue model
Jewelry AI accepts a model photograph of your own in place of a catalogue model. The generation runs the same way on both paths, and neither path unlocks a setting the other lacks. The difference arrives later, in the job record: a catalogue model is written down as a choice, and your own photograph is not.
The decision is about later, not about the upload
Both inputs are accepted. Picking a catalogue model and uploading your own model photo produce the same kind of request, and neither one reveals a setting the other hides.
What separates them is what survives the run. A catalogue model is a choice the job can still name after the fact. Your own photograph is an input the job cannot name: the model field on the record stays empty, and the record holds no reference to the file you supplied.
So the question to answer before the run is not which input looks better in the moment. It is whether you will need this result again from the app itself, without going back to your own files to rebuild it.
What the job record keeps, and what it drops
The record is the part of the product that decides whether a generation can be repeated. It treats the two inputs differently.
- A catalogue generation can be run again from its job.
- The catalogue model is stored as a choice, so the record still describes the inputs a repeat run would need.
- An own-photo generation cannot be run again from its job.
- Nothing in the record points at the photograph, so a repeat has nothing to read. Producing that image again means starting a new generation and supplying the file again.
- The empty model field is the shape of the record, not a failure.
- The generation is recorded and the result is yours. The field that would name a model is simply blank, and blank cannot be resolved back into a photograph.
- Your own copy of the file is the only copy the workflow can rely on.
- If that file is deleted, renamed beyond recognition or replaced, the result made from it can no longer be reproduced through the app.
- Switching inputs does not switch behaviours.
- Placement stays anatomical and automatic, the category still names the body region, and the preservation clause is sent with the request either way.
How a run with your own model photo goes
The steps are the ordinary ones. Only the last step is specific to this path, and it is the one the app cannot do for you.
Choose the category before anything else
Ring, bracelet, necklace and earring are not labels on the result. The category is the part of the request that names the body region the piece is carried on and decides whether close framing is available at all.
Supply your photograph in place of a catalogue model
You are not restricted to the catalogue. The photograph you supply becomes the base the piece is carried on for that generation, and the run continues as it would otherwise.
The same instructions travel with the request
The preservation clause goes out with every generation: the piece is instructed not to be mirrored or duplicated, and openings, links and closures are instructed to remain as they are. An earring run additionally carries its single-and-pair instruction. These are instructions, not promises about the returned image.
The result comes back with nothing to tune
Output resolution is fixed by the product, and the interface presents no resolution, background or aspect-ratio selector. The proportions of the result follow from the base photograph rather than from a choice you make at this point.
Record the link between the file and the result yourself
This step has no equivalent on the catalogue path. Store the photograph next to the image it produced, under names that connect them, because the job will not carry that connection.
What comes back
The same answer holds for a catalogue run, except for the last row.
| Property | What you get |
|---|---|
| The file | A finished image of the piece carried on the photograph you supplied. It is a complete picture, not a cut-out. |
| Transparency | Not part of this path. A file with the background removed is what the background remover produces, and that is a separate tool. |
| Resolution | Fixed by the product. There is no resolution selector in the interface, and no background or aspect-ratio selector either. |
| Proportions | Inherited from the base photograph rather than chosen. When the proportions you have and the frame you need disagree, that becomes a crop-or-pad decision rather than a setting. |
| Reporting | A result you consider wrong can be reported from the result screen. The reasons offered cover product changes, stone count, metal colour, anatomy and third-party rights, among others. |
| The job record | A record of the generation with no reference to your photograph: the model field is empty, so the run cannot be repeated from it. |
What the own-photo path puts at risk
None of these risks are about how the image looks. They are about what you can still do a month after the run.
The source file is gone and the result becomes unrepeatable.
Archive the photograph with the result it produced, at the moment you accept the result rather than at the moment you notice it is missing.
A set mixes catalogue runs with own-photo runs.
Keep one set on one path. A set reads as a set when one thing changes between frames, and the base photograph is a thing.
You expected a close view the category does not offer.
Check the category before the run. Close framing exists for ring and bracelet; a necklace run names the neck and the upper chest, so it arrives wider.
Rights over the person in the photograph were never settled.
Decide who may appear in a listing before you supply the file. The report flow on a result includes a third-party rights reason, but it acts after publication decisions have already been made.
The same base photograph is reused until buyers recognise it before they recognise the piece.
Treat the base photograph as part of the listing's design, and keep a note of which listings already use it.
Before you commit to your own model photo
Answers that are cheap to give now and expensive to recover after the run.
- The file is stored somewhere you will still have access to it later, not only in the picker you uploaded it from.
- You know whether this image will ever need to be produced again from the app rather than from your own archive.
- The category you are about to run matches the body region the piece belongs on.
- The frame you need and the proportions of your photograph agree, or you have already decided which loss you will accept.
- Everyone visible in the frame has agreed to appear in a published listing.
- You have a place to record which result came from which photograph, since the job will not hold that link.
What this page does not cover
- How to make the photograph itself. Skin as a surface, pose as a setting that drifts, and what a body does between frames belong to the guide on photographing jewelry on a real hand.
- Cropping against padding as a comparison of proportions. That comparison is owned by its own guide and is not repeated here.
- How to build a variant set so that a buyer can compare options rather than photographs.
- How placement is derived and what to inspect on every returned image. That mechanism is documented where it lives, not here.
- What the provider model does internally with the photograph you supply.
- Editing an image you already have. That is a different tool with controls of its own, including preservation switches you can turn off.
- Anything that has not shipped. Nothing on this page describes a capability that is not currently in the product.
Questions
Should I use my own model photo or a catalogue one?
Both are accepted, so decide on repeatability rather than on convenience. A catalogue generation stores the model as a choice and can be run again from its job record; an own-photo generation cannot, because the record carries no reference to your file. Choose your own photograph when the specific subject matters more than being able to reproduce the image from inside the app, and choose the catalogue when the image may have to be produced again.
Can I repeat a generation that used my own model photo?
Not from the job. The model field on that record is empty and no reference to the photograph is kept, so there is nothing for a repeat to read. You can produce a comparable image by starting a new generation and supplying the same file again, which is why keeping the file matters.
Does the app keep the model photo I upload?
The job record does not. It records that a generation happened without naming the photograph that carried the piece. Whatever else happens around a file, the record you would repeat a run from holds no pointer to it, so treat your own copy as the one you rely on.
Does supplying my own photograph unlock any extra settings?
No. There is no resolution, background or aspect-ratio selector on either path, output resolution is fixed by the product, and placement still follows the category rather than anything you set. Uploading your own model photo changes the base the piece is carried on, not the controls available to you.