Jewelry AI

The app cannot get your photo: access, or the file itself

Two different things stop a photograph at this step, and the app reports them as two different things. Only one of them is yours to fix. And once an upload has begun, moving off the step does not undo it.

Two refusals that look alike, and are not

When a photograph will not go into a generation, there are two different reasons the app can give you, and it gives them separately. One says it does not have access to your photos. The other says the file you picked could not be read. They arrive at the same moment in the same place, which is why they get confused, and they call for opposite responses.

Access is a decision made outside the app, and only you can change it. The file is a decision about the thing you picked, and only a different file changes it. Nothing you do to the photograph helps with the first; nothing you do to a setting helps with the second.

The app keeps the two apart on purpose. In the photo step the handling splits three ways - access refused, file unreadable, photograph accepted - and the same split appears again in the source picker (photo-step.tsx:33, source-picker.tsx:286-294; source checked 2026-08-18).

What the app separates, and why it bothers

The distinction is not a wording accident. The reason is recorded next to the branch that makes it.

A refused photo permission is reported on its own.: It is not folded into a general failure message about the image (photo-step.tsx:33; source checked 2026-08-18).
A file the app could not read is reported as its own outcome.: It sits on a different branch of the same three-way split, which the source picker repeats (source-picker.tsx:286-294; source checked 2026-08-18).
The reason for keeping them apart is that only one of them is yours to fix.: The note in the step says that reporting a refused permission as an image that could not be processed would be misleading, because the resolution is with you (photo-step.tsx:33; source checked 2026-08-18).
So the message is also a statement about who acts next.: Access refused means the next move is on your device. File unreadable means the next move is a different file. There is no third party to wait for in either case.

Which outcome you have, and what to do with it

Four situations at this step, and the response each one calls for.

Situation	Choose	Why
The app says it does not have access to your photos.	Change the access on your device. Leave the photograph alone.	The app is not making a claim about the file. It is saying it never got to one, and the resolution sits with you (photo-step.tsx:33).
The app says the file you picked could not be read.	Pick a different file, or a different copy of the same photograph.	This is the other branch of the split. A permission change is not what unblocks it, because a permission problem would have been reported as one.
The photo went through and you moved to another step while it was still going up.	Go back to the step. Do not pick the file again.	For an uploaded source on that image step, the upload keeps running when the picker is taken away (create-wizard.tsx:584, store.tsx:1740-1741).
You picked an existing result from your library rather than uploading a file.	Do not expect that rule to be doing anything here.	There is nothing being uploaded, so there is nothing for it to hold open.

An upload is not tied to the step you started it on

The second question a blocked seller asks is whether stepping back loses the upload. It does not. Whether the step counts as complete is read from two things together: the flow being complete, and the upload being ready for that step (create-wizard.tsx:584). The upload itself is not held by the screen. The store note is explicit that it continues even if the picker is unmounted because the step changed (store.tsx:1740-1741; source checked 2026-08-18).

What this step hands forward, then, is an upload that carries on without the picker in front of it - and nothing wider than that. What the finished generation comes back as is decided after submission, and is not this page's subject.

The practical consequence is that re-picking the same file after you step away is not a safety measure. It starts a second upload of something that was already on its way.

Before you pick the photo again

Four checks, in this order.

Read the refusal: is it about access to your photos, or about the file you picked?
If it is access, change it on your device and do not touch the photograph.
If it is the file, pick a different file rather than a different setting.
If the photo was already going up and you only stepped away, go back to the step instead of picking the file a second time.

What this page does not settle

Each of these is a neighbouring subject, and each is answered somewhere other than here.

Which file formats the app accepts, and where that acceptance is decided - settled on the page about accepted files, and not repeated here.
The exact wording, location and steps of the photo permission on your device: that belongs to your operating system, and this page does not present those screens as verified product behaviour.
What happens after you submit - the wait, the job, and what the finished image comes back as.
How the library picker builds the list of results it offers you.
Whether an upload survives the app being closed. The behaviour described here covers leaving the picker step, and no further.

Questions

The app says it cannot access my photos. Is something wrong with my photograph?

No. That message is about access, not about the file, and the app deliberately keeps the two apart - a file it could not read is reported as its own separate outcome (photo-step.tsx:33; source checked 2026-08-18). Change the access on your device; the photograph is not what is blocking you.

If I go back a step, do I lose the upload I already started?

No. For an uploaded source on the image step it belongs to, the upload keeps running when the picker step is taken away (create-wizard.tsx:584, store.tsx:1740-1741). Return to the step rather than picking the same file again.

Does the upload survive if I close the app?

This page does not claim that. What is established is narrower: leaving the picker step does not cancel an upload that has already started. Closing the app is a different thing, and it is outside what is described here.

I chose an existing result from my library instead of uploading. Does the same rule apply?

It has nothing to apply to. That rule holds an upload open across a step change, and a library pick is not an upload. How the picker assembles the results it offers is a separate subject and is not covered here.