ElanoryaJewelry AI
What actually leaves your phone when you submit a generation
Your photograph is not always sent as it sits on the phone. A file longer than 2048 px on its longest side is brought down to that bound, orientation is applied to the pixels and then stripped, and a file that is already upright and inside the bound is passed through untouched.
The file that leaves is not always the file you picked
Between the picker and the provider there is a step that measures your photograph and decides whether it needs rewriting. Two things are checked: how long the longest side is, and whether the image is already upright.
If the file is longer than 2048 px on its longest side, or if it carries an orientation that still has to be applied, it is rewritten before it goes out. If it is upright and already inside the bound, it is not rewritten at all — that case is passed through as it is.
So the thesis of this page is not that every submission is transformed. It is that two specific conditions decide whether yours is.
What the outgoing request carries
Each statement below is what the provider layer does on the way out, for the jewelry image and the model image alike.
- A bound of 2048 px on the longest side, applied to both images.
- The jewelry photograph and the model photograph are each bounded to 2048 px on the longest side before the request is assembled.
- The bound shrinks and never enlarges.
- The resize fits the image inside the bound without enlargement. A file below 2048 px on its longest side is left at the size it already is.
- Pixels above the bound are discarded before the request is sent.
- For a file larger than the bound, the detail above 2048 px on the longest side is not part of what goes out.
- EXIF orientation is applied to the pixels, then the tag is stripped.
- The rotation is baked into the image data and the orientation metadata is removed, so the pipeline corrects orientation rather than passing the problem downstream.
- An upright file inside the bound is passed through, not re-encoded.
- When the orientation value is 1 or lower and the longest side is within the bound, the fast path is kept and the file is sent as it is.
- A file that is rewritten is re-encoded as PNG.
- Files outside the fast-path case are encoded to PNG before being attached to the request.
A submission, from picker to provider
The order matters, because each step decides what the next one receives.
The image is measured against the bound
The longest side is compared with 2048 px. This is the same bound for the jewelry image and for the model image.
The orientation value is read
An image whose orientation value is 1 or lower is treated as already upright. Anything above that still has a rotation to apply.
Upright and inside the bound: nothing is rewritten
Both conditions together take the fast path. The file is not resized and not re-encoded; it is passed through as it is.
Otherwise the pixels are rotated and the tag removed
The rotation described by the EXIF orientation is applied to the image data, and the orientation metadata is stripped afterwards.
Otherwise the longest side is brought down to 2048 px
The resize fits inside the bound and does not enlarge, so this step can only make an image smaller.
The rewritten image is encoded as PNG and attached
PNG is the encoding used for a file that leaves the fast path. It is the format of the attachment, not the format of the reply.
The reply format and the retention field are set on the request
The response format is set to image/jpeg, and the body carries store:false as a request to the provider not to retain the interaction.
The outgoing request, field by field
Values as they appear in the provider layer.
| Field | Rule applied on the way out | Value |
|---|---|---|
| Longest side, jewelry image | Fitted inside the bound, never enlarged | 2048 px |
| Longest side, model image | Fitted inside the bound, never enlarged | 2048 px |
| EXIF orientation | Applied to the pixels, tag then stripped | Rewritten into the image data |
| Upright image inside the bound | Fast path kept, not re-encoded | Passed through |
| Image that leaves the fast path | Re-encoded before it is attached | PNG |
| Reply format | Requested from the provider | image/jpeg |
| Retention field | Sent as a request, compliance not audited | store:false |
| Provider runs per submission | Queued with a single attempt | 1 |
Manual placement travels as a sentence, not as coordinates
When you position the piece yourself, the figures do not reach the provider as parameters. They are written into an English sentence in the prompt.
The centre of the piece is expressed as a whole percentage from the left and from the top, the width of the piece as a whole percentage, and the rotation to one decimal place. The rounding happens before the sentence is written, so the sentence carries the rounded figures.
This is worth knowing because it sets the register of the instruction: placement is described to the model in words, along with everything else in the prompt.
What the reply is asked to be, and how many runs you get
The outgoing request also fixes the shape of the answer it wants back.
- The reply is requested as JPEG.
- The response format on the request is image/jpeg.
- An on-model result cannot carry transparency.
- That follows from the requested reply format. Sending a transparent PNG in does not bring transparency back out.
- One submission is one provider run.
- The queue job is added with a single attempt, so there is exactly one run at the provider for a submission.
- A retryable classification slows the queue rather than re-running your job.
- Rate-limit, server-side and network failures are classified as retryable, and a retry-after value is used to penalise the limiter. That throttles the queue; it does not repeat your run.
- Some outcomes are classified as not retryable.
- A safety block, a missing reply, and a reply that returns text where an image was expected are each classified as not retryable.
What the bound means for a jewelry photograph
The bound is not a quality judgement. It is a size decision made before the request leaves, and these are the cases where it changes what you should do.
You approve a chain or a pave setting at full size on the master file, but the request carries the bounded version.
Review at 2048 px on the longest side. When the original is larger, that is the size the outgoing image is fitted into.
You export small to save time and expect the pipeline to make up the difference.
It cannot. The resize never enlarges, so re-export from the original when you need more.
You rotate a photograph by hand before submitting because it once came back sideways.
Submit it as the phone shows it. The orientation is applied to the pixels and the tag is stripped in the same step.
You submit a transparent cut-out and plan a composite that relies on the transparency surviving.
Build the composite around an opaque result. The reply is requested as JPEG.
You treat store:false as a deletion guarantee when answering a client.
Describe it as what it is: a field in the request asking the provider not to retain the interaction, sent without any check that it was honoured.
An enlargement request is measured before it starts
Where a file is submitted for enlargement rather than for an on-model image, the outgoing step applies its own input bounds first.
A file whose shortest side is under 64 px is refused. A file above roughly 30 megapixels is stopped by decode-bomb protection. Between those, the longest side is first brought down to 1600 px, and the enlargement result is described in the pipeline as four times that, up to 6400 px.
So the input to an enlargement is bounded before the enlargement happens, in the same spirit as the 2048 px bound on an on-model submission.
What this page cannot settle
These are outside what the outgoing request layer establishes, so they are not claimed here.
- Whether the provider honours store:false. The request is sent; compliance is not audited.
- Which provider or model is behind the request in any given deployment, and how that model behaves internally.
- Whether any single instruction in the prompt is reflected in the returned image.
- Which tools are switched on in a given deployment.
- What the returned image measures. Nothing on this page settles the size or shape of the result.
- What a run costs, when credit is deducted, and what happens to it on failure.
- Which controls appear on screen in the app, and which file types are accepted before an upload begins.
Questions
Does the provider receive my photograph at full resolution?
Not when the file is longer than 2048 px on its longest side. In that case the longest side is brought down to the bound and the pixels above it are discarded before the request is sent. A file that is already upright and inside the bound is a different case: it is passed through unchanged.
Is every image re-encoded before it is sent?
No. An image whose orientation value is 1 or lower and whose longest side is already inside the bound takes the fast path and is not re-encoded. An image that falls outside that case is rewritten and encoded as PNG.
Will a small photograph be enlarged to reach 2048 px?
No. The resize fits the image inside the bound without enlargement, so it can only ever shrink an image. A file below the bound is sent at the size it already is.
Does store:false mean my image is deleted at the provider?
It means the outgoing body asks the provider not to retain the interaction. The code sends that field and does not check whether it was honoured, so the accurate statement is that the request is made, not that the retention is prevented.