Elanorya

Jewelry AI

Your jewelry image is still generating

A rising counter and no other signal looks like a stuck screen, and that appearance is not evidence of one. This page explains what the number is measured from, why there is no percentage, and why leaving the screen is safer than starting the job again.

What the number on the screen actually is

The wait screen shows one moving value: the time that has passed since the job was created. It is read from the clock, so it is true regardless of what the server is doing. That is also its limitation — it tells you how long you have been waiting and nothing about how far along the work is.

There is no percentage because there is nothing to compute one from. A percentage needs a known total and a verified position within it, and the screen has neither. What it has is a start time, so a start time is what it reports.

This is why a rising counter is not evidence of a problem. A slow job and a stopped screen look identical here, and the number is honest about not being able to distinguish them. What distinguishes them is elsewhere: the job continues on the server, and the Library is where you find out how it ended.

Why there is no progress bar

A staged progress list is written in the codebase — preparing, analysing the jewelry, creating the image, finalising — and it is never drawn on screen. That is not an unfinished feature. The reason sits next to it in the code: the server sends back no real sub-stage information, so there is nothing to drive those stages with except a local timer.

A local timer would work perfectly well as theatre. Stages would tick over, the screen would feel alive, and the impression of measured progress would be entirely manufactured. It would also mislead in exactly the moment it matters: a job that stalled would keep advancing through invented stages, and a job that was moving quickly would be held back to match a script.

So the app draws the one thing it can verify and declines the rest. If the screen ever does show a stage, it will be because the server started reporting one. Until then, the absence of a progress bar is the design working, not a piece missing from it.

The app waits longer than the server does

The client has a wait budget, and it was deliberately set to outlast the server-side ceiling. The reason is written down: an earlier, shorter budget was showing failure for jobs that were, at that moment, still being processed. Those were false reports, and the fix was to make the client the more patient of the two.

That decision spends your time in exchange for the meaning of a single message. Because the client gives up after the server would have, a failure shown on this screen is not the client running out of patience. It is an answer.

Which is what makes the two situations genuinely different in practice. While the counter is rising, the useful move is to leave. Once a failure is reported, the useful move is to run the job again — and that is the only point at which starting it again is the right instinct.

What to do while a generation is running

In order, from the moment the counter starts.

  • Read the number as elapsed time, not as position in a queue or percentage of work done.
  • Once the screen adds the line about busy periods, close the screen — the job continues without it.
  • Reopen the job from the Library rather than starting the piece again; reopening resumes polling on its own slower loop.
  • Do not run the same piece a second time while the first is still going, or you will be comparing outputs instead of checking one.
  • Treat a reported failure as real and run the job again — the client already waited past the point where the server would have stopped.
  • Check the finished image against the piece itself before it goes anywhere, because that check belongs after the wait, not during it.

What comes back when it finishes

What arrives is a finished image at a size fixed upstream. The wait screen offers no choice about that and neither does any other screen; a separate article covers why generated output size is set rather than selected, and why treating it as a setting leads people to look for a control that does not exist.

Waiting on the screen does not change what returns. The output is the same whether you watched it arrive or found it in the Library afterwards, so the only thing the wait screen decides is whether you were watching when the work finished.

What becomes relevant afterwards is covered properly elsewhere. Whether the piece itself survived the generation is a check you perform against the original, and there is a live report path in the app whose first listed reason is that the product changed — the vintage-seller page sets out what to look for. And if the job you ran was a background removal, what comes back in terms of format and transparency is that tool's own question, answered on its own page.

Waiting through a whole catalogue

The calculation changes when the wait is not for one image but for a set of them. Watching each job individually is the slowest possible way to produce a group, because the screen has nothing to add and the Library is where the results collect anyway.

There is a second reason to work in batches rather than one screen at a time. A catalogue page is judged as a comparison between images rather than as a series of individual pictures, which the Shopify catalogue page covers in full — and comparisons are easier to make when the images are side by side in the Library than when each one is inspected alone as it arrives.

What this page does not tell you

  • How long a generation takes. No duration appears here, because no measured figure is recorded for one. The screen reports elapsed time after the fact; it does not predict.
  • What the provider model is doing internally. What is described here is what the client draws, when it draws it, and how long it is prepared to wait — not what happens on the other side.
  • Anything about output quality. Preservation of the piece is instructed rather than guaranteed, and this page makes no promise about what the finished image will look like.
  • Controls that do not exist. There is no resolution, background or aspect selector to reach while a job runs, and nothing on this screen changes the output that is already being produced.
  • What to do with the image afterwards. Checking it against the piece, sizing it for a channel and keeping a set of images consistent each belong to their own pages.

Questions

Why is my jewelry image still generating?

Because the job is still running on the server, and from outside a slow job looks exactly like a stopped screen. The number you can see is real elapsed time since the job was created, so it rises whether the work is fast or slow. Once the screen adds the line about busy periods, the job is expected to take a while and it continues even if you close the app.

Does the job stop if I close the app or leave the screen?

No. The work belongs to the server rather than to the screen, so closing the screen cancels nothing. The job reappears in the Library, and reopening it there resumes polling on its own slower loop — which is why the app tells you to leave rather than to wait.

Should I retry if it is taking a long time?

Not while it is still running. A second attempt starts a second job: it does not cancel the first, does not speed it up and leaves you comparing two outputs of the same piece. The moment to run it again is when the screen reports a failure, and that report is worth trusting because the client's wait budget was deliberately set to outlast the server's own ceiling.

Why is there no progress bar or percentage?

Because there is nothing real to drive one with. A staged list is written in the codebase and deliberately never drawn, since the server returns no sub-stage signal — anything shown would be a local timer manufacturing the impression of stages completing. The app shows the value it can verify, which is time elapsed.