ElanoryaJewelry AI · Enhancement
What 4x enhancement does to the file you send
The multiplier is not applied to your file as you sent it. The longest side is brought down to 1600 px first, and only what survives that step is enlarged. The code comment defines the result as 4x, capped at about 6400 px.
Four times what the path kept, not four times what you sent
The multiplier attached to enhancement describes the last thing that happens to your file, not the first. Before it applies, the longest side of the input is brought down to 1600 px. Whatever was above that line is gone by the time anything is enlarged.
This is why the code describes the result of the step as 4x capped at about 6400 px: four times a longest side that has already been bounded at 1600 px. A photograph whose longest side arrives at 4000 px does not become 16000 px, and a photograph that arrives at 900 px has no way to reach the top of that range.
Read both figures as bounds the code sets. Neither is a measurement taken from a returned file, and neither is a size the product commits to handing back.
The three bounds the enhancement path applies to an input
Two of them can stop the request. The third does not stop it — it quietly changes what the multiplier is multiplying.
- Shortest side under 64 px: refused.
- The file does not enter the enhancement step. It is not enlarged to reach the floor, and nothing is reconstructed on its behalf.
- More than roughly 30 megapixels: stopped.
- Decode-bomb protection reads the total pixel count of the file. A file can be well within any single-side expectation and still be stopped here.
- Longest side above 1600 px: brought down to 1600 px.
- This one is silent. The request goes through, and the file that reaches the enlargement is smaller than the one you picked.
- The factor written in the code: 4x, capped at about 6400 px.
- It is stated in the enhancement provider as the definition of the step's output bound. Treat it as the ceiling the code sets, not as the size of the file you will receive.
The order the file is handled in
The order is the whole point. Each step below runs against the file as it stands after the previous one.
The shortest side is measured
If it is under 64 px the request ends here with a refusal. Nothing downstream sees the file.
The total pixel count is measured
Above roughly 30 megapixels the file is stopped by decode-bomb protection. This check reads the whole frame, not one side of it.
The longest side is brought down to 1600 px
This is the step most predictions miss. From this point on, the file in the pipeline is not the file you selected, and the pixels above 1600 px on the longest side are no longer available to any later step.
The enlargement is applied to the bounded file
The code comment defines this step's result as 4x, capped at about 6400 px. Both numbers describe the bound the code sets on the enlargement — not a reading taken from an output.
The bounds, as the code sets them
Every row below is a limit written into the enhancement path. None of them is a measurement of a returned file.
| Bound | Value in the code | What it does to your file |
|---|---|---|
| Shortest side | 64 px | Under this, the input is refused. It is not enlarged to reach the floor. |
| Total pixels | about 30 MP | Above this, decode-bomb protection stops the file before the enhancement step. |
| Longest side, before enlargement | 1600 px | Anything longer is brought down to 1600 px, and the multiplier applies from there. |
| The factor named in the code | 4x, capped at about 6400 px | How the code comment defines the step's output bound — not a measured or committed output size. |
Where the expectation goes wrong, and what to do instead
Each row is a prediction a seller can reasonably make from the multiplier alone, and the reason the file does not behave that way.
Planning a listing around four times your own longest side.
Base the estimate on 1600 px instead. The reduction happens before the enlargement, so your original longest side stops being the input to the multiplication.
Sending a tight crop of a stone, clasp or hallmark and expecting it to be brought up to a usable size.
Check the shortest side of the crop first. Under 64 px it is refused, so enhance the wider frame it came from and crop afterwards.
Sending the largest export available on the assumption that more input pixels can only help.
Export a smaller version. Above roughly 30 megapixels the file is stopped outright, and anything above 1600 px on the longest side would have been discarded regardless.
Treating about 6400 px as the delivered size of every enhanced image.
Treat it as the ceiling the code names and measure what you actually receive; a file bounded below 1600 px cannot reach it.
Before you send a file to enhancement
Four things to check on the file itself, in this order.
- The shortest side is 64 px or more — otherwise the input is refused rather than enlarged.
- The total pixel count is under roughly 30 megapixels, which is a check on the whole frame and not on one side.
- You have looked at the piece at 1600 px on its longest side, because that is the version the enlargement receives.
- Your size expectation comes from 1600 px, not from the longest side of the file you selected.
What this page does not settle
This page covers one path: what the enhancement step does to the size of an input. The following belong elsewhere.
- The file format of an enhanced result, and whether it can carry transparency. The bounds recorded for this path describe size, not encoding.
- How sharp or clean the enlarged file looks. Nothing here describes or promises output quality.
- Which image file types the app will accept in the first place — that decision is made before any of these bounds are read, and is settled on its own page.
- Why the model photograph is held to a different floor than the jewelry photograph, and which side that floor is measured on.
- What a run costs and when the charge lands.
- What happens to an image on the generation path, which has its own handling and is not described here.
Questions
If I send a 4000 px photograph, do I get 16000 px back?
No. The longest side is brought down to 1600 px before anything is enlarged, so the multiplier applies to 1600 px and not to your 4000 px. The code describes the result of that step as 4x capped at about 6400 px.
My photograph is very small. Will enhancement bring it up to a usable size?
If its shortest side is under 64 px, no — the input is refused at that check. It is not enlarged to reach the floor and nothing is reconstructed from it. Enhance a larger copy of the same photograph instead.
Why was my largest camera export refused?
Files above roughly 30 megapixels are stopped by decode-bomb protection, which reads the total pixel count rather than a single side. A smaller export of the same photograph passes that check, and loses nothing the enhancement step would have kept, since the longest side is bounded at 1600 px anyway.
Can I plan a marketplace listing around a file of about 6400 px?
Treat about 6400 px as the ceiling the code sets on that step, not as a size you will be handed. It is the definition written in the code, not a measurement of a returned file, and an image whose bounded longest side is below 1600 px cannot reach it. Measure the file you receive.