How to Deliver Fujifilm GFX 100MP Photos to Clients Without Lag

Every web gallery, ours included, has to decode an image in a browser before it can do anything with it. Browsers have a hard ceiling on how large an image they will decode, and a 100MP frame sits above it. That is the whole mechanism. The general case, including what medium format does to storage economics, is covered in the medium format proofing gallery guide. This page assumes you accept the constraint and want the GFX procedure.

Import the card into Lightroom Classic or Capture One and do the whole cull there, on your own machine, with the embedded previews. This is the cheapest step in the job and the one most often skipped.

A GFX shoot produces near-duplicates that look identical at thumbnail size and differ only in a detail nobody can judge on a phone. Cut them before the client sees them. What survives the cull is what you export. Nothing else goes anywhere near the upload.

If you shoot pixel-shift or multi-frame composites, flatten and finish those first. They are not proofing material. Proof the single frame that represents the setup and keep the composite in your own edit.

Export a downsized sRGB JPEG for proofing. Do not push a full-resolution file through a browser and hope. The proof exists to be judged on a laptop and a phone, and every setting below serves that.

Save that as a named export preset in your processor. GFX Proof, GFX Retouch, GFX Print. You will use the first one on every job and you should never have to think about it again.

If you publish from Lightroom Classic, the decision is already made for you. The clientgallery.io plugin is both an Export service and a Publish service, and it forces sRGB JPEG export settings rather than offering them. There is no dialog in which you can accidentally leave ProPhoto selected from the last retouch job. The setup is in publishing a gallery from Lightroom Classic.

Uploaded photos are compressed in your own browser into proof JPEGs before they are stored. That is what keeps the plan flat, and it is also the reason the export step above matters. A very large file handed to a browser can fail to decode, and when it does it is skipped with only a failure count to show for it. You get a number, not a diagnosis.

Say the other half of that plainly, because it is the reason the failure is yours to prevent. There is no file-size guard and no megapixel guard on the browser upload path. Nothing stops an oversized frame from being handed to the browser in the first place, so the export settings are the only place the problem gets caught.

Exporting a proofing JPEG first removes that failure mode entirely. If you ever see a failure count on a GFX job, the answer is almost always that a native-resolution file slipped into the batch.

Send the gallery link. The client marks what they want in the gallery, with likes, loves, colour labels and per-image comments. No login, no account, no software on their side.

Then pull the result back into your catalog rather than retyping it. Likes become 3 stars, loves become 5 stars and a flagged pick, and the client's colour labels become native Lightroom labels. Comments can optionally be written into the IPTC caption, which is off by default. The full behaviour is in getting client picks back into Lightroom.

This is the step that pays for the whole pipeline on a medium format job. You retouch only the frames that were chosen, at full resolution, from the original RAF files that never left your drives.

When the retouch is done, the full-resolution files go out as one ZIP per gallery that you upload yourself. It is a paid feature and it is enforced on the server. The client's download is logged and served from a short-lived signed link.

Be clear-eyed about the shape of it. A GFX ZIP is large, and the quota is a handoff window, not a library.

You get 100 GB of standing ZIPs across the whole account, counted across every gallery. On GFX work that is a handful of live deliveries at once, not a shelf. The working pattern is to upload the ZIP when the client is ready to collect, let the 3 days run, and re-upload later if they come back. Hosted galleries themselves never expire; only the ZIP does. Keep that distinction exact when you write the delivery email.

With you. clientgallery.io hosts JPEGs. It does not warehouse RAW files or master video, and it is not a backup for your camera originals.

That is a deliberate limit, not an oversight. Flat pricing on a medium format workload is only honest if the platform is not asked to store the biggest files you own. Your RAF library belongs on your own drives with your own offsite copy, the same as it did before you had a gallery.

If the client's actual requirement is that their retoucher can pull full-resolution files on demand for months, a 3-day handoff window is the wrong tool and you should not force it. That is a file transfer or cloud storage job. Use a product built for it for that leg, and use the gallery for what it is good at, which is the proofing round and the branded client-facing page.

Two other cases where you should stay where you are. A studio that lives inside a print lab and a CRM keeps Pixieset or Pic-Time. And a photographer whose clients genuinely need every frame at full resolution, permanently, needs a storage product, not a proofing product.

The plan is one price, and the ceilings below are abuse tripwires rather than pricing tiers. On a GFX job the photo count matters more than the byte count, because your proofs are small by the time they are stored.

If a campaign shoot runs past 1,000 frames, the upload tells you to split it into another gallery, and galleries are unlimited. On medium format work that is usually the right structure anyway, because a client choosing from a thousand GFX frames is a client who is not going to choose.